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