Deploy a Secure IKEv2 VPN with PKI: A Step-by-Step Guide

Implementing a scalable, secure VPN using IKEv2 backed by a Public Key Infrastructure (PKI) provides strong authentication, easier certificate management, and robust protection for remote access and site-to-site scenarios. This guide walks through the practical steps, with configuration snippets, command-line examples, and operational recommendations tailored for sysadmins, developers, and business IT teams.

Why choose IKEv2 with PKI?

IKEv2 is modern, resilient to network changes, and supports MOBIKE for seamless roaming. When combined with PKI, it eliminates shared secrets and improves security posture by using certificate-based authentication, which is easier to rotate and revoke. Compared to PSK (pre-shared keys), certificates provide:

• Non-repudiation and unique identity per client or device.
• Centralized lifecycle control: issuance, renewal, and revocation via CRLs or OCSP.
• Better scalability for large deployments and automated provisioning.

Prerequisites and assumptions

This guide assumes a Linux-based VPN server (examples use Ubuntu or Debian-like systems), strongSwan as the IKEv2 implementation, OpenSSL or strongSwan’s pki utility for certificate management, and control of your firewall/NAT. You should have root access on the server and the ability to install packages and open UDP ports 500 and 4500.

Base packages

Install the required packages:

apt update && apt install strongswan strongswan-pki libcharon-extra-plugins openssl -y

Enable IP forwarding:

sysctl -w net.ipv4.ip_forward=1

Persist it in /etc/sysctl.conf:

net.ipv4.ip_forward=1

Design the PKI

Decide whether to run a simple local CA for your organization or integrate with an enterprise CA. For most VPN deployments a dedicated internal CA is sufficient. Use strongSwan’s pki or OpenSSL—strongSwan pki produces compatible output and is convenient.

Create a root CA (example with strongSwan pki)

On a secure workstation or an air-gapped machine:

mkdir -p ~/pki/{cacerts,certs,private}

Create root key and certificate:

ipsec pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/ca-key.pem

ipsec pki --self --ca --lifetime 3650 --in ~/pki/private/ca-key.pem --type rsa --dn "CN=MyVPN Root CA" --outform pem > ~/pki/cacerts/ca-cert.pem

Keep the CA private key offline. Only use it to sign intermediate CA certs or server/client certs if required. For better security, create an intermediate CA for day-to-day signing and keep root offline.

Issue server certificate

Generate server key and CSR:

ipsec pki --gen --type rsa --size 3072 --outform pem > ~/pki/private/vpn-server-key.pem

ipsec pki --pub --in ~/pki/private/vpn-server-key.pem --type rsa | ipsec pki --issue --lifetime 1825 --cacert ~/pki/cacerts/ca-cert.pem --cakey ~/pki/private/ca-key.pem --dn "CN=vpn.example.com" --san "vpn.example.com" --flag serverAuth --outform pem > ~/pki/certs/vpn-server-cert.pem

Transfer vpn-server-cert.pem and vpn-server-key.pem to the VPN server securely. Also copy the CA certificate ca-cert.pem to the server and to clients that will trust the VPN CA.

Configure strongSwan on the server

Place certificates under /etc/ipsec.d:

• /etc/ipsec.d/private/vpn-server-key.pem
• /etc/ipsec.d/certs/vpn-server-cert.pem
• /etc/ipsec.d/cacerts/ca-cert.pem

Minimal /etc/ipsec.conf for IKEv2 site or remote access:


config setup
uniqueids=never



conn %default
keyexchange=ikev2
ike=aes256-sha2_256-modp2048!
esp=aes256-sha2_256!
dpdaction=clear
rekey=no
left=%any
leftcert=vpn-server-cert.pem
leftsendcert=always
leftid="CN=vpn.example.com"
leftsubnet=0.0.0.0/0
right=%any
rightsourceip=10.10.10.0/24
rightauth=pubkey
rightsendcert=never
auto=add


Notes:

• left refers to the VPN server; set leftid to the server certificate common name.
• rightsourceip assigns an internal IP pool for connecting clients (choose your own private subnet).
• Harden transform sets for IKE and ESP: prefer AES-GCM where possible, and larger DH groups (e.g., modp2048 or better).

Create /etc/ipsec.secrets with server private key reference:

: RSA "/etc/ipsec.d/private/vpn-server-key.pem"

Firewall and NAT considerations

Open UDP ports 500 and 4500 and allow ESP (protocol 50) if not using NAT Traversal. If the server is behind NAT, strongSwan will handle NAT-T on 4500 automatically.

Example iptables (legacy) rules for IPv4 NAT if you want all client traffic to go through the VPN:

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

Also allow forwarding:

iptables -A FORWARD -s 10.10.10.0/24 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -d 10.10.10.0/24 -j ACCEPT

For production use prefer nftables or cloud security groups with explicit policies. Ensure your hosting provider allows IPsec traffic.

Client certificate issuance and provisioning

For each user or device, generate a key and certificate signed by your CA. Example:

ipsec pki --gen --type rsa --size 2048 --outform pem > client-key.pem

ipsec pki --pub --in client-key.pem --type rsa | ipsec pki --issue --lifetime 825 --cacert ca-cert.pem --cakey ca-key.pem --dn "CN=user1@example.com" --outform pem > client-cert.pem

Distribute to clients:

• For macOS/iOS: provide a combined PKCS#12 file (client.p12) with the private key and certificate, protected with a strong password. Use openssl pkcs12 -export.
• For Windows: use PKCS#12 or import into the certificate store and configure a native IKEv2 connection.
• For Linux: place certs under /etc/ipsec.d/ or configure strongSwan’s client packages accordingly.

Example PKCS#12 export:

openssl pkcs12 -export -inkey client-key.pem -in client-cert.pem -name "user1" -certfile ca-cert.pem -out client.p12

Client configuration examples

iOS/macOS

Use the built-in IKEv2 VPN profile. Install the CA cert and the client .p12. Configure:

• Type: IKEv2
• Server: vpn.example.com
• Remote ID: vpn.example.com (match certificate CN)
• Local ID: user1@example.com (optional)
• Authentication: Certificate (select installed identity)

Windows 10/11

Import the user .p12 into Personal Certificates. Create a new VPN connection using IKEv2, set authentication to use a certificate, and choose the certificate. If certificates are issued with user UPNs, Windows will map automatically; otherwise, set the local/remote IDs appropriately.

Revocation and certificate lifecycle

Plan for certificate expiry and revocation. You can publish a CRL or run an OCSP responder. For moderate deployments, issuing short-lived certificates (e.g., 90 days) and automating renewal reduces the need for CRLs.

To generate a CRL with strongSwan pki (issued by the CA):

ipsec pki --gen-crl --cacert ca-cert.pem --cakey ca-key.pem --outform pem > ca-crl.pem

Serve ca-crl.pem over HTTPS or place in a known distribution point referenced in certificate extensions. strongSwan supports CRL checking if configured.

Monitoring, logging, and hardening

Enable detailed logging in /etc/strongswan.d/charon.conf or via log settings. Monitor connections with:

ipsec statusall

and logs via journalctl -u strongswan or /var/log/syslog depending on your system.

Hardening tips:

• Use certificate pinning or strict ID checks (leftid/rightid) to prevent impersonation.
• Prefer AES-GCM ciphers and SHA-2 family for integrity.
• Disable legacy algorithms (e.g., DES, MD5, weak DH groups).
• Apply kernel/network hardening: limit ICMP redirect acceptance, enforce RPF checks if applicable.
• Use automated configuration management (Ansible/Chef) to ensure consistent builds.

Troubleshooting common issues

Connection fails to establish:

• Check that UDP 500/4500 are reachable from client to server (use nc -u or packet captures).
• Verify certificates: chain must be valid and not expired; CN/subjectAltName must match server name used by clients.
• Look for NAT-related issues: if NAT hides client IPs, ensure NAT-T and NAT keepalive are enabled.

Clients receive no internet access:

• Confirm rightsourceip pool is routed and NATed to the internet interface, or push split-tunneling as required.
• Inspect iptables/nftables FORWARD rules and masquerading.

Performance is poor:

• Enable hardware crypto offload if available.
• Consider AES-NI support and ensure cipher suites use AES-GCM with proper key sizes.
• Scale servers horizontally and use load balancers that support IPsec only for separate endpoint clustering; note that stateful IPsec is not trivial behind L4 balancers—use identical certificates and consistent NAT settings.

Automation and scaling

For medium to large deployments, automate certificate issuance (ACME is not suitable for client certs), use enrollment protocols (e.g., SCEP, EST), or integrate with an enterprise CA for SSO and centralized identity. Deploy monitoring to auto-scale gateway instances and use configuration management to maintain consistent strongSwan setups.

Summary and next steps

Deploying IKEv2 with PKI yields a robust remote access or site-to-site VPN suitable for enterprise needs. Follow these core steps: set up a secure CA, generate server and client certificates, configure strongSwan with hardened algorithms, correctly handle firewall/NAT rules, and plan certificate lifecycle management with CRL/OCSP or short-lived certs. Regular monitoring, logging, and automation will keep the deployment secure and maintainable.

For additional resources on setup patterns, example configs, and troubleshooting notes, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.