Encryption gateway in front of or behind firewall?

An encryption gateway is a physical or virtual device that encrypts traffic at the IP layer between two points, such as two sites, a site and a cloud environment, or a remote user and the network. Where it sits relative to the firewall determines what the firewall can still inspect, which rules change and which routes you add.

For operators of OT and critical infrastructure, this placement question has become practical rather than theoretical. Links between control centres, substations, pumping stations and cloud historians are being upgraded to quantum-safe encryption, and nobody wants to rebuild a working, certified network to do it. This article explains the placement options, the effect on firewall inspection, and the specific rule, NAT and routing changes involved.

Should an encryption gateway sit in front of or behind the firewall?

Put the gateway in front of the firewall (on the WAN side) when the firewall must keep inspecting the traffic on that path. Put it behind the firewall when inspection is not needed on that path and the firewall only has to permit one tightly scoped encrypted flow.

The deciding factor is simple: a firewall can only enforce application-level policy on traffic it can read. The gateway is where decryption happens, so the gateway’s position decides which side of the firewall sees cleartext.

In front of the firewall

The packet path is WAN, then gateway, then firewall, then the internal network. Incoming traffic is decrypted by the gateway and handed to the firewall with its original source and destination addresses. Your existing policy, intrusion prevention and protocol-aware rules for industrial protocols keep working on the traffic exactly as before.

The trade-off is that the gateway faces the internet directly and must be treated as an exposed system. The link between gateway and firewall carries cleartext, so keep it short and physically controlled, ideally a patch cable within one locked rack.

Behind the firewall

Here the path is internal network, then gateway, then firewall, then WAN. The firewall sees only encrypted packets between two gateway addresses. It still shields the gateway itself, but it can no longer filter on inner addresses or protocols. This suits paths where both ends are already trusted and inspection adds nothing, for example replication between two control centres in the same security zone.

Where the DMZ and network segmentation fit

In IEC 62443 terms, an encrypted link is a conduit between zones. Let that conduit end at the zone boundary, where the zone firewall can still enforce policy, rather than deep inside the plant floor network. In practice, many organisations place gateways in a dedicated segment of the IT/OT DMZ, so network segmentation stays the same and the gateway does not become a new path around it.

Can a firewall inspect encrypted traffic?

A firewall cannot read the payload of encrypted traffic. It can see outer headers, ports, packet sizes and timing. To inspect content, something has to decrypt the traffic first: either the firewall acting as a proxy, or a gateway placed in front of it.

This is a growing operational problem. ENISA notes that browser-vendor studies show encrypted HTTPS accounting for around 70-90% of loaded HTTPS web pages, and that controls such as application firewalls, Intrusion Detection and Prevention Systems (IDPS), Data Loss PreventionProtection (DLP) tools etc. largely depend on access to unencrypted traffic.

The usual answer for web traffic is TLS inspection, which defines TLSI (a security process that allows incoming traffic to be decrypted, inspected, and re-encrypted) in the NSA’s wording. The NSA has also cautioned that “network owners should be aware that TLSI is not a cure-all”. NIST SP 1800-16 describes the decision as one that involves important tradeoffs between traffic security and traffic visibility that organizations should weigh carefully.

Layer 3 site-to-site encryption differs from TLS in one key way. Everything above Layer 3 is wrapped, so on the encrypted side a firewall cannot tell Modbus/TCP from IEC 60870-5-104 or DNP3, or one internal host from another. There is no man-in-the-middle option here, and you should not try to build one. Instead, design where decryption happens.

Do I need to change firewall rules to add encryption?

Usually only a little. With the gateway in front of the firewall, existing rules stay valid because the firewall sees the same inner traffic. With the gateway behind it, you add one narrow rule permitting the tunnel between the two gateway addresses.

Rule changes by placement

• In front: the internal rule set is unchanged. Review whether the firewall’s outside interface now connects to the gateway rather than the provider router, and adjust interface or zone assignments to match.
• Behind: allow only the tunnel traffic between the specific public addresses of the two gateways. Write it as a source and destination host pair, never as “any”.
• Cleanup: if older rules opened broad cleartext site-to-site access that the tunnel now replaces, remove them. Otherwise the unencrypted path stays available as a silent alternative.

NAT considerations

NAT matters on two levels. On the outside, the side of a site-to-site link that accepts connections needs a reachable address. If its gateway sits behind a NAT device, that usually means a static NAT or port-forward entry. On the inside, avoid NAT that rewrites the inner addresses your firewall rules and OT allow-lists depend on. Rewriting them breaks rules that look correct on paper.

Remote access works differently. Clients make outbound connections, so in some designs, including QPN, remote-access clients need no incoming firewall ports at the user’s location.

What routing changes does an encryption gateway need?

Typically you add or adjust a few routes, so that traffic for remote prefixes uses the gateway as its next hop and the gateway knows its own path to the WAN. Addressing, VLANs and segmentation stay as they are.

The core changes

• Remote prefixes: on the internal router or firewall, point routes for the other site’s subnets at the gateway’s inside interface.
• Gateway default route: the gateway forwards encrypted traffic towards the WAN, either directly (in front) or through the firewall (behind).
• Return path symmetry: stateful firewalls drop traffic that leaves through one path and returns through another. Check that both directions of each flow cross the same gateway and firewall.

Pitfalls specific to OT networks

Overlapping address space is common when several plants were built from the same template. Routed encryption needs unique prefixes, so plan either a NAT step at the site boundary or renumbering of the overlapping segments.

Encapsulation adds header overhead to every packet. Verify the path MTU and, where needed, clamp TCP MSS, especially for older PLCs and RTUs that handle fragmentation poorly.

Above all, check backup routes. A secondary default route over an LTE or backup line can carry traffic to remote OT prefixes without passing through a gateway. In that case encryption depends on which link happens to be active. Every route to protected prefixes must pass through a gateway.

How to add encryption without redesigning the network?

Insert gateways at the edges of the paths that need protection, adjust routes, and leave firewalls, addressing and segmentation in place. The work is mostly preparation and verification, not re-architecture.

1. Map flows by secrecy lifetime. Rank site-to-site, edge-to-cloud and remote-access flows by how long the data stays sensitive. Engineering drawings, grid topology and long-term operational data come before short-lived telemetry.
2. Decide placement per path. For each path, ask whether the firewall must keep inspecting it. That answer sets in-front or behind placement.
3. Pre-stage addresses and routes. Document gateway inside and outside addresses, the remote prefixes and the exact route entries before the change window.
4. Install and switch routes. Bring the gateway up, then move the routes for one prefix at a time so rollback stays trivial.
5. Verify. Firewall logs should show the expected inner flows (in front) or only the gateway pair (behind). A capture on the WAN link should show no cleartext OT protocols.
6. Test line failure. Pull the WAN link and confirm that traffic stops rather than taking an unencrypted detour, and that the tunnel recovers without manual action.

Quantum Network’s QPN gateway is one example of this approach. It is added at each end of a connection as hardware or software and integrated by adding or adapting a few routes, with no software installed on the equipment behind it. It encrypts at Layer 3, uses hybrid key agreement that combines a classical part with ML-KEM, never falls back to unencrypted traffic, and takes roughly 30 minutes per gateway for a team that knows its own network and IP addresses. For edge-to-cloud links, a virtual gateway runs in the organisation’s own data centre or cloud on a supported Linux platform.

Why is quantum-safe encryption between sites a priority now?

Traffic recorded today can be stored and decrypted once a sufficiently capable quantum computer exists. Standards and official migration deadlines are now in place, so the open question for OT operators is how to deploy, not whether to.

NIST explains that adversaries can intercept and store encrypted information now and simply hold onto it until they have a quantum computer capable of breaking that encryption. CISA, NSA and NIST jointly addressed their quantum-readiness factsheet to organizations - especially those that support Critical Infrastructure.

The EU milestone explicitly covers critical infrastructure (eg water, energy, health care, finance and transportation). NIST’s Dustin Moody, who heads the PQC standardization project, put it plainly: “We encourage organizations to begin their transition to these standards immediately to ensure their data remains secure in the quantum era.” In Brussels, Executive Vice-President Henna Virkkunen said that “The post-quantum cryptography roadmap provides a clear direction to ensure the robust security of our digital infrastructure.”

For network teams, these deadlines lead back to the placement question. Every link between sites that gets quantum-safe encryption needs a decision on which side of the firewall the gateway goes, which rules change and which routes move. If you make that decision deliberately for each path, you can migrate without redesigning a network that already works.