Encrypted Transit Does Not Grant Access to the Carrier

Two approved gateways carry a lower-trust network's traffic across a restricted transport network. Encrypting the payload keeps it unreadable to ordinary transit observers, which is the part people design first and then stop thinking about. What encryption does not do is define which resources the lower-trust side may reach. The design needs two boundaries: one around the carried conversation, and one around access to the carrier itself.

Run the steps below in order, and treat a failure at any step as a design change rather than a configuration tweak.

Define both boundaries before you touch a config

The first boundary is the conversation: which pairs of gateways may establish a tunnel, and which inner traffic is allowed through it. The second is the carrier: which addresses and services the lower-trust hosts can reach outside the tunnel. Teams usually build the first and inherit the second from whatever routing already existed, which is how a constrained design quietly becomes a wide one. That inheritance is the usual root cause when a review finds a lower-trust host talking to something nobody approved.

Write both down as lists of addresses, ports and directions. If a list cannot be written, the boundary is not defined yet.

Step 1: constrain the outer tunnel

On the carrier-facing interface, permit only what the tunnel needs: IKE on UDP 500 and 4500 between the two gateway addresses, and ESP where NAT traversal is not in use. Deny everything else arriving on that interface, including management protocols. The ESP specification covers the protection services; it says nothing about which of the carrier's own services the gateways may use. Express it as an explicit allow list, so a newly published carrier service does not become reachable by default.

This is the rule set that makes the design a transit design rather than a peering arrangement.

Check it from the lower-trust side, not from the gateway console. A host there should fail to reach a carrier DNS server even before the tunnel is up.

Step 2: decide what the far gateway delivers

At the far end, recovered traffic has to go somewhere specific. Define which inner services are permitted, from which source ranges, and whether replies are expected to be symmetric. Review management access separately, because the same gateway often exposes an administrative interface that was never part of the transit plan.

A diagram that stops at successful decryption has skipped the decision that matters most.

Step 3: keep ownership per layer

Transit equipment still receives and forwards outer packets, so it needs patching and capacity planning. Tunnel endpoints process the protected protocol and expose inner traffic to their forwarding path, so they need their own rules and their own monitoring. Final applications process the payload, and an opaque payload is not evidence that a decrypted download is harmless.

Assign an owner to each layer. The layers without an owner are the ones that drift.

Step 4: verify, then hand it to the authority

Verify the outer path with the tunnel up and the carrier rules in place. Then try each resource the lower-trust side should not reach and confirm the failure is a denial rather than a timeout that hides a route. Check availability and resource limits as well, since an encrypted link can still be saturated.

For regulated or classified environments, take the design to the responsible security authority and use its approved separation architecture. A VPN configuration and a conceptual explanation do not establish accreditation. That step is not paperwork; it decides whether the design is allowed to exist at all.