Using ipsec.conf to Configure a Secure IPsec VPN

The suite of protocols grouped under strongSwan (and other IPsec systems) allows you to build robust, encrypted VPN tunnels between hosts or networks. One of the core configuration files in many Linux-based IPsec setups is the ipsec.conf file: it defines connections, cryptographic policies, IKE/IKEv2 parameters, traffic selectors, lifetimes and more. In this detailed article, we’ll go through everything from syntax and semantics to advanced features (certificates, NAT traversal, site-to-site subnets, fragmentation, DPD, logging) and end with a production-grade example. By the end you should have the technical understanding needed to craft secure IPsec VPN tunnels using ipsec.conf.

1. Overview of ipsec.conf Syntax & Sections

The ipsec.conf file is used by strongSwan (when operated in the legacy “starter” or stroke control interface mode) as well as by other IPsec implementations such as Libreswan. :contentReference[oaicite:2]{index=2} It is typically located at /etc/ipsec.conf and consists of distinct section types:

• config setup: Global configuration options, debug levels, plugin settings, default behaviour.
• conn <name>: One or more connection definitions; each defines a tunnel (or transport) with specific peers, sub-nets, algorithms, lifetimes, keyexchange type, etc.
• include directives: The file format supports inclusion of other files to modularise configuration. :contentReference[oaicite:3]{index=3}

Important notes: — Only a single config setup section is allowed (though you may split include files). :contentReference[oaicite:4]{index=4} — There can be many conn definitions. — Comments begin with a # and blank lines outside sections are ignored. :contentReference[oaicite:5]{index=5}

1.1 Example minimal structure

# ipsec.conf example config setup charondebug="ike 1, knl 1, cfg 0" uniqueids=no conn myvpn authby=secret keyexchange=ikev2 left=192.168.1.1 leftsubnet=0.0.0.0/0 right=192.168.2.1 rightsubnet=0.0.0.0/0 ike=aes256-sha2_256-modp2048 esp=aes256-sha2_256 keylife=3600 ikelifetime=28800 rekey=no keyingtries=1 

Note: some parameter names vary slightly depending on implementation/version. Always check your man pages: e.g. ipsec.conf(5). :contentReference[oaicite:6]{index=6}

2. Breaking Down Key Parameters

Let’s examine the important fields you’ll encounter in a conn section and what they mean.

Parameter	Purpose
authby	Defines how the peers authenticate. Common values: secret (pre-shared key / PSK), pubkey (certificate or RSA signature). Example: authby=secret.
keyexchange	Specifies use of IKE version: typically ikev2 (recommended) or ikev1. E.g., keyexchange=ikev2.
left, right	IP addresses (or hostnames) of VPN endpoints. “left” is local (client/gateway) side, “right” remote. Example: left=192.168.1.1.
leftsubnet, rightsubnet	Traffic selectors – what internal networks are tunneled. 0.0.0.0/0 means all traffic. Example: rightsubnet=0.0.0.0/0.
ike	Phase 1/IKE SA crypto parameters. Format often: <encryption>-<hash>-modp<DHgroup>. Example: ike=aes256-sha2_256-modp2048.
esp	Phase 2 / ESP (Encapsulating Security Payload) crypto algorithms. Example: esp=aes256-sha2_256.
keylife	Lifetime of the Child SA (Phase 2) in seconds. Example: keylife=3600.
ikelifetime	Lifetime of the IKE SA (Phase 1) in seconds. Example: ikelifetime=28800.
rekey	Whether to renegotiate keys when the SA expires. rekey=yes allows, no disables.
keyingtries	Number of attempts to establish the connection before giving up. Example: keyingtries=1.

Let’s comment further on some of those:

Phase 1/IKE configuration (“ike=”): You choose an encryption algorithm (e.g. AES 256), a hashing algorithm (e.g. SHA2_256) and a Diffie-Hellman group (modp2048 corresponds to group 14). Strong crypto parameters help resist attacks such as brute force or weak key exchange. Phase 2/ESP configuration (“esp=”): This determines how user data is encrypted after the tunnel is up. Matching secure choices with IKE parameters is important. Traffic selectors (leftsubnet/rightsubnet): These define which IP ranges are carried through the VPN vs which traffic stays plain. A very permissive value like 0.0.0.0/0 means “all traffic,” but this might not be appropriate in all situations. Authentication method (authby): Using PSK is easier but less scalable/trusted than certificates. Certificates allow stronger authentication, revocation, etc. Key lifetimes: A shorter keylife means more frequent renegotiation, which may increase overhead but reduces risk of key reuse. IKE lifetime is often much longer than ESP lifetime. Rekeying: Controls whether new key exchanges will happen automatically. Some sites disable rekeying for simplicity, but it may reduce resilience. Unique IDs / multiple tunnels: You may want to allow multiple connections per peer (see uniqueids in config setup) to avoid conflicts.

3. Recommended Additional Security Settings

Beyond the basics, a production-grade ipsec.conf should include enhanced settings for NAT-traversal, replay protection, logging/debugging, and connection hardening. Below are important knobs.

• NAT Traversal: If one or both peers sit behind NAT devices (common in home/office setups), enable nat_traversal=yes. This allows IPsec to use UDP encapsulation (typically port 4500) to traverse NATs. Without this, setting up the tunnel may fail when NAT is involved.
• DPD (Dead Peer Detection): Use parameters like dpddelay=30s, dpdtimeout=120s, dpdaction=clear to ensure that if the remote peer becomes unreachable, the SA is cleared and traffic stops rather than hanging.
• Fragmentation / Force Encapsulation: In environments with path MTU issues, using fragmentation=yes or forceencaps=yes can help prevent packet drops caused by packets larger than the path MTU.
• Logging: In config setup, set charondebug="ike 2, knl 1, cfg 1" (or higher) to capture relevant logs. More verbose logs help when diagnosing failures.
• Replay protection / Perfect Forward Secrecy (PFS): Choose modern DH groups (e.g., modp2048, modp3072, or elliptic-curve groups) and utilise PFS if required (e.g., pfs=yes). Also ensure algorithms offer replay protection (e.g., adding “+” to algorithm lists in some configs). Refer to strongSwan docs for specifics. :contentReference[oaicite:7]{index=7}
• Interface binding / Route installation: Some setups require specifying which interface to use (e.g., if multiple NICs). In strongSwan you may also control whether IPsec installs routes automatically; e.g., install_routes = no to disable legacy behaviour. :contentReference[oaicite:8]{index=8}

3.1 Example enhanced config snippet

# in ipsec.conf conn myvpn authby=secret keyexchange=ikev2 left=192.168.1.1 leftsubnet=10.0.1.0/24 right=203.0.113.5 rightsubnet=10.0.2.0/24 ike=aes256-sha2_256-modp2048 esp=aes256-sha2_256-modp2048 keylife=3600 ikelifetime=28800 rekey=yes keyingtries=3 nat_traversal=yes dpddelay=30s dpdtimeout=120s dpdaction=clear fragmentation=yes forceencaps=yes 

4. Certificate-Based Authentication (Pubkey) vs PSK

While PSK (pre-shared key) authentication may suffice for small or single-tunnel setups, larger deployments benefit from certificate (pubkey) authentication. Certificates enable stronger security, identity checks, revocation, and scale. The strongSwan documentation emphasises this. :contentReference[oaicite:9]{index=9}

4.1 Example config snippet using certificates

# ipsec.conf snippet conn certvpn authby=pubkey keyexchange=ikev2 leftcert=mycert.pem rightcert=remotecert.pem left=192.0.2.1 leftid="CN=myvpn.example.com" leftsubnet=0.0.0.0/0 right=198.51.100.2 rightid="CN=remote.example.com" rightsubnet=0.0.0.0/0 ike=aes256-sha2_256-modp3072 esp=aes256-sha2_256 keylife=7200 ikelifetime=86400 

Key points here: — Use authby=pubkey instead of secret. — The leftcert and rightcert parameters specify which certificates to use. — You may also specify leftid and rightid to ensure identity matching. — Diffie-Hellman group might be stronger (modp3072) for higher assurance.

When using certificates you must of course ensure your certificate authority (CA) chain is set up correctly, certificates have proper validity periods and revocation (CRLs/OCSP) as needed. strongSwan supports these features. :contentReference[oaicite:10]{index=10}

5. Site-to-Site VPNs & Multiple Subnets

In scenarios where you connect entire networks (site-to-site), you’ll often configure leftsubnet/rightsubnet to non-zero values that specify the internal networks behind each gateway. For example:

# ipsec.conf snippet – site-to-site conn branchoffice authby=secret keyexchange=ikev2 left=198.51.100.1 leftsubnet=10.10.1.0/24 right=203.0.113.5 rightsubnet=10.20.1.0/24 ike=aes256-sha2_256-modp2048 esp=aes256-sha2_256 keylife=3600 

Here we are securely tunnelling traffic between the 10.10.1.0/24 and 10.20.1.0/24 networks via their respective public gateways. Using this traffic-selector approach ensures only defined networks are carried, reducing attack surface and simplifying routing. The example above aligns with best practices in production IPsec VPNs. Also, using exact subnets rather than 0.0.0.0/0 means you are not proxying *all* traffic unnecessarily.

6. Applying and Verifying the Configuration

Once the ipsec.conf (and optionally ipsec.secrets) is fully configured, follow these steps to apply and verify:

1. Restart or reload the IPsec daemon:

   sudo systemctl restart strongswan-starter # or whichever service your distro uses sudo ipsec restart # sometimes the command variant

2. Check connection status:

   sudo ipsec statusall sudo ipsec status

   You should see the defined conn name, the IKE SA and the Child SA negotiations. For example:

   Security Associations (1 up, 0 connecting): branchoffice[1]: 198.51.100.1...203.0.113.5 IKEv2, ESP in AES256-SHA2_256

3. Test connectivity: From one internal subnet, ping a host in the other subnet. Check logs (e.g., /var/log/auth.log or <code/journalctl-u strongswan-starter) for any errors, such as mismatched proposals, NAT issues, certificate problems.
4. Fine-tune: Once operational, monitor latency, throughput, rekeying behaviour, packet drop counters. Adjust lifetimes, keyingtries, DPD parameters, fragmentation as needed.

7. Performance, Tuning & Best Practices

When operating an IPsec VPN in a production environment (especially site-to-site with heavy traffic), the following tuning guidelines apply:

• Choose modern cryptography: Use AES­GCM (if supported), SHA-2 family, and strong DH groups (e.g., modp2048, modp3072, or even elliptic curve groups). Weak proposals cause negotiation failure or allow downgrade attacks.
• Reuse connections / Keep-alive: Ensure NAT-Traversal (if needed) is enabled, use mobike=yes if mobile endpoints, and use correct DPD settings so stale SAs clear out.
• Fragmentation handling: Enabling fragmentation=yes and/or forceencaps=yes helps in environments with nested tunnels or low MTU paths.
• Route optimization: Rather than routing all traffic (0.0.0.0/0) through the tunnel, define specific subnets where possible to reduce overhead and attack surface.
• Monitor logs & metrics: Use charondebug in config setup to capture vital logs, and use monitoring tools to watch SA counts, rekeys, and dropped packets.
• Secure your keys/certs: Store private keys securely (e.g., using HSM/PKCS#11 if supported), restrict file permissions, rotate PSKs/certs periodically.
• Avoid mixing legacy and modern interfaces: Note that strongSwan documentation states that ipsec.conf (legacy) is deprecated and newer setups should use swanctl.conf. :contentReference[oaicite:11]{index=11} If you are setting up a new deployment, consider using the modern interface instead of legacy ipsec.conf.

8. Full Example Configuration (Production-Grade)

# /etc/ipsec.conf – full example config setup charondebug="ike 2, knl 1, cfg 1, enc 0" uniqueids=yes strictcrlpolicy=yes conn site2site1 auto=start type=tunnel keyexchange=ikev2 authby=pubkey left=198.51.100.1 leftid="C=US, O=MyOrg, CN=gw1.myorg.com" leftcert=gw1Cert.pem leftsubnet=10.10.1.0/24 right=203.0.113.5 rightid="C=US, O=MyOrg, CN=gw2.myorg.com" rightcert=gw2Cert.pem rightsubnet=10.20.1.0/24 ike=aes256gcm16-sha384-ecp384!modp3072 esp=aes256gcm16-sha384-ecp384!modp3072 pfs=yes keylife=3600s ikelifetime=86400s rekey=yes dpddelay=30s dpdtimeout=120s dpdaction=clear fragmentation=yes forceencaps=yes mobike=no install_routes=yes 

In this example: — We use certificate-based authentication for strong identity assurance. — We choose AES-GCM (with 16 byte tag) and SHA-384, a modern elliptic-curve DH group (ecp384), and fallback/modp3072 for compatibility. — Perfect Forward Secrecy (PFS) is enabled. — DPD is configured so that stale SAs are removed after ~120s of unresponsiveness. — Routing is enabled automatically. — Fragmentation and forced encapsulation guard against MTU issues and nested tunnels.

9. What’s Next: Migration to Modern Control Interface

A key consideration: the strongSwan project now recommends moving away from the legacy ipsec.conf + starter/stroke interface and instead using the modern swanctl.conf (via the VICI interface). :contentReference[oaicite:12]{index=12} If you are deploying new systems, this may be the better long-term path. However, many existing environments still use ipsec.conf, so knowing it remains valuable.

If you plan to migrate, then you’ll translate your ipsec.conf connections into swanctl.conf syntax, adjust package dependencies and the control daemon accordingly. There are several migration guides available. :contentReference[oaicite:13]{index=13}

10. Summary

Configuring a secure IPsec VPN using ipsec.conf involves a deep understanding of the syntax and semantics of its sections, connection definitions, encryption/authentication parameters, traffic selectors, lifetimes and supplementary features (DPD, NAT-T, fragmentation, routing). Key takeaways:

• Use config setup for global parameters (debug, unique IDs, strict policies).
• Define a conn section per tunnel or endpoint pair; specify left/right, subnets, algorithms, keyexchange mode.
• Choose strong cryptography: AES 256 or AES-GCM, SHA2/384, modern DH groups (or elliptic curve if supported).
• Enable additional protection: NAT traversal, DPD, fragmentation, forced encapsulation, PFS.
• Prefer certificate‐based authentication for scalable/secure setups; PSK may suffice only for small/simple use cases.
• In site-to-site deployments, restrict traffic selectors to the minimal required subnets rather than 0.0.0.0/0.
• Monitor logs, tune key lifetimes, rekey behaviour, and routing installation for performance and resilience.
• Be aware of the legacy status of ipsec.conf and evaluate migration to swanctl.conf for future-proofing.

By following these principles and leveraging the examples above, you can build strong, performant, secure IPsec VPN tunnels using the ipsec.conf configuration file. The flexibility of strongSwan and the maturity of the IPsec protocol make this a robust foundation for secure network connectivity.

External resources & manuals

• strongSwan: conn section reference (ipsec.conf)
• ipsec.conf(5) manual page – strongSwan
• strongSwan configuration files overview
• Migration guide: ipsec.conf → swanctl.conf