NAT behind IPSEC GW working OK - please review patch
sfrost at snowman.net
Wed Apr 6 17:04:40 CEST 2005
* 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
> 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 188.8.131.52 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 184.108.40.206 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
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..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/netfilter-devel/attachments/20050406/801939fa/attachment.bin
More information about the netfilter-devel