Kill switch blocking your printer? Three checks to run first
A kill switch blocks printer traffic on purpose. Run three checks to decide whether a scoped LAN exception is justified, and keep it to one address.
Your printer worked an hour ago. Then you turned the VPN on, and now jobs sit in the queue until they fail. The kill switch is the likely cause, not the printer: it drops traffic that would leave the machine outside the tunnel, and a LAN printer is exactly that kind of traffic. The real decision is not how to fix printing but whether this device should reach the local network at all. Three conditions settle that, and any one of them can end the discussion early.
What the kill switch drops and why
A kill switch is a routing rule with a failure mode attached. With the tunnel up, matching packets leave encrypted; when the tunnel drops, the client blackholes the default route so nothing goes out in plaintext. A printer on the same subnet never matches the tunnel route, so it is treated as an escape attempt even though the traffic never leaves the building.
Discovery makes the symptom confusing. Printers advertise over multicast DNS on port 5353, and the queue shown in the add-printer dialog is built from those advertisements. While the block is active the advertisement may not arrive, so the printer vanishes from the list even though its address still answers. IPP on 631, raw printing on 9100 and SMB on 445 are ordinary LAN services with no tunnel path at all.
Prove the printer is reachable first
Before changing any policy, confirm the printer is healthy and confirm the address you think it has. Read the address from the printer panel or its own web page. A stale entry in the operating system list can point at an address that DHCP handed to another device weeks ago.
Disconnect the VPN, then test the address and the two common print ports:
nc -vz 192.168.1.50 9100
nc -vz 192.168.1.50 631On Windows the equivalent is Test-NetConnection 192.168.1.50 -Port 9100. Reconnect the VPN and repeat. If the ports answer with the VPN off and time out with it on, you have reproduced the block and the rest is a policy question. If they fail in both states, stop: the printer, the Wi-Fi segment or client isolation is at fault, and a VPN exception would only add exposure.
Three conditions that decide allow or block
Run these in order. The first condition that fails settles the outcome, so the later ones do not need testing.
| Condition | Allow a scoped exception | Keep the block |
|---|---|---|
| Who owns the network | Home or single-tenant office where you control the segment | Hotel, cafe or shared Wi-Fi where the printer is not yours |
| Who owns the device policy | Personal device with no enforced profile | Managed profile that enforces always-on VPN |
| What the device carries | Nothing another LAN peer must not reach | Client data that must not touch an untrusted segment |
Guest networks are the clearest no. On a hotel segment the local range is every other guest, so an exception that reaches your printer also reaches their laptops. A printer you do not own is not a reason to open that segment.
Managed devices are the second no. When an administrator profile enforces always-on VPN with lockdown, the client reasserts the block after any local change, and the workaround may breach the policy you accepted. Ask for a supported local-resource path instead of editing settings that will be overwritten.
The smallest exception your client supports
What you want is a destination-scoped rule for one printer address, not a blanket allow-local toggle. A blanket toggle tends to cover the whole private range and link-local traffic, which is far more than one print queue needs, and it turns every device on the segment into a peer you accepted.
Windows exposes split tunnelling, and some builds also expose a local-network option. Where the only supported route is a host entry, add a single address through the physical gateway after the tunnel is up, for example route add 192.168.1.50 mask 255.255.255.255 192.168.1.1, then delete it when the session ends. WireGuard works differently: AllowedIPs decides what enters the tunnel, so a full-tunnel 0.0.0.0/0 profile carries the print job to the endpoint unless a more specific route bypasses it, and wg-quick can install firewall rules that block everything else.
On Android the always-on setting that blocks connections without the VPN is the kill switch, and printer discovery from an app inside that block has no LAN path. The per-app and exclusion model is documented on the Android VPN page, which is the place to check before you change anything: Android VPN connectivity guide. Recent macOS releases ask for local network permission separately from the tunnel, and iOS does the same for local network access, yet the queue can still fail with the tunnel up because the vendor client routes the subnet into it.
Whichever client you use, keep the exception to one address and the two or three ports the printer actually uses. Reserve a DHCP lease rather than widening the rule to the whole subnet because the address might move.
Verify the exception and know when to undo it
After the change, reconnect and check three things in order. The printer answers on its ports, a harmless test page prints, and an address lookup still returns the VPN endpoint rather than your ISP. If printing works but the lookup shows your ISP, you opened more than the printer and should revert.
Repeat the test after a reboot and after any client or profile update, since updates restore defaults often enough to matter. An exception that survives only until the next reconnect is not a decision, it is a temporary hole. Write the exact rule down so you can remove it deliberately.
If the device is meant to be tunnel-only, a travel laptop or a machine holding client data, the right answer is to keep the block and print elsewhere: save to PDF and print from a phone or another machine, or reach a print server the tunnel can route to. Disabling the kill switch for one job trades a real protection for a small convenience.