Vendor compatibility
strongSwan post-quantum VPN support
strongSwan IKEv2 daemons on Linux and BSD, configured through swanctl or the legacy ipsec.conf interface, used as a software VPN gateway or as an overlay terminator.
Last reviewed
2 compatibility records
Direct answer
strongSwan is open source and configured entirely from text, which makes its capability easier to establish than an appliance's: the installed version and the compiled-in plugin set determine what is available. Establish the package version, the plugin set actually loaded, and the distribution's packaging decisions, because a distribution package may omit plugins present in the upstream release.
Practical status
What this means in a real estate
strongSwan is frequently the most tractable part of a mixed estate, and it is also frequently the answer to the least tractable part. Where an appliance cannot be upgraded, a strongSwan overlay gateway terminating a second tunnel behind the legacy device is often the cheapest path to a migrated connection. Establish the version and loaded plugins per host, and record whether hosts are configuration-managed, since a strongSwan fleet under Ansible is a very different change effort from a set of hand-maintained hosts.
What to establish about key exchange
Determine the installed strongSwan version, whether the plugins providing the relevant key exchange methods are compiled and loaded, and how the proposal syntax expresses additional key exchanges. Confirm against the running daemon rather than the package changelog, since distribution builds vary in which plugins they enable.
Why authentication is a separate question
Authentication configuration is independent of the key exchange proposal. A strongSwan connection using additional key exchanges continues to authenticate with its configured certificate or preshared key, and post-quantum authentication is a separate matter of certificate and signature algorithm support.
Products and versions
Compatibility records
Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.
| Product | Key establishment |
|---|---|
| strongSwan IKEv2 daemon | Post-quantum key establishment: Requires exact-version review |
| strongSwan IKEv2 daemon | Post-quantum key establishment: Unsupported |
strongSwan IKEv2 daemon
6.xWhat a strongSwan install can negotiate is determined by the version and by which plugins the build actually compiled and the daemon actually loaded. Confirm against the running daemon, not the upstream changelog.
Migration implication: strongSwan is often the cheapest overlay option for connections whose appliance cannot be migrated, so it is worth assessing even in estates that do not currently run it.
Caveats
- Distribution packages can lag upstream releases substantially
- Two builds of the same version number can have different plugin sets
Last reviewed · medium confidence · 2 sources
strongSwan IKEv2 daemon
5.9.xLong-term-support Linux distributions frequently ship a 5.9 series package well after newer upstream releases exist. Establish what the installed build supports rather than assuming the upstream position.
Migration implication: Where a distribution package is the constraint, the decision is between waiting for a backport, building from upstream, or moving the host to a newer base image — each with different operational ownership consequences.
Caveats
- Backports vary between distributions
- Building from upstream changes the support and patching model for that host
Last reviewed · medium confidence · 1 source
Prerequisites
Establish these before assessing migratability.
- strongSwan version per host, as installed rather than as packaged upstream
- The set of plugins actually loaded by the running daemon
- Distribution and package source, since builds differ in enabled plugins
- Configuration management coverage, if any
Peer compatibility
A tunnel is governed by the weaker of its two peers.
- Both peers must offer a compatible proposal; strongSwan will not negotiate a method the peer does not offer
- Where strongSwan terminates against an appliance, the appliance constrains the achievable proposal
- Overlay designs must account for the outer tunnel's own capability
Operational limitations
Constraints that shape the plan rather than block it.
- Distribution packages may lag upstream releases substantially
- Plugin availability differs between builds of the same version number
- Hand-maintained hosts carry configuration drift that must be resolved before migration
Migration paths
The routes available when the current state is not the target.
- Upgrade the package, or build from upstream where the distribution lags
- Enable the required plugins and restart the daemon
- Deploy strongSwan as an overlay gateway to migrate connections behind a legacy appliance
- Bring hosts under configuration management before migrating, where drift is significant
Verification requirements
What must be evidenced before a change is recorded as complete.
- Confirm the negotiated proposal on the established SA from the daemon's own status output
- Verify the loaded plugin list on the running daemon
- Capture evidence from both ends where both are under PQVPN or customer control
Sources
- 1. swanctl.conf reference(opens in a new tab)
strongSwan Project · verified by PQVPN
- 2. strongSwan releases(opens in a new tab)
strongSwan Project · verified by PQVPN
Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.
Related reading
- GuideOptions for Legacy VPN Gateways That Cannot Migrate
- GuideHybrid Post-Quantum IPsec in Practice
- GuideVerifying a Post-Quantum VPN Migration
- Standard · RFC 7296, RFC 8784, RFC 9242, RFC 9370IKEv2 Post-Quantum Migration: The Protocol Mechanisms Available
- Standard · RFC 9370Hybrid Key Establishment: Why Migrations Combine Classical and Post-Quantum
- Standard · FIPS 203ML-KEM (FIPS 203): What It Is and What It Means for VPN Migration
Need this mapped to your actual strongSwan estate?
A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.