Network Shares Not Showing on a VPN? Discovery Stops

The share opens when you type its path, and the network browser shows nothing at all. That combination is common over a tunnel and usually not a fault. Discovery asks the local segment a question; reachability asks one host. A routed tunnel carries the second and not the first.

Discovery and Reachability Are Separate

A browse list is produced by protocols that announce services to a local segment and listen for those announcements. Opening a share by name is a direct connection to one host. The first needs a broadcast or multicast domain; the second needs a route and a port.

Over a tunnel the second can work perfectly while the first returns an empty window. Treating the empty window as the failure sends you looking for a broken tunnel that is doing its job.

Why the Browse List Stays Empty

Windows retired the Computer Browser service and disabled SMB version 1 by default, which removed the machinery behind the old Network Neighborhood. Replacements such as WS-Discovery, SSDP and multicast DNS address broadcast or multicast groups that exist only on a local link. A point-to-point tunnel has no such link, and routers do not forward those groups by default. Every host can be reachable and the list can still be empty.

Some clients add their own discovery helper. When that helper works, it is a feature of the client, not a property of the tunnel.

Use Explicit Names, Then Confirm Access

A UNC path, a mapped drive or a Finder connection to an SMB address works over the tunnel once the name resolves and the port is open. Resolution can come from DNS, from a search suffix the VPN supplies, or from a centrally managed hosts entry. In a domain, a directory query can list computer objects, and that list is usually the nearest substitute for a browse view on a routed network. A port scan of known prefixes is acceptable only on networks you run or are explicitly authorized to test.

A host that answers does not promise that the share will open. A NAS can have an allowlist limited to its own subnet, which rejects VPN-pool addresses. A file server's firewall rule may name the local subnet only. The account you supply for the share may be a local account that was never created on that server, and connecting through the VPN does not create it.

Some corporate clients deliberately block local and virtual-machine traffic while the tunnel is up. That missing access is policy, and the fix belongs to the administrator rather than to the client's route table.

A Diagnostic Order Worth Repeating

Walk the layers in order: reach the address, resolve the name, open port 445, authenticate, then read the share permissions. Each answer is separate, and skipping ahead produces a confident wrong conclusion. Only after all of them pass is discovery worth investigating.

nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe

Leave a note with the server name, the share path, the address it resolved to and the account that worked. If the browse list later fills in after a service restart, treat that as a discovery quirk rather than proof that the earlier route was wrong. The note is what lets the next person skip the empty window.