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/


