FWP_RANGE (0X80320020) Fix: Invalid IP Range in Firewall Rules

Why You’re Seeing 0X80320020

This error comes from the Windows Filtering Platform (WFP) when you try to add or update a firewall rule that contains an IP range or port range that doesn’t parse correctly. What’s actually happening here is that the WFP engine validates every rule against a strict grammar for ranges — if you write 10.0.0.0-10.0.0.256 or 1000-70000, it’ll reject the whole rule with 0X80320020.

You’ll most likely see this when:

• You run a script that creates firewall rules programmatically (PowerShell, batch, third-party VPN or gaming software).
• You manually edit a rule in wf.msc and mistype a range.
• A piece of malware or a broken driver tries to register a malformed rule.

Thing is, Windows doesn’t tell you which rule is broken — it just throws the error and quits. So you have to hunt the bad rule yourself.

Cause 1: A Port Range That Overflows or Uses Wrong Syntax

This is the most common trigger. Port ranges in Windows must be between 1 and 65535, inclusive. If you write 0-100 or 50000-70000, the WFP engine returns 0x80320020 because the range boundaries aren’t valid.

# Example of a bad port range rule in PowerShell:
New-NetFirewallRule -DisplayName "BadRule" -Direction Inbound -LocalPort 0-100 -Protocol TCP
# This fails with 0x80320020 because port 0 is invalid.

The Fix

Open an elevated PowerShell or Command Prompt and run this to find rules with suspiciously low or high port numbers:

Get-NetFirewallRule | Where-Object { $_.LocalPort -contains '0' -or $_.LocalPort -contains '65536' } | Format-Table Name, LocalPort, RemotePort -AutoSize

# If you get results, delete them:
Remove-NetFirewallRule -Name "NameOfBadRule"

The reason step 3 works is that Get-NetFirewallRule returns the parsed rule objects — if the range was stored as a string like "0-100", the LocalPort property shows it as an array. Any entry with 0 or 65536 is an instant fail.

If you don’t get results that way, export all your rules and grep for port ranges that exceed 65535:

netsh advfirewall firewall show rule name=all verbose > C:\rules.txt
# Then open rules.txt and search for "LocalPort" or "RemotePort" values above 65535 or below 1.

Cause 2: An IP Range That’s Out of Bounds or Misformatted

IP ranges in WFP must follow CIDR notation or explicit start-end notation (e.g., 10.0.0.0-10.0.0.255). If you specify an end address that’s less than the start, or an octet outside 0-255, you’ll hit the same error.

Common mistakes:

• 10.0.0.0-10.0.1.255 (actually fine if it’s a contiguous block, but some apps generate garbage like 10.0.0.0-10.0.0.256)
• 192.168.1.0-192.168.0.255 (reversed range — start > end)
• 172.16.0.0/33 (prefix length > 32)

The Fix

First, identify which rules have remote or local address conditions that are broken:

Get-NetFirewallRule | Get-NetFirewallAddressFilter | Where-Object { $_.RemoteAddress -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}-(?:25[6-9]|2[6-9]\d|[3-9]\d{2}|[1-9]\d{3,})' } | Format-Table -Property RemoteAddress, LocalAddress

# Or simpler — look for any rule referencing IPs with octets >255:
Get-NetFirewallRule | Get-NetFirewallAddressFilter | Where-Object { $_.RemoteAddress -match '(?:25[6-9]|2[6-9]\d|[3-9]\d{2}|[1-9]\d{3,})' }

If you find a rule with a bad IP range, delete it with Remove-NetFirewallRule. If you’re not comfortable deleting, you can disable it first:

Disable-NetFirewallRule -Name "BadRuleName"

Then test whether the error goes away. If it does, you’ve found your culprit.

If you want to be thorough, dump every rule’s address filter to a CSV and check manually:

Get-NetFirewallRule | Get-NetFirewallAddressFilter | Export-Csv C:\firewall_addresses.csv -NoTypeInformation
# Open in Excel or Notepad++ and sort by RemoteAddress.

Cause 3: A Corrupted or Partial Rule Entry from a Third-Party App

Some VPN clients (looking at you, old versions of Cisco AnyConnect and certain OpenVPN builds) or game launchers create firewall rules with placeholder values — often 0.0.0.0-0.0.0.0 or 1-1 as a port range — that don’t actually validate. The WFP engine sees these as syntactically valid but semantically empty or malformed, and the driver-level rule registration fails with 0x80320020.

Also, I’ve seen this happen after a Windows update (KB5034441 specifically, on some Windows 10 22H2 builds) where the firewall service gets into a weird state and can’t parse existing rules correctly — even though they were fine before.

The Fix

First, try resetting the Windows Firewall service without losing all your rules:

net stop MpsSvc
net stop BFE
net start BFE
net start MpsSvc

If the error persists, you need to find and remove the corrupted rule. The safest way is to export all rules before modifying anything:

netsh advfirewall export "C:\firewall_backup.wfw"

Now, enable logging to see which rule fails on load:

netsh advfirewall set currentprofile logging filename C:\fwlog.log
netsh advfirewall set currentprofile logging droppedconnections enable
# Reboot, then check fwlog.log for any rule names mentioned in failed lines.

If you can’t find the rule by logging, a nuclear option is to delete all rules added by the offending app. For example, if you suspect it’s a VPN client:

Get-NetFirewallRule -PolicyStore ActiveStore | Where-Object { $_.DisplayGroup -match "VPN" -or $_.Description -match "VPN" } | Remove-NetFirewallRule

Then reinstall the app fresh — it will recreate its rules correctly.

Quick-Reference Summary