Re: Iptables / KAME IPSec problem: source port information lost

[Alexander Samad <alex@samad.com.au>]

[-- Attachment #1: Type: text/plain, Size: 3440 bytes --]

On Tue, Mar 09, 2004 at 01:27:18PM +0100, Carsten Maass wrote:
> Dear List,
> 
> 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)

Sorry but isnt this the Sync/Ack packat in response to the sync above

> 
> 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)

Isn't this the same packet above but looks NAT'd ? Not sure why it is
coming from port 1 though.

> 
> 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.
> 
> So my questions are:
> --------------------
> 
> I this an iptables problem or IPSec related?
> Can you think of any iptables rules, which causes this behavior?
> Do you know how to explore this problem further?
> Do you have any other hints?
> 
> 
> I hope i was able to make the problem clear. Please tell me if you need 
> more information. As i have no clue how to go on with this problem, any 
> help would be highly appreciated.
> 
> Thanks for your time and patience,
> Carsten.
> 
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]