VPN blocks local LAN on Windows: route or client policy?

A printer, a NAS or a development box on your own desk stops answering the moment the work VPN connects. Sometimes a route command fixes it in seconds; sometimes the same route is correct and the packets still vanish, which means you are looking at a different problem with a similar symptom. The decision comes down to three questions, and getting them in the wrong order is why people spend an evening deleting and re-adding routes.

Three questions before any command

First: is there an entry for the local prefix, and does it point at the physical adapter? Second: does the client receive a local-network permission or denial from the gateway at connect time? Third: do you need outbound access to the LAN only, or must something on the internet also reach a service running on your machine?

The first question separates a routing fault from a filtering fault. The second tells you whether a routing fix is allowed to work at all. The third changes the repair: a route fixes outbound traffic, while an unreachable inbound service is usually a listener binding and return-path problem that a route makes worse.

Question one: route, filter, or name

Read the table before you add anything to it. The interface index matters, because every route command below is anchored to it:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

A directly attached subnet normally keeps an on-link route even while the tunnel is up, so an entry can exist and traffic can still fail. That combination is the signature of a filter that runs after routing, and it is the case where a second, more specific route changes nothing at all.

Test by address and by name separately. If ping 192.168.1.50 answers and net view 192.168.1.50 does not, the routing table was never the problem: the tunnel changed the resolver and the local name no longer resolves. Adding a route for that is wasted work.

Question two: does the gateway allow local LAN access?

A commercial client installs more than routes. It gets a policy at connect time, and that policy can include an explicit local-network permission. In Cisco IPsec deployments the group policy carries the split-tunnel setting and a separate local LAN access flag; the checkbox in the client is a request the gateway may refuse. In AnyConnect the profile controls the split include and exclude lists and the same permission. On Windows RRAS the equivalents are the default gateway option on the profile plus the static routes the server assigns.

When the flag is off, the documented behaviour is that the client blocks traffic to the directly connected subnet even though a valid, more specific route exists. That is also why routes the client does not own can disappear seconds after you add them: the client is rebuilding the state it was told to build, not fighting you.

The client log records the decision at connect time, and reading it is faster than any experiment on the machine. If the log says local access is blocked, stop: no command-line fix survives that, and the only paths left are a policy change, reaching the resource through the tunnel, or containing the client in a virtual machine and leaving the host on the local network.

Question three: which direction do you need?

Outbound traffic to a nearby device is a routing question. Point the LAN prefix at the local gateway with a metric low enough to beat the tunnel's default route:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

The second form pins a single device, which is what you want when one address is the whole requirement. The netsh equivalent records the same decision by interface name rather than index:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Route commands fail with The parameter is incorrect when the address and mask disagree, for example a host address with a /24 mask. Use the network address for a subnet route and a host mask for a single host.

Inbound is different. A VNC or SSH server on the same machine becomes unreachable when replies to an incoming connection leave through the VPN gateway and never return. Check what the service listens on before touching routes:

netstat -ano | findstr :5900

A listener bound to one specific address will not answer on the other interface. Binding it to all interfaces is a deliberate decision, made together with a firewall rule scoped to the network you trust. Only after that does the route repair restore the return path.

Apply the smallest change that matches

The other common move is unchecking "Use default gateway on remote network" on the IPv4 advanced properties. It keeps internet traffic local, but it does two things at once: the VPN stops being the default path, and the client stops receiving routes for the remote network, including multicast. Uncheck it and the remote LAN disappears unless the server pushes the specific remote prefixes every client needs.

That asymmetry decides the order of work. If the remote side must stay fully reachable, push remote subnets from the server and leave the local default alone. If you cannot change the server, add a persistent route to the remote prefix through the address the tunnel assigned, and check with route print that the prefix points at the VPN interface while the default still points at the physical gateway.

Then confirm the repair survives a reconnect, because non-persistent routes die with the adapter and a script that runs after each connect is the honest place for them. Test one local device and one remote resource in the same session, disconnect, reconnect, and test again. If the local device still fails while the route looks right, go back to question two: the client is filtering, and the answer is a policy change rather than a second competing route.