Encryption gateway asymmetric routing: firewall drops fixed

Encryption gateway asymmetric routing is a firewall failure that happens when a separate encryption gateway sits next to a stateful firewall, so a session’s outbound packets and its return packets cross the firewall on different paths or interfaces. The firewall sees only half of the conversation, treats the rest as invalid, and drops it. In OT networks this usually looks like polling sessions that keep breaking or tunnels that come up but carry no traffic.

The fix is almost never a new device. You need symmetric routing, a deliberate choice of where the gateway sits, and narrowly scoped rules for the tunnel protocol. This article covers each of those steps for site-to-site, edge-to-cloud and remote-access connections in critical infrastructure.

Why are OT operators adding post-quantum gateways now?

Because the standards and the deadlines now exist. NIST has finalized its post-quantum key establishment standard, and published transition dates for retiring quantum-vulnerable algorithms. OT links carry data that has to stay confidential for a long time, so they are often among the first connections organizations protect.

NIST’s Dustin Moody, who heads the PQC standardization project, told administrators in 2024: “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.” The networking work in this article makes up much of that integration time.

Why does a stateful firewall drop traffic after adding a separate VPN encryption gateway?

A stateful firewall only forwards packets that match a session it saw being set up. Adding a gateway changes the path, so the firewall often sees a reply without the request, a request without the reply, or tunnel packets it has no rule for.

The four most common causes

• Half-seen TCP handshakes. The SYN from an engineering workstation leaves through the firewall, but the SYN-ACK comes back through the gateway and enters on another interface (or skips the firewall entirely). The firewall then logs the next packet as out-of-state or “no SYN” and drops it.
• Anti-spoofing and reverse-path checks. The decrypted packets from a remote site’s subnet come out of the gateway onto a segment the firewall doesn’t link to that subnet. Reverse-path filtering then treats them as spoofed.
• Missing tunnel rules. The encrypted outer packets are not ordinary TCP. If the firewall sits in the path of the ciphertext, it needs explicit rules for the gateway’s key exchange and transport protocols.
• NAT that doesn’t match. If the firewall translates addresses in one direction only, the gateway peer sees a different source address from the one it expects, and replies go to the wrong place.

OT traffic makes these faults worse. Long-lived Modbus/TCP or DNP3 sessions can sit idle longer than a firewall’s default idle timeout. When polling resumes after a path change, the firewall no longer has the state entry.

How do you route OT traffic through an encryption gateway without creating asymmetric paths?

Make sure both directions of every flow use the same gateway pair and cross the same firewall interfaces. In practice this means specific routes for remote subnets on both sides, rather than relying on default routes.

Routing rules that keep paths symmetric

1. Route remote subnets explicitly. At Site A, the route for Site B’s OT subnet points to the local gateway. At Site B, the route back to Site A’s subnet points to Site B’s gateway. If you configure only one side, you create asymmetry by design.
2. Check the end devices’ default gateway. Many PLCs, RTUs and HMIs have a single static default gateway, often the firewall. If the firewall then forwards replies to the encryption gateway, return traffic hairpins through the firewall twice. Either put a route on the firewall that matches the forward path, or move the device’s next hop.
3. Avoid independent load-sharing. Two gateways in equal-cost multipath, without shared state, will split flows unpredictably. Use active/standby with one shared next hop, and confirm that failover moves both directions together.
4. Use policy-based routing sparingly. Source-based rules that send only some traffic into the tunnel are easy to break when you add a subnet. Write down every policy route next to the matching return route.

Under IEC 62443-3-2, the encrypted path between two sites is a conduit. Conduits consist of the grouping of cyber assets dedicated exclusively to communications, and which share the same cybersecurity requirements. They ensure that only authorized data or traffic can pass between Zones. Writing the forward and return route for each conduit into the zone and conduit documentation makes asymmetry visible before go-live.

Should the encryption gateway be inline, one-arm or in a dedicated firewall zone?

Choose based on where the cleartext needs to be inspected. If the firewall has to keep inspecting OT traffic, the gateway goes outside it (on the WAN side), so the firewall sees decrypted packets. If inspection isn’t needed on that path, the gateway can sit behind the firewall.

NIST SP 800-41 Rev. 1 warns about the dedicated-zone design. Placing one firewall behind another can serve a security goal, but in general such multiple layers of firewalls can be troublesome. A gateway that the firewall sees twice raises the same issues of duplicate state and NAT.

Which firewall rules are needed for ESP, IKE and TLS from a post-quantum gateway?

Allow only the gateway’s tunnel protocol, only between known peer addresses, and filter the inner OT traffic separately on the cleartext side. Generally, firewalls should block all inbound and outbound traffic that has not been expressly permitted by the firewall policy, and that applies to tunnel protocols as well.

Rules by tunnel type

RFC 7296 states that IKE packets MUST be sent to and from UDP port 500 or 4500, and that port 4500 is reserved for UDP-encapsulated ESP and IKE. It also requires implementations to accept requests from any source port, because NAT rewrites ports. So pin your rules to peer IP addresses, not to source ports.

Details that break post-quantum handshakes

• Fragments. Hybrid key agreement (a classical exchange combined with ML-KEM from FIPS 203) produces larger handshake messages than a classical exchange alone. Firewalls that drop IP fragments, or block the ICMP “fragmentation needed” messages that path MTU discovery depends on, can break the handshake while small test pings still work.
• Two policies, not one. RFC 4301 separates the security policy (which traffic is protected) from the transport. Mirror that in the firewall: one rule set for the outer tunnel, and one for which OT subnets and protocols may pass inside it.
• Remote users. Client-initiated designs need inbound rules only at the central gateway. For QPN’s remote access client on Windows and macOS, the product documentation states that clients need no incoming firewall ports.

Keep management access to the gateway on a separate interface or address, with its own rules. SP 800-41 Rev. 1 notes that organizations should determine the types of network traffic that are required, including the protocols that the firewall itself may need to use for management.

How do you troubleshoot dropped sessions between the firewall and the quantum-safe gateway?

Follow a single flow end to end. Capture it on both sides of the gateway, compare what the firewall logged with what the gateway sent, and check whether the drops line up with path changes, rekeys or idle periods.

A structured sequence

1. Read the drop reason. “Out-of-state” or “no SYN” points to asymmetry. “Policy deny” means a missing rule. A reverse-path or spoofing drop means a routing mismatch.
2. Trace both directions. Run a traceroute from the OT device to the remote subnet and from the remote side back. If the hop lists don’t mirror each other, you have found the asymmetry.
3. Capture on both legs. Compare the cleartext 5-tuple on the inside of the gateway with the outer tunnel packets on the outside. Confirm that the firewall sees the outer packets on the interface it expects.
4. Test the MTU. Send pings with the don’t-fragment bit set and increase the size step by step between gateway peers. Failures above a certain size, while small packets pass, point to fragment or ICMP filtering.
5. Look at timing. Drops that cluster at regular intervals suggest rekey problems. Drops after quiet periods suggest that the idle timeout on the firewall or a NAT device is shorter than the tunnel’s keepalive.

No two sites behave the same. As Moody said of NIST’s 2026 transition guidance, “We understand there’s not one strategy that fits all use cases”, and the same goes for gateway placement. Start with the conduit that carries the longest-lived sensitive data, get its routing symmetric and its rules tight, and use that as the template for the other sites.