One VPN Login on a Shared PC: Who Else Gets the Route?

Sharing a workstation raises a question that a single-user laptop never has to answer: once one person authenticates the tunnel, who else can use it? The login identifies a subject, and the route it installs describes a scope, and those two things are not the same object. Between them sit the operating system, the client's configuration and whatever the private service demands on its own. Comparing the enforcement points is the only way to answer the question without guessing.

One Login, Several Scopes

Authentication answers who was admitted. The route answers which packets may leave through the tunnel. Authorization answers which service will accept the resulting connection, and none of the three implies the next.

A host-wide tunnel is the common default, and it makes the gap obvious. The route sits in the kernel's table, so every process using that table can reach the private network, including one started by a user who never saw the VPN dialog. That is not a defect in the tunnel; it is what a system-wide route means. The private service can still refuse the connection, which is why reachability and permission need separate answers.

Writing the four questions down before testing keeps the review from collapsing into one of them.

Where the Boundary Actually Sits

Four arrangements cover most machines: a host-wide tunnel, a per-user connection, a per-application allowlist, and a separate network namespace or virtual machine.

Each one puts the enforcement point somewhere different, and the differences matter more than the labels. A per-user connection is enforced by the profile's permissions rather than by the desktop login screen. A per-app allowlist is enforced inside the client, which decides what it will carry. A namespace or a VM enforces at the interface boundary, so a process inside cannot see the host's route at all. The number of login screens on the machine says nothing about any of them.

Reading the table by row shows that the real question is not whether isolation exists, but where it is implemented.

Compare Four Enforcement Points

On Linux the route table is the first thing to inspect, because a host-wide tunnel appears there and a namespace does not. Running the lookup as the second user is the step people skip; the answer differs from the one they got as themselves, and it explains the report.

The next two checks look at policy rather than routing. A firewall rule matching a UID applies to locally generated traffic, so it can separate two users on one host even when both share the route. A connection profile with an explicit permission list is enforced by the network manager at activation time. Neither check requires the tunnel to change, which is why they are worth doing before redesigning anything.

ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid

If the second lookup shows the tunnel route, the boundary is not where the design assumed it was.

Concurrent-Session Rules Are a Separate Control

Gateways often limit how many sessions one account may hold, and that limit has nothing to do with local users. It restricts the account, so a second person signing in with the same credential can terminate the first person's tunnel.

Read the failure before assuming a local isolation problem. A session limit produces a disconnect at the gateway, while a scope problem produces a working tunnel that simply does not carry the other user's traffic. Those two symptoms lead to completely different fixes. Keep the exact client message, since it usually names the rule. Ask the profile owner for the approved workflow instead of working around the limit.

A virtual machine does not exempt anyone from that rule, and it adds its own network and credential design.

Test the Context You Care About

Test the intended user and application, then test a context that should be denied. A review that only proves the original password works has tested authentication and nothing else.

sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'

Record the enforcement point beside each result: the route table, a UID rule, a profile permission, or the gateway's session policy. That record makes the next change reviewable. It also stops the same question from being reopened every time somebody notices a second login screen. Reachability is not authorization, and neither one is isolation.