FortiGateEnable hybrid post-quantum key exchange (ML-KEM, RFC 9370) on FortiGate IPsec VPNs: FortiOS CLI configuration, testing, and the agentic MCP path with DuoKey.
If FortiGate is carrying your site-to-site VPN traffic, it is carrying exactly the kind of data an adversary would want to capture today and decrypt once a quantum computer can break classical key exchange: inter-site financial traffic, replication links, industrial control data, anything with a confidentiality shelf life measured in years. FortiOS 7.6.1 added post-quantum hybrid key exchange for IPsec to address that, but the configuration surface is easy to get wrong: the wrong FortiOS version, a missing childless-ike setting, or a group ID that does not mean what it meant on your last upgrade.
This guide covers exactly what FortiGate's PQC support does and does not cover, the FortiOS CLI to turn it on, a real known issue that looks like a PQC problem but is not, and the agentic MCP path that sidesteps the group-ID guesswork entirely.
FortiOS implements post-quantum cryptography for IPsec as a hybrid key exchange under RFC 9370, which extends IKEv2 to run multiple key exchanges inside a single IKE SA negotiation. A classical Diffie-Hellman group (dhgrp) still runs alongside one or more post-quantum key encapsulation mechanisms (KEMs): the session key is only as weak as the stronger of the problems an attacker has to break, not the weaker one, the same defense-in-depth logic every vendor uses for this transition.
Mechanically, FortiOS carries the extra key exchanges using the IKE_INTERMEDIATE exchange (RFC 9242) during initial SA setup, and IKE_FOLLOWUP_KE for additional key exchanges on IKE SA rekeys or new IKEv2 Phase 2 child SAs. You can configure up to three KE groups per round, across up to seven rounds (addke1 through addke7).
FortiGate's PQC support covers the IPsec VPN key exchange. It does not cover FortiGate's SSL-VPN or HTTPS management listener: FortiOS does not expose a post-quantum hybrid key exchange for TLS the way F5 BIG-IP does (see our F5 BIG-IP PQC guide for that surface specifically). If your PQC checklist includes "FortiGate's admin GUI and SSL-VPN portal," this feature does not get you there; it gets you quantum-resistant site-to-site and remote-access IPsec tunnels.
Supported KEMs beyond classical DH include ML-KEM (the NIST FIPS 203 standard, formerly Kyber), BIKE, HQC and FRODO. Of these, only ML-KEM is NIST-standardized and FIPS 203 compliant today; treat BIKE, HQC and FRODO as experimental unless your compliance requirement specifically calls for algorithm diversity beyond ML-KEM.
FortiOS 7.6.1 introduced PQC for IPsec key exchange. It requires IKEv2; IKEv1 does not support the additional key exchange mechanism at all.
Both tunnel endpoints must support RFC 9370 hybrid key exchange. This is not optional or backward-compatible in the way TLS hybrid groups can gracefully fall back: if the peer does not understand IKE_INTERMEDIATE, the additional key exchange simply will not negotiate, so plan FortiGate-to-FortiGate (or FortiGate-to-another-RFC-9370-capable-peer) tunnels first.
childless-ike must be enabled on the phase1-interface whenever you use additional key exchanges; it is required by IKE_INTERMEDIATE, not an optional hardening setting.
FortiOS supports IKE fragmentation per RFC 7383, enabled by default, which matters here because post-quantum key material is larger than classical DH and can otherwise hit UDP fragmentation limits during the handshake.
Site-to-site links carrying long-lived data. Inter-site financial transfers, database replication, backup traffic and industrial control links are exactly the "store now, decrypt later" targets described in our companion piece on the quantum threat: capture the ciphertext today, decrypt it once a cryptographically relevant quantum computer exists.
NIS2 and critical-infrastructure obligations. Fortinet's install base sits heavily in exactly the sectors NIS2 treats as critical or important entities. Demonstrating a tested, documented crypto-agility step on your site-to-site VPN estate is concrete evidence for the kind of supervisory conversation NIS2 pushes toward.
You already run FortiGate at both ends. The cleanest first rollout is FortiGate-to-FortiGate, where RFC 9370 support on both sides is guaranteed by the FortiOS version rather than something you have to verify against a third-party vendor's roadmap.
You're not ready if: any device in the tunnel path is below FortiOS 7.6.1, you're relying on IKEv1 anywhere in the estate, or you have not confirmed the peer's addke group IDs match yours for your specific FortiOS versions (see the caveat below).
PQC for IPsec requires IKEv2 and FortiOS 7.6.1 or later on every device in the tunnel path. Check your version before doing anything else, and confirm the existing phase1-interface is not still on ike-version 1.
config vpn ipsec phase1-interface
edit "pqc-tunnel"
set interface "wan1"
set ike-version 2
set peertype any
set remote-gw 203.0.113.10
set psksecret YOUR-PRESHARED-KEY
set dhgrp 21
set addke1 36 37
set childless-ike enable
set proposal aes256gcm-prfsha384 aes256-sha384
next
end
dhgrp 21 sets the classical group (NIST P-521 ECDH) that runs alongside the post-quantum exchange. addke1 36 37 offers ML-KEM-768 and ML-KEM-1024 as the first round of additional key exchanges; the peer negotiates down to whichever it supports. childless-ike enable is required here, not optional, because IKE_INTERMEDIATE depends on it.
Group ID numbers vary between FortiOS releases. As a starting reference: 36 maps to ML-KEM-768 and 37 to ML-KEM-1024 on the versions this guide was written against, but confirm the exact IDs for your FortiOS version in the Fortinet Document Library before deploying, and re-confirm after any FortiOS upgrade. This version drift is exactly what makes the agentic path below worth using instead of hardcoding numbers into scripts.
config vpn ipsec phase2-interface
edit "pqc-tunnel-p2"
set phase1name "pqc-tunnel"
set proposal aes256gcm
set dhgrp 20 21
set addke1 36 37
next
end
Phase 2's additional key exchange settings should match Phase 1's algorithm selections so rekeys and new child SAs get the same post-quantum protection as the initial handshake, not a silent downgrade.
Commit the configuration and bring the tunnel up from both ends. If either peer is not yet on a matching FortiOS version or does not have matching addke groups configured, the additional key exchange will fail to negotiate; see Common Challenges for what that looks like.
The manual path above has one real weak point: the numeric addke group IDs are not stable across FortiOS releases, so a script or runbook that hardcodes 36, 37, 1083 today can silently reference the wrong algorithm after an upgrade. DuoKey's MCP tools remove that entirely by taking algorithm names, not FortiOS-version-specific numbers.
list_fortinet_ipsec_gateways(target_id: "YOUR-FORTINET-TARGET-UUID")
Read-only, lists every IPsec phase1 (IKE gateway) name on the target so you pick the real one instead of guessing.
ensure_fortinet_mlkem_ipsec(
target_id: "YOUR-FORTINET-TARGET-UUID",
phase1_name: "pqc-tunnel",
kem_groups: ["ml-kem-768"]
)
This sets ML-KEM (or another supported KEM) as the IKEv2 additional key exchange on that phase1 gateway, the same RFC 9370 addke1..addke7 mechanism as the manual path, but addressed by algorithm name (ml-kem-768, ml-kem-1024, kyber768, frodo-l3, bike-l1, hqc192, and so on) rather than a version-specific group ID you have to look up and keep current. It's idempotent: re-running it to change the KEM list or after a FortiOS upgrade just reconciles the configuration, it does not duplicate settings.
This tool is explicitly scoped to the IPsec surface, the real FortiGate PQC surface described above, not the HTTPS or SSL-VPN TLS listener; FortiOS does not expose a PQC hybrid key exchange there, so there is nothing to configure on that surface regardless of tooling.
ensure_fortinet_mlkem_ipsec is outward-facing: it mutates a real FortiGate's configuration and requires the Operations.Pki.Deploy.ConfigureTarget permission. list_fortinet_ipsec_gateways is read-only and requires only Operations.Pki.Deploy.Read. Scope agent credentials the same way you would scope a human operator: read access for discovery and drift-checking, configure access only for whoever is authorized to change production tunnels.
diagnose debug application ike -1
diagnose debug enable
Bring the tunnel up (or trigger a rekey) and watch the debug output for the negotiated proposal. You are looking for both a classical DH_GROUP value and an ADDKE1 (or higher round) value corresponding to an ML-KEM group, confirming hybrid operation rather than a silent fallback to classical-only. Turn debugging off when you are done:
diagnose debug disable
A hybrid handshake only succeeds when both peers offer overlapping addke groups. If one side offers ml-kem-768 and the other only understands the group ID that used to mean ML-KEM-768 on an older FortiOS release, the negotiation fails rather than silently downgrading, which is the correct failure mode for a security feature, but means you should test this explicitly after any FortiOS upgrade on either end, not just at initial rollout.
Post-quantum key material is larger than classical DH. FortiOS enables RFC 7383 IKE fragmentation by default to handle this, but if you have hardened UDP fragmentation handling elsewhere in the path (a firewall, a NAT device, a cloud security group), confirm it still permits the larger IKE_INTERMEDIATE exchanges before rolling this out broadly.
This one runs in the opposite direction from everything above: it's not about configuring PQC on your own IPsec tunnels, it's about FortiGate failing to inspect other people's PQC-protected TLS traffic.
Modern browsers (Chrome 131+, Edge 131.0.2903.48+, Firefox 132.0+) now offer ML-KEM as a TLS 1.3 key exchange group by default. When FortiGate's flow-based SSL deep inspection intercepts one of these connections, older IPS engine versions do not recognize the ML-KEM group in the ClientHello and respond with a fatal "Illegal Parameter" TLS alert, which the browser shows as ERR_SSL_PROTOCOL_ERROR. Proxy-based deep inspection is not affected.
Fixed IPS engine versions (as of the initial advisory): 7.0189+ for FortiOS 7.0, 7.0353+ for FortiOS 7.2 (7.2.11 ships 7.0357), 7.0555+ for FortiOS 7.4 (7.4.6 ships 7.0559), and 7.1026+ for FortiOS 7.6 (the FortiOS 7.6.1 default).
Check your current IPS engine version with:
diagnose autoupdate versions | grep 'Attack Engine' -A 7
If you cannot update immediately, workarounds include switching the affected policy to proxy-based deep inspection or certificate inspection only, or adding a temporary SSL exemption for the affected sites. Disabling ML-KEM on the client side (chrome://flags, edge://flags) is a client-side workaround, not a fix, and is not viable at any scale; treat it as a stopgap, not a plan.
Start FortiGate-to-FortiGate. RFC 9370 interoperability is guaranteed within a matched FortiOS version pair; third-party peers are a separate compatibility question to validate before you depend on it.
Don't hardcode addke group IDs in scripts or runbooks. They are not stable across FortiOS releases. Either re-verify them against the Fortinet Document Library for your exact version at deploy time, or use the agentic path above, which takes algorithm names instead.
Match Phase 1 and Phase 2 algorithm selections. A Phase 2 that does not carry the same addke groups as Phase 1 means rekeys and new child SAs quietly lose the post-quantum protection the initial handshake had.
Patch your IPS engine even if you're not deploying PQC IPsec yet. The deep-inspection known issue above will affect you the moment your users' browsers start using ML-KEM by default, which for current browser versions is now, independent of anything you configure on FortiGate.
Treat this as the IPsec piece of a larger migration. FortiGate's PQC support does not extend to its own SSL-VPN or management TLS listener. If those are in scope for your migration, they need a different plan; this feature solves site-to-site and IPsec remote-access, not the whole estate.
Confirm both peers are on FortiOS 7.6.1 or later, both are on ike-version 2, and childless-ike is enabled on both phase1-interfaces. A mismatch in any of these causes the additional key exchange to fail outright rather than fall back gracefully.
The peer likely does not support RFC 9370 hybrid key exchange, or the configured addke1 groups do not overlap between the two sides. Re-verify the exact group IDs for both FortiOS versions independently; do not assume they match just because the same number was used on both sides.
This is very likely the deep-inspection known issue above, not an IPsec configuration problem. Check your IPS engine version before troubleshooting the VPN tunnel.
Almost always a group ID drift: the numeric value that meant ML-KEM-768 on the old version may not mean the same thing on the new one. Re-confirm the mapping for the upgraded version, or switch that tunnel to the agentic path so the algorithm name, not the number, is what gets configured going forward.
NIS2 critical-infrastructure obligations. A tested, documented PQC rollout on site-to-site IPsec tunnels, including which tunnels are covered and which are still classical-only, is concrete evidence for the crypto-agility conversation NIS2 pushes toward for essential and important entities.
"Store now, decrypt later" risk register entries. If your risk register includes harvest-now-decrypt-later exposure for site-to-site traffic, document which FortiGate tunnels this rollout covers and which remain on classical-only key exchange.
For the audit trail itself: document FortiOS version per device, the exact addke configuration (or, on the agentic path, the KEM names passed to ensure_fortinet_mlkem_ipsec), which tunnels are covered, and your interoperability testing results between peer pairs.
Q: What FortiOS version do I need for PQC on IPsec?
7.6.1 or later, on every device in the tunnel path. It also requires IKEv2; IKEv1 does not support the additional key exchange mechanism.
Q: Does this cover FortiGate's SSL-VPN or admin GUI?
No. FortiGate's PQC support is scoped to IPsec key exchange. FortiOS does not currently expose a post-quantum hybrid key exchange for TLS on the SSL-VPN portal or management interface.
Q: What's the difference between this and F5 BIG-IP's PQC support?
F5 BIG-IP's hybrid key exchange applies to TLS (client-ssl and server-ssl profiles, including SSL Forward Proxy on 21.1+). FortiGate's applies to IPsec (site-to-site and remote-access VPN key exchange), not TLS. They solve different parts of your estate; see our F5 guide for the TLS side.
Q: Why does my tunnel fail instead of falling back to classical key exchange?
Unlike TLS hybrid groups, which can negotiate down to a classical-only client, IPsec's additional key exchange either negotiates on both sides or the exchange fails outright. This is a deliberate protocol property, not a bug, so plan your rollout around peers you know support RFC 9370, not a hopeful fallback.
Q: Are the addke group ID numbers the same across FortiOS versions?
Not guaranteed. Group ID numbers have varied between FortiOS releases, which is exactly the problem DuoKey's ensure_fortinet_mlkem_ipsec tool avoids by taking algorithm names (ml-kem-768) instead of numeric IDs. If you script the manual CLI path, re-verify the mapping for your exact FortiOS version before deploying and again after any upgrade.
Q: I'm seeing ERR_SSL_PROTOCOL_ERROR on random websites since enabling deep inspection. Is that related?
Probably, but it runs the opposite direction: it's your flow-based deep inspection failing to parse other sites' ML-KEM TLS handshakes, not your own IPsec configuration. See the known issue above and check your IPS engine version.
Q: Can an agent configure this without me looking up group IDs myself?
Yes. ensure_fortinet_mlkem_ipsec takes a phase1_name and a list of KEM names and handles the rest, idempotently. list_fortinet_ipsec_gateways is a read-only companion tool for finding the right phase1 name first.
childless-ike is enabled on both phase1-interfacesaddke group selections match on each sidediagnose debug application ike, not just assumed it from a successful tunnel-upOnce your first FortiGate-to-FortiGate tunnel is stable, extend to the rest of your site-to-site estate, and separately plan for the surfaces this feature does not cover: SSL-VPN, management TLS, and any third-party peers that do not yet support RFC 9370.
Écrit par
Nagib Aouini
Related Resources
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
