Why Your VPN Adapter Stays on the Public Firewall Profile

The tunnel is up, the account authenticated against the domain, and Windows still labels the connection Public. A firewall rule written for the domain profile therefore does not apply, and the file share stays unreachable. The usual fix attempt is to set the adapter to Private, which changes which rules apply without changing anything about authentication. Both the label and the fix are widely misunderstood, and separating them takes three commands.

The account that dialled in is not the network's category

Two different decisions happen during a VPN connection and they are easy to conflate. The gateway decides whether the account may connect. Windows decides how to classify the resulting network, and that classification drives which firewall rules apply to the interface.

A successful domain authentication at the gateway is evidence about the account. It is not evidence that the endpoint has authenticated the network against a domain controller, which is what the domain category actually represents.

That is why a machine can be domain-joined, connect with a domain account, and still show Public. The classification is a local determination about the network, not a statement about the credentials that opened the tunnel. The account can be perfectly valid while the label stays where it started.

Three categories, one of which you cannot set

Windows exposes three categories and only two of them are assignable by an administrator. The third is decided by the operating system after it successfully authenticates the network against a domain controller.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

The third command fails, and that is the documented behaviour rather than a permissions problem. The cmdlet's own reference states that the domain category cannot be assigned this way, because Windows derives it from domain authentication. Seeing the error is useful confirmation that the category is a consequence rather than a setting.

Read the first command on the endpoint whose traffic is being blocked. A gateway's own interface classification tells you nothing about how each connecting workstation classified its tunnel.

Rules follow the profile they were written for

Once you know the category, the missing access usually explains itself. Every Windows Firewall rule carries a profile scope, and a rule scoped to domain does not apply when the interface is public. Three commands turn that into an answer rather than a theory, and the third one catches the case where the profile was never the problem:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

The second command is the one that turns a vague report into a fix. If the rule is scoped to a remote address range that does not include the VPN pool, changing the profile will not help either.

Check the default inbound action as well. On a machine where inbound is blocked by default, a missing allow rule produces silence rather than a rejection. That looks identical to a routing failure from the client side, which is why so many of these tickets start with the wrong assumption.

Work out which machine enforces the rule

Before changing a category, establish where the block is happening. The server that hosts the share may have its own firewall, and its rules apply to the traffic arriving from the VPN pool regardless of how the client labelled its adapter. A rejection there is invisible to every local command you run, and the client side only reports that the resource is unavailable. Test the destination's own rules before you touch the client's classification.

Test from the client to the specific port, then compare with a test from another host on the same VPN. If both fail, the problem is at the destination or on the path. If only one fails, the difference is local to that machine, and the profile category becomes a plausible cause.

Keep the direction in mind as well. A rule that allows inbound SMB does nothing for a client whose own outbound rule blocks the same traffic. From a file explorer window the two failures are indistinguishable, so test each direction separately before editing anything.

What to do instead of relabelling everything

Making an unidentified network Private to satisfy a broad rule is a real change with real consequences. The private profile typically allows more discovery and more inbound traffic than the public one.

If the goal is to let a specific service reach the VPN clients, scope the rule by remote address instead of by profile. That expresses the intent precisely, works regardless of classification, and does not depend on Windows guessing correctly about a virtual adapter. It also survives a client update that reclassifies the interface. Write the pool into the rule and the next person can read the intent without asking.

If the domain category is genuinely expected and never appears, that is a separate investigation. Check that the machine is domain-joined, that it can reach a domain controller over the tunnel, and that the secure channel is healthy. Those three commands answer it without a single registry edit:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Those three answer whether the endpoint could have authenticated the network at all. If it cannot reach a controller, the domain category will never be assigned no matter how many times the adapter is reset. The firewall rule you were chasing was never the real problem, and the label was a symptom of a broken path rather than a cause.