Local Devices Vanish on VPN: Three Separate Failures

A printer that disappears from the device list when the VPN comes up may still answer at its address. The list is populated by discovery, the name may come from a resolver, and the service itself is reached over a socket, and the three can fail independently. Comparing what works at each layer tells you which feature to change. Turning on every local-access exception first removes the evidence.

That is the difference between a device that is missing and a device that is merely not advertised.

Discovery, Names and Reachability Are Three Layers

Discovery protocols rely on multicast or broadcast, and those do not cross a routed tunnel by default, which is why a device can vanish from a list while remaining perfectly reachable. Name resolution is a second layer: a VPN may change the resolver, and a name previously answered by the local network may now be answered elsewhere or not at all. Reachability is the third: a route, a firewall rule and a listening service. Each layer can break while the other two are fine.

Test them from the bottom up. A single reachability check makes the split obvious: nc -vz 192.168.1.20 443 either succeeds, which means the path and the service are fine and the name is the suspect, or it fails, which moves the question to routing and policy. Then ask the name. The first failure you hit is the layer to work on, and the layers above cannot compensate for it.

Ask the Address First, Then the Hostname

If the address answers and the name does not, the problem is resolution rather than routing. A VPN client that installs its own resolver can change which server answers local names, and one that does not forward the local domain leaves the name unanswered. If the address fails as well, the path is the issue: a default route through the tunnel, a client-side block on local traffic, or a firewall rule that only permits the physical interface.

If both work but automatic discovery does not, the device simply is not advertising across the tunnel. That is expected behaviour for multicast-based discovery, not a configuration failure. Adding the device by address is usually the honest fix.

What the Local-Access Toggle Actually Changes

A local network access setting typically permits traffic to the directly attached subnet to bypass the tunnel, and it does different things in different clients. It does not configure forwarding to a remote office, and it does not change the host firewall or the application's own permissions. It also does not make an overlapping subnet unambiguous. Read the client's documentation for what the setting covers before enabling it broadly.

A narrow exception for one trusted device beats a blanket allowance, especially on a guest network where the block may be deliberate. A private address is not an identity check, so the choice depends on the network you are on.

When the Networks Overlap

If the home network and the remote network use the same range, routing becomes ambiguous and neither a local-access toggle nor an exception resolves it. Two services at the same address cannot both be reached, and which one wins depends on route specificity and ordering rather than intent. The fix is address planning, not a client setting. Check the ranges before spending an evening on the printer.

For a device behind the remote gateway, the operator owns forwarding, host policy and the return route. A local checkbox on the client cannot supply any of them, and asking for one is more productive than experimenting with toggles.

Record which layer failed and what you changed. The next device will fail in one of the same three places.