NAT behind IPSEC GW working OK - please review patch

[Stephen Frost]

* Christophe Saout (christophe at saout.de) wrote:
> Am Sonntag, den 20.03.2005, 17:12 +0100 schrieb Patrick McHardy:
> > This is not correct, the reason why the packets are dropped
> > is most likely a missing forward policy. If this is not the
> > case, there must be a bug somewhere in nf_nat_decode_session4().
> 
> You were right. Actually it's working without the patch, I was just too
> stupid to allow forwarding in the other direction when I tested it the
> first time.
> 
> And there actually was a bug in my nf_nat_decode_session4 when using
> both SNAT and DNAT.
> 
> The updated version of ipsec-04-policy-checks.diff can be found at
> http://www.saout.de/misc/linux-2.6.12-rc1-ipsec-nat/
> 
> The patches are against linux-2.6.12-rc1, but the only change compared
> to linux-2.6.11 is ipsec-01-output-hooks.diff.

Using these patches (except w/ ipsec-01-output-hooks.diff from the prior
thread w/ 2.6.11 since the one from the URL above didn't patch cleanly)
I seem to still be having a problem with certain situations.  Hopefully
you all might be able to shed some light on it.  This is the situation:

IPSEC tunnels using strongswan for:
A <--> B
A <--> B/subnet *
subnet/A <--> B *
subnet/A <--> B/subnet

This all worked just fine under 2.6.10 w/ the 2.6.10 ipsec/netfilter
patches.  Using 2.6.11.6 the two *'d tunnels don't seem to be working.  
When trying to ping from A to B/subnet what I see happening is this:

Packet from A is encrypted using the appropriate tunnel going from 
A to B.  On B I see the packet going through the firewall rules I have
set up in iptables and see the appropriate response is generated and
according to tcpdump on B the return packet is encrypted and sent out
the correct B -> A tunnel.  I don't see that encrypted return packet 
on A though, again according to tcpdump.  I also see both the icmp 
return packet and the encrypted packet pass through the OUTPUT chain 
of B, which is what I'd expect.  I also don't see the encrypted or 
unencrypted return packet from B to A in the chains of netfilter 
on A (checked INPUT and nat/PREROUTING).

subnet/A and B/subnet are subnets on the localhost interface of the
associated machine using aliases, technically.  This didn't seem to
bother 2.6.10 at all and I wouldn't expect 2.6.11.6 to care but I wanted
to put that out there too in case it makes a difference.  I could test
w/ real interfaces if necessary but what I actually want working is with
them on localhost.  Additionally, I'm using Vserver 1.9.5 (which is why
I want things on localhost to work in this setup).  Again, worked fine
under 2.6.10 and wouldn't expect it to be a problem.

I understand that people using 2.6.11 have this working w/o the
netfilter patches (at least the A <--> B/subnet part, don't know if
they've tried it w/ using localhost but wouldn't expect that to make a
difference...)..

I've also tried disabling all the firewall rules on both systems and
still the same problem.  I'm probably going to try w/o the patches but
I'd really like to have them..

Any thoughts?

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/netfilter-devel/attachments/20050406/801939fa/attachment.bin