Split Tunnel Is On and the Printer Is Still Offline: Why

Your tunnel is up, the internet works, split tunnelling was enabled months ago, and the printer beside the desk still shows as offline. That combination is not a contradiction, because split tunnelling is a routing decision rather than a reachability promise. Three mechanisms sit between the print queue and the paper, and they fail in ways that look identical from the tray icon. Follow the address first, then the route, then the filter.

Start with the address behind the queue

Read the address or hostname stored in the print queue, then compare it with the address the printer reports on its own network screen. A queue that still points at a previous address behaves exactly like a routing failure, and the two are hard to tell apart from the symptom alone. Get both values before you change either. One of them is usually stale, and the stale one is usually the queue.

A queue built on a hostname adds name resolution to the path, which is a separate mechanism from routing. If the hostname resolves differently inside the tunnel, the queue reaches a different machine or reaches nothing. A numeric address removes that variable for the duration of the test.

Write the pair down, because the rest of the investigation compares them rather than guessing.

How the route for that address is chosen

Suppose the printer is at 192.168.1.50 and the office network also uses 192.168.1.0/24. The tunnelled route covering that subnet can now compete with the on-link route to the printer in your flat, and the more specific entry wins. Changing the port to the same numeric address cannot remove that ambiguity, because the ambiguity is in the routing table.

A VPN profile that installs a default route captures everything, and the local-link prefix is then reachable only through the tunnel. A split-tunnel profile installs the corporate prefixes instead, which usually restores the local path. Inspect the route actually selected for the printer's address rather than the name of the setting that produced it.

Read the table and the selected route together, because the table shows candidates and the lookup shows the winner.

Get-Printer | Select-Object Name, PortName, DriverName
Get-PrinterPort -Name 'IP_192.168.1.50' | Select-Object PrinterHostAddress
route print -4 | Select-String '192.168.1'

Why discovery fails when the address works

Automatic printer discovery on a local network depends on multicast DNS or on an older broadcast protocol, and both are scoped to a link. A router does not forward that multicast by default, and a VPN is a router. Adding an address-based queue fixes the case where discovery is the only thing broken, which is exactly why that workaround is so often mistaken for luck.

The distinction is easy to record: if the address answers on the print port but the printer never appears in the add-printer list, discovery scope is the fault. If neither works, the route or the filter is. Two tests, two different owners, and no driver reinstall in between.

Test the address directly instead of waiting for a list to populate. The commands below do exactly that.

Test-NetConnection 192.168.1.50 -Port 9100
nslookup 192.168.1.50
ping -c 2 192.168.1.50

What the client's local-access filter adds

Endpoint clients can filter local traffic independently of the route table. The setting is often called local network access, and it can block traffic to the local segment while the tunnel is connected even when the route lookup looks correct. That is a policy layer, and no amount of route editing changes it.

On a managed device, ask the administrator what the profile intends rather than flipping the toggle yourself. The filter usually exists because somebody decided that a connected machine should not be able to reach the coffee-shop network, which is a reasonable decision to have made.

Read the client's own status or log for the policy in force, since the user interface often hides it behind a summary line. That log entry usually names the rule that decided.

Check the path with one small job

Once the address, the route and the filter all point at the printer, send a single short document to the same queue while the tunnel stays connected. That reproduces the original failure more closely than a driver reinstall tested only after disconnecting. Keep the job unremarkable, because you are testing a path rather than a device.

Then repeat with the tunnel disconnected, so you know whether the path you fixed was the one that used to work. That comparison is the only proof the change mattered.

Test-NetConnection 192.168.1.50 -Port 9100
Get-PrintJob -PrinterName 'Front Desk'
Get-NetRoute -DestinationPrefix 192.168.1.0/24

If the job prints in both states, the queue, the route and the filter agree and the fault is gone. If it prints only when disconnected, the tunnel still captures the printer's address or the filter still blocks it, and the next step is the route lookup rather than another driver. Record which of the three layers you changed, and the same ticket will not reopen next month.