Debian Bug report logs - #215980
ipsec changes ip headers; fails to say about this to conntrack

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Aidas Kasparas <kaspar@gmc.lt>

To: <submit@bugs.debian.org>

Subject: ipsec changes ip headers; fails to say about this to conntrack

Date: Wed, 15 Oct 2003 20:29:50 +0300 (EEST)

[Message part 1 (text/plain, inline)]

Package: kernel-source-2.4.22
Version: 3


***SETUP***
where this miscommunication shows weird results:

[BoxA]-----[GwA]======[GwB]-----[BoxB]

Interfaces:
BoxA- eth0 192.168.0.2/24
GwA- eth0 192.168.0.254/24
GwA= eth1 Some public address, say PubA
GwB- eth0 192.168.1.254/24
GwB= eth1 Some public address, say PubB
BoxB- eth0 192.168.1.2/24

Tunnel between GwA and GwB -

192.168.0.0/24 192.168.1.0/24 -P out ipsec esp/tunnel/PubA-PubB/unique

and in other direction vice versa.

iptables @GwA empty +
-t nat -A POSTROUTING -o eth1 -j MASQUERADE

BoxA tries to telnet to BoxB:80. tcpdump @BoxA shows

BoxA.1025 -> BoxB.80 SYN
BoxB.1 -> BoxA.1025 ACK
BoxA.1025 -> BoxB.1 RST

tcpdump @GwB- shows normal answer of BoxB:
BoxB.80 -> BoxA.1025 ACK

ping between BoxA and BoxB is working fine.

If iptables rule with MASQUERADE is removed or rule like
POSTROUTING -o eth1 -p esp -j ACCEPT
is inserted before MASQ rule - communications between BoxA and BoxB
returns to normal.

Changing MASQUERADE to DNAT makes no difference.

OK. I agree, initialial configuration of iptables could be better. But I'm
ready to bet money, that I'm not the last one who will make configuration
like this. And I'm ready to bet big money that at least some of those who
will configure like I did, will have no idea what is causing that port-1
maddness and where to start trying to fix it [for me it took 5 days].

It is clear, that ipsec and masquerading do not play well together. I
failed to trace exact place in code which is responsible for storing 1
into source port's position. But I found that ipsec code changes packets
(and headers of them) in place and do not follow Rusty's
instructions
(http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-6.html)
that such modules should release skb->nfct when they
encapsulate/decapsulate packets.

I tried to add missing code for first of Rusty's requirement. Not sure
that code added at right/best place. But at least kernel with these
additions works on my test box. And port-1 madness is gone on that box no
matter how I play with MASQUERADE rules.

Code is added only to IPv4 part. Can try to add to ipv6 part also, given
my modifications to ipv4 part are ok.

Second of Rusty's requirements - encapsulated packets should go through
LOCAL_OUT hook. I did not managed to come up with code which does this.

I also checked kernel v2.6 code. Other tunnel drivers (ip_gre.c ipip.c)
still contain code for skb->nfct release and ipsec drivers do not.
Therefore I think it is very likely that 2.6 kernel version suffers from
this problem also.

[ipsec_conntrack.diff (text/plain, attachment)]

Message #10 received at 215980@bugs.debian.org (full text, mbox, reply):

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Aidas Kasparas <kaspar@gmc.lt>, 215980@bugs.debian.org

Subject: Re: Bug#215980: ipsec changes ip headers; fails to say about this to conntrack

Date: Sun, 2 Nov 2003 22:01:50 +1100

reassign 215980 kernel
tags 215980 forwarded
forwarded 215980 linux-kernel@vger.kernel.org
quit

On Wed, Oct 15, 2003 at 08:29:50PM +0300, Aidas Kasparas wrote:
> 
> Tunnel between GwA and GwB -
> 
> 192.168.0.0/24 192.168.1.0/24 -P out ipsec esp/tunnel/PubA-PubB/unique
> 
> and in other direction vice versa.
> 
> iptables @GwA empty +
> -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Yes, this is a known problem.  It is not clear what the solution to
SNAT over IPSEC is yet but rest assured that it is being worked on.

> BoxA tries to telnet to BoxB:80. tcpdump @BoxA shows
> 
> BoxB.1 -> BoxA.1025 ACK

This is really weird though, can you please show me the entire header?
(tcpdump -x)
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Message #23 received at 215980@bugs.debian.org (full text, mbox, reply):

From: Aidas Kasparas <a.kasparas@gmc.lt>

To: 215980@bugs.debian.org

Subject: Re: Bug#215980: ipsec changes ip headers; fails to say about this to conntrack

Date: Mon, 03 Nov 2003 22:14:31 +0200

Herbert Xu wrote:
>>BoxA tries to telnet to BoxB:80. tcpdump @BoxA shows
>>
>>BoxB.1 -> BoxA.1025 ACK
> 
> 
> This is really weird though, can you please show me the entire header?
> (tcpdump -x)

OK, here it goes.
GwA uses kernel-image-2.4.22-1-586tsc 2.4.22-3


**** tcpdump from BoxA ****

21:59:52.350060 172.17.2.10.33131 > 10.19.65.252.80: S 
3249808723:3249808723(0)
win 5840 <mss 1460,sackOK,timestamp 4923964 0,nop,wscale 0> (DF) [tos 0x10]
                         4510 003c 076f 4000 4006 3913 ac11 020a
                         0a13 41fc 816b 0050 c1b4 2553 0000 0000
                         a002 16d0 abc2 0000 0204 05b4 0402 080a
                         004b 223c 0000 0000 0103 0300
21:59:52.352793 10.19.65.252.1 > 172.17.2.10.33131: S 
990472689:990472689(0) ack
 3249808724 win 5792 <mss 1260,sackOK,timestamp 91120089 
4923964,nop,wscale 0>
                         4500 003c 0000 0000 3d06 8392 0a13 41fc
                         ac11 020a 0001 816b 3b09 69f1 c1b4 2554
                         a012 16a0 a0b6 0000 0204 04ec 0402 080a
                         056e 61d9 004b 223c 0103 0300
21:59:52.352812 172.17.2.10.33131 > 10.19.65.252.1: R 
3249808724:3249808724(0) w
in 0 (DF)
                         4500 0028 008a 4000 4006 401c ac11 020a
                         0a13 41fc 816b 0001 c1b4 2554 0000 0000
                         5004 0000 4d41 0000



*** tcpdump from GwB private interface ****
19:22:25.853514 172.17.2.10.33131 > 10.19.65.252.80: S 
3249808723:3249808723(0)
win 5840 <mss 1360,sackOK,timestamp 4923964[|tcp]> (DF) [tos 0x10]
                         4510 003c 076f 4000 3e06 3b13 ac11 020a
                         0a13 41fc 816b 0050 c1b4 2553 0000 0000
                         a002 16d0 ac26 0000 0204 0550 0402 080a
                         004b 223c 0000
19:22:25.854669 10.19.65.252.80 > 172.17.2.10.33131: S 
990472689:990472689(0) ac
k 3249808724 win 5792 <mss 1460,sackOK,timestamp 91120089[|tcp]>
                         4500 003c 0000 0000 3f06 8192 0a13 41fc
                         ac11 020a 0050 816b 3b09 69f1 c1b4 2554
                         a012 16a0 9f9f 0000 0204 05b4 0402 080a
                         056e 61d9 004b

Yes, times are not sinchronized but dumps are for the same connection. 
And policies are 10.0.0.0/8 any 172.17.2.0/24 any esp/tunnel/Gws/unique.

-- 
Aidas Kasparas
IT administrator
GM Consult Group, UAB

Send a report that this bug log contains spam.