my network layout looks like this: ----------------------------------
(Localnet A)---(Gateway A)==IPSec==(Gateway B)---(Localnet B)
where "==IPSec==" is a IPSec connection using the backport of the 2.6 KAME IPSec stack on a static 2.4.24 kernel in tunnel-mode. Both gateways are running Debian stable with racoon and the ipsec-tools coming from testing:
kernel-source-2.4.24 2.4.24-3 iptables 1.2.6a-5 ipsec-tools 0.2.2-8 racoon 0.2.2-8
My problem is: --------------
At some point in the filtering process, the information about the source ports of the incoming and decrypted packet gets lost, so that the clients on the localnet don't accept it as one of the established connection.
Here is some example: ---------------------
The tcpdump was taken on Gateway A, listening on all interfaces.
Client 192.168.3.4 on Localnet A tries to establish a http-connection to client 192.168.0.1 on Localnet B.
12:05:48.370984 192.168.3.4.35114 > 192.168.0.1.80: S 3186461765:3186461765(0) win 5840 <mss 1460,sackOK,timestamp 220395665 0,nop,wscale 0> (DF)
The initial packet...
12:05:48.372462 218.10.35.139 > 146.254.136.108: ESP(spi=0x0a6825be,seq=0xaf) (DF)
...gets correctly encrypted and sent out to Gateway B (146.254.136.108).
12:05:48.447361 146.254.136.108 > 218.10.35.139: ESP(spi=0x03e34241,seq=0xa5) (DF)
The encrypted response arrives at Gateway A (218.10.35.139).
12:05:48.447361 192.168.0.1.80 > 192.168.3.4.35114: S 969293027:969293027(0) ack 3186461766 win 5792 <mss 1460,sackOK,timestamp 2220996862 220395665,nop,wscale 0> (DF)
The packet gets decrypted, the source port is correct.
12:05:48.448584 192.168.0.1.1 > 192.168.3.4.35114: S 969293027:969293027(0) ack 3186461766 win 5792 <mss 1460,sackOK,timestamp 2220996862 220395665,nop,wscale 0> (DF)
And here the strange thing apperars: The packet is sent out with a source port of 1!
12:05:48.448816 192.168.3.4.35114 > 192.168.0.1.1: R 3186461766:3186461766(0) win 0 (DF)
As it comes from source port 1, the client does not recognize it as a packet which belongs to the established connection and rejects it.
12:05:48.449038 218.10.35.139 > 192.168.0.1: ESP(spi=0x0a6825be,seq=0xb0) (DF)
The reject gets encrypted, sent out over the tunnel and the game starts over again.
Portless connections like ping don't show this behavior and gets established correctly.
Even if it's not completely clear to me why: the offending rule was
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
It seems to do some kind of NATing to all traffic leaving the gateway. When i narrowed it down to only match traffic which comes out of the LAN it works like a charm:
$IPTABLES -t nat -A POSTROUTING -s 192.168.3.0/24 -o $INET_IFACE -j SNAT --to-source $INET_IP
Is this a bug?
Greetings, Carsten.
