0XC022002A fix: duplicate condition in Windows firewall filter

Yeah, I've been there. You're scripting a firewall rule or tweaking one in the GUI, and bam — error 0XC022002A with that useless message. No hint where the duplicate is. Let's fix it.

What's actually happening here is...

The Windows Filtering Platform (WFP) — the engine behind Windows Firewall — won't let you create a filter that has more than one condition targeting the same field. A field is something like LocalPort or RemoteIP. If your rule says LocalPort equals 443 and also LocalPort equals 8443, WFP chokes. It expects you to use a single condition with a list, or split into two separate rules.

The fix (2 minutes)

Find the offending rule and either merge the values into one condition, or delete the duplicate. Here's how for the most common scenarios:

If you're using netsh

You probably wrote something like:

netsh advfirewall firewall add rule name="MyRule" dir=in localport=443,8443 protocol=tcp action=allow

That's fine — localport is one field with a comma-separated list. The error happens when you use localport twice:

netsh advfirewall firewall add rule name="MyRule" dir=in localport=443 localport=8443 protocol=tcp action=allow

The fix: replace the two localport statements with one that has both ports separated by a comma:

netsh advfirewall firewall add rule name="MyRule" dir=in localport=443,8443 protocol=tcp action=allow

If you're using PowerShell

Classic mistake — you pass an array to a parameter that expects a single value, but you accidentally call the parameter twice:

New-NetFirewallRule -DisplayName "MyRule" -Direction Inbound -LocalPort 443 -LocalPort 8443 -Protocol TCP -Action Allow

PowerShell doesn't warn you until you add the rule to the WFP store. The fix: pass all ports as a single array:

New-NetFirewallRule -DisplayName "MyRule" -Direction Inbound -LocalPort @(443, 8443) -Protocol TCP -Action Allow

Or use the -LocalPort once with comma-separated string: -LocalPort "443,8443" — both work.

If you're using the GUI (wf.msc)

You can't duplicate a field in the GUI because the drop-down only lets you pick each field once. But you can get this error when you import an XML rule via Group Policy or export/import with netsh advfirewall export. The XML might have two <condition> blocks for the same field. Edit the exported .wfw file in Notepad, find the duplicate condition, delete it, and re-import.

Why step 3 works

WFP's filter engine is designed for performance. It pre-computes a lookup table based on field types. If two conditions on the same field exist, the engine can't decide which one to use — does it match both? Either? The designers decided: one field, one condition. You can still match multiple values by using an array or list within that single condition. Under the hood, WFP treats localport=443,8443 as a single condition with a multi-value token.

Less common variations of the same issue

Duplicate remote IP conditions. Same error, same fix. RemoteIP=192.168.1.0/24 and RemoteIP=10.0.0.0/8 must become RemoteIP=192.168.1.0/24,10.0.0.0/8.
Duplicate application path conditions. You can't have two ApplicationName conditions in one filter. Either merge paths into one condition using OR logic (not supported in GUI — you'll need a script) or create two separate rules.
Duplicate interface alias conditions. Rare, but happens when you copy-paste a rule in a script and forget to remove the old -InterfaceAlias line.

Prevention

Before writing firewall rules, check your script for multiple uses of the same parameter. In PowerShell, use splatting with a hashtable to ensure each parameter appears exactly once:

$ruleParams = @{
  DisplayName = "MyRule"
  Direction = "Inbound"
  LocalPort = "443,8443"  # one line
  Protocol = "TCP"
  Action = "Allow"
}
New-NetFirewallRule @ruleParams

For netsh, read your command carefully before hitting Enter. I'd recommend PowerShell over netsh for anything beyond basic rules — cleaner syntax, better error messages, and you can test with -WhatIf.