From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Maass Subject: [solved] Re: Iptables / KAME IPSec problem: source port information lost Date: Sat, 13 Mar 2004 23:16:35 +0100 Sender: netfilter-admin@lists.netfilter.org Message-ID: <40538843.9050303@blinkenlichten.de> References: <404DB826.3000709@blinkenlichten.de> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <404DB826.3000709@blinkenlichten.de> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: netfilter@lists.netfilter.org Carsten Maass wrote: > 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 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 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 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.