Implementing an IKEv2 VPN on a pfSense firewall delivers a strong combination of performance, reliability, and modern cryptographic standards. For hosting providers, enterprise administrators, and developers who need secure remote access or site-to-site tunnels, IKEv2 is an excellent choice thanks to built-in mobility support, robust rekeying, and native support on most operating systems. This guide walks through a practical, technically detailed setup process on pfSense, covering certificate management, IPsec phase configuration, client provisioning, firewall considerations, and common optimizations.

Why choose IKEv2 on pfSense?

IKEv2 offers several advantages for enterprise-grade VPN deployments:

  • Stability and mobility: Fast reconnection and support for MOBIKE make it resilient when clients change networks (e.g., cellular to Wi‑Fi).
  • Modern cryptography: Supports AES-GCM, SHA2, and modern Diffie-Hellman groups (19, 20) which increase security and performance.
  • Native client support: iOS, macOS, Windows, and many Linux distributions support IKEv2 without third-party clients.
  • Efficient: Lower overhead than SSL/TLS for equivalent security levels, often translating to better throughput on the same hardware.

High-level steps

The setup flow is:

  • Create a CA and server certificate on pfSense.
  • Configure IPsec: Phase 1 (IKE) and Phase 2 (IPsec/ESP) parameters tuned to modern algorithms.
  • Define a Mobile Client configuration (virtual IP pool, authentication).
  • Add firewall rules to allow IKE and ESP traffic.
  • Export client certificates or configuration and test with iOS/macOS/Windows clients.

Step 1 — Create CA and server certificate

Using certificates for authentication is strongly recommended over pre-shared keys for enhanced security and easier revocation. On pfSense:

  • Navigate to System → Cert. Manager → CAs and create a new internal CA. Use a descriptive name (e.g., “CorpVPN-CA”).
  • Go to Certificates and create a new server certificate signed by the internal CA. Set Common Name to the public DNS name or public IP of the pfSense WAN interface.
  • Export the server certificate if needed and create a client certificate (or a PKCS#12 bundle) per user. PKCS#12 includes the private key and is convenient for distributing to users securely.

Key size: choose at least 2048-bit RSA or consider elliptic-curve (e.g., P-256) for smaller keys and good performance. Keep CA and server certificates with appropriate lifetimes (e.g., CA 10 years, server 2–5 years) and document revocation processes.

Step 2 — Configure IPsec (Phase 1: IKE)

IPsec configuration on pfSense uses separate Phase 1 and Phase 2 sections. In Phase 1:

  • Mode: select IKEv2.
  • Interface: WAN (the public-facing interface).
  • Negotiation mode: Mutual RSA when using certificates; alternatively you can use EAP for username/password combined with server certs for two-factor-like behavior.
  • Authentication: choose the previously created server certificate.
  • Negotiation algorithms: choose modern, strong ciphers. A recommended set:
    • Encryption: AES-GCM-256 (or AES-GCM-128 for compatibility)
    • Integrity: intrinsic to AES-GCM; if using AES-CBC, use SHA-256 or SHA-384
    • Diffie-Hellman group: 19 (ECDH P-384) or 20 (Curve25519) / 14 (2048) as fallback
  • Lifetime: 28800 seconds (8 hours) is common; shorter lifetimes (1-2 hours) increase rekey frequency but can improve security.
  • Enable NAT Traversal (NAT-T): pfSense does this automatically, but ensure UDP 4500/500 are reachable if behind NAT devices.

Advanced Phase 1 tips

Enable Dead Peer Detection (DPD) for quicker detection of stale peers, and enable rekeying options if you expect mobile clients to roam. If you have multiple CPU cores or hardware crypto acceleration, verify pfSense kernel crypto offload settings to improve throughput.

Step 3 — Configure IPsec (Phase 2: ESP)

Phase 2 controls the actual traffic protection (ESP). Create a Phase 2 entry linked to the Phase 1 settings:

  • Mode: Tunnel IPv4.
  • Local network: typically “LAN subnet” or “any” depending on the use case. For full-tunnel VPNs, set this to 0.0.0.0/0 (but be careful with routing implications).
  • Remote network: for mobile clients use Dynamic and enable Virtual Address Pool (e.g., 10.10.10.0/24) to assign IPs to clients.
  • Protocol: ESP.
  • Encryption algorithms: AES-GCM-256 or AES-256 with SHA-256 for integrity. Enable multiple proposals for backward compatibility if needed.
  • PFS (Perfect Forward Secrecy): enable with the same or compatible DH group as Phase 1 (recommended).
  • Lifetime: 3600 seconds (1 hour) is typical for Phase 2.

For split-tunnel configurations, specify particular destination networks for remote access so only corporate traffic traverses the VPN. For full-tunnel, ensure proper DNS and routing configuration to avoid leaking traffic.

Step 4 — Authentication and user management

You can authenticate mobile users using:

  • Certificates only — clients must present a valid certificate signed by your CA.
  • Certificate + EAP (username/password) — ideal for central management via RADIUS if you need directory integration (Active Directory or FreeRADIUS).
  • Local user database — suitable for small teams; configure under System → User Manager.

When using RADIUS, pfSense can offload authentication and accounting. Configure Services → RADIUS and adjust EAP settings accordingly. EAP-MSCHAPv2 is commonly used for Windows clients.

Step 5 — Firewall and NAT

IPsec needs corresponding firewall rules to let traffic through:

  • On the WAN interface, allow UDP 500 and UDP 4500 (NAT-T). Some admins also explicitly allow IP protocol 50 (ESP), but note that ESP is connectionless and may be blocked by NAT devices — NAT-T avoids that problem.
  • On the IPsec interface in pfSense, add allow rules to permit the VPN client subnet to access internal resources (LAN), e.g., allow 10.10.10.0/24 to LAN subnet.
  • Disable or fine-tune NAT for VPN traffic depending on whether you want clients to appear from an internal IP or from the firewall address.

Also ensure any upstream firewall or hosting provider security groups permit the required ports and protocols to your pfSense WAN IP.

Client provisioning — iOS/macOS/Windows

Distribute client certificates securely, usually as a password-protected PKCS#12 (.p12/.pfx) file. Steps per platform:

  • iOS/macOS: Import the PKCS#12 into the device (tap/Install on iOS). Create a new IKEv2 VPN profile in Settings → VPN with the server address, remote ID matching the server certificate CN, and select certificate authentication. Set encryption to “Automatic”.
  • Windows 10/11: Import the PKCS#12 to the user certificate store. Create a new VPN connection using IKEv2, set server address, and configure the security settings to use certificate authentication. If using EAP, configure credentials accordingly or use machine certificates.
  • Linux (strongSwan): Configure /etc/ipsec.conf with conn parameters, reference the client certificates and include rightsourceip for the assigned pool. Restart the ipsec service and use ipsec up connname.

For RADIUS/EAP setups, clients will present username/password combinations; server certificate on pfSense must be trusted by the client for full validation.

Troubleshooting checklist

  • Verify server certificate CN matches the server address clients connect to; mismatches cause authentication failure.
  • Check logs in pfSense: Status → System Logs → IPsec for phase failures (e.g., no proposals, DH mismatch, certificate rejected).
  • Use packet captures on the WAN interface for UDP 500/4500 and ESP to confirm traffic flow.
  • If clients fail during large transfers, adjust MTU/MSS clamping on the pfSense WAN or VPN interface to avoid fragmentation.
  • Confirm firewall/NAT rules upstream (cloud provider security groups) allow necessary UDP ports and ESP.

Performance and security tuning

To maximize throughput and maintain security:

  • Prefer AES-GCM where possible — it provides authenticated encryption with less CPU cost for equivalent security.
  • Use elliptic-curve DH groups (20 or 19) for both security and performance benefits.
  • Enable hardware crypto offload if your platform supports it — check pfSense System Information and kernel crypto settings.
  • Monitor CPU usage during peak loads and consider dedicated hardware (or appliances) for high VPN concurrency.
  • Regularly rotate certificates and enforce strong key sizes and lifetimes.

Wrapping up

Configuring IKEv2 on pfSense provides a robust foundation for secure remote access and site-to-site connectivity. Using certificates for authentication, selecting modern algorithms, and carefully configuring Phase 1/2 parameters will yield a fast, secure VPN suitable for enterprise use. Always test configurations with representative client devices, document CA and certificate lifecycles, and monitor logs and performance after deployment.

For more practical walkthroughs and tips on managing dedicated IP VPNs, visit Dedicated-IP-VPN: https://dedicated-ip-vpn.com/