Known issues with Openswan on a NETKEY IPsec stack based kernel --------------------------------------------------------------- The Openswan userland can now use either KLIPS or NETKEY as the kernel level IPsec stack. The option protostack= in config setup can be used to select an IPsec stack. This is an overview of known issues with Openswan using NETKEY (CONFIG_NET_KEY). * 2.6.18 (but not 2.6.18.1+) seems to fail for NETKEY in combination with NAT-Traversal. * 2.6.19 and 2.6.20 cause crashers with NAT-Traversal * pluto[709]: initiate on demand from 172.18.1.37:0 to 172.23.1.5:0 proto=0 state: fos_start because: acquire Netkey does not have %hold operations. It is a serious design bug that KAME also has. It also does not rate limit messages from the kernel to userspace. This means that each packet that wanted to go into a tunnel causes an acquire from the kernel to userspace. Each acquire that the keying daemon gets causes it to initiate a connection. We could rate limit them in some fashion, but we need to be cautious about doing that. Please file a bug with your supplier of your kernel. * The iproute2 (sometimes called iproute) package, as of version 2.6.8, contains XFRM support (ip xfrm), obsoleting the use of the 'setkey' command from the ipsec-tools package. If for some reason you cannot use iproute >= 2.6.8 on your kernel, you can still use the fallback method of using 'setkey' from the ipsec-tools package which is available at: http://ipsec-tools.sourceforge.net/ * 'ip xfrm state' has been reported hanging in uninterruptable sleep, causing Openswan to hang (eg during shutdown) * Openswan-2 ships with support for NETKEY. Many thanks to Herbert Xu for the initial code patches. * setkey doesn't like spaces in PSK's from ipsec.secrets. If you are on a recent distro with 'ip xfrm' support, or using KLIPS, this isn't a problem. * Use the most recent Linux Openswan-2 release from ftp.openswan.org to try our 2.6 kernel support. Currently, this is 2.3.1 DESIGN-RELATED ISSUES * WIth NETKEY, IPsec policies are detached from routing decisions. Because of this design, Opportunistic Encryption on the local LAN will be possible with NETKEY. 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. * With NETKEY, non-initial fragments might not be covered by an IPsec policy, and leak out in plaintext. CURRENT ISSUES * There are versioning problems with the current klips module on 2.6.9, kernel: ipsec: no version for "struct_module" found: kernel tainted. * 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) * There are crashers in xfrm_user in kernels < 2.6.3-rc1. These will happen after the connection goes up and down a few times in quick succession. [ There is currently a bug in the rekeying code that triggers this ] * starting with 2.6.9 NETKEY needs to have xfrm4_tunnel support. You might need to modprobe this on older Openswan versions. * SNAT and NETKEY behaviour changed around 2.6.16. The "-t nat -A POSTROUTING" rules on the IPsec gateway now match before the IPSEC routes. Thus, one needs to exclude packets from SNAT using -j ACCEPT rules. * State information is not available to the user, eg. ipsec eroute, ipsec spi and ipsec look do not fully work. Instead, use ip xfrm policy and ip xfrm state. The exception: ipsec auto --status. * 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.23, this has not been addressed. * 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 OLD ISSUES None, yet. RELATED DOCUMENTS Openswan Install page doc/install.html Openswan Install guide INSTALL Openswan and FreeS/WAN mailing list posts, including: http://lists.freeswan.org/archives/design/2003-September/msg00057.html http://lists.openswan.org/ To sign up for our mailing lists, see http://lists.openswan.org/