Update for 2.6 Kernel

The introduction of the linux 2.6 kernel has resulted in a new, native IPSEC implementation. There are a number of significant improvements from this, but there is also a problem which precludes using IPSEC and DHCP together.

This worked with the 2.4 kernel and FreeS/WAN implementation due to the creation of virtual network interfaces, namely ipsec<n> which allows the use of policy routing of outgoing IPSEC packets to bypass the tunnel, since DHCP clients appear to listen to the raw socket. The downside to this was that firewall rule starting was problematic as a single step operation, since the ipsec<n> interfaces did not exist until the tunnels were started, but this was after the real interface was enabled, and thus either a two step firewall start up was required, or there was a period of operation without any firewall rules between starting the network interfaces and starting the IPSEC tunnel.


There are two workarounds for this problem. The first is to give up DHCP in conjunction with IPSEC tunnels. This is what I have done. It's a pain in the rectum, but it works, and is reliable.

The other option is to use a very long lease period for the DHCP transaction. The first request comes before the IPSEC tunnel is started, and so will operate correctly. In an environment where wireless DHCP leases are only ever used for a fixed time, this method will work. But note that if any wireless device is operating long enough for the DHCP lease to expire, renewing it will fail, resulting in the device loosing connectivity through the access point.

Firewall Rules

The absence of the virtual ipsec<n> interface means that the firewall rules become just a little bit tricker. The solution I used is to place rules in the pre-routing table for the real interface (e.g. eth0) to mark the IPSEC packets. This tag persists through the IPSEC decoding, so when the packets hit the input or forward table, they will be so marked. Unmarked packets which are not IPSEC traffic should be rejected. Marked packets which are IPSEC traffic should be accepted, while non-IPSEC packets which are marked are regular traffic coming out of the IPSEC tunnel and should be filtered accordingly.

Work In Progress

This is still a work in progress (or perhaps more a thought-in-progress), and I'll post any ideas which help solve this inconvenience.

Version: $Revision: 1.2 $; Updated at 15:47 EST on Tue Apr 11, 2006
Copyright (C) 2002 - 2006, Lindsay Harris