Always-on VPN: separating path, permission and session

Keeping a tunnel up around the clock is a design choice with a legitimate version and a careless version. A branch that needs a central application all day, plus an overnight backup job, has a reason. A laptop left connected in a hotel room for three days has an accident.

Both show the same green icon, and both answer the same way if you ask how long the tunnel has been up. That number is not the interesting one. What matters is what the connection keeps available, to whom, and what actually ends it.

Three clocks that run separately

The first state is the path. A tunnel and its policies make a set of services reachable, and a link with no traffic can stay ready for the next request. How long it stays ready is an implementation decision, not a universal timer.

The second state is permission. An accepted identity or device may be authorized to use that path. That authorization should change when a role changes, a device goes missing, or compromise is suspected, and it is independent of whether packets are flowing.

The third state is the application's own session. A database client, a remote desktop, or a web application authenticates separately and keeps its own state. Closing the tunnel does not necessarily end any of it.

A review that treats these as one question ends up arguing about idle timers. The three can each be healthy or broken on their own, and a finding in one says little about the others. A checklist with three lines beats a debate about a single timeout value. Write the answer for each state separately.

The tunnel is a path, not a badge

An established tunnel is evidence that a protected path exists between two endpoints. It is not evidence that every process behind either endpoint should reach every service on the other side.

Zero-trust guidance from NIST makes the same point from the other direction: network location should not be treated as implicit trust. A site link is a transport fact, and permission for one host to use one application is a separate decision with its own owner.

A peer that is compromised can still attempt harmful actions through services it is allowed to reach. Filtering and monitoring reduce specific risks without erasing the consequences of endpoint compromise. Design for the path, and authorize for the service.

Justifying a permanent site link

The defensible version of always-on names its purpose precisely. Which sources, which destinations, which direction, and who owns each entry. A branch firewall that permits every branch host to every central subnet has not kept a link for a named purpose; it has kept it for anything anyone thinks of later.

Where a peer cannot meet the required trust level, narrow the boundary or change the arrangement. Relying on occasional manual disconnection is a process control, and process controls are least reliable exactly when an incident makes them inconvenient.

Keep the justification with the configuration. A permanent exception with a written purpose can be reviewed and retired. One without a purpose becomes permanent by default.

Rekeying is not revocation

Replacing keys on a schedule maintains the protection lifecycle. It refreshes material and preserves confidentiality. It does not remove an endpoint's entitlement.

If the endpoint still holds valid credentials and an access policy that accepts it, the next negotiation restores the same permitted path. That is why "keys rotate hourly" is not an answer to a lost device: the lost device rotates too, as long as its identity is still trusted. Check the entitlement before you check the schedule. Rotation is hygiene, and revocation is an access decision.

Revocation is a different mechanism with its own latency: a revoked certificate, a disabled account, a changed group, a removed network rule. Each takes effect at a different point, and each behaves differently for sessions that are already established.

Ending what is already running

Ask what the implementation does to established sessions when access is removed. It may terminate them, wait for expiry, or apply some documented behavior in between. Do not assume that tomorrow's admission change closes today's application connection.

For interactive access, put session limits and inactivity rules in the hands of the identity and VPN owners rather than the network team alone. For a site service, set the procedure that maintenance, an outage, or a security incident uses to disable access.

Then test three outcomes: permitted work still works, an unrelated service is denied, and the removal procedure produces the documented result. An always-on design is acceptable when its purpose, authorization, and shutdown capability are all written down and exercised. Otherwise it is a convenience that outlived its reason.