Why might the filter behind your VPN head-end see only the forward direction of decrypted traffic?

## The claim being tested "We land the tunnel in a screened tier behind a second enforcement device" is an assertion about **paths**, not about racks. A path is produced by routing and layer-2 adjacency, and both are edited by people who are not thinking about your boundary claim. The characteristic way the claim quietly becomes false is that only one direction of the traffic actually crosses the device. ## How it happens The forward direction is easy to get right: the head-end's inside leg has the enforcement device as its default gateway, so everything it decapsulates leaves through it. The return direction is decided somewhere else entirely — by how the rest of the estate routes back to the VPN client pool. If the core learns or is configured with a route for the pool pointing at the head-end's inside-leg address, then the return path is whatever the core uses to reach *that address*. If the core has its own interface in the screened tier (very common: a legacy backup link, a management adjacency, an SVI created for a migration and never removed), it reaches the head-end directly and the enforcement device is simply not on the return path. ## Why nobody notices Because the traffic works. Both endpoints get their packets; the application is fine. A stateful device seeing only the forward direction of a flow still forwards what its policy permits — it just never observes the responses, so its state table is built on half the conversation. There is no alarm and no failed connection to investigate. The gap surfaces only when somebody actually tests the boundary, or after an incident when you try to say what the device would have stopped. The other outcome is worth naming because it looks like the opposite problem: if the *return* path traverses a stateful device that never saw the forward direction, that device drops the responses as out-of-state, and you get an intermittent, protocol-dependent breakage that gets blamed on the application. Same root cause, louder symptom. ## What is actually lost - **Internally initiated traffic toward the tunnel population and toward the head-end itself is unenforced.** That is precisely the direction a lateral move takes, and precisely the direction that matters if the head-end is the thing being attacked from inside. - **The device cannot reason about responses**, so any policy or logging that depends on a completed exchange is unreliable. - **Your evidence is invalid.** A deny test in the forward direction proves nothing about the reverse one, and "the device is in the path" was the load-bearing sentence in the design review. ## Fixing it, and what the fix costs The only durable fix is topological: the enforcement device must be the *sole* path between the screened tier and everything else. In practice that means removing every other adjacency into the tier — including the convenient ones — or placing the tier in a separate routing instance so that reachability to the pool exists only via the filter. Source-address verification on the tier's uplink helps catch the leak but does not create the path. The cost is a routing change in the core, an outage window for remote access while the return path moves, and the loss of whatever the leftover adjacency was doing (backup access, a management path) — which someone will have to re-provision the long way. That negotiation is the real work; the configuration is minutes. ## Proving the path, not the intent The honest test is a known flow in both directions: originate from a tunnel client to an internal service and confirm both the forward and return packets appear in the enforcement device's own accounting, then originate from an internal host toward the pool and confirm the same. Path evidence from the endpoints alone is not enough, because a bypassed device is invisible from the endpoints — that is exactly why it went unnoticed. ## Interview framing The question separates people who have drawn the diagram from people who have traced the packet. Say that placement is a routing property, name the leftover adjacency as the usual cause, note that the failure is silent because the traffic still works, and finish with what the fix costs in outage and in taking someone's backup path away.