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.