Known issues with Openswan on a 2.6 kernel                   

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

* 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 ]

* compression seems to be incompatible between KLIPS and the 2.6 ipsec code.
  Since we believe the 2.6 ipsec code is wrong, we cannot fix this. If you
  get a successful IKE negotiation and can send ESP packets, but never get
  replies, compile KLIPS without CONFIG_IPSEC_IPCOMP. There is currently no
  runtime switch to disable compression. Note that setting compress=no is not
  enough; it just means we do not announce compression, but we'll still do it
  if the other end requests it.

* Using SNAT and the 2.6 ipsec code apparently doesn't go well together.
  Reported by Alexander Samad. Known issue for the netfilter team. DNAT
  works as usual, meaning you have to exlude DNAT'ing packets meant for
  a tunnel.

* For the moment, users wishing to test Openswan with 2.6 will require
  ipsec-tools' "setkey" program. Though Openswan's keying daemon, Pluto,
  directly sets IPsec policy, setkey is currently required to reset kernel SPD 
  (Security Policy Database) states when Pluto restarts. We will likely add 
  this basic functionality to an upcoming Openswan release.

* State information is not available to the user, eg. ipsec 
  eroute/ipsec spi/ipsec look do not 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.0-test6, this has not been fixed.

* 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're 
  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