strongSwan

h1. Route-based VPNs

{{>toc}}

Generally IPsec processing is based on policies. After regular route lookups are done the OS kernel consults its SPD(Security Policy Database) for a matching policy and if one is found that is associated with an IPsec SA(Security Association) the packet is processed (e.g. encrypted and sent as ESP packet). Refer to [[IPsecDocumentation]] for details.

Depending on the operating system it is also possible to configure route-based VPNs. Here IPsec processing does not (only) depend on negotiated policies but may e.g. be controlled by routing packets to a specific interface.

Most of these approaches also allow easy capture of plaintext traffic, which, depending on the operating system, might not be that straight-forward with policy-based VPNs (see [[CorrectTrafficDump]]). Another advantage this approach could have is that the MTU can be specified for the tunneling devices allowing to fragment packets before tunneling them in case PMTUD does not work properly.

h2. VTI Devices on Linux

_*Disclaimer:* VTI devices are supported since the Linux 3.6 kernel, but some important changes were added later (3.15+). The information below might not be accurate for older kernel versions._

VTI devices act like a wrapper around existing IPsec policies. This means you can't just route arbitrary packets to a VTI device to get them tunneled, the established IPsec policies have to match too. However, you can negotiate _0.0.0.0/0_ traffic selectors on both ends to allow tunneling anything that's routed via VTI device.

To make this work, that is, to prevent packets not routed via VTI device from matching the policies (if _0.0.0.0/0_ is used every packet would match) marks are used. Only packets that are marked accordingly will match the policies and get tunneled, for other packets the policies are ignored. Whenever a packet is routed to a VTI device it automatically gets the configured mark applied so it will match the policy and get tunneled.

It's important to note that VTI tunnel devices are a local feature, no additional encapsulation (like with GRE, see below) is added, so the other end does not have to be aware that VTI devices are used in addition to regular IPsec policies.

A VTI device may be created with the following command:

<pre>

ip tunnel add <name> local <local IP> remote <remote IP> mode vti key <number equaling the mark>

</pre>

_<name>_ can be any valid device name (e.g. _ipsec0_, _vti0_ etc.). But note that the @ip@ command treats names starting with _vti_ special in some instances (e.g. when retrieving device statistics). The IPs are the endpoints of the IPsec tunnel. The number at the end has to match the mark configured for the connection. It is also possible to configure different marks for in- and outbound traffic using _ikey/okey <mark>_, but that is usually not required.

After creating the device it has to be enabled (@ip link set <name> up@) and then routes may be installed (routing protocols may also be used).  To avoid duplicate policy lookups it is also recommended to set @sysctl -w net.ipv4.conf.<name>.disable_policy=1@. All of this also works for IPv6.

{{collapse(Examples)

<pre>

ip tunnel add vti0   local 192.168.0.1 remote 192.168.0.2 mode vti key 42

ip tunnel add ipsec0 local 192.168.0.1 remote 192.168.0.2 mode vti key 0x01000201

sysctl -w net.ipv4.conf.vti0.disable_policy=1

ip link set vti0 up

ip route add 10.1.0.0/16 dev vti0

sysctl -w net.ipv4.conf.ipsec0.disable_policy=1

ip link set ipsec0 up

ip route add 10.2.0.0/16 dev ipsec0

ip route add 10.3.0.0/16 dev ipsec0

</pre>

}}

Statistics on VTI devices may be displayed with @ip -s tunnel show [<name>]@. Note that specifying a name will not show any statistics if the device name starts with _vti_.

A VTI device may be removed again with @ip tunnel del <name>@.

h3. Configuration

*First, the route installation by the IKE daemon must be disabled. To do this, set _charon.install_routes = 0_ in [[strongswan.conf]].*

Then configure a regular site-to-site connection either with the traffic selectors set to _0.0.0.0/0_ on both ends (_local|remote_ts=0.0.0.0.0/0_ in [[swanctl.conf]] or _left|rightsubnet=0.0.0.0/0_ in [[ipsec.conf]]) or set to specific subnets. As mentioned above, only traffic that matches these traffic selectors will then actually be forwarded, other packets will be rejected with an ICMP error message (_destination unreachable/destination host unreachable_).

The most important configuration option is the mark (_mark_in|out_ in [[swanctl.conf]], _mark_ in [[ipsec.conf]]). After applying the optional mask (default is _0xffffffff_) to the mark set on the VTI device, and applied by it to the routed packets, the value has to match the configured mark.

So referring to the example above, to match the mark on _vti0_ configure _mark_in_ = _mark_out_ = _42_ and to match the mark on _ipsec0_ set the value to _0x01000201_ (but something like _0x00000001/0x0000000f_ would also work).

h3. Sharing VTI Devices

VTI devices may be shared by multiple IPsec SAs (e.g. in roadwarrior scenarios, to capture traffic or lower the MTU) by setting the remote endpoint of the VTI device to 0.0.0.0. For instance:

<pre>

ip tunnel add ipsec0 local 192.168.0.1 remote 0.0.0.0 mode vti key 42

</pre>

Then assuming [[VirtualIP|virtual IPs]] for roadwarriors are assigned from the _10.0.1.0/24_ subnet a matching route may be installed with @ip route add 10.0.1.0/24 dev ipsec0@.

h3. Connection-specific VTI Devices

With a custom [[updown]] script it is also possible to setup connection-specific VTI devices.

For instance, to create a VTI device on a roadwarrrior client that receives a [[VirtualIP|dynamic virtual IP]] (courtesy of Endre Szabó):

This does not work when two roadwarriors are connected from the same IP. The kernel rejects the creation of a VTI where

the remote and local addresses of the VTI are already in use by another VTI.

{{collapse(Example script for RWs)

<pre>

#!/bin/bash

# set charon.install_virtual_ip = no to prevent the daemon from also installing the VIP

set -o nounset

set -o errexit

VTI_IF="vti${PLUTO_UNIQUEID}"

case "${PLUTO_VERB}" in

    up-client)

        ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti \

            key "${PLUTO_MARK_OUT%%/*}"

        ip link set "${VTI_IF}" up

        ip addr add "${PLUTO_MY_SOURCEIP}" dev "${VTI_IF}"

        ip route add "${PLUTO_PEER_CLIENT}" dev "${VTI_IF}"

        sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1"

        ;;

    down-client)

        ip tunnel del "${VTI_IF}"

        ;;

esac

</pre>

}}

In the following script, it is assumed that only the RW's assigned IPv4 VIP is supposed to be reachable over the assigned tunnel.

{{collapse(Example script for GWs)

<pre>

#!/bin/bash

# set charon.install_virtual_ip = no to prevent the daemon from also installing the VIP

set -o nounset

set -o errexit

VTI_IF="vti${PLUTO_UNIQUEID}"

VTI_IF="vti${PLUTO_UNIQUEID}" 

case "${PLUTO_VERB}" in

    up-client)

        ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti \

            key "${PLUTO_MARK_OUT%%/*}" 

        ip link set "${VTI_IF}" up

        ip route add "${PLUTO_PEER_SOURCEIP}" dev "${VTI_IF}" 

        sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1" 

        ;;

    down-client)

        ip tunnel del "${VTI_IF}" 

        ;;

esac

</pre>

}}

If there is more than one subnet in the remote traffic selector this might cause conflicts as the _updown_ script will be called for each combination of local and remote subnet.

h2. Marks on Linux

One of the core features of VTI devices, dynamically specifying which traffic to tunnel, can actually be replicated directly with marks and firewall rules. By configuring connections with marks and then selectively marking packets directly with Netfilter rules via @MARK@ target in the @PREROUTING@ or @FORWARD@ only specific traffic will get tunneled.

This may also be used to create multiple identical tunnels for which firewall rules  dynamically decide which traffic is tunneled though which IPsec SA (e.g. for {{tc(ikev2/net2net-psk-dscp, QoS/DiffServ)}}).

h2. GRE

An alternative to VTI devices is using GRE(Generic Routing Encapsulation), which is a generic point-to-point tunneling protocol that adds an additional encapsulation layer (at least 4 bytes).  But it provides a portable way of creating route-based VPNs (running a routing protocol on-top is also easy).

While VTI devices depend on site-to-site IPsec connections in tunnel mode, GRE uses a host-to-host connection that can also be run in transport mode (avoiding additional overhead). But while VTI devices may be used by only one of the hosts, GRE must be used by both of them.

Creating a GRE tunnel on Linux can be done as follows:

<pre>

ip tunnel add <name> local <local IP> remote <remote IP> mode gre

</pre>

<name> can be any valid interface name (e.g. _ipsec0_, _gre0_ etc.). But note that the @ip@ command treats names starting with _gre_ special in some instances (e.g. when retrieving device statistics). The IPs are the endpoints of the IPsec tunnel.

After creating the device it has to be enabled (@ip link set <name> up@) and then routes may be installed.

{{collapse(Example)

<pre>

ip tunnel add ipsec0 local 192.168.0.1 remote 192.168.0.2 mode gre

ip link set ipsec0 up

ip route add 10.1.0.0/16 dev ipsec0

ip route add 10.2.0.0/16 dev ipsec0

</pre>

}}

Statistics on GRE devices may be displayed with @ip -s tunnel show [<name>]@. Note that specifying a name will not show any statistics if the device name starts with _gre_.

A GRE device may be removed again with @ip tunnel del <name>@.

h3. Configuration

As mentioned above, a host-to-host IPsec connection in transport mode can be used. The traffic selectors may even be limited to just the GRE protocol (_local|remote_ts=dynamic[gre]_ in [[swanctl.conf]] or _left|rightsubnet=%dynamic[gre]_ in [[ipsec.conf]]).

h2. libipsec And TUN Devices

Based on our own userland IPsec implementation and the [[kernel-libipsec]] plugin it is possible to create route-based VPNs with TUN devices. Similar to VTI devices the negotiated IPsec policies have to match the traffic routed via TUN device.

In particular because packets have to be copied between kernel and userland it is not as efficient as the solutions above (also read the notes on [[kernel-libipsec]]).

h2. Problems

Make sure to disable the [[connmark]] plugin when running the VTI. Otherwise, it will insert iptables rules into the @*mangle@ table that prevent the VTI from working.