GRE tunnel

From Nasqueron Agora
Revision as of 11:03, 17 February 2026 by Duranzed (talk | contribs) (→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. ESP transport mode

IPsec solutions

IPsec solutions: Racoon2, Libreswan and Strongswan.

Brainstorming

1. Racoon2:

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:

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:

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

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().

  • When creating a GRE tunnel between two machines and this one doesn't respond or cuts connectiong, proceed to destory the tunnel on both sides to allow traffic back.

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

Retrieved from "https://agora.nasqueron.org/index.php?title=GRE_tunnel&oldid=2309"