kernel-libipsec plugin » History » Version 7

Noel Kuntze, 17.02.2016 01:42

1 1 Tobias Brunner
h1. kernel-libipsec plugin
2 1 Tobias Brunner
3 1 Tobias Brunner
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).
4 1 Tobias Brunner
5 6 Tobias Brunner
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). However, it generally performs worse than the OS kernel's IPsec stack. In particular, when handling lots of SAs and/or lots of traffic, so it is **not recommended to be used on security gateways**.
6 1 Tobias Brunner
7 1 Tobias Brunner
To enable the plugin, add
8 1 Tobias Brunner
<pre>--enable-kernel-libipsec</pre> to the [[InstallationDocumentation|./configure options]].
9 1 Tobias Brunner
10 2 Tobias Brunner
11 2 Tobias Brunner
A network kernel backend is still required, so either the _kernel-netlink_ or the _kernel-pfroute_ plugin has to be enabled too.
12 2 Tobias Brunner
13 1 Tobias Brunner
It is available since [[5.1.0]].
14 1 Tobias Brunner
15 1 Tobias Brunner
h2. Behavior
16 1 Tobias Brunner
17 6 Tobias Brunner
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.
18 6 Tobias Brunner
19 6 Tobias Brunner
**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. SA and policy lookups are also not particularly optimized. See #964 for details.
20 1 Tobias Brunner
21 1 Tobias Brunner
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.
22 3 Tobias Brunner
23 3 Tobias Brunner
h2. Configuration
24 3 Tobias Brunner
25 3 Tobias Brunner
The plugin is configured using the following [[strongswan.conf]] options.
26 3 Tobias Brunner
27 3 Tobias Brunner
28 3 Tobias Brunner
|charon.plugins.kernel-libipsec.allow_peer_ts|no|Allow that the remote traffic selector equals the IKE peer (see below for details)|
29 3 Tobias Brunner
30 3 Tobias Brunner
h2. Host-to-Host Tunnels
31 3 Tobias Brunner
32 3 Tobias Brunner
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.
33 3 Tobias Brunner
34 3 Tobias Brunner
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.
35 3 Tobias Brunner
36 3 Tobias Brunner
The relevant options in the [[strongswan.conf]] file are as follows:
37 3 Tobias Brunner
38 3 Tobias Brunner
charon {
39 3 Tobias Brunner
    plugins {
40 3 Tobias Brunner
        kernel-netlink {
41 3 Tobias Brunner
            fwmark = !0x42
42 3 Tobias Brunner
43 3 Tobias Brunner
        socket-default {
44 3 Tobias Brunner
            fwmark = 0x42
45 3 Tobias Brunner
46 3 Tobias Brunner
        kernel-libipsec {
47 3 Tobias Brunner
            allow_peer_ts = yes
48 3 Tobias Brunner
49 3 Tobias Brunner
50 3 Tobias Brunner
51 3 Tobias Brunner
52 3 Tobias Brunner
53 3 Tobias Brunner
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).
54 3 Tobias Brunner
55 3 Tobias Brunner
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.
56 3 Tobias Brunner
57 3 Tobias Brunner
The third option finally enables negotiation of host-to-host tunnels.
58 4 Tobias Brunner
59 4 Tobias Brunner
To make the Linux kernel actually consider the routes as required the _net.ipv4.conf.all.rp_filter_ setting has to be set:
60 4 Tobias Brunner
61 4 Tobias Brunner
62 4 Tobias Brunner
# sysctl -w net.ipv4.conf.all.rp_filter=2
63 4 Tobias Brunner
64 7 Noel Kuntze
65 7 Noel Kuntze
Read the "documentation": about this settings to understand the impact.
66 7 Noel Kuntze
It basically disables the rp_filter. You possibly need to alter your local firewall rules to plug a hole caused by changing the setting.