How to Configure Linux IPSec VPN (StrongSwan) with IKEv2 and EAP-TLS

While WireGuard has gained immense popularity for its simplicity, enterprise environments and strict compliance frameworks (like FIPS 140-2) still universally mandate IPSec. The challenge with IPSec is its notorious complexity, particularly regarding authentication. Relying on simple Pre-Shared Keys (PSKs) is a massive security vulnerability; if the PSK is leaked, the entire VPN is compromised.

The enterprise standard for IPSec authentication is IKEv2 (Internet Key Exchange version 2) combined with EAP-TLS (Extensible Authentication Protocol – Transport Layer Security). In this architecture, both the VPN server and the connecting client must present cryptographically valid x.509 certificates. There are no passwords to steal, and no shared secrets to leak.

This guide explains how to deploy a highly secure IKEv2 IPSec VPN server on Linux using the powerful StrongSwan daemon, enforcing strict EAP-TLS certificate-based authentication for remote clients.

Understanding the IKEv2 EAP-TLS Architecture

IKEv2 is the protocol that negotiates the encryption parameters and establishes the secure tunnel. EAP-TLS is the mechanism that handles the authentication within that negotiation.

1. The client initiates a connection to the StrongSwan server.
2. The server presents its TLS certificate. The client verifies this certificate against its trusted Root CA to ensure it is not connecting to a rogue server.
3. The client presents its own TLS certificate (often extracted from a smart card, a TPM, or an MDM payload).
4. The server verifies the client’s certificate against the corporate Root CA. If valid, the tunnel is established.

To deploy this, you must possess a functioning Public Key Infrastructure (PKI) to issue the server and client certificates.

Step 1: Installing StrongSwan

Install the strongswan package and the necessary cryptography plugins. On Debian/Ubuntu:

sudo apt-get update
sudo apt-get install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins

Step 2: Preparing the Certificates

Place your certificates in the strict directory structure required by StrongSwan located in /etc/ipsec.d/.

• Root CA Certificate: Place your corporate Root CA public certificate (e.g., ca.crt) in /etc/ipsec.d/cacerts/. StrongSwan uses this to validate incoming client connections.
• Server Public Certificate: Place the VPN server’s public certificate (e.g., vpn-server.crt) in /etc/ipsec.d/certs/. (Crucial: This certificate’s Subject Alternative Name (SAN) must exactly match the external IP or DNS name the clients will connect to).
• Server Private Key: Place the VPN server’s private key (e.g., vpn-server.key) in /etc/ipsec.d/private/. Secure this file strictly with chmod 600.

Step 3: Configuring the Secrets File

StrongSwan needs to know how to access the server’s private key to negotiate the TLS handshake. This is defined in the ipsec.secrets file.

Edit the file:

sudo nano /etc/ipsec.secrets

Add the following line, referencing the private key you placed in the private directory:

: RSA "vpn-server.key"

Step 4: Architecting the IPSec Configuration (ipsec.conf)

The core of StrongSwan’s behavior is defined in /etc/ipsec.conf. We must define a connection profile that explicitly mandates IKEv2 and EAP-TLS.

Edit the configuration file:

sudo nano /etc/ipsec.conf

Define the following configuration:

config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=never

conn ikev2-eap-tls
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes

    # IKE/ESP Cipher Suites (Enforce modern AES-GCM and SHA256)
    ike=aes256gcm16-prfsha256-ecp384!
    esp=aes256gcm16-ecp384!

    # Server Configuration (Left)
    left=%any
    [email protected]
    leftcert=vpn-server.crt
    leftsendcert=always
    leftsubnet=0.0.0.0/0 # Route all traffic through the VPN

    # Client Configuration (Right)
    right=%any
    rightid=%any
    rightauth=eap-tls
    rightsourceip=10.10.10.0/24 # The virtual IP pool for clients
    rightdns=8.8.8.8,8.8.4.4

Critical Parameters Explained:

• keyexchange=ikev2: Strictly enforces the modern IKEv2 protocol.
• [email protected]: Must match the SAN in the server’s certificate.
• rightauth=eap-tls: This is the mandate. The client must present a valid TLS certificate to authenticate. Passwords (EAP-MSCHAPv2) will be rejected.
• ike= and esp=: Forces high-security AES-GCM cryptographic suites, dropping support for legacy ciphers like 3DES or SHA1.

Step 5: Enabling IP Forwarding and NAT

For the VPN to function, the Linux kernel must route the decrypted packets, and iptables must masquerade (NAT) the traffic so clients can reach the internet.

Enable IPv4 forwarding in the kernel:

echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.d/99-ipsec.conf
sudo sysctl -p /etc/sysctl.d/99-ipsec.conf

Configure iptables to NAT the VPN client pool (assuming eth0 is your external interface):

sudo iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE

(Ensure you make this iptables rule persistent across reboots using netfilter-persistent).

Step 6: Restarting and Monitoring

Restart the StrongSwan service to apply the configuration and load the certificates:

sudo systemctl restart ipsec

To monitor incoming connections and troubleshoot TLS handshake failures, use the ipsec statusall command:

sudo ipsec statusall

This command will display the loaded certificates, the active cipher suites, and the real-time status of connected EAP-TLS clients.

Conclusion

Deploying IKEv2 with EAP-TLS transforms a standard Linux server into an enterprise-grade, cryptographically impenetrable VPN gateway. By eliminating shared passwords and enforcing mutual certificate validation via StrongSwan, security architects can establish robust Zero Trust remote access that satisfies the most stringent global compliance requirements.