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
