strongSwan

h1. kernel-libipsec plugin

The _kernel-libipsec_ plugin provides an IPsec backend that works entirely in userland, using TUN devices and our own IPsec implementation _libipsec_ (source:src/libipsec).

Both other kernel interfaces, _kernel-netlink_ (the default) and _kernel-pfkey_, install IPsec SAs in the operating system's IPsec stack. This plugin provides an alternative, for instance, if the OS implementation does not support a required algorithm (e.g. AES-GCM on Mac OS X).

To enable the plugin, add

<pre>--enable-kernel-libipsec</pre> to the [[InstallationDocumentation|./configure options]].

A network kernel backend is still required, so either the _kernel-netlink_ or the _kernel-pfroute_ plugin has to be enabled too.

It is available since [[5.1.0]].

h2. Behavior

With the plugin enabled a TUN device is created on startup that will be used to handle cleartext traffic from and to the host. For each IPsec SA routes get installed that direct traffic to the TUN device, from there the plugin reads the cleartext packets and encrypts them via _libipsec_. The resulting ESP packets will be sent over the UDP sockets the daemon uses for IKE traffic, which is why *the plugin currently only works with UDP encapsulation (NAT-T) enabled*.  Encapsulated ESP packets that are received on the daemon's UDP socket are decrypted by _libipsec_ and then injected via TUN device. _libipsec_ can use all ciphers supported for IKE to encrypt and authenticate traffic. Note that _libipsec_ is not intended for scenarios with high amounts of traffic or high burst traffic. It is not optimized for performance and buffers each packet in memory. In combination with insufficient processor power, this will lead to a out of memory condition and a crash of charon or the whole device. See #964 for details.

On systems that use the _kernel-pfroute_ plugin ([[FreeBSD]], [[MacOSX|Mac OS X]]) a separate TUN device will be created for each [[VirtualIP|virtual IP]], on Linux this is not required.

h2. Configuration

The plugin is configured using the following [[strongswan.conf]] options.

|Key|Default|Description|

|charon.plugins.kernel-libipsec.allow_peer_ts|no|Allow that the remote traffic selector equals the IKE peer (see below for details)|

h2. Host-to-Host Tunnels

If the IKE peer is included in the remote traffic selector a separate route is installed that excepts such traffic from the route via TUN device to allow further IKE traffic between the peers (otherwise a routing loop would ensue). But if the remote traffic selector _equals_ the IKE peer this won't work anymore, therefore, such traffic selectors are not allowed by default.

Since version:5.1.1 it is possible to use such traffic selectors on newer Linux hosts by using _fwmarks_ with the _kernel-netlink_ and _socket-default_ plugins. The {{tc(libipsec/host2host-cert)}} test scenario demonstrates this.

The relevant options in the [[strongswan.conf]] file are as follows:

<pre>

charon {

    plugins {

        kernel-netlink {

            fwmark = !0x42

        }

        socket-default {

            fwmark = 0x42

        }

        kernel-libipsec {

            allow_peer_ts = yes

        }

    }

}

</pre>

The first option configures the routing rule for strongSwan's own routing table in such a way that the routes in that table will only apply to packets that *do not* feature the configured _fwmark_ (0x42 in the example above).

The second option forces an _fwmark_ of 0x42 on all packets sent by the IKE daemon. This includes IKE packets but also the UDP encapsulated ESP packets that are sent over that socket. Such traffic is now not affected by the routes (via TUN device) installed by strongSwan in its own routing table.

The third option finally enables negotiation of host-to-host tunnels.

To make the Linux kernel actually consider the routes as required the _net.ipv4.conf.all.rp_filter_ setting has to be set:

<pre>

# sysctl -w net.ipv4.conf.all.rp_filter=2

</pre>