Should Your Windows VPN Adapter Be Private or Public?

Setting a Windows VPN adapter to Private is right for a corporate tunnel and wrong for a commercial VPN client, and the difference is not cosmetic. The network category selects a firewall profile, so one change admits an entire rule set at once. I have watched a login script set every unidentified adapter to Private, which quietly exposed file sharing on a hotel wireless network. Three conditions decide the answer, and all of them have to hold before you touch the setting.

What the category actually decides

Network Location Awareness builds a signature for every connected network from what the adapter can report: the gateway address and MAC, the DNS suffix, whether a domain controller answers, and whether the network reaches the internet. Windows attaches a profile to that signature, and the firewall then applies the rule set for that profile. Public is the fallback whenever identification fails, which is why a working tunnel can still be labeled Unidentified network.

A TUN or TAP adapter usually gives identification very little to work with. The tunnel peer is often a single address rather than a gateway, DNS may be pushed only inside the tunnel, and the adapter has no default route of its own. The resulting label describes the firewall input, not the health of the tunnel, and it is the reason private-profile rules stop matching the moment the VPN connects.

Condition one: the tunnel is the trusted path

Choosing Private asserts that everything reachable through this interface is at least as trustworthy as your own LAN, because discovery and inbound rules will treat that subnet as local. For a corporate tunnel into a managed subnet with file servers and printers, the assertion usually holds. The adapter is a door into a network your organization controls, and the machine on the other side was admitted by the same policy that admitted yours.

A commercial VPN exit fails this test. Other subscribers share the exit subnet, and marking it Private puts network discovery, LLMNR and NetBIOS name resolution onto a segment full of strangers. Split tunneling can fail it too: when the adapter carries a single host route to one application, there is no trusted subnet to speak of, and the category change buys you nothing.

Condition two: the classification survives reconnects

A new gateway or DNS suffix produces a new signature, and Windows makes a fresh profile decision for it. A one-off Set-NetConnectionProfile therefore survives until the next reconnect, not forever. Check the profile after a reconnect rather than after the first connect, because that is when the setting reverts on its own.

There are three ways to make it stick. The cleanest is policy: open secpol.msc, go to Network List Manager Policies, and set the location type for the network, including the unidentified-network policy, so the profile is applied by policy rather than by a command. The second is a per-connection script or scheduled task that runs the PowerShell cmdlet after the tunnel comes up. The third is the long-standing route trick, which gives identification a gateway to probe:

route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfile

The route trick is a workaround, not a classification. It breaks when the metric relationship changes or the VPN client rewrites routes on reconnect, and it silently changes path selection for anything that falls back to the second default route.

Condition three: you need the private rule set

Private commonly carries File and Printer Sharing, Network Discovery, and the remote administration groups. If the task is reaching an SMB share or a printer across the tunnel, that is the actual reason to change the category. If the task is outbound access to one web application, the category is irrelevant: write the outbound rule, keep Public, and stop there.

Read the table as a starting point, then check which private rules are actually enabled on your build. A hardened image may have removed file sharing from the private profile entirely, in which case the category change accomplishes nothing until you add the rule back. That check takes one command and saves a long afternoon.

Making the change without widening everything else

Target the interface index, not a wildcard, and read the list before and after:

Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfile

Stored profiles live under the NetworkList key in the registry, where the Category value separates public, private and domain networks. Editing it is possible and easy to get wrong: you must change the entry that matches the adapter current signature, not an older entry left behind by a previous address. A stale entry looks correct in the editor and does nothing on reconnect.

Whatever you do, do not ship a script that sets every unidentified adapter to Private. That is the one-line version of opening discovery on untrusted wireless. If you need sharing only with the tunnel subnet, keep the profile Public and add scoped inbound rules limited to the tunnel remote address range; the firewall rule is narrower than the category.

Verify the share, not the label

After the change, test the resource itself rather than trusting the label:

Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.example

If the share still fails while the adapter shows Private, the category is no longer your problem. Name resolution, a missing route, or share permissions will produce the same symptom, and changing the profile again cannot repair any of them. Reconnect once and re-run Get-NetConnectionProfile to confirm the setting held, then work the remaining failure as a normal SMB problem.

Checklist: confirm the tunnel is a managed path, confirm the profile survives a reconnect, confirm the private rules you need exist on the image, and confirm the share resolves and answers on port 445. If any of the first three is false, leave the adapter on Public and solve the access problem with a scoped rule instead.