LocalSubnet in an SMB firewall rule will not cover VPN clients
A LocalSubnet allow rule covers the server's own subnets, not a routed VPN pool. Compare the source address the server sees before widening the scope.
Office desktops reach the share, VPN users time out, and the same account works from a phone hotspot. The share permissions are rarely the difference; the address that arrives at the file server usually is. A rule scoped to LocalSubnet admits the server's own attached subnets, and a separately routed VPN pool is not one of them. Two designs close the gap, and they leave very different records behind.
Two designs, one symptom
The first design adds the VPN pool to the rule's remote address condition. The server then sees each client's tunnel address, so its logs can separate one remote user from another. The second design routes VPN traffic through a gateway that translates it to a LAN address before the server sees it. That restores connectivity and removes the distinction in the same step.
The table describes roles rather than addresses, and your own prefixes decide which row applies. Print the server's real values instead of copying an example from a blog post:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthThe table is a decision aid, not a claim about every deployment. A host with extra interfaces, a second site link or a different mask has a different local set.
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
Microsoft's New-NetFirewallRule reference documents the remote address conditions and the LocalSubnet keyword. Read it before you decide that the keyword means all private addresses, because it does not.
Compare what the server actually receives
Read the effective rule instead of the one somebody remembers creating. Check that it is enabled, that it applies to the active profile, and that its remote address condition matches the source the server sees. A rule enabled only on the Domain profile does nothing when the adapter has slipped to Public after a network change.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionThe first command prints the address filters attached to the file-sharing rules, and the second shows which profiles are active and how unmatched inbound traffic is treated. Also look for a blocking rule and for centrally managed policy. Block rules take precedence over allow rules, and a policy that disables local rule merging can make a new local exception inert.
That is the case where the rule looks correct in the console and has no effect on traffic. Check the profile assignment at the same time, because a laptop that joined a different network can move to the Public profile without anybody touching the firewall.
Test the transport before the login
Separate reachability from authentication. A listener on TCP 445 proves a service is bound to the port; it does not prove a remote packet can reach it. A completed TCP connection, in turn, says nothing yet about SMB session setup or share permissions. Test the handshake from both sides before you edit a rule.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedThe first command reports whether a TCP handshake succeeds from the machine you run it on, and the second adds the resolved address and interface details. Run it from the VPN client and from an office desktop, then compare. Ping answers neither question, because ICMP may be blocked while SMB is open, or permitted while the firewall drops 445.
If the handshake fails only from the VPN, the source scope is the leading suspect. If it succeeds and the share still refuses you, move to SMB session and permission diagnosis rather than editing firewall rules.
When source NAT removes the distinction
With translation in the path, the server cannot tell individual VPN clients apart by address. Every remote user arrives as the gateway. Any authorization that depends on distinguishing them has to be enforced where their identities are still visible, which usually means the VPN concentrator or an authenticating proxy. The firewall rule can admit traffic; it cannot restore a distinction that translation removed.
Once that gateway address is allowed, every remote user is recorded under a single address, so the rule grants the whole pool to anyone who can reach the gateway. If a per-user decision matters, keep the original addresses visible or move the decision to a layer that still knows the user. Otherwise every remote user inherits the permissions of the one address the server can see, and the audit trail cannot tell them apart afterwards. That is a design decision, not a firewall detail.
Choose deliberately between the two designs. Scope the rule to the real VPN pool when the server must see who connected, and accept the translated path only when the server genuinely does not need that information. Record the chosen source range next to the rule, because the next person to debug this will look at the address table first.