I upgraded my home gateway firewall to Edgy today in the hope of fixing some SATA problems I’ve been experiencing. The new Edgy kernel might help – we’ll see.
Anyway, it went pretty well. Two runs (?) of apt-get dist-upgrade -u, a reboot and there I was.
Unfortunately I had two problems with my Openswan IPSEC VPNs. I’m not so sure if these count as bugs. I’ll be investigating further and reporting if so. Anyway, techie details follow…
Firstly, whilst my Openswan IPSEC tunnels seemed to initiate fine no ipsec-bound traffic even gets routed. This was fixed by adding a rightnexthop=%defaultroute to my ipsec configs. Previously I’d had no rightnexthop setting, so this seems to be a change in some defaults somewhere (this took a little while to figure out, lots of systematic troubleshooting).
Secondly, I had a MTU problem over the tunnel mode ipsec VPNs. Any large packets were dropped. Now PMTU should sort this kind of problem out and that uses the “fragmentation needed” ICMP messages.
Sniffing around with tethereal (yes, I very quickly added a bash alias to point tethereal at the now renamed tshark) I noticed that the ICMP packets were malformed. Rather than being sent to the client machine, they were addresses to the NAT address of my gateway.
Now rememeber, I’ve not changed any firewall rules – this might suggest that either the new kernel has an ipsec/deNATing bug, or it had one before which is now fixed :) So to clarify: my client sent a packet too big for the VPN which was NATed as it went over it and the generated “fragment needed” ICMP message that would sort everything out ended up being addressed to the NAT address, rather than the client address.
Well I don’t actually want NATing applied to my tunnelled ipsec packets, so I just added a new POSTROUTING Netfilter rule above the NAT rule accepting any packets that match an ipsec policy:
iptables -t nat -A POSTROUTING -s my.home.net/24 -m policy --dir out --pol ipsec -j ACCEPT iptables -t nat -A POSTROUTING -s my.home.net/24 -o inet -j MASQUERADE
I think this might be a Netfilter stack NAT bug actually.
Comments
Hi,
This is regarding the DNAT’ing bug you’ve been talking about.
I came across a similar issue when IPSec and DNAT being used on the same peer. This applies only to kernel version below 2.6.16 and works well for kernel 2.6.18.
Observation:For example if I try to use Transparent Proxy using some DNAT..I find a new ESP packet originated from the translated IP(DNAT) towards the far end IPsec peer(Unintended behavior).
This results in integrity check failure thus failed Transparent Proxy behavior.
Any comments,suggestions and workarounds are welcome.
Thanks,
Santhish.