I have a 2.6 box doing IPSec and MASQUERADing that is borking up TCP
port numbers of .
/======IPSec ESP SA=====\
[box1]-----------[fw1]-------Internet-------[fw2]-----------[box2]
| / \ / \ |
.5 10.1.0.1 StaticRealIP DHCPRealIP 10.200.1.1 .22
fw1 = RHEL3 with latest official errata kernel (2.4+2.6ipsec)
fw2 = Debian Sarge with 2.6.5-2 kernel from unstable
IKE daemon is identical on both boxes -- current OpenSWAN CVS
fw1 is SNATing the internal 10.1.0.0/16 network
fw2 is MASQUERADing the internal 10.200.1.0/24 network
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
box2 sends a SYN packet to box1. It arrives OK at box1.
source TCP port 33763, destination TCP port 3389
So far so good.
box1 sends back a SYN/ACK with TCP source port 3389 destination 32834.
It leaves fw1 and arrives at fw2 on the external interface (eth0) and
gets decrypted OK and unmodified.
Here is the problem.
When the SYN/ACK packet leaves fw2 out eth1 towards box2 the TCP source
port has changed from the correct 3389 to the incorrect 1024. Box2
naturally sends back an ICMP error message--handshake never completes.
Packet capture details courtesy of tethereal...
arriving and being decrypted on the fw2 external interface (eth0):
0.078883 a.b.c.d -> w.x.y.z ESP ESP (SPI=0x3bb63b4f)
0.078883 10.1.0.5 -> 10.200.1.22 TCP 3389 > 32834 [SYN, ACK] Seq=0
Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
leaving the fw2 internal interface (eth1) now borked with the source
port changed to 1024:
/-- error here
0.229413 10.1.0.5 -> 10.200.1.22 TCP 1024 > 32834 [SYN, ACK] Seq=0
Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
If I flush the nat table on fw2 then the borkage disappears and the TCP
connection is properly established. The fw2 nat rule is simply this:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Another data point. TCP connections from fw2 itself into the remote
network are fine.
Dax Kelson
Guru Labs
Kernel bug. IPSec changes ip headers, but fails to say about this to
conntrack. More information
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215980
Patch at
http://bugs.debian.org/cgi-bin/bugreport.cgi/ipsec_conntrack.diff?bug=215980&msg=3&att=1
As a workaround insert rule exemting ipsec traffic from masquerade:
iptables -t nat -I POSTROUTING 1 -p esp -j ACCEPT
Dax Kelson wrote:
> I have a 2.6 box doing IPSec and MASQUERADing that is borking up TCP
> port numbers of .
>
> /======IPSec ESP SA=====\
> [box1]-----------[fw1]-------Internet-------[fw2]-----------[box2]
> | / \ / \ |
> .5 10.1.0.1 StaticRealIP DHCPRealIP 10.200.1.1 .22
>
>
> fw1 = RHEL3 with latest official errata kernel (2.4+2.6ipsec)
> fw2 = Debian Sarge with 2.6.5-2 kernel from unstable
>
> IKE daemon is identical on both boxes -- current OpenSWAN CVS
>
> fw1 is SNATing the internal 10.1.0.0/16 network
> fw2 is MASQUERADing the internal 10.200.1.0/24 network
>
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> box2 sends a SYN packet to box1. It arrives OK at box1.
>
> source TCP port 33763, destination TCP port 3389
>
> So far so good.
>
> box1 sends back a SYN/ACK with TCP source port 3389 destination 32834.
> It leaves fw1 and arrives at fw2 on the external interface (eth0) and
> gets decrypted OK and unmodified.
>
> Here is the problem.
>
> When the SYN/ACK packet leaves fw2 out eth1 towards box2 the TCP source
> port has changed from the correct 3389 to the incorrect 1024. Box2
> naturally sends back an ICMP error message--handshake never completes.
>
> Packet capture details courtesy of tethereal...
>
> arriving and being decrypted on the fw2 external interface (eth0):
>
> 0.078883 a.b.c.d -> w.x.y.z ESP ESP (SPI=0x3bb63b4f)
> 0.078883 10.1.0.5 -> 10.200.1.22 TCP 3389 > 32834 [SYN, ACK] Seq=0
> Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
>
> leaving the fw2 internal interface (eth1) now borked with the source
> port changed to 1024:
> /-- error here
> 0.229413 10.1.0.5 -> 10.200.1.22 TCP 1024 > 32834 [SYN, ACK] Seq=0
> Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
>
> If I flush the nat table on fw2 then the borkage disappears and the TCP
> connection is properly established. The fw2 nat rule is simply this:
>
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> Another data point. TCP connections from fw2 itself into the remote
> network are fine.
>
> Dax Kelson
> Guru Labs
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Aidas Kasparas
IT administrator
GM Consult Group, UAB
On Wed, 2004-04-28 at 00:55, Aidas Kasparas wrote:
> Kernel bug. IPSec changes ip headers, but fails to say about this to
> conntrack. More information
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215980
> Patch at
> http://bugs.debian.org/cgi-bin/bugreport.cgi/ipsec_conntrack.diff?bug=215980&msg=3&att=1
A 7 month old kernel bug with a patch. Is there any reason why this
hasn't been rolled into the Linus tree yet? Is the something
objectionable with the patch?
Dax Kelson
Guru Labs