How does encryption gateway high availability failover work?

Encryption gateway high availability failover means that a second gateway takes over the encrypted connections of a failed one, so traffic between sites, cloud environments and remote users keeps flowing protected. For quantum-safe gateways it also covers how hybrid key exchanges, security association state and rekeying survive the switch without downtime or plaintext exposure.

In OT and critical infrastructure, the encryption layer sits on paths that carry telemetry, engineering access and control traffic. A badly designed redundancy setup can turn a security upgrade into a new outage risk. This article explains how to place redundant gateways next to an existing firewall cluster, what happens to post-quantum tunnels during failover, and how to choose between active-active and active-passive designs.

How do you set up redundant encryption gateways alongside an existing firewall cluster?

Deploy the encryption gateways as their own redundant pair, positioned either in front of or behind the firewall cluster depending on whether the firewall must still inspect the traffic. Then connect the two redundancy domains through routing, not through shared failover logic.

Decide on placement first

Placement determines what the firewall sees. If the firewall cluster must keep inspecting OT traffic (protocol filtering, segmentation rules between zones), the encryption gateway has to sit on the WAN side of the firewall, so traffic is decrypted before inspection. If a path carries only traffic that needs no inspection, for example replication between two data centres, the gateway can sit behind the firewall and the firewall only has to permit the tunnel traffic itself.

Quantum Network’s Quantum Gateway follows this pattern: it co-exists with existing firewalls and routers, is integrated by adding or adapting a few routes, and goes in front of the firewall when inspection must continue or behind it when inspection is not needed on that path. Because it encrypts at Layer 3, everything above Layer 3 travels encrypted with it.

Choose a routing pattern for the pair

There are two common ways to connect a gateway pair to the surrounding network:

• Shared virtual address. Both gateways present one next-hop address via a first-hop redundancy protocol. The firewall and remote peers see a single endpoint. This is simple but requires that the standby can take over security association state, or that peers rebuild tunnels quickly.
• Two independent tunnels. Each gateway builds its own tunnel to the remote site, and a dynamic routing protocol or tracked static routes prefer one path. Failover becomes a routing decision. No state synchronisation is needed, at the cost of maintaining twice the tunnels.

Whichever you choose, keep the gateway pair’s health checks separate from the firewall cluster’s. If a firewall failover also triggers a gateway failover, you double the reconvergence time for every event.

What happens to post-quantum IPsec tunnels and rekeying during a gateway failover?

If the standby has synchronised state, the tunnel can continue after a counter resynchronisation; if not, the peer must perform a full new handshake, including every additional post-quantum key exchange. Rekeys that were in progress at the moment of failure are typically abandoned and restarted.

State synchronisation under RFC 6311

IKEv2, defined in RFC 7296, keeps message counters and replay windows that a cold standby does not know. RFC 6311 addresses this for hot standby clusters, where the main issues solved are the synchronization of IKEv2 Message ID counters and IPsec replay counters. When this works as designed, according to the RFC 6311 authors, the peer normally doesn’t notice that failover has taken place.

The mechanism is triggered actively: a new active node must immediately initiate a special INFORMATION exchange containing the IKEV2_MESSAGE_ID_SYNC notification. Both sides must support the extension. One detail matters for post-quantum setups that rely on fragmentation: IKE Message ID Synchronization messages MUST NOT be sent fragmented.

Hybrid rekeying under RFC 9370

RFC 9370 lets IKEv2 combine a classical and one or more post-quantum key exchanges. It utilizes the IKE_INTERMEDIATE exchange when an IKE SA is being established, and also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. A rekey in flight during failover therefore involves more messages than a classical rekey, and more chances for one to be lost. In practice, the safest assumption is that any rekey interrupted by failover will time out and restart from the new active member.

Short key lifetimes change the trade-off. QPN, for example, combines a classical and a post-quantum part (ML-KEM, standardised in FIPS 203) into one session key, and both handshakes renew every two minutes. With lifetimes that short, the window in which synchronised key material remains useful is small, so the design focus shifts to fast, automatic re-establishment. QPN never falls back to unencrypted traffic and retries automatically after a line failure, without user action.

Does larger post-quantum key exchange slow down tunnel re-establishment after a failover?

Somewhat, but the cost lies mostly in extra round trips and fragmentation rather than in computation. The effect becomes visible on lossy or high-latency links and when a hub must rebuild many tunnels at once.

The message sizes explain why:

• Key sizes: ML-KEM-768 has encapsulation keys of size 1184 bytes and a ciphertext size of 1088 bytes (IETF draft-ietf-tls-mlkem-00, 2025).
• IKEv2 payloads: the IKE_INTERMEDIATE payload from the initiator has a Payload Length of 1192, and the Payload Length of IKE_INTERMEDIATE message from the responder is 1096 (IETF draft-kampanakis-ml-kem-ikev2-01, 2023).
• Path MTU: in public comments on draft FIPS 203, a commenter noted that the maximum transmission unit (MTU) on the Internet is typically just around 1300 bytes (NIST, 2023).
• Reliability: FIPS 203 lists the ML-KEM-768 decapsulation failure rate as 2^−164.8 (NIST, 2024), so failed handshakes are not a practical concern.

Add headers and certificates, and a single message easily exceeds one packet. RFC 9370 anticipates this: large payloads can be carried by using IKE_INTERMEDIATE [RFC9242] to transport the large post-quantum key exchange payloads and using the generic IKEv2 fragmentation protocol [RFC7383]. Each additional key exchange also costs one more round trip before IKE_AUTH.

On a fibre link between two substations this adds little. On a cellular or satellite link to a remote pumping station, extra round trips and lost fragments can stretch re-establishment noticeably. The practical steps are:

• Confirm that firewalls and carrier equipment pass fragmented UDP on the IKE ports; dropped fragments look like a hung handshake.
• Measure re-establishment time per site on the real link, not in the lab.
• On hub gateways terminating dozens of sites, test simultaneous re-establishment of all tunnels, since a failover makes every peer reconnect at once.

Active-active or active-passive: which encryption gateway design suits OT sites?

For most OT field sites, active-passive is the better fit because it is deterministic and easy to test. Active-active pays off mainly at hubs and data centres, where throughput and many concurrent tunnels justify the extra complexity.

A common error with active-active is sizing for combined capacity. If both members run at 70 percent of their capacity, a single failure overloads the survivor. Size each member to carry the full load alone.

IEC 62443-3-3 is a useful lens here. It provides detailed technical control system requirements (SRs) associated with the seven foundational requirements (FRs) of IEC 62443-1-1. CISA’s crosswalk maps the outcome “adequate capacity to ensure availability” to ISA 62443-3-3:2013 SR 7.1, SR 7.2, while baseline configuration maps to SR 7.6. Treating the encryption layer as part of the control system’s resource availability, rather than as an IT add-on, leads naturally to simpler, testable designs.

How do you avoid single points of failure when adding a quantum-safe encryption layer to critical networks?

Map every dependency the new layer introduces, not just the gateway hardware, and give each critical one an alternative. Then prove the design with scheduled failover tests.

Typical hidden single points of failure include:

• Shared power and uplinks. Two gateways on one power feed or one switch provide no real redundancy.
• Credentials and trust anchors. If both gateways depend on one certificate authority or one key store that is unreachable during an incident, re-authentication fails after failover.
• Management plane. A single management server should not be required for gateways to forward or re-establish tunnels.
• Configuration drift. A standby with an older algorithm list or route set may fail to negotiate the same hybrid proposal. Keep configurations under change control, which aligns with SR 7.6 thinking.
• Time and name services. Certificate validation and logging depend on correct time; verify behaviour when NTP is unavailable.

Regulation points in the same direction. NIS2 (Directive (EU) 2022/2555) lists among minimum measures business continuity, such as backup management and disaster recovery, and crisis management. Commission Implementing Regulation (EU) 2024/2690, which details these measures for certain digital service providers, requires relevant entities to ensure sufficient availability of resources by at least partial redundancy of network and information systems and communication channels. Even where that regulation does not apply directly, its approach of testing redundancies is sound practice for OT operators.

Finally, keep crypto agility in scope. Post-quantum algorithms and their parameters may change; both gateways in a pair must be updated together, and the update procedure itself must not take the pair down at the same time.