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.