Related Ingenix tool
Build and validate a vendor-neutral VPN baseline in your browser.
In this guide
Key terminology
| Term | Meaning |
|---|---|
| Encryption | Transforms plaintext into ciphertext so unauthorised parties cannot read it without the required key. |
| Integrity | Provides confidence that protected data has not been modified. |
| AEAD | Authenticated Encryption with Associated Data: encryption and authentication in one construction. |
| DH | Diffie-Hellman key exchange used to establish shared keying material. |
| PFS | Perfect Forward Secrecy: uses fresh key exchange material for Child SA keys so compromise of long-term authentication material does not automatically expose past session keys. |
| Proposal | A set of cryptographic parameters a VPN peer offers or accepts. |
Authenticated encryption
AES-GCM provides encryption and authentication in one construction and is widely supported in modern VPN implementations. ChaCha20-Poly1305 is another modern authenticated-encryption design and can perform well on systems without suitable hardware acceleration.
With AEAD, do not configure a separate ESP integrity algorithm unless the specific implementation requires or exposes one for another reason. The important point is to understand what the selected suite actually provides rather than blindly copying settings from a different VPN platform.
Integrity and hashing
Hash functions and integrity algorithms are related but are not interchangeable concepts. In older IPsec designs, encryption and integrity may be separate parameters. In modern AEAD designs, authentication is integrated into the encryption construction.
Where a separate integrity or PRF setting is required, use a modern SHA-2 family option supported by both peers. Avoid obsolete MD5 and SHA-1 configurations for new deployments.
Diffie-Hellman and PFS
Diffie-Hellman allows peers to derive shared keying material without transmitting the resulting secret directly. The selected group affects security and computational cost.
PFS applies additional key exchange when creating or rekeying Child SAs. This limits the consequences of compromise of long-term authentication material. It can introduce additional interoperability and CPU considerations, so test it on the actual platforms.
Proposal design
A proposal is a compatibility contract between the peers. The strongest theoretical algorithm is not useful if the remote platform does not support it.
- Identify the capabilities of both peers.
- Choose a preferred modern suite.
- Keep the proposal list short rather than offering every legacy option.
- Separate IKE parameters from Child SA/ESP parameters.
- Document any compatibility fallback and why it exists.
- Remove the fallback when the legacy peer is retired.
| Parameter | Preferred direction | Engineering check |
|---|---|---|
| Encryption | AES-GCM where broadly supported. | Confirm hardware/software support. |
| Separate integrity | SHA-2 family. | Only where separate integrity is part of the selected design. |
| DH | Modern mutually supported group. | Balance security, interoperability and platform capability. |
| PFS | Enabled where appropriate. | Ensure both peers use compatible Child SA settings. |
Legacy algorithms
DES, 3DES and MD5 should not be retained simply for convenience. AES-CBC can appear for legacy interoperability, but AES-GCM is generally preferable where supported.
If a legacy algorithm is unavoidable, document the peer, business reason, scope, compensating controls and planned retirement date. Avoid creating a broad compatibility proposal that allows weak algorithms for every tunnel.
Operational considerations
Cryptography is only one part of VPN security. Review authentication, certificate/key lifecycle, access policy, endpoint posture, logging and incident response alongside the algorithm selection.
When troubleshooting a proposal mismatch, collect the exact negotiated or offered algorithms from both peers and compare them. A generic “no proposal chosen” message is less useful than knowing which parameter had no common value.
Do not collect or share private keys, pre-shared keys or reusable credentials when gathering evidence. See the IPsec VPN Engineering Guide and VPN Troubleshooting Guide for configuration and diagnostic context.