SMB Share Fails Only Over VPN: Signing or Subnet Clash?

A mapped drive that works in the office and times out at home gives you almost no useful information by itself. The tunnel is clearly carrying packets, or nothing would reach the server at all. What failed is one of three layers: the name resolved to the wrong address, the client refused to sign the session, or an old session outlived the connection that carried it. Each has a different repair, and two of the three are client-side.

Three failures wear the same error

The drive letter does not tell you which layer broke, and the error text is usually generic enough to fit all three. Split them with two quick questions: does the server answer by IP address, and does port 445 accept a connection?

Those answers produce a decision table rather than a guess. IP works and the name does not points at resolution. Both work and the logon is refused points at signing. Both work and a file read hangs after a tunnel outage points at a stale session.

Work through them in that order, because a name that resolves to the wrong host makes every later test meaningless.

Resolve the name before you touch the share

If the server answers at its address and the share name times out, the tunnel is doing its job and the client is looking in the wrong place. On remote access, two causes account for most of this.

The first is an address overlap. When the office uses 192.168.70.0/24 and the home router hands out the same range, a hostname that resolves to 192.168.70.20 can point at a local device instead of the server behind the tunnel. Windows may then send the request locally, refuse the route, or resolve to a printer that happens to hold that address. The repair is to renumber one side, not to add another route.

The second is DNS scope. A VPN adapter with no internal DNS server, or with one that is unreachable through the tunnel, leaves short names going to a public resolver. Read the adapter's DNS entries and query the internal name directly before touching the share:

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

If that lookup returns the address you expect, resolution is settled and the problem is further up the stack.

Read the signing requirement on both ends

A reachable server that refuses every logon is the signature of a policy mismatch rather than a network fault. Windows can require SMB signing on the client, and a server or NAS that does not sign cannot complete the session no matter how healthy the tunnel is.

You can read the client setting without hunting through the policy editor:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

The matching server-side value lives in the server's SMB configuration, and the two must agree. In one reported case the client had the requirement enabled by local policy while the server did not sign at all, and disabling it plus running gpupdate /force restored the share immediately. That is a diagnostic step worth taking to confirm the cause, not a permanent fix.

Prefer turning signing on at both ends where the server supports it. Changing a security setting to make a share work should be recorded with its previous value and the reason, so nobody has to rediscover it during the next audit.

Clear the stale session before tuning timers

A share that hangs only after the VPN drops and reconnects is usually holding a session the server has already discarded. The server closes idle SMB sessions on the Autodisconnect timer under LanmanServer\Parameters, which defaults to 15 minutes, while the client has its own SessTimeout under LanmanWorkstation\Parameters. An outage longer than those values leaves each end with a different idea of the session.

Reproduce it in a fixed order so the result means something: connect the tunnel, open the share, drop the tunnel for two minutes, restore it, then try to read a file. If the mount recovers on its own, leave the timers alone. If it hangs until you remount, reconnect the share after the tunnel is up instead of mounting before it exists, and check whether the mount helper retries.

Raising timeouts is a reasonable last step for a flaky link, but it treats the symptom. A client that waits longer for a session the server has forgotten still waits.

Finish by reading one file through the mount, then dropping and restoring the tunnel once more. That acceptance test covers all three layers at once, and it is the only test that matches what the user actually does.