What it is¶

strongSwan is an IPsec implementation for Linux. This page documents a client setup against a corporate-style gateway using IKEv1 with a client certificate plus XAUTH (username/password), which is a common legacy remote-access design. New deployments should prefer IKEv2 (keyexchange=ikev2) and modern ciphers; the layout below still applies.

Hostnames, subnets, and account names are placeholders. Substitute your own.

Install¶

# Debian / Ubuntu
sudo apt-get install strongswan strongswan-pki libstrongswan-extra-plugins libcharon-extra-plugins

# Fedora / RHEL
sudo dnf install strongswan

Package and plugin names vary by release. The eap/xauth plugins may be bundled or split out. Fedora keeps config under /etc/strongswan/ (for example /etc/strongswan/ipsec.conf and /etc/strongswan/ipsec.d/); Debian/Ubuntu use /etc/ipsec.conf and /etc/ipsec.d/.

Convert the certificates¶

You need your user certificate bundle (PKCS#12, .pfx), its password, and the CA certificate that signed the gateway's certificate.

# Private key (asks for the .pfx password, then a new passphrase for the key)
sudo openssl pkcs12 -in user.pfx -nocerts -out /etc/ipsec.d/private/user.key

# User certificate
sudo openssl pkcs12 -in user.pfx -nokeys -out /etc/ipsec.d/certs/user.crt

# CA certificate (DER -> PEM)
sudo openssl x509 -inform der -in ca.cer -out /etc/ipsec.d/cacerts/gateway-ca.pem

sudo chmod 600 /etc/ipsec.d/private/user.key

/etc/ipsec.conf¶

config setup
    charondebug="ike 1, knl 1, cfg 0"

conn %default
    ikelifetime = 1440m
    keylife = 60m
    rekeymargin = 3m
    keyingtries = 1
    keyexchange = ikev1
    ike = aes256-sha256-modp2048!
    esp = aes256-sha256
    fragmentation = force

conn site-a
    auto = route
    compress = no
    dpdaction = clear
    type = tunnel
    leftsourceip = %config
    leftsubnet = 192.168.253.0/24
    leftfirewall = no
    leftauth = pubkey
    leftauth2 = xauth
    leftid = "CN=Your Name, [email protected]"
    leftcert = /etc/ipsec.d/certs/user.crt
    leftsendcert = always
    right = vpn.example.com
    rightid = "CN=*.example.com"
    rightauth = pubkey
    rightca = /etc/ipsec.d/cacerts/gateway-ca.pem
    rightsubnet = 10.0.0.0/8
    xauth = client
    xauth_identity = your-username

The ike/esp proposals must match what the gateway accepts. The legacy examples in older guides use aes192-sha256-modp1024, and 1024-bit Diffie-Hellman is weak by today's standards. Use it only if the gateway leaves you no choice. To reach several gateways (primary and secondary sites), add one conn block per gateway, changing right, the subnets, and leftdns where needed. Share the conn %default block rather than repeating it.

/etc/ipsec.secrets¶

: RSA /etc/ipsec.d/private/user.key "private-key-passphrase"
your-username : XAUTH "your-directory-password"

This file holds credentials in cleartext, so make it chmod 600, root-owned. Some deployments leave the XAUTH line out and let the client prompt instead.

Bring the tunnel up and down¶

sudo ipsec restart
sudo ipsec up site-a
sudo ipsec down site-a

Status and troubleshooting¶

sudo ipsec status
sudo ipsec statusall
sudo ip xfrm state          # kernel security associations
sudo ip xfrm policy         # kernel policies deciding what is encrypted
journalctl -u strongswan --since "10 min ago"

Raise charondebug levels (for example ike 2, cfg 2) while diagnosing failures and lower them again afterwards, since high levels log sensitive details. Fragmentation and MTU issues on IPsec paths look like "connects but large transfers hang". See the MTU guide.