Known issues with Openswan on a 2.6 kernel when using Opportunistic Encryption ------------------------------------------- The Openswan userland can now use either KLIPS/MAST or NETKEY as the kernel level IPsec stack. This is an overview of known issues with Openswan on the 2.6 kernel codebase which includes NETKEY (CONFIG_NET_KEY). DESIGN-RELATED ISSUES * In 2.6, IPsec policies are detached from routing decisions. Because of this design, Opportunistic Encryption on the local LAN will be possible with 2.6. One side effect: When contacting a node on the local LAN which is protected by gateway OE, you will get asymmetrical routing (one way through the gateway, one way direct), and IPsec will drop the return packets. CURRENT ISSUES * OE with the NETKEY stack is broken. You will notice errors like: pluto[11081]: %hold otherwise handled during DNS lookup for Opportunistic Initiation for 193.110.157.17 to 208.245.212.67 while your command that triggered the OE connection shows: connect: Resource temporarily unavailable * DPD restarts might cause packet loss (see previous item) * State information is not available to the user, eg. ipsec eroute, ipsec spi and ipsec look do not fully work. The exception: ipsec auto --status This will be fixed in a future release. * If you're running Opportunistic Encryption, connectivity to new hosts will immediately fail. You may receive a message similar to this: connect: Resource temporarily unavailable The reason for this lies in the kernel code. Fairly complex discussion: http://lists.freeswan.org/archives/design/2003-September/msg00073.html As of 2.6.9, this has not been fixed. [note: Herbert Xu told me in junary 2011, this was fixed in RHEL kernels] * This initial connectivity failure has an unintended side effect on DNS queries. This will result in a rekey failure for OE connections; a %pass will be installed for your destination IP before a %pass is re-instituted to your DNS server. As a workaround, please add your DNS servers to /etc/ipsec.d/policies/clear. * Packets on all interfaces are considered for OE, including loopback. If you are running a local nameserver, you'll still need to exempt localhost DNS traffic as per the previous point. Since this traffic has a source of 127.0.0.1/32, the "clear" policy group will not suffice; you'll need to add the following %passthrough conn to ipsec.conf: conn exclude-lo authby=never left=127.0.0.1 leftsubnet=127.0.0.0/8 right=127.0.0.2 rightsubnet=127.0.0.0/8 type=passthrough auto=route