IPsec

IPsec

IPsec is a set of protocols used for security at the network layer of the OSI model.

IP = Internet Protocol sec = secure

Its purpose is to secure communications between two points in a network. This is done by adding encryption and authentication.

When machines communicate over a public network, the communication is usually transmitted in plain text. This is dangerous if sensitive information is being sent. IPsec solves this problem by protecting data during transmission using IKE (Internet Key Exchange).

• Phase 1: The two sites identify each other and negotiate parameters for the authentication and encryption methods to be used.
• Phase 2: IPsec creates a tunnel to protect the data (virtual tunnel).

Data transport is handled by the ESP (Encapsulation Security Protocol). It provides authentication, integrity, and encryption.

To use IPsec, the sender and the receiver must share a public or private key. This key is used to encrypt the data before sending and decrypt it upon reception. This ensures that the data remains intact during transmission.

IPsec has two modes:

• Tunnel mode
• Transport mode

Data transmitted through IPsec over a network is sent in multiple “packets.” These packets contain:

• IP HEADER | TCP HEADER | PAYLOAD

Source and destination IP address | Port and sequence number | Contains the data to be transmitted

By default, the packet does not include any security.

When using transport mode, an ESP header, ESP trailer, and ESP authentication are added. The TCP header, payload, and ESP trailer are encrypted.

When using tunnel mode, a “NEW IP HEADER” is added, and the original IP header is encrypted along with the TCP header, payload, and ESP trailer.

IPsec solutions

IPsec solutions: Racoon2, Libreswan and Strongswan.

Brainstorming

1. Racoon2:

• Racoon2 official repo

Advantages

• Lightweight and easy to use with minimal CPU/RAM usage, compared to other solutions.
• Native on FreeBSD.
• Simple configuration for point-to-point.

Disadvantages

• Project not actively maintained, last update was in 2020.
• Limited support for modern features (IKEv2, NAT traversal), configuration is possible but may be more complex than others solutions.
• Apple clients can have difficulty connecting because of the limitations of pfkeyv2 interface to the linux kernel that racoon2 uses.
• Harder to configure for complex setups.

Operational risk:

due to lack of maintenance Racoon2 presents:

• Security patch uncertainty
• Limited future protocol support
• Risk for long term deployments

2. Libreswan:

• Libreswan official website
• Forked from the original FreeS/WAN project.

Advantages

• Actively maintained and stable on older hardware
• IRC community.
• Support NAT traversal, IKEv2 and enterprise VPN.

Disadvantages

• Less native support on FreeBSD.
• heavier on ressource usage.
• might need kernel patches.

Suitable for :

• stable and conservative deployments
• compatibility with older systems
• Administrators familiar with FreeS/WAN style configuration

3. Strongswan:

• Strongswan official website
• Originally derived from FreeS/WAN but largely reimplemented.

Advantages

• Actively maintained with an active community on IRC.
• Full support for IKEv2, EAP, PKI and Mobike
• Well documented with community support.
• Native of FreeBSD and Linux.

Disadvantages

• More complex to configuration.
• Slightly heavier on ressources

Suitable for :

• Long term infrastructure.
• Modern cryptographic standards.
• FUll support of multiple protocols : IKev2, EAP, PKI, MOBIKE.
• Large or scalable deployments.
• Mixed FreeBSD/Linux environements.

1. Summary:

• Racoon2: easier to configure for basic setups but it is a deprecated project
• Libreswan: stable and maintained but less native on FreeBSD, might need kernel patches.
• Strongswan: Most complete solution with good documentation and community supports, more protocols than other solutions but might be more complex to configure and is heavier than other solutions.

The GRE tunnels over IPsec are to be created and configured on FreeBSD 15 OS.

IPsec Solutions Overview

Criteria	Racoon2	Libreswan	StrongSwan
Project status	❌ Not maintained	✅ Active	✅ Active
IKEv2 support	⚠ Limited	✅ Full	✅ Full
NAT-T support	⚠ Limited	✅ Yes	✅ Yes
FreeBSD integration	✅ Native	⚠ Partial	✅ Native
Linux integration	⚠ PF_KEY	✅ XFRM	✅ XFRM/VTI

Technical consideration for GRE over IPsec

When securing a GRE tunnel, the following features are needed:

IKEv2 stability: Required for:

• Reliable rekying
• Better NAT handling
• Long term compatibility

Route-based VPN support Important when:

• Using GRE with dynamic routing (BGP/OSPF).
• Managing multiple tunnels.
• Automating configuration.

NAT traversal (NAT-T)

• Needed if peers are behind NAT.

Rekeying behavior: Implementation must:

• Avoid traffic interruption
• Handle DPD correctly
• Maintain tunnel stability

IPsec solution - key decision questions

1. Protocol & Cryptography

Should we use IKEv ? if yes Which IKe version to use ? Which encryption algorithms must be supported ? Which authentification will we use ?

• PSK?
• PKI?
• EAK?

Do we require interoperability ?

• Cisco devices ?
• CLoud providers ?

1. Architechture

• Can we avoid GRE over GRE in the long term ?
• How many tunnels ?

1. Stability

• How stable is rekeying ? Does rekeying interrupt GRE traffic ?
• Any known issues with multicast over GRE ?
• How will IPsec impact CARP ?

Official documentation

• StronSgwan doc
• LibreSwan doc
• Racoon2 doc

Troubleshoot

sudo swanctl --load-all --> loads the complete strongswan configuration from swanctl.conf sudo swanctl --initiate --child "child name" --> initiates a connection on a specific child SA sudo swanctl --terminate --ike "connection name" --> closes an IKE SA and all of its children sudo swanctl --list-conns --> lists all configured connections in swanctl.conf, displays connection name, type and local addresses and remote, children and authentification type sudo swanctl --list-sas --> lists SA security associations actives and shows what's established in the tunnel. sudo tcpdump -i vmx0 proto 47 --> captures traffic on vmx0 interface which uses protocol 47, which means GRE(generic routing encapsulation) sudo tcpdump -i vmx0 proto 50 --> captures traffic on vmx0 interface which uses protocol 50, which means ESP(encapsulation security payload)

Linked to T2202