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
(including 2.4 backports and 2.5.x), which features 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/


* Use the most recent Linux FreeS/WAN 2.x release from ftp.xs4all.nl
  to try our 2.6 kernel support.

* As of FreeS/WAN 2.03, FreeS/WAN ships with some support for the 2.6 kernel
  IPsec code. Many thanks to Herbert Xu for the initial code patches.
  FreeS/WAN 2.06 is the first release with a KLIPS port for the 2.6 
  environment.

* 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


