It’s a common problem that Windows Firewall doesn’t switch to the Domain profile when a VPN tunnel is established to the company network. Apply the settings below on all Windows endpoints to avoid the issue.
The Problem
It’s important that Windows Firewall switches to the Domain profile when a VPN tunnel is established. However, you’ll often see seemingly random cases where this doesn’t happen. This can result in overly restrictive Public/Private profile rules blocking applications and OS features.
I’ve seen this issue with Pulse Secure, Palo Alto Global Protect and Cisco Anyconnect. It doesn’t happen all the time, but often enough that I now apply the solution below to all Windows computers with a VPN client.
The Solution
Create the following two registry values on the Windows client:
# Disable Domain Discovery negative caching
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
ValueName: NegativeCachePeriod
ValueType: REG_DWORD
ValueData: 0
# Disable DNS negative caching
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
ValueName: MaxNegativeCacheTtl
ValueType: REG_DWORD
ValueData: 0
You don’t even need to reboot. Just reconnect the VPN and re-check the active Firewall profiles. The Domain Profile should be active as shown below:
netsh advfirewall monitor show currentprofile
Domain Profile:
----------------------------------------------------------------------
MYCOMPANY.COM
Public Profile:
----------------------------------------------------------------------
Unidentified network
Ok.
What effect do the registry settings have?
Negative caching is a name resolution feature that occurs when a name lookup fails. The failure is cached and not retried until the time-to-live expires the item from the cache.
Background services on a Windows laptop may attempt to resolve the computer domain name and fail because the VPN is not connected. When the VPN does connects, the client attempts a DGGetDC call to the computer domain, but the negative name resolution result is returned from the cache and this fails. The Windows Firewall does not activate the Domain Profile even though the Domain would be reachable.
The two registry settings above disable workstation negative caching for the DNS client and Netlogon service. When the VPN connects, the DSGetDC call succeeds even if it recently failed.
I’ve not experienced any downsides or side-effects with these settings
Background
Windows Firewall has basic location awareness through its three profiles:
| Profile Name | Description |
|---|---|
| Public | Automatically applied when a domain controller is not reachable (computer domain) |
| Domain | Automatically applied when a domain controller is reachable (computer domain) |
| Private | A public network that has been manually designated as private by user selections |
Profiles allow different rules to be applied depending on the scenario. It’s common for the Domain profile to be more permissive than the Public profile (although this is changing with zero trust concepts).
Firewall Profiles are applied per-network interface. If a computer is connected to Public WIFI and Corporate ethernet at the same time, both the Domain and Public profiles will be active.
A VPN client is an example where per-adapter profiles come into play. VPN clients normally use a virtual network adapter that “connects” when the VPN tunnel is established. Windows Firewall should apply the Domain profile to the virtual interface, as the computer domain is reachable. At the same time, the physical network adapter is connected to a local network that receives the Public profile because a domain controller is not reachable.
The Private Profile is an edge case. Windows will prompt the user when it detects a new public network with a dialog asking “Do you want your PC to be discoverable by other PCs and devices on this network?”. If you select “yes” the network is tagged as Private. This dialog is often supressed by policy in enterprises.
This article was originally posted on Write-Verbose.com