Fix FWP_E_OUT_OF_BOUNDS (0x80320028) Windows Firewall Error

Quick answer: FWP_E_OUT_OF_BOUNDS (0x80320028) means a Windows Filtering Platform call got an integer outside the legal range — almost always a firewall rule with a bad port range, bad interface index, or a value that got corrupted by Group Policy. Kill the bad rule (or reset the policy) and it goes away.

I hit this on a client's domain-joined laptop last month. They couldn't receive RDP at all, and every time I ran a netsh advfirewall firewall add rule or the Defender Firewall MMC, Windows threw 0x80320028 and refused to apply anything. The real cause wasn't the new rule I was adding — it was an old rule already sitting in the store with a port range of 0-0 (yes, a vendor's installer wrote that). WFP validates every rule when you touch the store, so one bad apple blocks everything. That's the pattern: a stale or malformed rule, and suddenly the whole firewall API is angry.

What actually triggers 0x80320028

WFP is the kernel-side filtering engine under Windows Defender Firewall. Every rule stores numeric fields: port ranges (min and max), protocol numbers, interface LUIDs, security descriptor sizes, weight, ICMP types. When any of those falls outside the legal range defined in the Windows Filtering Platform API — for example, a port max of 70000, a negative interface index, or an ICMP type code above 255 — the call fails with FWP_E_OUT_OF_BOUNDS.

Common culprits I keep seeing:

• Third-party installers (VPNs, game anti-cheat, older backup agents) writing rules with empty port ranges.
• Group Policy objects pushed from an old server with rules built on a different OS build.
• Restored system images where the firewall policy store is out of sync with the Registry.
• PowerShell scripts that pass -LocalPort an array that includes 0 or a string.

Step-by-step fix

1. Open an elevated command prompt

Right-click Start → Terminal (Admin) or Command Prompt (Admin). Nothing here works without elevation.

2. Dump every firewall rule to a file

You need to see the bad one before you delete it. Export the full policy:

netsh advfirewall export "%USERPROFILE%\Desktop\fw-backup.wfw"

That gives you a rollback point. Do not skip this.

3. Find the offending rule

List rules and look for anything weird — empty port ranges, protocol 0, a LocalPort of 0:

netsh advfirewall firewall show rule name=all verbose > "%USERPROFILE%\Desktop\rules.txt"

Open rules.txt and search for LocalPort: 0 or a protocol you didn't add. Nine times out of ten the bad rule is the newest one or one from a recently installed app.

If you're on PowerShell and prefer structured output:

Get-NetFirewallRule | Where-Object { $_.Enabled -eq 'True' } |
  Get-NetFirewallPortFilter |
  Where-Object { $_.LocalPort -eq '0' -or $_.RemotePort -eq '0' }

4. Delete the bad rule

Once you've got the name or display name, nuke it:

netsh advfirewall firewall delete rule name="Rule Name Here"

Or PowerShell:

Remove-NetFirewallRule -DisplayName "Rule Name Here"

5. Test that the store accepts writes again

Add a harmless test rule and immediately delete it:

netsh advfirewall firewall add rule name="test" dir=in action=allow protocol=TCP localport=12345
netsh advfirewall firewall delete rule name="test"

If that completes without 0x80320028, you're done. If it still errors, the corruption is deeper — move to the alternative fixes below.

Alternative fixes

Reset the firewall to defaults

This throws away every custom rule, so only do it after you've exported. On a workstation that's usually fine; on a server, check with whoever relies on those rules first.

netsh advfirewall reset

Rebuild the WFP store

When the store itself is corrupt, the reset won't clear it. Stop the BFE service, then restart it:

net stop BFE
net start BFE

Then re-run netsh advfirewall reset.

Check Group Policy

If the machine is domain-joined, GPO can re-inject the bad rule the moment you delete it. On the client:

gpresult /h "%USERPROFILE%\Desktop\gpo.html"

Look for Windows Firewall with Advanced Security policies. If a GPO is pushing a rule with a bad port range, fix it on the server. Rebooting the client won't help until you do.

Repair the OS firewall components

As a last resort on Windows 10/11:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

If those find nothing, run a Windows Update — the March 2023 cumulative updates fixed a WFP store validation bug that produced this exact error on machines with specific VPN clients installed.

Prevention

Before you install anything that touches networking — VPN clients, backup agents, remote management tools — export your firewall policy. It takes five seconds and saves you an hour of hunting for the bad rule later. And when you write your own rules via script, validate your port ranges: anything above 65535 or below 1 will bite you with 0x80320028 eventually. The valid TCP/UDP port range is 0–65535, but for a real rule use 1–65535 or a specific range like 8000-8010. Never pass an empty string or 0 as a port parameter.