Windows Firewall evaluates Block before Allow
The rule-ordering assumption that quietly cuts machines off the network — and the correct way to carve an exception out of a broad block.
Here is a rule that has locked more than one administrator out of a machine, because it inverts the intuition everyone brings from other firewalls.
Windows Firewall evaluates plain Block rules before plain Allow rules. Not in the order you created them. Not in the order they appear in the interface. Block wins.
Why this matters immediately
Suppose you want to isolate a machine from its local network while keeping the router reachable. The natural approach:
- Block all traffic to
192.168.0.0/16 - Allow traffic to
192.168.1.1, the gateway
That configuration does not do what it appears to. The block rule is evaluated first, matches the gateway address, and the machine loses its default route. The allow rule sitting next to it never gets a look in.
If you are working remotely, you have just cut yourself off with a rule that reads correctly.
The correct pattern
The exception has to be in the addresses, not in a separate rule.
Rather than blocking the whole private range and allowing an exception, compute the range minus the exceptions and block only the remainder. If you want to block everything in 192.168.1.0/24 except .1, .2 and .3, your block rule's address list must contain 192.168.1.4-192.168.1.255 — the gateway and DNS servers are simply absent from the list of things being blocked.
It is more arithmetic, and it is the only approach that behaves predictably.
The exception to the exception
Windows Firewall does support explicit rule priority, but only in one direction: a rule marked as an override (-Override Block on an allow rule, in PowerShell terms) will beat a block rule. This is primarily for authenticated IPsec bypass, and it requires the connection to be authenticated. It is not a general-purpose "make this allow rule win" switch, and reaching for it usually signals that the address-based approach was the right answer.
Network drift will break your rules
A second trap, and a worse one, because it fires later.
Any allow list you compute is a snapshot. Networks move:
- Starting WSL or Docker adds virtual adapters on new subnets
- Joining a different network changes your gateway
- A DHCP renewal can change your own address
If your block rules were computed when the gateway was 192.168.1.1, and the machine later joins a network where the gateway is 10.0.0.1, that new gateway falls inside the blocked range. The machine loses its route — silently, from a security feature, at the worst possible moment.
Any rule set derived from the current network needs to be reconciled when the network changes: recompute the intended set, compare it with what is live, and rewrite on drift.
One detail that bites during that comparison: Windows reports firewall rule addresses in dotted-mask form (10.0.0.0/255.0.0.0), not CIDR (10.0.0.0/8). Comparing the two as strings will tell you every rule has drifted, every time.
Verify from outside the tool that made the change
After writing firewall rules, confirm the outcome through a different channel than the one you used to create them:
Get-NetFirewallRule -DisplayName 'YourRule*' |
Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Then actually test reachability — ping the gateway, resolve a name, fetch a page. A rule set that reads correctly and cuts off DNS is a rule set that reads correctly.
And before you apply anything broad, write down the revert command. For firewall rules that is usually a one-liner:
Remove-NetFirewallRule -DisplayName 'YourRule*'
Having it ready before you need it is the difference between an inconvenience and an outage.