GRE tunnel

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

Incident

While experimenting with creating a GRE tunnel between two router-001 and windirver already connected via GRE, the goal was to set up an additional tunnel for redundancy testing.

What happened:

• Creating a GRE tunnel on top of an existing GRE tunnel caused a cut connection between router-001 and windriver.
• Direct access to the router was unavailable, and the network interface (netif) was restarted without restoring the routing table.
• As a result, the server did not restart properly, and network services were unavailable.
• Access via KVM was required to correct the routing table directly on the remote machine.

Actions taken:

• Accessed the server via KVM to restore the routing table.
• Performed a controlled network interface restart.
• Established a rule: do not create GRE-over-GRE in the current infrastructure to avoid recursion and outages, if mandatory, always have KVM prepared and the VM itself to prevent any long server outage.

Technical analysis:

dmesg showed the following error: gre0: if_output recursively called too many times --> this was the cause of the cut connections between router-001 and windriver. this error comes from the FreeBSD kernel file sys/net/if.c, in the function if_tunnel_check_nesting().

Recommandations :

• avoid stacking GRE tunnels on top of existing ones, to avoid overcomplicating the configuration.
• test changes while having access to KVM.
• if restart is needed, always restart Netif along with the routing table with one command using "&&"

Linked to T2202