Setting up an IKEv2 client on Linux using NetworkManager is a reliable way to provide secure site-to-site or remote-access VPN connectivity while leveraging the desktop-friendly connection controls most administrators prefer. This guide dives into practical steps, configuration details, and troubleshooting tips for accomplishing a robust IKEv2 setup on common Linux distributions. It targets webmasters, enterprise operators, and developers who require a stable, performant VPN client that plays well with systemd, DNS resolvers, and modern cipher suites.

Why IKEv2 and NetworkManager?

IKEv2 (Internet Key Exchange version 2) combined with IPsec is a modern standard for secure VPN tunnels. It offers:

  • MOBIKE support for seamless roaming (switching networks without reconnection).
  • Strong cryptographic options (AES-GCM, CHACHA20-POLY1305, robust DH groups).
  • Better resilience to NAT and flaky network links via Dead Peer Detection (DPD) and reauthentication.

NetworkManager provides a consistent, distro-native client configuration interface and integrates with desktop environments and system services. The NetworkManager-strongswan plugin lets you manage IKEv2/IPsec connections using GUI editors or the command line (nmcli), while strongSwan performs the IKE/IPsec operations.

Prerequisites and packages

Install required packages depending on your distribution. The package names vary slightly:

  • Debian/Ubuntu: sudo apt update && sudo apt install strongswan network-manager-strongswan network-manager-strongswan-gnome
  • Fedora: sudo dnf install strongswan NetworkManager-strongswan
  • CentOS/RHEL (EPEL): enable EPEL, then install strongswan NetworkManager-strongswan

Confirm NetworkManager and strongSwan services are enabled:

  • systemctl status NetworkManager
  • systemctl status strongswan

Authentication choices and implications

IKEv2 supports multiple authentication modes. Choosing the right one depends on security and manageability:

  • Pre-shared Key (PSK): Simple but less scalable and more vulnerable to offline attacks if the key is weak. Good for quick lab setups.
  • EAP (username/password): Typical for remote access (RADIUS backend) and integrates well with certificates on the server side.
  • Client certificates (X.509): Most secure and scalable for enterprise deployments. Requires issuing and distributing PKI certificates.

For production, prefer certificates or EAP with strong backend authentication.

Creating certificates for client authentication (optional but recommended)

If you choose certificate-based authentication, you must create a CA, server, and client certificates. A minimal workflow using OpenSSL:

  • Generate a CA key and self-signed cert.
  • Create a server key & CSR, sign with the CA.
  • Create a client key & CSR, sign with the CA, then export as PKCS#12 (PFX) for import into NetworkManager.

Example export for client (on machine holding the private key):

openssl pkcs12 -export -inkey client.key -in client.crt -certfile ca.crt -out client.p12

NetworkManager-strongswan accepts PKCS#12 files for client certs. Keep your CA and keys safe and use secure permutations when generating keys (RSA 3072/4096 or ECDSA with P-256/384).

Configuring the connection via GUI (nm-connection-editor)

Open Network Connections (nm-connection-editor) or your GNOME/KDE network settings. Add a new VPN connection and select IPsec/IKEv2 (strongSwan). Important fields:

  • Gateway: IP or FQDN of the VPN server.
  • Authentication type: e.g., RSA for certificates, EAP for username/password, or Pre-shared Key.
  • PSK (if using PSK)
  • Client certificate: Import the PKCS#12 (.p12) file when using X.509.
  • CA certificate: Import CA certificate to validate the server.
  • IPsec options: Proposal (encryption/auth/DH), lifetimes, and MOBIKE enablement.

For DNS handling, set “Use this connection only for resources on its network” to control split tunneling, and configure IPv4/IPv6 settings to request DNS servers from the VPN or push routes.

Configuring with nmcli (example)

Use nmcli if you prefer scripted or headless setups. Below is an example for an EAP (username/password) IKEv2 connection:

nmcli connection add type vpn vpn-type strongswan con-name my-ikev2 ifname -- ipv4.method auto

Then set connection properties (replace values appropriately):

nmcli connection modify my-ikev2 vpn.data 'gateway=vpn.example.com,ike-proposal=aesgcm16-prfsha384-ecp521,aead=aesgcm16,dpd=yes,dpd-action=restart,dpd-delay=30s'

Set authentication:

nmcli connection modify my-ikev2 vpn.secrets 'eap=username,password=MySecretPassword'

Load and activate:

nmcli connection up my-ikev2

Note: property keys vary with plugin versions — run nmcli connection show --active and inspect the connection profile files in /etc/NetworkManager/system-connections/ to confirm options. The .nmconnection file contains clear fields for vpn.secrets and vpn.data.

Advanced IPsec/IKE parameters

Fine-tune the following parameters for security and interoperability:

  • Encryption/authentication: Use AES-GCM (AES-GCM-16) or CHACHA20-POLY1305 where available. For legacy peers, AES-CBC + SHA2 may be needed.
  • PRF and DH groups: Use PRF SHA2-256/384 and DH groups like MODP-3072, ECP-256/384 for better security.
  • SA lifetimes: Typical values: IKE SA 24h, Child SA 1h — adjust based on rekey frequency desired.
  • MOBIKE: Enabled by default in modern strongSwan; important for mobile clients.
  • DPD: Keep-alive/DPD settings to clean stale SAs (e.g., delay 30s, timeout 120s).

These can be set in the NetworkManager GUI or in vpn.data strings via nmcli. Consult your VPN server admin for compatible proposals.

Routing, DNS, and split tunneling

By default, pushing 0.0.0.0/0 routes forces all traffic through the VPN. For split tunneling, specify a subset of routes to tunnel. In NetworkManager:

  • Use IPv4 Method “Automatic (VPN) addresses only” if only DNS is needed.
  • Or manually add specific routes in the IPv4 tab of the VPN connection.

DNS integration: On systems using systemd-resolved, ensure NetworkManager is configured to update resolvectl. If DNS from VPN is not applied, check /etc/NetworkManager/NetworkManager.conf for the dns setting and verify systemd-resolved is active. You can also set a fallback global DNS in /etc/resolv.conf if necessary.

File locations and permissions

NetworkManager stores connection profiles in /etc/NetworkManager/system-connections/. Sensitive secrets such as PSKs or certificate passphrases may be stored here (with strict permissions). Ensure files are owned by root and mode 600. Example:

sudo chown root:root /etc/NetworkManager/system-connections/my-ikev2.nmconnection && sudo chmod 600 /etc/NetworkManager/system-connections/my-ikev2.nmconnection

Troubleshooting checklist

If the connection fails, use these steps:

  • Check NetworkManager and strongSwan logs: journalctl -u NetworkManager -f and journalctl -u strongswan -f (or charon logs under syslog).
  • Verify IKE negotiation: strongSwan logs will show proposals, selected transforms, and any authentication failures.
  • Confirm DNS and routing: ip route, ip -6 route, and resolvectl status to see DNS servers applied.
  • Check kernel IP forwarding if server side issues arise: sysctl net.ipv4.ip_forward and net.ipv6.conf.all.forwarding.
  • Ensure firewall/NAT rules allow UDP 500 and UDP 4500 (for NAT-T) and ESP (protocol 50) where necessary.
  • Validate certificates: expiration dates, CA trust chain, and that client cert CN/subjectAltName matches server expectations if enforced.

Security best practices

For production environments:

  • Prefer certificate-based or EAP with strong backend authentication (RADIUS with MFA where possible).
  • Use robust cipher suites (AES-GCM/CHACHA20-POLY1305 and strong DH groups).
  • Rotate keys and certificates on a regular schedule and maintain CRL/OCSP if feasible.
  • Limit VPN-allowed networks and enforce least-privilege routing and firewall rules.
  • Monitor connection logs and set alerts for repeated authentication failures or anomalous IP changes.

Example: common pitfalls

  • Server uses a stricter proposal than the client: adjust NetworkManager vpn.data proposals or ask the server admin to add compatible proposals.
  • Client time skew: certificates and IKE time-based checks can fail—keep system time synced via NTP/chrony.
  • Split DNS not applied: make sure the VPN connection is allowed to modify DNS settings and systemd-resolved is enabled.

Setting up IKEv2 with NetworkManager on Linux offers a powerful, manageable approach to secure VPN connectivity. By combining strongSwan’s robust IKE implementation with NetworkManager’s user-friendly configuration and nmcli scripting, administrators can support diverse use cases—from remote workforce access to automated service connections—while maintaining strong cryptographic posture and operational flexibility.

For more configuration examples, downloadable templates, and service-grade private IP options, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.