A hands-on lab walks through mutual authentication over an IKEv2 tunnel using two Docker containers, first with classical ECDSA certificates on stable strongSwan, then with post-quantum ML-DSA-44 certificates on strongSwan's experimental ml-dsa branch. Both runs use an ML-KEM-based hybrid key exchange, but only the second achieves fully post-quantum authentication. The ML-DSA leaf certificate plus signature balloons the IKE_AUTH message to about 6.9 KB, splitting into 6 fragments versus a single ~900-byte packet for ECDSA, illustrating why fragmentation support is essential and where current reassembly bugs live. The piece closes by noting that ML-DSA authentication is only available on an experimental branch, the composite/hybrid signature work is separate, and the IETF wire-format draft is still evolving, so post-quantum IKEv2 authentication remains an emerging capability rather than production-ready.
Table of contents
Clone the repoHow the trust worksExercise A: Classical mutual auth with ECDSAExercise B: Post-quantum auth with ML-DSAWatch the certs blow it upCleanupWhere IKEv2 authentication actually stands todayLook how far we’ve come in this blog seriesQuestions this post answers
Can I authenticate a strongSwan IKEv2 VPN with ML-DSA today?
Yes, but only on strongSwan's experimental ml-dsa branch (PR #2626), not in the stable 6.0.x release line. The branch supports mldsa44/65/87 key types through its pki tool, and swanctl.conf needs no changes since auth = pubkey is algorithm-agnostic and detects the key type from the certificate. Composite/hybrid signatures are being developed separately on a pq-composite-sigs branch, and the IETF IKEv2 PQC-auth wire format draft is still evolving. Track strongSwan's post-quantum authentication progress on daily.dev before betting a VPN rollout on it.
Why does ML-DSA certificate authentication in IKEv2 need message fragmentation?
An ML-DSA-44 leaf certificate (roughly 4 KB DER) plus its signature pushes the IKE_AUTH message to about 6.9 KB, which splits into 6 fragments on the wire, compared to a single ~900-byte unfragmented packet for the ECDSA equivalent. This size explosion is why fragmentation = yes is required, and larger variants like ML-DSA-65/87 or an added intermediate CA can push the fragment count into known strongSwan reassembly bugs (issue #2889). Developers sizing post-quantum VPN handshakes can follow fragmentation gotchas like this on daily.dev.
Is the ML-KEM key exchange in strongSwan already usable in production?
Yes, ML-KEM-based hybrid key exchange (for example CURVE_25519/KE1_ML_KEM_768) ships in stable strongSwan and works out of the box, unlike post-quantum authentication which remains experimental. This means the key-exchange side of an IKEv2 tunnel can already be made quantum-safe today while the certificate-based authentication side still relies on classical ECDSA in real-world deployments. Follow which post-quantum VPN building blocks are production-ready versus experimental on daily.dev.