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/
