Draw the Decrypted Path: Where a VPN Appliance Enforces Policy

Vendor diagrams usually stop at the encrypted listener, because that is the part with a public address. The question that decides the security posture is what happens after decryption, when the packet becomes ordinary IP and can reach anything the routing table allows. If nobody drew that leg, nobody owns it. The runbook below draws it first and then compares placements by what the decrypted request actually crosses.

Draw the packet after decryption, not before

The outer path is the part vendors document: a public endpoint, a transport policy that admits the connection, and a terminating service. The inner path begins the moment the packet loses its tunnel header, and from there it is governed by routing and filter rules that have nothing to do with the tunnel. Put both on the same page, because a diagram with only the first implies that admission and authorisation are one decision. They are not, and the gap between them is where most placements go wrong.

Write the inner leg as a numbered sequence with named device types rather than as an arrow. An arrow hides whether the request crosses a filter, and crossing or not crossing is the entire question. Each hop below names the device and the rule set that acts there, so a missing filter appears as a gap rather than being implied by a line.

1. Remote client: the user device that originates the tunnel.
2. Edge policy: the rule set that admits the outer transport to the public listener.
3. Terminating appliance: the VPN endpoint that decapsulates and hands the packet to ordinary IP.
4. Inner filter: the forwarding or security-group rule set that limits client-to-service traffic.
5. Application host: the service that receives the decrypted request.

Two policies, two owners

The outer policy answers who may establish a tunnel, and it is expressed in the rules that admit the transport to the terminating service. The inner policy answers which service an authenticated user may reach, and it lives in forwarding rules, security groups or the application itself. One device can host both, and a design with several devices still has both. Naming them separately is what lets you say which one failed when a user cannot reach an application.

Admission controls such as certificates and multi-factor authentication answer identity and nothing else. They do not decide placement, and they do not grant per-resource permission once a user is inside.

Placement decides which boundary the request crosses

Three placements are common, and each changes which boundary the decrypted request crosses. Compare them by what terminates there, what can see plaintext, which control can still deny the request, and what fails with the appliance. The table below uses those four columns instead of a generic question, because each answer is a separate design decision.

The third placement is the one that quietly removes enforcement, because a leg on the protected segment gives the appliance a direct path the diagram may not show. Inspect interfaces and routes rather than the picture: ip route get 10.20.5.10 reports which interface the packet would leave by, and the answer is often not the one the design assumed. The classic firewall role of controlling traffic between postures, as described in NIST SP 800-41, is a useful test here, because a device with an unrestricted leg to the protected network is not controlling much. A route lookup is a more honest diagram than the one in the deck.

Administration belongs on its own explicitly permitted path. Letting users reach an application never requires letting them reach the appliance control interface, and the two permissions should be granted from different rules. Audit both paths separately, because a shared rule hides which one was opened.

Translation changes what downstream rules can see

Source translation is convenient and it destroys information. After masquerade every client looks like the appliance, so a downstream rule written to distinguish users can no longer do so. That is not only a logging problem, it is a policy problem: a rule keyed on client address silently becomes a rule keyed on the gateway. If per-user policy matters, preserve the source or enforce the policy before translation.

The reply path deserves the same scrutiny. Record which route the destination chooses for the return packet, because an asymmetric return bypasses stateful inspection and produces a connection that establishes and then stalls. Both directions have to cross the boundary you drew, or the boundary is decoration.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

Accept a permitted operation and a denied one

Test from the real remote client rather than from a management host, because the management host usually sits somewhere the user never will. One permitted operation proves the path works, and one denied operation proves the policy is doing anything at all. Run both after every placement change, and record the source identity and destination you used. A test that only proves success cannot tell a correct rule from a missing one.

Then test the cases that change state: a reconnect, a session that outlives a key rotation, and a failure of the appliance itself. Compare updates, capacity and recovery as part of the same layout, because one appliance holding several logical controls is one failure domain wearing several labels. A second box is not independent either when a shared administrative credential or an unrestricted route defeats the boundary it was meant to create.

Document the endpoint, the decrypted path and the control that restricts it. Those three lines stay meaningful whatever the implementation is called.