Mapped Drive Over a Site VPN: DNS, SMB and the UNC Path

The Network page in Explorer shows devices that announced themselves on the local segment, and a routed tunnel carries none of those announcements. That is why a server can be perfectly reachable while the window in front of the user stays empty. A named UNC path does not depend on discovery at all, and the fix is to make the name resolve and the port answer. The empty window is a symptom of the wrong layer, not a broken share.

Discovery is not the same as reachability

Windows discovers nearby machines through protocols that are designed for a broadcast domain, then presents what it found as a convenience list. Nothing in that list is required for SMB file access. A client that knows the server name and can reach TCP 445 will open the share whether or not the machine ever appears under Network.

The two layers fail independently, which is why "I cannot see it" and "I cannot open it" deserve different tests. Checking the list tells you about discovery; opening the path tells you about the service.

Name the server before you map the share

Publish the file server in DNS with the address it holds on the far side, and point the client site at a resolver that can answer for that zone. A fully qualified name avoids depending on a local suffix search list, which is the usual reason a short name works at one site and fails at another.

If the environment uses Active Directory, name resolution is also part of authentication: the client needs to reach a domain controller for Kerberos, and a clock that is too far out of step will fail the ticket exchange. That is a different problem from SMB reachability and looks like a credential error. Test the domain controller before you retype the password.

Route and filter in both directions

A site-to-site tunnel needs the remote prefix in the local route table and the local prefix in the remote one, and the firewall on each side must permit the traffic that arrives. One-way configuration produces a connection that opens and never answers, which users describe as the share being slow. Check the tunnel's own counters first. If packets leave and nothing returns, the return route or the remote filter is the place to look.

With WireGuard, the peer's allowed IPs and the operating system routes have to agree with that design. The tunnel carries packets; it does not provision DNS records or share permissions on either side.

Base the firewall rule on the actual source network that will connect, and write the exception down. If the design translates addresses somewhere in the path, the rule has to use the translated source, and the original client address is no longer visible for logging.

Authenticate, then map the drive

Work down the layers with commands rather than with the Explorer window:

Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:no

The second command proves the TCP path, not the right to read anything. The third is where authentication and authorization are exercised, and a failure there should send you to the share and filesystem permissions rather than back to the router.

Keep SMB signing and the existing authentication policy intact. Re-enabling SMB1 or forwarding discovery broadcasts across the tunnel is not needed for an explicit path, and TCP 445 should stay on the private path rather than on an internet-facing forward. Give users a managed shortcut or mapped drive to the approved name, and the empty Network page stops mattering.