Deploying a robust remote access VPN for businesses and development teams requires both a secure tunnel protocol and a scalable, centralized authentication backend. Combining IKEv2 (via strongSwan or similar) with FreeRADIUS gives you modern cryptographic guarantees, support for certificate and credential-based authentication, and extensibility for integrating with databases, LDAP or multi-factor systems. This article walks through a production-ready configuration approach with detailed technical choices, certificate handling, firewall settings, and troubleshooting tips suited for site operators, sysadmins and developers.

Architecture and design decisions

Before diving into configuration, decide on these architectural parameters:

  • Authentication mode: Certificate-based (EAP-TLS) for the strongest security, or username/password (EAP-MSCHAPv2) for easier client setup. You can also support both via FreeRADIUS.
  • Crypto suite: Use AEAD ciphers (AES-GCM or ChaCha20-Poly1305), SHA-2 PRF, and modern DH/ECDH groups (e.g., ECP256/384 or MODP3072).
  • Server software: strongSwan is the common choice for IKEv2 on Linux; it supports swanctl.conf (recommended) and ipsec.conf.
  • RADIUS backend: FreeRADIUS with rlm_sql/mysql or rlm_ldap for centralized user stores. Enable EAP modules for EAP-TLS/EAP-MSCHAPv2.
  • Network placement: NAT considerations, firewall rules, and IP addressing for VPN clients (virtual private subnet or per-client static routes).

Certificates and PKI

A proper PKI is crucial for IKEv2. You can run a private CA (OpenSSL or strongSwan pki) or integrate with an existing CA. For production use, prefer elliptic-curve keys (ECDSA P-256 or P-384) or RSA 3072+.

Creating a simple CA and server cert (strongSwan pki)

Example commands (run on CA host):

  • Generate CA key and cert: ipsec pki --gen --type rsa --size 4096 --outform pem > caKey.pem then ipsec pki --self --ca --lifetime 3650 --in caKey.pem --type rsa --dn "CN=VPN-CA" --outform pem > caCert.pem.
  • Generate server key and CSR: ipsec pki --gen --type rsa --size 3072 --outform pem > serverKey.pem and ipsec pki --pub --in serverKey.pem --type rsa | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --lifetime 1825 --dn "CN=vpn.example.com" --san="vpn.example.com" --outform pem > serverCert.pem.
  • Distribute serverCert.pem and serverKey.pem to the VPN host, and install caCert.pem in the RADIUS server and clients (depending on auth method).

Note: For EAP-TLS, each client needs a certificate signed by the same CA. For EAP-MSCHAPv2 you only need server cert on the VPN server and trust the RADIUS server via secure channel.

strongSwan (IKEv2) configuration

Prefer the swanctl (charon) configuration. Below are the key sections for a minimal but secure IKEv2 server supporting EAP-MSCHAPv2 and EAP-TLS.

Example swanctl.conf structural highlights

  • connections: define ike proposal, auth method, pool and child SA definitions (esp proposal, lifetimes).
  • secrets: server private key and PSKs if used.
  • pools: IP pool for clients (e.g., 10.10.10.0/24).

Security choices to include:

  • ike = aes256gcm16-prfsha384-modp3072 or ike = chacha20poly1305-prfsha256-ecp256 for ECDH.
  • esp = aes256gcm16-ecp256 or chacha20poly1305-prfsha256.
  • rekey and lifetimes tuned to your policy (e.g., IKE SA 8h, CHILD SA 1h).
  • enable MOBIKE and NAT traversal (NAT-T) for mobile clients.

Place server cert and key in /etc/swanctl/secrets or referenced paths. Example secrets entry:

  • : RSA serverKey.pem

FreeRADIUS configuration for EAP

Install FreeRADIUS (v3.x recommended). The main files are in /etc/freeradius/3.0. Key things to configure:

clients.conf

Define the IKEv2 server as a RADIUS client so FreeRADIUS accepts requests from it:

  • client strongswan { ipaddr = 127.0.0.1 secret = verysecret shortname = strongswan }

eap module

Enable and tune EAP in mods-enabled/eap. Configure supported methods (tls and mschapv2), TLS files, and the default TLS operation for EAP-TLS:

  • tls-config tls-common { private_key_file = /etc/freeradius/certs/server.key certificate_file = /etc/freeradius/certs/server.crt ca_file = /etc/freeradius/certs/ca.pem }

users file and SQL

For quick tests you can add entries to /etc/freeradius/3.0/mods-config/files/authorize (or users):

  • testuser Cleartext-Password := “secretpassword”

For production, enable rlm_sql and store credentials in MySQL/Postgres. You can also use rlm_ldap for AD/LDAP integration.

strongSwan ↔ FreeRADIUS integration

Configure strongSwan to send EAP requests to RADIUS via the vici/charon radius plugin or via the legacy rlm_passwd? The typical approach is:

  • Enable the radius plugin in strongSwan (installed with libstrongswan-extra-plugins or enabling vici plugin).
  • Configure /etc/strongswan.d/charon/radius.conf (or similar) with FreeRADIUS endpoint, secret, NAS-Identifier and timeout settings.
  • Ensure server names and TLS options match so EAP-TLS validates client certs against the CA you set in FreeRADIUS.

Networking and firewall

On the VPN gateway:

  • Enable IP forwarding: sysctl -w net.ipv4.ip_forward=1.
  • Allow UDP 500 and 4500 (IKE and NAT-T) inbound and outbound.
  • Configure iptables/nftables to NAT client traffic if providing internet access: e.g., iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE.
  • Open policies for ESP (protocol 50) if NAT-T is not used and ensure fragmentation settings are appropriate.

Client configuration notes

Clients must trust your CA for EAP-TLS and may need the server name set for certificate validation. On modern platforms (Windows, macOS, iOS, Android, Linux strongSwan client), configure IKEv2 profile using:

  • Server address (FQDN or IP)
  • Authentication: EAP-TLS (client cert) or EAP-MSCHAPv2 (username/password)
  • Child SA traffic selectors—set to 0.0.0.0/0 for full-tunnel or specific subnets for split-tunnel.

Operational considerations

High-availability and scaling tips:

  • Deploy multiple strongSwan instances behind a load balancer or DNS round-robin; ensure RADIUS requests are routed to a centralized FreeRADIUS cluster (use rlm_sql with a shared DB or proxying).
  • Use session accounting (radacct) to track concurrent users and enforce limits in radius post-auth.
  • Rotate server certificates and maintain CRL or OCSP responders for revocation checking in FreeRADIUS and clients.

Testing and troubleshooting

Useful commands and log locations:

  • strongSwan: journalctl -u strongswan -f and ipsec statusall, swanctl --list-sas.
  • FreeRADIUS: run in debug mode radiusd -X or freeradius -X to see step-by-step EAP handling.
  • Verify RADIUS connectivity with radclient for Authentication and Accounting requests.

Common issues:

  • Certificate validation failures — check certificate chain, subjectAltName, and CA trust stores on client and FreeRADIUS.
  • EAP-MSCHAPv2 authentication fails — verify user password in FreeRADIUS and ensure MS-CHAPv2 support is enabled in EAP config.
  • Clients can’t reach internal resources — check push routes, ip_forward, and firewall rules on gateway and internal routers.

Security hardening checklist

  • Prefer EAP-TLS for strong mutual authentication and consider hardware-backed keys (TPM or smartcards) for clients.
  • Enable certificate revocation checking in FreeRADIUS (CRL/OCSP) for EAP-TLS.
  • Use secure ciphersuites only (AEAD, modern PRF, strong DH groups).
  • Log and monitor RADIUS authentication attempts; integrate with SIEM for anomaly detection.
  • Restrict RADIUS clients to known IPs and use strong shared secrets over the management network.

Example end-to-end checklist

  • Generate CA, server, and (optional) client certificates.
  • Install strongSwan and FreeRADIUS, configure swanctl.conf and radius.conf.
  • Configure FreeRADIUS clients.conf and EAP TLS/MSCHAP modules.
  • Set up IP pool, firewall NAT, and routes for clients.
  • Test authentication using a debug FreeRADIUS session and a client connection; iterate on logs.
  • Harden and automate cert rotation and CRL publishing.

Combining IKEv2 with FreeRADIUS provides a flexible, scalable and secure remote access solution suitable for modern enterprise needs, enabling centralized user management, multi-factor extensions, and strong cryptographic controls. Follow the configuration patterns above, validate with debug logging during rollout, and put monitoring and certificate lifecycle processes in place for long-term reliability.

For more in-depth guides, examples and downloadable configuration snippets tailored for dedicated IP VPN deployments, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.