Known issues with FreeS/WAN on a 2.6 kernel Claudia Schmeing
-------------------------------------------
This is an overview of known issues with FreeS/WAN on the 2.6 kernel codebase
(also 2.5.x), which includes native Linux IPsec code.
More information on the native IPsec code is available here:
http://lartc.org/howto/lartc.ipsec.html
Tools for use with that code are here:
http://ipsec-tools.sourceforge.net/
* As of FreeS/WAN 2.03, FreeS/WAN ships with some support for the 2.6 kernel
IPsec code. As of FreeS/WAN 2.05, more testing is required, but preliminary
results are positive.
Many thanks to Herbert Xu for the initial code patches.
* Use the most recent Linux FreeS/WAN 2.x release from ftp.xs4all.nl
to try our 2.6 kernel support.
* The installation procedure for use with 2.6 kernel IPsec is a little
different from a traditional FreeS/WAN installation. Please see
the latest doc/install.html, and CURRENT ISSUES, below.
* IPv6 support is partial. Please see CURRENT ISSUES, below.
* Please see the design and users' mailing lists
(http://www.freeswan.org/mail.html) for more detail and the latest reports.
DESIGN-RELATED ISSUES
* In 2.6, IPsec policies are detached from routing decisions. Because of this
design, Opportunistic Encryption on the local LAN is 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.
To communicate with this node, you must set a "clear" policy for it.
* Because 2.6 IPsec does not have KLIPS style ipsecN interfaces, you
cannot rely on the virtual interface to identify IPsec traffic, nor can
you directly filter packets on this interface. Instead, incoming 2.6
IPsec packets pass through regular (iptables) firewall rules on the external
interface both before and after decryption. By modifying FreeS/WAN's default
_updown script (/usr/local/lib/ipsec/_updown), you can insert firewall rules
based on IP address at FreeS/WAN start time.
CURRENT ISSUES
* Install/Setup issues:
* You cannot run native IPsec kernel code and KLIPS at the same time,
since there can be only one PF_KEY implementation running.
This means you cannot compile both into the kernel statically.
If both native IPsec kernel modules and KLIPS are available,
the kernel will use KLIPS. To switch to the native kernel modules, preload
them. To switch back to KLIPS, unload them and restart FreeS/WAN.
Do not try to load the KLIPS module (ipsec.o) when the native IPsec modules
(af_key/esp4/ah4) are loaded; you will have sudden death. The opposite
is not a problem. Reference:
http://lists.freeswan.org/pipermail/design/2003-December/msg00023.html
For the moment, users wishing to test FreeS/WAN with 2.6 will require
ipsec-tools' "setkey" program. Though FreeS/WAN's keying daemon, Pluto,
directly sets IPsec policy, setkey is currently required to reset kernel
SPD (Security Policy Database) states on Pluto restart. This should
be added to Pluto in a future release.
* State information is currently 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.
* IPv6 support
* is partial. While you may create an IPv6 connection using Pluto +
kernel native IPsec + FreeS/WAN's _updown scripts, FreeS/WAN's
configuration file parser does not yet support IPv6. See:
http://lists.freeswan.org/pipermail/design/2003-November/msg00012.html
http://lists.freeswan.org/pipermail/design/2003-November/msg00015.html
http://lists.freeswan.org/pipermail/design/2003-October/msg00030.html
* Running Opportunistic Encryption
* With FreeS/WAN + 2.6, connectivity to new hosts will immediately fail.
You may see:
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 also blocks the first query to any
DNS server. Pluto then installs a %pass (cleartext route) for your
destination IP before the %pass for your DNS server. The end result is
a rekey failure for OE connections. Workaround: add your DNS servers to
/etc/ipsec.d/policies/clear.
* Packets on all interfaces are considered for OE, including loopback. If
you're running OE with a local nameserver, you'll need to exempt
DNS traffic to localhost, or it will fail as described above.
Since localhost 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
* Other Issues
* IPComp with 2.6 native IPsec is insecure. 2.6 native IPsec puts an
extraneous IPIP header into IPComp packets, which defeats the
purpose of the compression and constitutes a security risk. The problem
is independent of the keying daemon used with the 2.6 code.
http://lists.freeswan.org/pipermail/design/2004-January/msg00011.html
http://lists.freeswan.org/pipermail/design/2003-December/msg00032.html
* There may be a problem determining path MTU which may affect Road Warriors.
More detail on the problem would be appreciated.
OLD ISSUES
None, yet.
RELATED DOCUMENTS
FreeS/WAN Install web page doc/install.html
FreeS/WAN Install guide INSTALL
FreeS/WAN mailing list posts, including:
http://lists.freeswan.org/archives/design/2003-September/msg00057.html
To sign up for our mailing lists, see http://www.freeswan.org/mail.html