Fix 0x80320009: FWP_E_ALREADY_EXISTS Windows Firewall Error

I know this error is infuriating. You're trying to add a firewall rule, push a GPO, or run an installer, and Windows throws 0x80320009 at you with zero useful context. The full string usually looks like "An object with that GUID or LUID already exists" or "FWP_E_ALREADY_EXISTS". That's actually a gift — it tells you exactly what's wrong. Windows Filtering Platform is refusing to create a rule because something with that identifier is already sitting in the policy store.

The most common real-world trigger: you're re-running a deployment script or installer that creates firewall rules by a hardcoded GUID. First run succeeded. Second run fails because the rule's already there. I've also seen it happen when two admins push overlapping firewall GPOs at the same time, or when a third-party VPN client (looking at you, older Cisco AnyConnect builds) re-registers its filter and collides with a leftover entry.

Work through these in order. Stop as soon as your rule works.

Step 1: The 30-Second Fix — Retry With Idempotency Check

Before you touch anything, ask yourself: does the rule already exist? If yes, you might just need to modify it instead of creating it. In PowerShell, check first:

Get-NetFirewallRule -DisplayName "Your Rule Name" | Select-Object Name, DisplayName, Enabled, Direction

If that returns a rule, don't create a new one. Update it:

Set-NetFirewallRule -DisplayName "Your Rule Name" -Enabled True

If you're running a script that creates rules, wrap the create call in a check. The lazy-but-effective pattern:

$rule = Get-NetFirewallRule -DisplayName "My App" -ErrorAction SilentlyContinue
if (-not $rule) {
    New-NetFirewallRule -DisplayName "My App" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8443
}

If the rule exists and you still need to blow it away, jump to Step 2.

Step 2: The 5-Minute Fix — Delete the Orphaned Rule

Most 0x80320009 cases are orphaned rules that live in the policy store but don't show up in the standard firewall GUI. That's the trap. wf.msc hides rules owned by the Windows Filtering Platform provider, and those are exactly the ones causing your collision.

Run an elevated PowerShell and go hunting. First, if you know the GUID from the error message, target it directly:

Get-NetFirewallRule | Where-Object { $_.Name -eq "{YOUR-GUID-HERE}" }

Or widen the net by display name:

Get-NetFirewallRule -DisplayName "*Partial Name*" | Format-Table Name, DisplayName, PolicyStoreSourceType

Once you've found it, remove it:

Remove-NetFirewallRule -Name "{YOUR-GUID-HERE}"

If PowerShell refuses because the rule is managed by Group Policy (you'll see PolicyStoreSourceType: GroupPolicy), you can't delete it locally. That's a real thing and it trips up almost everyone the first time. You'll need to remove the GPO association, run gpupdate /force, and then retry — or exclude that rule from the GPO.

When PowerShell and the GUI both come up empty but you know damn well something's still there, check the raw policy store:

netsh wfp show state

That dumps a wfpstate.xml file to your current directory. Open it in a browser or your editor and search for your GUID. If it's in there under a filter that no rule claims ownership of, you've got a corrupted or half-removed entry. Move to Step 3.

Step 3: The 15-Minute Fix — Reset the Offending Provider

When the entry is genuinely stuck — no owning rule, no GPO, and netsh wfp show state still lists it — you've got a stale filter from an uninstalled or half-installed provider. Antivirus agents and VPN clients are the usual suspects. McAfee Endpoint Security, older Symantec builds, and Fortinet FortiClient all leave these behind after a botched uninstall.

Find the provider that owns the stuck GUID. In the same wfpstate.xml, search for your GUID and note the providerKey attribute on the surrounding filter. Then list providers:

netsh wfp show options

You can also enumerate per-provider filters through PowerShell:

Get-NetFirewallRule | Group-Object -Property Owner | Sort-Object Count -Descending

Once you've identified the provider, the cleanest fix is to reinstall that software so it re-registers cleanly, then uninstall it properly. If that's not practical, disable the base filtering engine for a moment to force a rebuild:

net stop bfe
net start bfe

Be careful here. Stopping BFE kills all firewall enforcement until it restarts. Do this on a workstation, not a production server, and not over a remote session you can't recover from. If BFE refuses to stop because dependent services are running (Windows Defender Firewall is one), stop those first with sc queryex to find dependents.

If the stuck filter belongs to a legitimately bad provider and you can't uninstall it, the nuclear option on a workstation is to reset the whole firewall policy:

netsh advfirewall reset

That wipes every rule — local, group policy, and provider-registered — and rebuilds the default policy. It works. It's also disruptive. Save it for machines you can afford to re-baseline.

Quick Reference Table

The Pattern Behind the Error

FWP_E_ALREADY_EXISTS isn't a bug. It's Windows telling you that firewall rules are keyed by GUID and LUID, and creating a second object with the same key violates the policy store's uniqueness constraint. Every fix above is fundamentally about removing or reusing the existing object. Once you internalize that, the error stops being scary and becomes a diagnostics clue — it literally points at the rule you need to look at.

Pro tip I wish someone had told me years ago: when a vendor's installer keeps failing on 0x80320009 across a fleet, don't fix each machine. Patch the installer's rule-creation logic to check Get-NetFirewallRule first. Saves you a weekend.