Site-to-Site VPN Using strongSwan (and a few Observations for Supported Capabilities)

To perform IPsec related tests, of course we need to establish our own lab. The simplest way is to set-up a virtual lab by using Linux systems.

In my case I used VirtualBox, and Fedora.

Fedora provides in its own repositories two options: Racoon2 and strongSwan.

Racoon2 provides an implementation of key management system for IPsec. It supports IKEv1, IKEv2, and KINK protocols. It works on FreeBSD, NetBSD, Linux, and Mac OS X.

StrongSwan is an openSource IPsec-based VPN Solution that runs on Linux 2.6, 3.x and 4.x kernels, Android, FreeBSD, OS X, iOS and Windows. It implements both the IKEv1 and IKEv2 (RFC 7296) key exchange protocols. It has been fully tested support of IPv6 IPsec tunnel and transport connections.

 In my example I will use strongSwan (for no particular reason) to establish a site-to-site VPN connectivity.

In order to install strongSwan in our systems, we simply run (as root): dnf install strongswan.

Let’s assume that the IP of Site A is 192.168.56.103 and of Site B is 192.168.56.1. In order to keep things as simple as possible (i.e. using the minimum capabilities), I will establish the IPsec connections without certificates, but by using a pre-shared key.

The ipsec.conf configuration files(located at /etc/strongswan) look as follows:

If my pre-shared key is 'test12345', then ipsec.secrets file (located also at (located at /etc/strongswan) should look like as follows:

Then, at both sites we need to start the corresponding service: systemctl start strongswan

(of course, you also need to configure the host firewalls to allow UDP port 500.

If everything went well, we should see something like the following:

The Security Association establishment (and the IKE_SA_Init and IKE_Auth exchanges) should be familiar by now to us. If not. Please refer to my previous blogposts here and here. However, we have a closer look at them, and specifically to IKE_SA_Init, we may be surprised (with respect to what we have seen so far in the aforementioned blogposts):

As we can see, in addition to the standard payloads (Security Association, Key Exchange, Nonce) encountered and examined so far, we now have payload, the Notify payload.

The Notify payload is used to transmit informational data, such as error conditions and state transitions, to specifying why a request was rejected (in a response message), or to indicate sender capabilities or to modify the meaning of the request.

The payload type for the Notify payload is forty-one (41).

- Protocol ID indicates the type of the SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP.

- SPI Size is the length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty.

- Notify Message Type specifies the type of notification message.

- SPI (of a variable length) is the Security Parameter Index.

- Notification Data (also of a variable length) defines the status or error data transmitted in addition to the Notify Message Type.

For more information, the reader should refer to RFC 7296.

In the wireshark snapshot presented above, the Notify payload advertises the following capabilities:

• NAT Detection (source IP and Destination IP). IPsec faces some uses when used through NAT. To manage NAT traversal, IKEv2 can use UDP encapsulation of IKE and ESP packets, as described in paragraph 2.23 of RFC 7296.

• IKEv2 Fragmentation support (RFC 7383). IKEv2 uses UDP as a transport for its messages. Most IKEv2 messages are relatively small, usually below several hundred bytes. A notable exception is the IKE_AUTH exchange, which requires fairly large messages, up to several KB, especially when certificates are transferred. When the IKE message size exceeds the path MTU, it gets fragmented at the IP level. The problem is that some network devices, specifically some NAT boxes, do not allow IP fragments to pass through. This apparently blocks IKE communication and, therefore, prevents peers from establishing an IPsec SA. Especially as far as IPv6 is concerned, several attack vectors that rely on IP fragmentation have been found. Therefore, many network operators filter all IPv6 fragments. Moreover, the default behavior of many currently deployed firewalls is to discard IPv6 fragments. To avoid such cases, the implementation of RFC 7383 allows the fragmentation of IKEv2 exchanges without relying on the IP protocol.

• Signature Hash Algorithms negotiation support, as described in RFC 7427.

• Multiple Authentication supported (not depicted in this wireshark snapshot), an experimental protocol defined in RFC 4739 which allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism.

• Redirect Mechanism support, defined in RFC 5685, that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent.

From the above capabilities, of a special interest are the support of IKEv2 fragmentation, and especially the Redirect capability.

In general, as it becomes clear from the above wireshark snapshot, in IKEv2 Exchanges we can add a set of Notify payloads advertising various capabilities. Their use (and potential abuse) needs to be tested.