Post-quantum IPsec NAT traversal firewall ports to open

Post-quantum IPsec NAT traversal means running an IKEv2 IPsec tunnel whose key exchange includes a post-quantum algorithm such as ML-KEM (FIPS 203) across one or more NAT devices, using UDP encapsulation on port 4500 as defined in RFC 3948. It covers which firewall ports to open, how large key exchange messages get fragmented, and which keepalive settings keep the tunnel up.

For operators of OT and critical infrastructure the question is practical, not academic. Substations, pumping stations, wind parks and remote telemetry sites often connect over consumer broadband, mobile networks or satellite links. Those links put NAT, sometimes several layers of it, between the site and the control centre. Adding ML-KEM to IKEv2 does not change the ports, but it does change the size and number of messages. Those are exactly the things that NAT devices and middleboxes handle badly.

Which firewall ports and protocols must be open for a post-quantum IKEv2 IPsec tunnel?

A post-quantum IKEv2 tunnel needs the same ports as a classical one: UDP 500 and UDP 4500 in both directions between the peers, plus IP protocol 50 (ESP) only when no NAT sits on the path. The post-quantum part travels inside IKE messages, so it adds no new ports.

RFC 7296 (IKEv2) starts every negotiation on UDP 500. Once the peers detect NAT, they move to UDP 4500, and RFC 3948 then carries both IKE and ESP on that one port. The authors of RFC 3948 chose port sharing because it means only one NAT mapping and, in their words, “only one port to be configured in firewalls”.

Two OT-specific points apply here. First, on a site firewall the rule should be pinned to the hub’s public address, not opened to any source. Second, if a site router has an “IPsec passthrough” or IKE helper feature, test with it disabled. Those helpers were written for older IKE behaviour and can get in the way of the port change to 4500.

Does ML-KEM key exchange work through NAT-T on UDP 4500?

Yes. In a standards-based hybrid design the ML-KEM exchange happens after the switch to UDP 4500, inside encrypted IKE_INTERMEDIATE messages, so NAT traversal treats it like any other IKE traffic.

The sequence is defined by RFC 9370 (Multiple Key Exchanges in IKEv2) and RFC 9242 (the IKE_INTERMEDIATE exchange). IKE_SA_INIT runs on UDP 500 with a classical key exchange and the NAT detection payloads. If NAT is found, the next messages move to UDP 4500 with the four-byte non-ESP marker from RFC 3948. Then, as RFC 9370 puts it, one or more IKE_INTERMEDIATE exchanges “are carried out, each of which contains an additional key exchange”, and this is where ML-KEM goes. IKE_AUTH follows, and ESP traffic flows on the same 4500 mapping.

The reason for this design is size. ML-KEM is much larger than an elliptic-curve key share:

• FIPS 203 published: 13 August 2024, with three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024 (NIST, 2024).
• ML-KEM-768 sizes: a 1,184-byte encapsulation key and a 1,088-byte ciphertext (NIST FIPS 203, 2024).

IKE_SA_INIT is unencrypted and cannot use RFC 7383 fragmentation. IKE_INTERMEDIATE messages are encrypted, so they can. The RFC 9370 draft explains that the additional exchanges use IKE_INTERMEDIATE because, “because these messages are encrypted, the standard IKE fragmentation mechanism is available.”

Why do post-quantum IKE_INTERMEDIATE exchanges fail through some NAT devices?

Most failures come from IP fragmentation. When an IKE_INTERMEDIATE message carrying ML-KEM is bigger than the path MTU and IKE fragmentation is off, the IP layer fragments it, and many NATs drop those fragments.

Dropped IP fragments

Valery Smyslov, author of RFC 7383 (IKEv2 Message Fragmentation), states the problem directly: “some network devices, specifically some NAT boxes, do not allow IP fragments to pass through.” Non-initial fragments carry no UDP port numbers, so a NAT keyed on ports cannot match them to a mapping. The symptom is easy to spot: IKE_SA_INIT succeeds, then the initiator keeps retransmitting the first IKE_INTERMEDIATE request until it times out. The fix is to make sure both peers advertise IKE fragmentation support in IKE_SA_INIT and to set a fragmentation threshold that stays below the smallest path MTU you expect, including mobile backup links.

Tunnels inside tunnels

OT links often already run over an underlay: a carrier MPLS service, a PPPoE line, an LTE APN with its own GTP encapsulation, or a satellite modem. Each layer reduces the usable MTU. A threshold that works on the primary fibre may fail on the cellular backup. Set the threshold for the worst path, not the typical one.

Middleboxes that parse IKE

Some NAT routers and firewalls inspect IKE on port 500 and track sessions using older assumptions. RFC 3947 already advised moving IKE “off port 500 as soon as possible to avoid any IPsec-aware NAT special casing.” A helper that does not recognise the IKE_INTERMEDIATE exchange type, or that only opens a pinhole for port 500, can block the exchange right after the port switch. Turning off the helper, or allowing UDP 4500 explicitly, usually solves it.

Retransmission timing on lossy links

A hybrid handshake adds at least one round trip, and fragmented messages multiply the number of packets that all have to arrive. On a lossy radio link, one lost fragment means retransmitting the whole message. Generous retransmission timeouts on the initiator help more than aggressive ones.

How do I build a quantum-safe site-to-site tunnel when the remote site is behind carrier-grade NAT?

Make the remote site the permanent initiator and the hub, with a stable public address, the responder. Authenticate both ends by identity, not by IP address, and design for the NAT mapping to change at any time.

Behind carrier-grade NAT the remote site has neither a public address nor a reachable port. In practice, that leads to the following design:

1. Direction: only the remote site initiates. Configure the hub so it never tries to initiate or re-establish towards that peer, because those attempts can never reach it.
2. Identity: use certificate or FQDN-style IKE identities. The source address and port seen by the hub belong to the carrier, change over time, and may be shared with other subscribers.
3. Encapsulation: expect UDP 4500 throughout. Even on IPv6 mobile service, where there is no NAT, operator firewalls may not pass raw ESP, so forcing UDP encapsulation is often the more reliable choice.
4. Fragmentation: enable RFC 7383 with a conservative threshold, as described above.
5. Fallback transport: if a carrier blocks UDP, TCP encapsulation on port 4500 (RFC 8229) is the last resort. It costs performance, and the IETF text says direct ESP or UDP encapsulation should be preferred.
6. Address changes: RFC 7296 lets the responder update the peer address when NAT mappings change. Check that the hub accepts this, so a carrier-side remap does not force a full renegotiation.

Remote-access users face the same constraint as CGN sites: they sit behind networks they do not control. Quantum Network’s QPN software client for Windows and macOS needs no incoming firewall ports, which matches the “client always initiates” principle above.

How should NAT keepalives and dead peer detection be set for quantum-safe tunnels to unmanned sites?

Set NAT keepalives on the side behind NAT to fire well inside the shortest mapping timeout on the path. Treat dead peer detection as a separate mechanism, and let the remote site restart the tunnel when it detects a failure.

The baseline values come from the IETF:

• NAT-keepalive default: 20 seconds without other traffic before a peer behind NAT sends a keepalive (RFC 3948, January 2005).
• NAT UDP mapping lifetime: must not expire in less than 2 minutes, with 5 minutes recommended as default (IETF BEHAVE draft on NAT UDP behaviour, January 2005).

Carrier-grade NATs and some mobile networks do not always meet those recommendations. Before rolling out to a fleet of unmanned sites, measure the real idle timeout on each carrier type. Leave a test tunnel idle with keepalives disabled and see when inbound traffic from the hub stops arriving. Then set the keepalive interval comfortably below the shortest value you saw.

Practical settings for unmanned sites:

• Remote site: DPD enabled, with the action set to restart, so the site re-initiates the full hybrid handshake by itself after an outage. Nobody is on site to do it.
• Hub: DPD enabled, with the action set to clear state only. The hub cannot reach a peer behind CGN, so a restart action just produces failed attempts.
• DPD timing: on radio and satellite links, use longer intervals and more retries than on fibre, so brief fades do not cause needless renegotiation. Each renegotiation sends ML-KEM payloads again.
• Rekeying: RFC 9370 also lets CREATE_CHILD_SA rekeys carry additional key exchanges. Those messages are encrypted and can be fragmented, but on large fleets you should stagger rekey timers so hundreds of sites do not hit the hub at the same moment.
• Monitoring: alert on repeated IKE_INTERMEDIATE retransmissions, not just on tunnel down. Retransmissions are the early sign of an MTU or fragmentation problem.

Some purpose-built gateways handle this cycle by design. QPN from Quantum Network, for example, renews both its classical and its ML-KEM handshake every two minutes. After a line failure it retries automatically, without user action and without ever falling back to unencrypted traffic, which is the recovery behaviour an unmanned site needs.

Why should OT operators fix NAT traversal for post-quantum tunnels now?

Migration timelines are fixed and long, and site connectivity problems are cheaper to solve before a deadline than during one. The NAT behaviour described above is what usually separates a lab success from a fleet rollout.

• NIST transition schedule: quantum-vulnerable public-key cryptography is deprecated after 2030 and disallowed under NIST standards and guidelines after 2035 (NIST IR 8547, 2026).
• Historical pace: previous cryptographic transitions have taken 10 to 20 years (NIST IR 8547, 2026).
• Threat estimate: experts expect quantum computers able to break many common forms of cryptography between 2030 and 2040 (NCSC-NL and AIVD, March 2024).

NIST’s report puts it plainly: “Organizations should treat the migration to PQC as a current operational priority.” The Dutch NCSC and AIVD make the same point: “Organizations should act now and prepare to make the switch to quantum-secure cryptography.” On the role of NIST’s guidance, Dustin Moody of NIST said: “The new report can help you understand the standards and requirements of the migration.”

For OT networks this means a short checklist per site type: confirm UDP 500 and 4500 are open towards the hub, confirm RFC 7383 fragmentation is negotiated, test on the worst-MTU backup link, measure the NAT idle timeout, and set keepalives and DPD to match. Sites that pass all five checks are ready for post-quantum tunnels.