SMB 2240 Over VPN: Check the Logon Workstation List

Opening a share across the tunnel returns error 2240, and the first instinct is to look at routing. The number is more specific than that. Windows is reporting that the account may not log on from this workstation, which is a policy statement about one account rather than a statement about reachability.

Keep the error number in the ticket. It narrows the investigation to one attribute and one event.

What 2240 actually names

The network management error list identifies 2240 as NERR_InvalidWorkstation, a name worth reading literally. The account is restricted to a set of permitted logon computers, and the machine presenting the credentials is not among them. Nothing in that definition mentions the tunnel, the file share or the password. The attribute sits on the account and is evaluated when the logon is attempted.

Other numbers in the same family mean something else. A permitted logon hours violation is a different code, and so is a bad password. Reporting them all as an access problem wastes the specificity the operating system just provided.

The restriction lives on the account, so it follows the identity wherever it authenticates. A user who works at the office every day and takes a laptop home encounters it only when the machine name changes, which is why the failure can look like a VPN problem for months before anyone recognises the pattern.

Two related facts do not explain it. A NAT device can change the observed source address without touching the account attribute, and a DNS suffix change can fix a short name while leaving the logon restriction exactly where it was. Both are worth ruling out, and neither is a substitute for reading the attribute.

Read the failed-logon record first

Establish which identity the file server authenticated, and which machine presented it. A domain account, a local account with a similar short name, and a separate VPN account are not interchangeable, and the error only makes sense once the exact one is known.

The security log records the attempt with the account and the calling workstation name, which is the pair the restriction is evaluated against:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated,Message | Format-List
Get-ADUser -Identity jdoe -Properties LogonWorkstations |
  Select-Object SamAccountName,LogonWorkstations

The first command shows the failure and the workstation string the server received, and the second shows the permitted list on the account. Compare the two rather than assuming the client's own computer name is what the server recorded. A name that looks wrong in the log is usually the useful finding, because it names the machine the server actually believes it is talking to. That belief is what the restriction is checked against.

Do not add the VPN gateway's name because traffic passes through it. The gateway is not the authenticated caller, and adding it to the list changes nothing while making the account harder to review.

Correct the restriction at the smallest scope

If the machine should be permitted, add exactly that entry to the account's workstation list and leave everything else alone. If it should not, the correct answer is an approved machine rather than removing the restriction, because the restriction exists to limit where those credentials can be used.

Bulk edits are common here and usually wrong. An account with a long list of permitted machines is an account whose restriction has stopped meaning anything.

It also helps to know whether the identity is shared. When several people use one service account from several laptops, the workstation list grows until the policy is meaningless, which is a design problem rather than an administrative one.

Read the next result, not the absence of one

After an approved change, make a fresh request with the intended account and record what happens. A different error is progress, because it names the next stage rather than repeating the last one.

A DFS path can introduce several servers and several access decisions. Clearing one account attribute settles one of them. The referral targets still have to be reachable, and the share and filesystem permissions on each of them still have to admit the account. Work through the next error in the same way rather than assuming the first fix covered them all.

There is no reason to rebuild the VPN profile or reset the password while Windows is reporting a workstation restriction. Microsoft's network error list is worth keeping open for exactly this reason: the code tells you which attribute to inspect before you touch anything.