VPN client traffic and firewall state: outer vs inner flow

The VPN handshake completes, the client gets an address, and a service behind the gateway still refuses the connection. The firewall is often doing exactly what it was told. It permitted the outer tunnel flow, which is a different packet from the decapsulated application connection. Two decisions follow: which flow you are permitting, and whether the boundary tracks state at all.

Until you separate those, every rule change is a guess.

The firewall sees two different packets

Before decapsulation, the firewall sees traffic addressed to the VPN endpoint: an outer UDP flow to the listener. After decapsulation, a forwarded packet carries the client's inner address and the service destination.

An allowance for the outer flow does not authorize the forwarded TCP connection. They can be evaluated in different chains, against different interfaces, and with different addresses after translation.

Compare captures from equivalent positions on both sides. A capture at the tunnel edge and a capture at the server show different tuples for the same session.

Decision one: permit the tunnel or the service

If the client only needs the VPN endpoint itself, the outer allowance may be enough. If it needs a service beyond the gateway, you need a forwarding allowance for that destination and port. A tunnel rule that also permits the service is a design choice you should name, not an accident.

Keep the client range and the service scope narrow. A permit from the tunnel subnet to the whole LAN is a decision to trust every host, not a shortcut for one application.

Write both rules down separately. The tunnel rule and the service rule fail in different ways and are debugged with different evidence. When one fails, you know which layer to inspect first.

Decision two: stateful or stateless at each boundary

An established-flow rule can admit replies for a permitted exchange, but its behavior depends on the product. A cloud security group is usually stateful; a subnet ACL is often stateless and needs explicit handling in both directions. Do not assume every boundary in the path treats state the same way. List each boundary and mark it stateful or stateless before you design the rules.

If a rule changes, existing tracked flows may keep working while new ones fail, or the reverse. That difference is a useful clue, not a reason to flush all connection state on a live gateway.

Test with a fresh controlled request and inspect the relevant counters. A clean test beats a disruptive reset. Note the counter name in the change record so the next test uses the same evidence.

Verify the return path under the same policy

Send a new request from the client to the service, then check the forward and return counters on each boundary. Confirm the reply uses the path you expect, especially if translation is involved.

Keep the intended client range and service scope narrow, and verify the return path under the same rule set that permitted the request. A rule that only works because an old flow is still open is not a working rule.