Printer Offline When the VPN Connects? Check the Route Table

Your laptop joins the corporate VPN and the printer two metres away stops answering. Nothing changed on the printer, and the local network did not go down. What changed is the route table: the tunnel adapter now owns a path that covers the printer address, so those packets leave through the VPN and arrive at a gateway that has no idea where your flat network is. Work the four checks below in order, and stop at the first one that fails.

Step one: prove the printer is still reachable on the LAN

Before you touch routing, confirm the device is alive for something that is not using the VPN. Ask a phone on the same Wi-Fi to open the printer's web page, or ping the address from another machine on the flat network. If the printer does not answer there either, the VPN is a coincidence and the fault sits with the printer, its Wi-Fi association, or client isolation on the access point.

If it answers everywhere except this laptop, you have a routing or name-resolution problem that lives on the laptop, and the next step tells you which of the two it is.

Step two: find the route Windows actually picks

Do not read the table from the top down and guess. Ask Windows which entry it selects for the exact address you care about, and get the interface index at the same time.

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

Find-NetRoute prints the winning route and its interface, which are the two facts the rest of this depends on. route print -4 shows the surrounding entries, including the two half-defaults that full-tunnel clients install: 0.0.0.0/1 and 128.0.0.0/1, together covering the whole IPv4 space without ever replacing 0.0.0.0/0. A /1 is longer than a /0, but your 192.168.1.0/24 is longer still, which is why a missing LAN route matters more than the tunnel claim itself.

Two rules decide the answer. The longest matching prefix wins first, and among entries with the same prefix the lower total metric wins, where the total combines the route metric and the interface metric. If the selected interface is the tunnel, keep going. If it is the physical adapter and traffic still fails, stop here: your problem is name resolution or the printer's own access list, not the VPN route.

Step three: add the narrowest route that names gateway and interface

The repair is one entry pointing the printer address at the local router on the local adapter. Run it in an elevated prompt and substitute the values you just read.

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

The if number is the interface index of the physical adapter. Leaving it out is the most common reason the command appears to succeed and changes nothing, because with two adapters able to reach the same next hop Windows is free to choose the one you did not want. The -p flag makes the entry persistent, so it survives a reboot instead of dying with the session.

Prefer a host route for the single device over a route for the whole 192.168.1.0/24. A subnet route is broader than the task needs, and it collides the moment the corporate side also uses that prefix: one prefix then has two owners, and whichever entry wins decides which network you can actually reach.

Going the other direction, if you cleared the default-gateway option on the VPN connection to protect the LAN, the remote private prefixes stop resolving too. Add routes for those through the VPN interface in the same way, or the tunnel becomes a link that carries nothing.

Step four: make the exception survive the next connect

Many corporate clients reinstall their entire route set on every connect and recompute interface metrics while doing it, so a route that worked yesterday can be outranked today. After reconnecting, repeat Find-NetRoute for the printer and check that the interface still matches the physical adapter. If the entry is gone, something is deleting it; a persistent route does not protect you from an agent that sweeps the table. Scheduled tasks that re-add the route after the VPN connects are the usual workaround, and they are also the workaround that breaks when the adapter index changes after a dock or a driver update.

Watch IPv6 on its own. A client that claims only the IPv4 default can leave the IPv6 default route on the physical adapter, so a printer reachable over IPv6 keeps working while IPv4 fails, or the reverse. Test with ping -4 and ping -6 before you decide the route table is innocent.

What the local shortcut costs you

Any route that bypasses the tunnel is a hole in the tunnel's promise. Traffic to that address no longer passes the corporate gateway, which means no inspection, no logging, and no policy enforcement on it. On a managed device that can be a compliance problem rather than a preference, so ask whether an official split-tunnel exception exists before you add one by hand. Keep yours as narrow as the task and as short-lived as the situation allows.

If the printer answers after the change, re-run the four checks after your next reconnect rather than assuming the fix held. If it does not answer, capture Find-NetRoute output before and after the connect; the difference tells you whether the client deleted the entry or only re-ranked it.