Deploying an IKEv2 VPN based on StrongSwan and managed via systemd offers a robust, secure and highly automatable solution suitable for production environments. This article walks through practical design decisions, configuration examples and operational guidance to build a production-ready IKEv2 setup that is maintainable for webmasters, enterprise operators and developers.

Why IKEv2 + StrongSwan + systemd?

IKEv2 is a modern, efficient IPsec key exchange protocol with built-in support for mobility and multihoming (MOBIKE), NAT traversal (NAT-T) and rekeying. StrongSwan is a widely used open-source implementation of IPsec/IKEv2 with a modular plugin architecture and production-grade security features. Using systemd to manage StrongSwan and related tasks gives you reliable startup ordering, auto-restart, logging via the journal and the ability to run custom timers and health-checks.

Key advantages

  • Stability and resilience: systemd ensures automatic recovery and starts services in the correct order on boot.
  • Security: StrongSwan supports modern crypto primitives (ECC, AES-GCM, SHA2) and granular policy control.
  • Automation: systemd timers and the VICI management API let you script dynamic tasks (certificate renewal, dynamic route updates).
  • Scalability: Works for single-server dedicated IP VPNs, multi-host clusters, and integrates with orchestration tooling.

Architecture and operational considerations

Before diving into configuration, decide these core aspects:

  • Authentication mode: Server certificate + client certificate (mutual TLS) or server cert + EAP (username/password). For large user bases, EAP-MSCHAPv2 or EAP-TLS via a central identity provider is common.
  • Addressing: Routed (tun) vs. bridged (tap) IPsec — IKEv2 typically uses routed mode (assign virtual IPs via ipsec pool or IKEv2 configuration).
  • Split tunneling: Choose whether to route all client traffic through the VPN or only certain subnets.
  • High availability: For production, consider active/passive with virtual IP (Keepalived) or use BGP/VRRP for multi-host routing.

System-level hardening and prerequisites

On the host, enable kernel features and secure networking defaults:

  • Enable IP forwarding:

    sysctl -w net.ipv4.ip_forward=1 and for IPv6 net.ipv6.conf.all.forwarding=1.

  • Harden RP filter and ICMP redirects:

    Disable confusing redirects: net.ipv4.conf.all.send_redirects=0 and set net.ipv4.conf.default.rp_filter=1.

  • Configure firewall: allow UDP 500 and 4500, and permit ESP if not using NAT-T:

    Example (iptables/nft): open UDP 500 and 4500 and allow ESTABLISHED/RELATED traffic.

  • Load kernel modules:

    Ensure xfrm_user, ip_gre and related modules are available (StrongSwan uses xfrm subsystem).

PKI and certificates

StrongSwan can run with simple PSK, but a PKI using X.509 certificates is recommended for production. Use separate CA keys, keep CA offline if possible, and use modern algorithms:

  • Use ECC (e.g., P-256/P-384) or RSA 3072+ for server certs.
  • Short lifetimes (e.g., 1 year) and CRL/OCSP support for revocation.
  • Generate server key and CSR, sign with your CA. StrongSwan’s built-in pki tool is convenient: ipsec pki --gen --outform pem.

Sample certificate commands (conceptual)

Use the StrongSwan pki tool or OpenSSL. Keep CA private key offline where possible. Export PEM files for leftcert in the server config and distribute client certs safely.

Configuration with swanctl.conf and ipsec.secrets

Modern StrongSwan setups favor swanctl.conf and the VICI control API. Below are example snippets and explanations for a server that uses a server cert and EAP for client authentication.

Example swanctl.conf (essentials)

connections {
  ikev2-eap {
    local_addrs = 1.2.3.4
    pools = vpn-pool
    remote {
      auth = eap-mschapv2
      id = %any
    }
    children {
      net {
        local_ts = 0.0.0.0/0
        remote_ts = dynamic
        esp_proposals = strong
      }
    }
    proposals = strong
  }
}
pools {
  vpn-pool {
    addrs = 10.10.10.0/24
    dns = 10.0.0.10
  }
}
secrets {
  eap {
    username = "password"
  }
}
policies {}
plugins {
  include strongswan.d/
}

Key points:

  • local_addrs binds StrongSwan to the server public IP (or 0.0.0.0 for all interfaces).
  • pools defines client private IP allocation, and pushes DNS.
  • esp_proposals and proposals reference ciphers you define under charon or plugin profiles: prefer AES-GCM and strong DH curves.

ipsec.secrets (store private key securely, readable only by root)

: RSA server-key.pem
: EAP "secret-for-eap-users"

Cipher suites and proposal recommendations

Configure proposals to prefer AEAD ciphers and modern PRFs. Example strong proposal:

  • IKE: AES256-GCM, AES128-GCM, PRF: SHA2_256/384, DH: curve25519 or P-384
  • ESP: AES-GCM-16 or AES-GCM-12, with PFS (DH) enabled

Example proposal line inside StrongSwan config: ike=aes256gcm16-prfsha384-modp2048 or use ECC: ike=aes256gcm16-prfsha384-ecp384.

systemd integration and automations

StrongSwan installs systemd units (charon.service or strongswan.service). Use systemd unit overrides and timers for robust automation:

  • Auto-restart: Ensure the unit has Restart=on-failure and a conservative RestartSec=5.
  • Ordering: If you use networkd or a network-manager, set After=network-online.target and Wants=network-online.target.
  • VICI hooks: Use systemd services triggered by scripts that call the VICI socket for dynamic tasks (update allowed subnets, gather stats).
  • Timers: Add a systemd timer to run certificate renewal or CRL fetches and restart StrongSwan on CA change.

Example simple override snippet under /etc/systemd/system/strongswan.service.d/override.conf:

[Service]
Restart=on-failure
RestartSec=5
After=network-online.target
Wants=network-online.target

Monitoring, logging and diagnostics

Use journald and StrongSwan’s logging plugin for detailed debug levels in production only when needed.

  • View logs: journalctl -u strongswan -f
  • List active SAs: swanctl --list-sas or ip xfrm state
  • Inspect policies: ip xfrm policy
  • Enable VICI metrics and integrate with Prometheus using an exporter or scripts for health checks.

Performance tuning

For high throughput:

  • Choose AES-NI capable ciphers and ensure CPU supports crypto acceleration.
  • Use appropriate MTU/MSS clamping to avoid fragmentation (reduce MTU for tunnel interfaces; clients behind NAT may need 1400–1420).
  • Tune kernel networking (net.core.rmem_max, net.core.wmem_max) for large concurrent flows.

Operational best practices

  • Backup configs and keys securely and automate configuration deployment (Ansible/Terraform).
  • Rotate server keys and client credentials periodically and maintain a revoked list (CRL/OCSP).
  • Use monitoring and alerting for tunnel down events, auth failures and CPU/network saturation.
  • Test failover and rekey behavior — IKEv2 with MOBIKE handles IP changes well, but test with mobile clients and NAT conditions.

Example deployment checklist

  • Provision server with up-to-date kernel and StrongSwan package.
  • Harden sysctl networking and firewall rules; open UDP 500/4500.
  • Generate CA and server certificate; sign and place files with correct permissions.
  • Configure swanctl.conf and ipsec.secrets; enable strong proposals.
  • Create systemd unit overrides and timers for certificate/CRL management.
  • Integrate monitoring/exporter and enable alerting for connectivity/CPU/network anomalies.
  • Document client onboarding steps: how to install the server cert or root CA, client config profiles (iOS/macOS/Android/Windows/Linux).

Conclusion

Combining IKEv2, StrongSwan and systemd provides a production-caliber VPN solution that is secure, maintainable and automatable. The approach above emphasizes modern cryptography, PKI-based authentication, systemd-managed reliability and operational practices that scale from single-server deployments to multi-host architectures. With careful attention to firewalling, certificate lifecycle, monitoring and tuning, you can operate a resilient dedicated-IP VPN service appropriate for business and developer use cases.

For deployment examples, client configuration snippets, and downloadable templates tailored for Dedicated-IP-VPN, visit Dedicated-IP-VPN.