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

