Why your Windows VPN kills the local printer and how to stop it

Connect the VPN and the printer vanishes, the NAS share stops opening, and a Remote Desktop session to the machine beside you times out. Nothing broke. The client added a default route and now owns every destination the laptop can name, including the ones sitting three metres away. That is the whole mechanism, and calling it a VPN fault is what turns a one-line fix into a support case.

Read the route table first

Before changing anything, capture the IPv4 table with route print -4 and keep the output. Connect, capture again, and compare the 0.0.0.0 lines: the active default route names an interface, and if that interface is the tunnel, local printing and browsing are being sent to the office first.

The interface number in the second column is what a persistent route has to reference later, so note it down while the tunnel is up. It is also the value that changes when the adapter is recreated, which is why routes pinned to it can quietly outlive their usefulness.

Remove the default route, three ways

On a built-in Windows profile the control is a checkbox. Open the connection's properties, IPv4, then Advanced, and clear Use default gateway on remote network; the newer Settings app hides the same dialog one layer deeper. From an elevated prompt the same change is one cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

An OpenVPN profile works differently, which is why its behaviour confuses people who expect a checkbox. Its redirect-gateway def1 directive does not replace the default route at all; it installs two half-range routes, 0.0.0.0/1 and 128.0.0.0/1, which together win over the default without deleting it. Because the original default survives, adding a prefix pointed at net_gateway sends only that prefix back to the local router. That detail explains why the fix for a def1 profile is a prefix route rather than a checkbox nobody can find.

Add back only what belongs to work

With the default route gone the tunnel carries nothing, so the work prefixes have to be named explicitly. The cmdlet that binds a prefix to the connection is safer than a persistent route, because it is installed only while that connection is up and does not depend on an interface number:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

The older approach still works and is still in every checklist: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, with the tunnel's own interface index and gateway address. It persists across reboots, which is the point and also the hazard, since the index may belong to something else on the next boot.

Metrics decide the rest. If both the physical and tunnel adapters claim a route for the same prefix, the lower metric wins, and raising the tunnel's metric is a legitimate client-side control rather than a hack.

When the server decides for you

A client that ignores your checkbox is usually obeying a policy. Cisco profiles carry an Allow Local LAN Access setting, and a headend can push a tunnel-all policy that overrides whatever the client would prefer; in a compulsory-tunnel deployment there is no local switch to flip. Read the client log for pushed routes and policy lines rather than re-checking the same dialog.

Then look at name resolution, which is a separate switch from routing. A split tunnel can still receive an internal resolver and a search suffix, so a local device is reachable by address and unfindable by name until the DNS side is fixed too.

Overlaps are a different problem

If the home LAN and the office LAN share a prefix such as 192.168.0.0/24, no route can tell them apart. Every packet for that range has one lookup result, and the fix is to renumber a side or to reach the office through a translated address from the pool. Adding more specific routes only moves which half of the network breaks.

Finish with one verification rather than five: connect, then run tracert against an internal host and a public one. The first hop should differ, and if it does not, the split is not in place regardless of what the client reports. Then reconnect once and repeat, because pushed routes return with every session.