SMB Guest Logon Over VPN: Windows Still Wants an Identity

Joining the office VPN makes the file server reachable and still leaves the share refusing access, which invites the conclusion that the tunnel is broken. It usually is not. SMB authenticates each session separately, and Windows has been tightening what it accepts as an anonymous logon. A network path and a user identity are different requirements, and the second one is what the error is about.

Why the tunnel cannot substitute for an SMB identity

Sharing a subnet with a server has never implied permission to read its files; it only removes the routing problem. Windows records event 31017 when its client blocks an insecure guest logon, and that is a decision made on your machine rather than on the server. The tunnel carries SMB packets faithfully while the guest session is refused. That is why one laptop on identical home networks works and another does not.

Treat the event as evidence of a policy, not as a network fault. The fix belongs in identity or in the appliance.

Read the client policy and the rejection event

Two outputs settle the question quickly: the effective client configuration and the recent rejection events.

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

A false guest setting combined with a true signature requirement explains the failure before any further investigation. The event log confirms the client refused the session rather than the server rejecting a credential. Note the share path and account used in a working attempt on another machine, because a cached session can make two tests look identical when they are not. Clear existing connections with net use before comparing, so an old session does not answer for the new one.

Use a named account and keep signing

The durable fix is an account the server knows, supplied explicitly, with signature and encryption policy left alone. Provide the credential on the connection instead of typing a random name into the dialog.

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

A named logon produces a session the server can audit, and Get-SmbConnection shows the dialect and whether signing is active. Guest sessions cannot satisfy signing or encryption requirements, so enabling a guest flag cannot rescue a policy that demands them. Where a legacy appliance has no account model, treat guest access as an explicit documented exception with a replacement plan. Do not weaken signing for every connection to accommodate one device.

When the appliance only speaks guest

Some consumer NAS boxes expose shares with no account concept, which leaves two honest options: isolate the device or replace it. Put it on a segment with no route to anything sensitive, and do not let a convenience exception become the default for the whole client. A guest share holding backups or credentials is a data exposure problem rather than a Windows annoyance. If a firmware update adds user accounts, that is the cheaper long-term answer.

Record the accepted account and the policy values in the ticket. The next person will otherwise rerun the tunnel test and arrive at the same refusal.