IPsec predates both WireGuard and OpenVPN by years and remains the default choice for a lot of site-to-site and mobile-device VPN deployments, largely because IKEv2 is natively supported by iOS, macOS, Windows, and Android without installing any additional client software. Its configuration syntax — a dense, hyphen-separated string like aes256-sha256-modp2048 — packs several independent cryptographic choices into one line, which makes it easy to configure without fully understanding, and easy to get subtly wrong in a way that still connects successfully. This post breaks that string down piece by piece.
Two negotiations, not one
IPsec/IKEv2 separates its work into two distinct security associations. The IKE_SA is the initial authenticated channel two peers establish first — it always includes a Diffie-Hellman exchange, verifies each side's identity (certificate or pre-shared key), and exists to negotiate everything that follows securely. The Child SA is what actually carries traffic afterward, using ESP (Encapsulating Security Payload) to encrypt and authenticate real packets. Each gets negotiated with its own proposal string — in strongSwan configuration, ike= for the IKE_SA and esp= for the Child SA — and they're free to use entirely different algorithms.
Anatomy of a proposal string
ike=aes256-sha256-modp2048!Read left to right: aes256 is the encryption algorithm and key size — AES with a 256-bit key. sha256 here serves as both the integrity algorithm and (implicitly, in strongSwan's shorthand) the PRF (pseudorandom function) used to actually derive keying material during the exchange — some configs make the PRF explicit with a separate prfsha256 token instead. modp2048 is the Diffie-Hellman group: a 2048-bit finite-field group, the current baseline most hardening guides recommend. The trailing ! marks the list as strict — connect using exactly one of the listed proposals, or fail, rather than silently falling back to a broader implementation default.
AEAD ciphers simplify the string
ike=aes256gcm16-prfsha384-ecp384!AES-GCM (and ChaCha20-Poly1305) are AEAD ciphers — they provide integrity as part of encryption itself, so a separate integrity algorithm isn't needed. Because the PRF still has to be specified independently for key derivation (it's a different job from integrity), AEAD proposals commonly use the explicit prf... form rather than letting one digest serve double duty the way sha256 does in a non-AEAD proposal. ecp384 here is an elliptic-curve Diffie-Hellman group — roughly comparable in strength to a much larger MODP group, at lower computational cost.
Diffie-Hellman groups and Perfect Forward Secrecy
The DH group is what actually provides PFS (Perfect Forward Secrecy) — the property that even if a long-term key is later compromised, past session traffic captured earlier can't be decrypted retroactively, because each session's actual encryption keys were derived from a fresh, ephemeral exchange rather than the long-term key directly. This matters at two different levels: the IKE_SA's own DH group protects the control channel's forward secrecy, while a DH group specified again inside a Child SA proposal gives that specific data tunnel its own independent forward secrecy — commonly omitted from ESP proposals for performance, in which case that Child SA relies on the parent IKE_SA's protection instead of getting a fresh exchange of its own.
Group strength varies enormously across what's still technically valid syntax: modp768 and modp1024 date to the original IPsec RFCs from the 1990s and are considered breakable by a sufficiently resourced attacker today. modp2048 is the current practical minimum most guidance converges on; modp3072, modp4096, and the elliptic-curve groups (ecp256, ecp384, ecp521) all exceed it by a comfortable margin.
Multiple proposals: offering alternatives, not requiring all of them
ike=aes256gcm16-prfsha384-ecp384,aes256-sha256-modp2048!A comma-separated list offers several acceptable combinations, and the two peers agree on whichever one both sides support — useful during a migration from an older cipher to a newer one, letting old and new clients connect through the same server config without a hard cutover. This is different from AND-ing every listed algorithm together; each comma-separated entry is a complete, independent proposal a peer can pick in full.
Authentication: certificates vs. pre-shared keys
The proposal string covers what encrypts and authenticates the traffic once a connection exists, but a separate setting — authby in strongSwan — determines how the two peers prove their identity to each other in the first place. A pre-shared key (authby=secret) is the simplest option: both sides configure the same secret string ahead of time, which works well for a small, fixed number of site-to-site connections but scales poorly and offers no way to tell peers apart if the same key is reused across more than one of them. Certificate-based authentication (authby=rsasig or authby=pubkey) scales better for anything with more than a handful of peers — each gets its own certificate signed by a shared CA, which can be individually revoked without touching any other peer's configuration, the same operational advantage individual SSH keys have over a single shared password.
A pre-shared key used with IKEv1's now-deprecated Aggressive Mode had a genuine, well-documented weakness: part of the exchange included a hash derived from the PSK that an eavesdropper could capture and attack offline, effectively turning PSK strength into a crackable password problem. IKEv2 removed Aggressive Mode entirely, which is one of several concrete reasons IKEv2 is the safer default over IKEv1 wherever both ends support it.
Checking what actually got negotiated
Because a proposal string only describes what's offered, confirming what a live connection actually settled on needs a look at the running daemon rather than the config file alone:
# strongSwan
sudo ipsec statusall
sudo swanctl --list-sasBoth report the live IKE_SA and Child SA state for each active connection, including exactly which encryption, integrity, and DH group were actually agreed on — the authoritative answer when a config offers several alternatives and you need to know which one two specific peers actually ended up using, rather than assuming it's the strongest option in the list.
Common mistakes
- A strong IKE_SA proposal paired with a weak ESP proposal, or vice versa. The two are negotiated independently — hardening one says nothing about the other.
- Carrying forward modp1024 from an old config. Valid syntax, silently weak; nothing about a successful connection reveals which DH group was actually used.
- Omitting the trailing ! and assuming the exact listed proposal is what gets used. Without it, many implementations fall back to a broader default list if negotiation with the exact proposal fails.
- Pairing an AEAD cipher with a redundant separate integrity algorithm. Not wrong, just unnecessary — the AEAD cipher already provides it.
FAQ
What's the difference between IKEv1 and IKEv2?
IKEv2 (2005, refined since) simplified the negotiation process, added built-in support for NAT traversal and mobility (a connection surviving a change of IP address, useful for mobile devices switching networks), and fixed several IKEv1 weaknesses — Aggressive Mode in particular, which could leak a hash usable for offline password-guessing against pre-shared-key authentication. Nearly all current deployments should use IKEv2; IKEv1 support mostly remains for legacy hardware.
Why does ESP need its own proposal separate from IKE's?
The IKE_SA (the control channel) and the Child SA (the actual data-carrying tunnel, via ESP) are cryptographically independent — negotiated separately and free to use different algorithms. In practice, a strong IKE_SA paired with a weak ESP proposal (or vice versa) is a real, if easy-to-overlook, way for a config to be strong on one side and weak on the other.
What does the exclamation mark (!) at the end of a proposal string mean?
In strongSwan configuration, it marks a proposal list as strict — the connection will only use one of the exact listed proposals and refuse to fall back to any implementation default. Without it, most implementations fall back to a broader default list if none of the specified proposals are acceptable to the peer, which can silently negotiate a weaker cipher than the one explicitly configured.
Is Perfect Forward Secrecy the same thing as the Diffie-Hellman group in a Child SA proposal?
Closely related but not identical. Including a DH group in a Child SA (ESP) proposal is what actually provides PFS for that specific tunnel — it performs a fresh key exchange rather than deriving keys purely from the IKE_SA's existing material. Omitting the DH group from an ESP proposal (valid syntax, and common for performance) means that Child SA doesn't get its own PFS, relying instead on whatever protection the parent IKE_SA's own DH exchange already provided.
Are elliptic-curve DH groups (ecp256, ecp384) actually stronger than MODP groups?
For equivalent security, yes, using meaningfully shorter keys — a 256-bit elliptic-curve group is roughly comparable in strength to a 3072-bit MODP group, with less computational cost per operation. The tradeoff is that elliptic-curve implementations require careful, constant-time code to avoid side-channel leaks, a concern MODP groups don't share to the same degree; both are considered acceptable choices in a modern configuration when paired with adequate parameters.
Try it yourself
IPsec/IKEv2 Proposal Strength Checker breaks down any ike=/esp= proposal string and flags weak ciphers, digests, and DH groups, entirely in your browser.