'''Alkane''' is the new codename for our platform to host PHP and static websites.

Alkane servers offer:
* nginx to serve static content directly and proxy other requests
* php-fpm to serve PHP content

We maintain a state-of-art installation in the continuity of our shared hosting expertise: up-to-date PHP versions, dedicated site users for privilege separations, custom PHP pools.

Sites are published to Alkane by a Jenkins job running on CD. Again for privilege separation, Jenkins uses different containers per site to build the site artefact.

Alkane is a work in progress to track at [https://devcentral.nasqueron.org/T1803 T1803].

[[File:alkane.png|Scheme]]

== Guides ==
=== Host a new site ===
==== DNS ====
'''Production.''' subdomain.domain.tld CNAME www-alkane.nasqueron.org

'''Devserver.''' subdomain.domain.tld CNAME www-dev.nasqueron.org

==== nginx ====
* In {{Ops file|pillar/paas/alkane/web-001/}} add the subdomain in nginx_vhosts
* In {{Ops file|roles/webserver-alkane/nginx/files/vhosts/}} add the nginx configuration file

==== Auto-provisioning ====

;Through Jenkins:
* A CD job to deploy specific releases or your last commit
* Nothing fancy? You can adopt a standard job template "git fetch --all && git switch <new tag>" or the job "ensure you're on main then git pull"
** But beware to trap like Laravel cache clearing, databases migrations
* Jenkins build scripts can be ported to Dockerfile if you prefer to host the PHP site on our Docker PaaS

;Through Salt:
{{Ops file|roles/webserver-content}} can provision configuration for your site, especially if you need content elsewhere than in /var/wwwroot/<domain.tld>/<sub> (that content is for Jenkins to provision)

==== Database ====

'''PostgreSQL.''' Hosted on db-A cluster, see [[Operations grimoire/PostgreSQL]]

'''MySQL.''' Hosted on db-B cluster, see [[Operations grimoire/MySQL]]

'''Redis/memcached/etc.''' There are fully supported. For more complex applications, there are two roads:
* (i) the Docker PaaS, look for example how are deployed Airflow, Sentry and Penpot stacks;
* (ii) we create role/saas-<app> and we look if it's suitable for Alkane or if we create a specific server for that app.

We're here to help, create a task on DevCentral with your ideas and we can offer architecture guidance and tips to host it in the best conditions.

=== Provision credentials with .env ===

You can use the <code>webserver_content_dotenv</code> pillar to generate .env files.

Those files allow sites using libraries like DotEnv to read secrets.

To ensure secrets can only be read by application user, use:

user: <php-fpm pool user>

If your configuration can be read and stored in memory,
it's probably best to directly call Vault from the app
and only provision Vault AppRole credentials:

vault: <path to AppRole credential>

For PHP sites where the configuration file is read every
request, it's probably best to cache secrets in file
through this mechanism.

If you need a database, you can use:

db:
service: entry in nasqueron_services table
credentials: path to Vault secret

To provision a secret key or other credentials, use:

extra_credentials:
key: path to vault secret

If you need to pass extra plain values use:

extra_values:
key: value

=== Migrate from Ysul ===
A small checklist:

* Secrets should be stored on Vault
** As a migration path or alternative, you can use rOPS to provision files from Vault content
** Database user must be declared to {{Ops file|pillar/dbserver/cluster-B.sls}} (and Vault)
** You can use a PHP Vault SDK to read it and ask {{Ops file|roles/webserver-content}} to generate AppRole information for your site
* Build instructions should be moved from {{Ops file|roles/webserver-content}} to a Jenkinsfile on your repository
* Access to Docker resources should use private network

== Why the name Alkane? ==
Oh, it's a word Dereckson thought about while thinking about a new webserver-<word> to replace webserver-legacy.

Meanwhile, ChatGPT suggested "pulse" among other uninspired names.

Some fun about what ChatGPT has to say about Alkane:

Alkane could be a good product name for a webserver distribution for PHP and static sites. The name "Alkane" is a chemical term that refers to a type of hydrocarbon molecule that is characterized by its stability and simplicity. This name could be interpreted to mean that the webserver distribution is stable and easy to use.

Additionally, the name "Alkane" has a unique and memorable sound, which could help the product stand out in a crowded market. The name is also short and easy to spell, which could make it easy to remember and type into search engines.

______

Alkane, with its connotations of stability and simplicity, could be a good fit for a PaaS that offers a reliable and user-friendly hosting experience. The name also has a technical-sounding quality that could resonate with developers and IT professionals who are familiar with the concept of hydrocarbons in chemistry.

Both Alkane and Pulse are aligned with Nasqueron values:

Alkane, with its connotations of stability and simplicity, could reflect the value of elegance and simplicity that Nasqueron promotes. Meanwhile, Pulse, with its connotations of speed and responsiveness, could reflect the values of innovation and continuous improvement that Nasqueron also promotes.

File:Alkane.png

2026-02-19T14:19:11Z

Duranzed:

Operations grimoire/Alkane

2026-02-19T14:18:51Z

Duranzed:

'''Alkane''' is the new codename for our platform to host PHP and static websites.

Alkane servers offer:
* nginx to serve static content directly and proxy other requests
* php-fpm to serve PHP content

We maintain a state-of-art installation in the continuity of our shared hosting expertise: up-to-date PHP versions, dedicated site users for privilege separations, custom PHP pools.

Sites are published to Alkane by a Jenkins job running on CD. Again for privilege separation, Jenkins uses different containers per site to build the site artefact.

Alkane is a work in progress to track at [https://devcentral.nasqueron.org/T1803 T1803].
[[File:alkane.png|Caption text]]
== Guides ==
=== Host a new site ===
==== DNS ====
'''Production.''' subdomain.domain.tld CNAME www-alkane.nasqueron.org

'''Devserver.''' subdomain.domain.tld CNAME www-dev.nasqueron.org

==== nginx ====
* In {{Ops file|pillar/paas/alkane/web-001/}} add the subdomain in nginx_vhosts
* In {{Ops file|roles/webserver-alkane/nginx/files/vhosts/}} add the nginx configuration file

==== Auto-provisioning ====

;Through Jenkins:
* A CD job to deploy specific releases or your last commit
* Nothing fancy? You can adopt a standard job template "git fetch --all && git switch <new tag>" or the job "ensure you're on main then git pull"
** But beware to trap like Laravel cache clearing, databases migrations
* Jenkins build scripts can be ported to Dockerfile if you prefer to host the PHP site on our Docker PaaS

;Through Salt:
{{Ops file|roles/webserver-content}} can provision configuration for your site, especially if you need content elsewhere than in /var/wwwroot/<domain.tld>/<sub> (that content is for Jenkins to provision)

==== Database ====

'''PostgreSQL.''' Hosted on db-A cluster, see [[Operations grimoire/PostgreSQL]]

'''MySQL.''' Hosted on db-B cluster, see [[Operations grimoire/MySQL]]

'''Redis/memcached/etc.''' There are fully supported. For more complex applications, there are two roads:
* (i) the Docker PaaS, look for example how are deployed Airflow, Sentry and Penpot stacks;
* (ii) we create role/saas-<app> and we look if it's suitable for Alkane or if we create a specific server for that app.

We're here to help, create a task on DevCentral with your ideas and we can offer architecture guidance and tips to host it in the best conditions.

=== Provision credentials with .env ===

You can use the <code>webserver_content_dotenv</code> pillar to generate .env files.

Those files allow sites using libraries like DotEnv to read secrets.

To ensure secrets can only be read by application user, use:

user: <php-fpm pool user>

If your configuration can be read and stored in memory,
it's probably best to directly call Vault from the app
and only provision Vault AppRole credentials:

vault: <path to AppRole credential>

For PHP sites where the configuration file is read every
request, it's probably best to cache secrets in file
through this mechanism.

If you need a database, you can use:

db:
service: entry in nasqueron_services table
credentials: path to Vault secret

To provision a secret key or other credentials, use:

extra_credentials:
key: path to vault secret

If you need to pass extra plain values use:

extra_values:
key: value

=== Migrate from Ysul ===
A small checklist:

* Secrets should be stored on Vault
** As a migration path or alternative, you can use rOPS to provision files from Vault content
** Database user must be declared to {{Ops file|pillar/dbserver/cluster-B.sls}} (and Vault)
** You can use a PHP Vault SDK to read it and ask {{Ops file|roles/webserver-content}} to generate AppRole information for your site
* Build instructions should be moved from {{Ops file|roles/webserver-content}} to a Jenkinsfile on your repository
* Access to Docker resources should use private network

== Why the name Alkane? ==
Oh, it's a word Dereckson thought about while thinking about a new webserver-<word> to replace webserver-legacy.

Meanwhile, ChatGPT suggested "pulse" among other uninspired names.

Some fun about what ChatGPT has to say about Alkane:

Alkane could be a good product name for a webserver distribution for PHP and static sites. The name "Alkane" is a chemical term that refers to a type of hydrocarbon molecule that is characterized by its stability and simplicity. This name could be interpreted to mean that the webserver distribution is stable and easy to use.

Additionally, the name "Alkane" has a unique and memorable sound, which could help the product stand out in a crowded market. The name is also short and easy to spell, which could make it easy to remember and type into search engines.

______

Alkane, with its connotations of stability and simplicity, could be a good fit for a PaaS that offers a reliable and user-friendly hosting experience. The name also has a technical-sounding quality that could resonate with developers and IT professionals who are familiar with the concept of hydrocarbons in chemistry.

Both Alkane and Pulse are aligned with Nasqueron values:

Alkane, with its connotations of stability and simplicity, could reflect the value of elegance and simplicity that Nasqueron promotes. Meanwhile, Pulse, with its connotations of speed and responsiveness, could reflect the values of innovation and continuous improvement that Nasqueron also promotes.

IPsec

2026-02-19T08:05:27Z

Duranzed:

= 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.
[[File:Ipsec-transport-mode-ip-packet.png|ESP transport mode]]

==IPsec solutions ==

===IPsec solutions: Racoon2, Libreswan and Strongswan.===

[[File:ProjetTunnelGRE.png|thumb|Brainstorming]]

'''1. Racoon2:'''

*[https://github.com/zoulasc/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:'''

*[https://libreswan.org/ 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:'''

*[https://strongswan.org/ 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.

#'''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.

{| class="wikitable"
|+ 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 ===

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 ?

Architechture:
* Can we avoid GRE over GRE in the long term ?
* How many tunnels ?

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

=== Official documentation ===
*[https://docs.strongswan.org/docs/latest/index.html StronSgwan doc]
*[https://libreswan.org/man/ LibreSwan doc]
*[https://github.com/zoulasc/racoon2/ Racoon2 doc]

== Troubleshoot ==
- '''sudo service strongswan start''' --> Starts strongswan service.
- '''sudo service strongswwan stop''' --> Stops strongswan service.
- '''sudo service strongswan status''' --> Shows strongswan service.
- '''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).
- '''sudo tcpdunmp -i grex''' --> Captures traffic on the gre tunnel interface.

Linked to {{T|2202}}

Duranzed: /* Incident */

==IPsec solutions ==

===IPsec solutions: Racoon2, Libreswan and Strongswan.===

[[File:ProjetTunnelGRE.png|thumb|Brainstorming]]

'''1. Racoon2:'''

*[https://github.com/zoulasc/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:'''

*[https://libreswan.org/ 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:'''

*[https://strongswan.org/ 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.

#'''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.

{| class="wikitable"
|+ 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 ===

# 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 ?

# Architechture
* Can we avoid GRE over GRE in the long term ?
* How many tunnels ?

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

=== Official documentation ===
*[https://docs.strongswan.org/docs/latest/index.html/ StronSgwan doc]
*[https://libreswan.org/man/ LibreSwan doc]
*[https://github.com/zoulasc/racoon2/ 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 to 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 {{T|2202}}

GRE tunnel

2026-02-16T11:02:15Z

Duranzed:

2026-02-13T15:51:06Z

Duranzed:

==IPsec solutions ==

===IPsec solutions: Racoon2, Libreswan and Strongswan.===

'''1. Racoon2:'''

*[https://github.com/zoulasc/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:'''

*[https://libreswan.org/ 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:'''

*[https://strongswan.org/ 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.

#'''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.

{| class="wikitable"
|+ 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
==== Official documentation ====
*[https://docs.strongswan.org/docs/latest/index.html/ StronSgwan doc]
*[https://libreswan.org/man/ LibreSwan doc]
*[https://github.com/zoulasc/racoon2/ Racoon2 doc]

[[File:ProjetTunnelGRE.png|thumb|Brainstorming

Linked to {{T|2202}}

File:ProjetTunnelGRE.png

2026-02-13T15:27:22Z

Duranzed:

GRE tunnel

2026-02-13T10:28:19Z

Duranzed:

==IPsec solutions ==

===IPsec solutions: Racoon2, Libreswan and Strongswan.===

'''1. Racoon2:'''

*[https://github.com/zoulasc/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:'''

*[https://libreswan.org/ 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:'''

*[https://strongswan.org/ 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.

#'''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.

{| class="wikitable"
|+ 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
==== Official documentation ====
*[https://docs.strongswan.org/docs/latest/index.html/ StronSgwan doc]
*[https://libreswan.org/man/ LibreSwan doc]
*[https://github.com/zoulasc/racoon2/ Racoon2 doc]

Linked to {{T|2202}}

GRE tunnel

2026-02-13T10:24:27Z

Duranzed:

==IPsec solutions ==

===IPsec solutions: Racoon2, Libreswan and Strongswan.===

'''1. Racoon2:'''

*[https://github.com/zoulasc/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:'''

*[https://libreswan.org/ 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:'''

*[https://strongswan.org/ 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.

#'''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.

{| class="wikitable"
|+ 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
==== Official documentation ====
*[https://docs.strongswan.org/docs/latest/index.html/ StronSgwan doc]
*[https://libreswan.org/man/ LibreSwan doc]
*[https://github.com/zoulasc/racoon2/ Racoon2 doc]

Linked to {{T|2202}}

GRE tunnel

2026-02-09T14:36:27Z

Duranzed: /* Official documentation */

==IPsec solutions ==

===IPsec solutions: Racoon2, Libreswan and Strongswan.===

'''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.

'''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.

'''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 configure than racoon2 and libreswan.
* Slightly heavier on ressources

#'''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.

'''NOTE''': Libreswan and Strongwan are both based on FreeS/WAN project, Libreswan is closer to it's origin whereas Strongwan is a full reimplementation with a focus on IKEv2 and strong authentification

==== Official documentation ====
*[https://docs.strongswan.org/docs/latest/index.html/ StronSgwan doc]
*[https://libreswan.org/man/ LibreSwan doc]
*[https://github.com/zoulasc/racoon2/ Racoon2 doc]

Linked to {{T|2202}}

GRE tunnel

2026-02-09T14:26:24Z

Duranzed:

==IPsec solutions ==

===IPsec solutions: Racoon2, Libreswan and Strongswan.===

'''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.

'''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.

'''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 configure than racoon2 and libreswan.
* Slightly heavier on ressources

#'''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.

'''NOTE''': Libreswan and Strongwan are both based on FreeS/WAN project, Libreswan is closer to it's origin whereas Strongwan is a full reimplementation with a focus on IKEv2 and strong authentification

==== Official documentation ====
*[https://docs.strongswan.org/docs/latest/index.html/ Strongwan doc]
*[https://libreswan.org/man/ Libreswan doc]
*[https://github.com/zoulasc/racoon2/ Racoon2 doc]

Linked to {{T|2202}}

GRE tunnel

2026-02-09T14:25:09Z

Duranzed:

==IPsec solutions ==

===IPsec solutions: Racoon2, Libreswan and Strongswan.===

'''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.

'''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.

'''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 configure than racoon2 and libreswan.
* Slightly heavier on ressources

#'''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 modern solution with good documentation and community supports more protocols than the other solutions but might be more complex to configure and is heavier than other solutions.

'''NOTE''': Libreswan and Strongwan are both based on FreeS/WAN project, Libreswan is closer to it's origin whereas Strongwan is a full reimplementation with a focus on IKEv2 and strong authentification

==== Official documentation ====
*[https://docs.strongswan.org/docs/latest/index.html/ Strongwan doc]
*[https://libreswan.org/man/ Libreswan doc]
*[https://github.com/zoulasc/racoon2/ Racoon2 doc]

Linked to {{T|2202}}