Overview and prerequisites
Implementing a secure IKEv2 VPN that authenticates clients via EAP‑MSCHAPv2 provides a modern balance between ease of deployment and strong security. This guide walks through a practical, production‑oriented configuration using strongSwan as the server on Linux and native clients (Windows, macOS, Android, iOS). It covers certificate management, server configuration, client setup, firewall/OS tuning, and common troubleshooting steps.
Before you begin, ensure the following prerequisites are met:
- Linux server with public IPv4/IPv6 reachable address (Debian/Ubuntu/CentOS supported).
- strongSwan version 5.x or later (IKEv2 + EAP support).
- X.509 certificate for the server (issued by a trusted CA or your own CA).
- Account store for EAP‑MSCHAPv2 (local passwd/psk file, PAM, LDAP, or RADIUS).
- Root or sudo access for installing packages and editing system network settings.
- Firewall open for UDP ports 500 and 4500 (NAT‑T) and IP forwarding enabled.
Design decisions and security considerations
Before configuring, choose the following to align security and operational needs:
- Authentication model: EAP‑MSCHAPv2 authenticates username/password pairs; it requires a valid server certificate to protect the EAP exchange. For centralized credential management, integrate RADIUS/PAP-to-MS-CHAPv2 (with protection) or LDAP/PAM on the server.
- Cryptographic policy: Use AES‑GCM or AES‑CBC with SHA‑2, DH group 14/19/21 (2048/256/4096 bits), and enable PFS (Perfect Forward Secrecy).
- Certificate handling: Use a CA issued cert for client trust; keep the server private key secure and rotate certificates as part of lifecycle management.
- NAT and mobility: Enable NAT‑Traversal (UDP 4500) and consider MOBIKE support (IKEv2 builtin) for clients roaming between networks.
Step 1 — Install and prepare strongSwan
On Debian/Ubuntu:
sudo apt update && sudo apt install strongswan strongswan-plugin-eap-mschapv2 libcharon-extra-plugins
On RHEL/CentOS use the corresponding packages or EPEL. Verify charon is present with EAP and PKI plugins enabled (charon is the IKE daemon).
Enable IP forwarding and kernel settings for IPsec:
sudo sysctl -w net.ipv4.ip_forward=1
Persist this in /etc/sysctl.conf or a drop‑in.
Step 2 — Generate or install certificates
You can use a public CA (recommended for simplicity) or a private CA. For private CA, create a CA and issue a server certificate. Example minimal steps (OpenSSL):
- Generate CA key and cert; then create server CSR and sign it.
- Install serverCert.pem and private key as /etc/ipsec.d/private/serverKey.pem and /etc/ipsec.d/certs/serverCert.pem.
- Place CA cert in /etc/ipsec.d/cacerts/caCert.pem so strongSwan can present full chain and validate client trust.
Step 3 — Configure strongSwan for IKEv2 + EAP‑MSCHAPv2
Edit /etc/ipsec.conf (or use split config with swanctl.conf). A simple production‑ready profile:
config setup
charondebug=”ike 2, knl 2, cfg 2, net 2″
uniqueids=yes
conn ikev2-eap
keyexchange=ikev2
ike=aes256-sha256-modp2048!
esp=aes256-sha256!
left=%any
leftid=@vpn.example.com
leftcert=serverCert.pem
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
eap_identity=%identity
rightsourceip=10.10.10.0/24
auto=add
Key points:
- leftid must match the server certificate subject (or altName) and the hostname clients will use.
- rightauth=eap-mschapv2 enables username/password authentication for clients.
- rightsourceip assigns an internal pool for VPN clients.
- Use ike and esp to enforce strong algorithms; include an exclamation mark (!) to make them strict.
Now configure secrets for EAP. For simple setups, configure local EAP credentials in /etc/ipsec.secrets or use PAM/RADIUS for scalable authentication. Example local file (not recommended for large deployments):
# /etc/ipsec.secrets
: RSA “serverKey.pem”
username : EAP “userPassword”
For enterprise environments, configure strongSwan’s RADIUS plugin or use PAM with a secure password store. When using RADIUS, enable the strongswan‑radius plugin and configure /etc/strongswan.d/charon/radius.conf with server, secret, and attribute mappings.
Step 4 — Firewall and NAT considerations
Open the required ports on the host and any upstream firewall:
- UDP 500 (ISAKMP)
- UDP 4500 (NAT‑T)
Example iptables (legacy) rules:
iptables -A INPUT -p udp –dport 500 -j ACCEPT
iptables -A INPUT -p udp –dport 4500 -j ACCEPT
iptables -A FORWARD -s 10.10.10.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
On systems using nftables or firewalld, ensure equivalent rules are added. If server sits behind NAT, port forward UDP 500 and 4500 to the server.
Step 5 — Client configuration examples
Windows 10/11 (native IKEv2 client)
Use GUI or PowerShell. Example PowerShell command to create a profile that uses EAP‑MSCHAPv2:
Add-VpnConnection -Name “IKEv2-EAP” -ServerAddress “vpn.example.com” -TunnelType Ikev2 -AuthenticationMethod Eap -EncryptionLevel Required -Force
Windows requires an EAP XML profile to force MSCHAPv2; you can create one via RRAS templates or export from a GUI. Alternatively, in the VPN connection properties set EAP type to Microsoft: Secured password (EAP‑MSCHAP v2) and enable Verify server certificate selecting the CA if you use a private CA.
iOS / macOS
Use the built‑in IKEv2 profile. In Settings (iOS) or System Preferences (macOS), add a VPN profile: Type IKEv2, Server: vpn.example.com, Remote ID: vpn.example.com, User Authentication: Username, enter user credentials. Ensure the certificate chain is trusted in device trust store if using a private CA.
Android
Modern Android supports IKEv2 via the strongSwan VPN client (Play Store) or built‑in depending on device. In strongSwan app, create a new connection using server name and select EAP‑MSCHAPv2 as the authentication method; server certificate check can be pinned by CA or server pin.
Troubleshooting and logs
Enable debug for charon in config setup: charondebug=”ike 2, cfg 2, net 2, knl 2″. Check logs with:
sudo journalctl -u strongswan -f
or
sudo tail -f /var/log/syslog | grep charon
Common errors and fixes:
- Authentication failed: Verify EAP credentials and whether strongSwan is using the correct secrets backend. If using RADIUS, ensure shared secret and attribute mappings are correct.
- Certificate validation errors: Confirm server cert chain is installed, leftid matches certificate, and clients trust the CA.
- NAT issues: If NAT exists between client and server, confirm UDP 4500 is permitted. Inspect packets with tcpdump: tcpdump -n -i eth0 udp port 500 or udp port 4500.
- IP routing problems: Check that IP forwarding is enabled and that NAT/postrouting rules are configured so VPN client traffic can reach the internet or internal resources.
- MTU/MSS problems: If browsing is slow or connections hang, clamp TCP MSS on VPN tunnel or adjust MTU (typical MSS clamp to 1350 or similar).
Hardening recommendations
- Strict cipher suite policy: Prefer AEAD ciphers like AES‑GCM (aes128gcm16/aes256gcm16) and SHA‑2 HMAC where AEAD isn’t available.
- Enforce server certificates: Always require clients to validate the server certificate; do not fall back to PSKs for production.
- Use RADIUS or LDAP: Centralize authentication to support multi‑factor auth, auditing, and password policies. If using RADIUS, secure the channel (radsec) or use IPsec between RADIUS and VPN server.
- Logging and monitoring: Send logs to a central syslog server and monitor for repeated authentication failures or unusual connection patterns.
- Certificate revocation: Deploy OCSP or CRL checking if client validation of revoked certs is required.
Operational tips
For large deployments, automate certificate issuance (ACME with DNS challenge for server certs where supported), and use configuration management (Ansible, Puppet) to maintain consistent strongSwan profiles. Use split tunneling rules carefully to avoid data leakage and document user onboarding steps for different client platforms.
With the above steps you can deploy a robust IKEv2 VPN using EAP‑MSCHAPv2 that supports username/password authentication while preserving the strong security properties of IKEv2. Test thoroughly with representative clients and network conditions before opening the service to production users.
Published by Dedicated‑IP‑VPN