VPN Clients Blocked by the Windows Public Firewall Profile

Your tunnel is up, the gateway answers ping, and the file share still times out. That combination is rarely a route problem: Windows has put the VPN adapter's subnet in the Public profile, and every allow rule written for Private or Domain never applied. I have hit this on laptops that reach the office fine and on RRAS servers that serve every other client, and the repair is short once you name the profile in play. Here is the order I work in, with the check that tells you to stop before the next step.

Find which profile the traffic actually arrives on

Windows Firewall has no single global mode. Each connected interface carries a category, and inbound packets are filtered against the category of the interface they arrive on, so the VPN adapter's profile decides what a tunneled client can reach, not the Wi-Fi or Ethernet adapter sitting beside it. Read both facts before editing anything:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

On a stock OpenVPN or WireGuard install the VPN adapter appears as an unidentified network and lands in Public, which is the default for any network Windows cannot classify: no domain controller answered over it and no gateway profile matched. The interface name is irrelevant here, so calling the adapter "VPN" or "Corp" changes nothing. DomainAuthenticated needs a domain-joined machine that can actually reach a domain controller over that interface, and a split tunnel that carries one subnet will not satisfy it.

If the rule you need is already scoped to the VPN pool and already applies to the category you just read, stop here: filtering is not your layer, and the next place to look is the service configuration. That check takes ten seconds and saves an hour of rule editing. The category names and what each one covers are documented in the Get-NetConnectionProfile reference.

Confirm filtering, not routing, before you edit rules

Ping is a weak test. ICMP can pass while the service port is dropped, and a host can answer from the LAN while refusing the same request over the tunnel. Test the port the client needs, from the client:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

If the port test fails, separate the two layers. A tunnel or route fault usually shows up as no answer from the gateway address at all, while a firewall drop shows a gateway that answers and a service port that does not. On a Windows server publishing the pool through RRAS, run the same test from a client and read the server's own profile: the RAS interface can sit in a category whose inbound rules never mention the client range, which is why the box serves its LAN and refuses every tunneled client.

When the result is still ambiguous, log the drops for the profile in play and read them:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Entries naming the client address and port with DROP are conclusive, and they also tell you which rule was missing. A log with nothing in it while the client's SYN never appears points upstream of the host, so go back to the tunnel, the NAT rule, or the pool route before touching another firewall object.

Scope one inbound rule to the client pool

The repair is one inbound allow rule whose remote address is the pool, not the world. From an elevated session:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

When the service is a single binary, prefer a program-scoped rule with -Program over a port list; that confines the exception to the process as well as to the source range.

Profile choice is where the same mistake gets made in the other direction. -Profile Public is enough when the adapter is Public and stays Public. -Profile Any is defensible when the service must work no matter how Windows classifies the adapter, but only while the remote scope stays. What is never defensible is -RemoteAddress Any on the Public profile: that rule follows the laptop into every cafe and hotel network it joins and opens the port to whoever shares that subnet.

Record the pool next to the rule. -RemoteAddress 10.8.0.0/24 silently stops matching the day the VPN pool is renumbered, and the failure looks exactly like the original bug, which is why it wastes a second afternoon. Name rules after the service and the source range, keep them together with -Group, and re-read them whenever the pool definition changes. A rule inventory you can audit in one screen beats a correct rule nobody can find.

Change the category only when the category is the decision

Flipping the interface to Private also works, and it is the wrong default. The Private profile carries a long list of built-in allow rules, covering file and printer sharing, network discovery, remote desktop, and more depending on the baseline, so reclassifying the VPN adapter enables all of them for every client on the tunnel at once. One scoped rule grants one service to one range. On a laptop that also joins untrusted networks, that difference is not cosmetic.

There are cases where the classification is genuinely wrong: an always-on or site-to-site tunnel carrying an office subnet is trusted infrastructure, and marking that adapter Private is a legitimate design choice made once, by policy, not per ticket. When you do make it, make it explicitly:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

On a managed device, check first whether Group Policy or an MDM baseline owns the setting. If it does, the local change is undone at the next refresh and gpresult /h will name the policy that owns it; fix it there, not on the endpoint.

Verify from both ends and leave a trail

Verify the flow the user reported, from the client, after the change:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Then close the loop on the things that break next week. Reboot the host and re-test, because a rule scoped to the wrong profile keeps working until the adapter comes back in another category. Test from a second client, since one client holding a stale lease can hide a pool mismatch. Count the rules you added against the rules you removed, because overlapping exceptions are how a two-line fix turns into a filtering policy nobody can review.

Before you call it done:

• The profile named in the rule is the profile on the interface the traffic arrives on.
• The remote scope is the VPN pool, and that pool matches what the server actually hands out.
• No rule you added uses -RemoteAddress Any on the Public profile.
• Nothing was disabled to make the test pass, and any category change records who approved it.