One VPN, Two Windows Accounts: Why the Other Session Breaks
Routes and resolvers are machine-wide, so one account's tunnel reroutes the others. Then find which policy or logon module removed the Switch user entry.
Two people are signed in, one of them connects the corporate tunnel, and the other account's browser stops loading pages that were fine a minute ago. On the same machine, the Switch user entry has also disappeared from the sign-in screen, so the second person cannot get back to their own session. Following this from the second session outward is the quickest way to understand it, because nothing about the first user's connection is hidden, and nothing about the second user's problem is mysterious once you see which objects are shared.
Start in the session that broke
Walk to the second account's desktop, not the first. Open a terminal there and look at the routing table and the resolver list while the other session is connected. Everything you see belongs to the machine, not to the other user, which is the first clue.
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 12 DestinationPrefix,NextHop,InterfaceAlias
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,ServerAddresses
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4ConnectivityIf the default route now points at the tunnel interface, the second user's traffic follows it too. If the resolver list has gained a private server, their lookups now go somewhere they cannot reach once the tunnel drops. Neither of those is a bug in the client; they are the consequences of a single, shared network stack.
The third command explains a second class of complaint. When an adapter flips the machine from a public to a private network category, firewall rules scoped to a profile change for every account at once, so applications that were permitted in the morning can be blocked in the afternoon without anyone touching a rule.
The connection is per-user, the network is not
Windows keeps the connection object in the profile of the user who created it. The virtual adapter it produces, the routes it installs and the DNS servers it registers are machine-scoped. That split is the source of both symptoms in the title.
It also explains why signing the first user out usually fixes the second one. Removing the connection removes the adapter and the routes with it, and the machine-wide state returns to what it was before anyone dialled in. That is a useful diagnostic: if signing out repairs the other account, you are looking at shared state rather than at a broken profile.
What you cannot do is give the second session a different routing table. There is one table, and any two sessions share it. That is a property of the operating system rather than a limitation of a particular client. It also means any design that assumes otherwise will keep failing, and the failures will look like unrelated application bugs.
Find what removed Switch user, in this order
Fast user switching disappeared for a completely different reason, and the fix has nothing to do with routing. Work through the four candidates in order, because the first two are reversible in seconds and the later ones have a cost.
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name HideFastUserSwitching
gpresult /h $env:TEMP\gp.html
Get-Service | Where-Object { $_.DisplayName -match 'Logon|Access|Credential' } | Select-Object Status,Name,DisplayNameThe registry value is the simplest explanation. If it exists and reads 1, the entry is hidden by policy, and the Group Policy path is Computer Configuration, Administrative Templates, System, Logon, and the setting named for hiding fast user switching entry points. Set it to Not Configured and refresh with gpupdate /force.
The second command tells you whether that policy is being delivered from a domain rather than written locally. If it appears in the report with a winning GPO, editing the local value is a temporary fix that reverts at the next refresh, and the conversation belongs with whoever owns the policy.
The third command covers the other mechanism. A credential or network access provider that installs a logon module can suppress the entry while it runs, and some clients also register a start-before-login component that keeps a claim on the sign-in screen. Disabling that service restores switching, and it also removes the pre-logon or posture functions the module exists to provide.
| Cause | How to confirm | Cost of the fix |
|---|---|---|
| HideFastUserSwitching policy | Registry value present and set to 1 | None; remove the policy |
| Logon module service | Service running under a vendor name | Loses pre-logon and posture behaviour |
| GINA-era assumption | Only relevant on very old Windows | Nothing to fix; the mechanism is gone |
Change it without locking yourself out
Keep one administrative session open while you work, and never make a logon-screen change on a machine you can only reach through that screen. Sign the other sessions out first, apply the change, refresh, and then test by switching users rather than by rebooting.
Record which posture functions you disabled. A client update can reinstall or re-enable the logon module, and the symptom returns with no obvious cause, usually in the middle of a support window when nobody remembers the earlier change.
On a managed device, assume the setting is delivered from above. Checking the policy report first saves an hour of local edits that revert. It also tells you who to ask when the answer is no. A ticket that names the winning policy is resolved twice as fast as one that describes a registry key someone already changed.
Verify both accounts and pick the model
Test the outcome in the order the two users experience it. Sign in as the second account with the first one disconnected, confirm normal access, then connect the first account's tunnel and confirm that the second account's expected path is still what you intended.
qwinsta
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object InterfaceAlias,NextHop,RouteMetric
Test-NetConnection -ComputerName intranet.example.internal -Port 443If both accounts genuinely need different network paths at the same time, the honest answer is two machines, two virtual machines, or a policy where only one path is required. A split tunnel on the shared connection can narrow what moves, but it cannot give each session its own table. Getting there early is cheaper than discovering it after three attempted workarounds.
That is the decision to make explicitly rather than patching around. One routing table, one resolver list, one firewall profile: everything else follows from that, and the fix that respects it will still be working next month.