Local network unreachable while the VPN is connected? Four checks

The tunnel comes up, the intranet appears, and the printer stops answering. Nothing on the LAN has failed; the client changed which path it uses for addresses it no longer treats as local. Walk the four checks below in order and stop when one produces a concrete mismatch, because the same symptom has four common causes and only one of them is fixed by editing the VPN.

First, look at the route table the client installed

Open the client's route table while the VPN is connected. On Linux use ip route, on Windows use route print or Get-NetRoute, and on macOS use netstat -rn. You are looking for a default through the tunnel and for what happened to the physical default.

A full-tunnel client often adds two half-default routes, 0.0.0.0/1 and 128.0.0.0/1, instead of replacing 0.0.0.0/0. The original default stays visible but loses every lookup, which is why the table can look intact while all off-subnet traffic moves. If the VPN client offers a split-tunnel option and policy allows it, that is the cleanest repair.

If the tunnel must remain the default, pin the local subnet instead. On Linux the route names the physical interface and gateway; on Windows add -p to make it persistent and read the interface number from route print rather than guessing it:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

A pinned route only holds while the address it names stays the same. A laptop that renumbers its Wi-Fi adapter on every connect will break the rule again, so check the interface address before deciding that the fix failed.

Second, confirm the address was local in the first place

If the destination sits inside the connected subnet, the tunnel default never applies and the VPN is not the cause. A printer at 192.168.1.40 on a client with 192.168.1.0/24 uses the connected route; if that address fails, look at the device, the switch or the firewall on the client instead of the VPN.

The case that fools people is a public address for a local server. From inside the LAN, reaching the router's WAN address and coming back requires hairpin NAT, and many routers simply do not implement it for port forwards. Test the private address next to the public one. If the private address works and the public one does not, the VPN only exposed a NAT limitation that was already there.

A hostname makes this worse. If the local name now resolves to the public address, the client will keep trying the path that cannot loop back. Use the private address for the test, then fix the name rather than adding another port forward.

Third, see who answers names now

A corporate resolver knows the intranet and usually nothing about a NAS hostname, a printer's Bonjour name or a router's local alias. When the VPN pushes its DNS servers, those names stop resolving even though their addresses are still reachable. Query the name directly and compare the answer with the address you know the device holds.

On Linux, resolvectl query nas.local shows which resolver answered. On Windows, nslookup nas.local names the server, and ipconfig /all shows the resolver order. If the local suffix is now handled by the corporate resolver, either route that suffix back to the local resolver or use the IP address for the device.

Discovery is a separate layer. mDNS and broadcast do not cross a routed tunnel, so a device can be reachable by address while its name stays invisible. A reflector or a local DNS entry solves that; a route does not.

Fourth, check whether the other machine is on a VPN too

When the machine you want to reach also runs a VPN client, your session can arrive while its reply leaves through the other tunnel. That produces a connection that establishes and then stalls, or an RDP and SSH attempt that times out with no error on your side. Check the other host's route table and its default path before blaming your client.

Also check the address the service listens on. A listener bound only to the tunnel address accepts connections from the VPN and refuses them from the LAN, even when routing is perfect. That is a service configuration, not a network path, and it is common on management interfaces that were locked down to the VPN address.

Keep a management path that does not depend on the tunnel: a static route naming your source network, another interface attached to the LAN, or a console that bypasses the tunnel entirely. Designing that path after the session drops is much harder than adding it before the next connect.

Apply the fix that matches the check that failed

If the route table showed a half-default capture, choose split tunnel when policy permits and a pinned local route when it does not. If the address turned out to be public, switch the test and the name to the private address. If the resolver changed hands, scope the local suffix or use the address. If the other host is tunneled, fix its return path or its listener binding.

Change one thing, then repeat the same check. A route added for the wrong subnet, a resolver suffix with a typo and a pinned route on an interface that renumbers all look like the original failure. The repeat is what separates a fix from a coincidence.

Write down the route, the address and the resolver that worked while the VPN is connected. The next reconnect will change at least one of them, and the note turns the next outage into a short comparison instead of a fresh investigation.