STATUS_FWP_INCOMPATIBLE_CIPHER_CONFIG (0xC0220039) Fix

When This Error Hits

You're setting up an IPsec connection — maybe a site-to-site VPN or a direct tunnel between two Windows servers — and boom, the firewall spits out STATUS_FWP_INCOMPATIBLE_CIPHER_CONFIG (0xC0220039). The exact error message reads: "The IPsec cipher configuration is not compatible with the cipher type."

I've seen this most often right after a Windows security update (KB5025221 and its friends) or when someone imports a VPN policy from an older Windows 10 build into Windows 11. It's also common in mixed environments where one side still uses DES or 3DES and the other requires AES. The trigger is almost always a mismatch between what the rule demands and what the firewall can actually negotiate.

What's Actually Going Wrong

Let's cut through the jargon. The IPsec cipher configuration has two parts: an encryption algorithm (like AES-128 or 3DES) and an integrity algorithm (like SHA-1 or SHA-256). Windows Firewall with Advanced Security expects them to match a predefined cipher type. If you set a cipher type like ESP_AUTH (which only wants integrity, no encryption) but your rule also defines an encryption algorithm, you get this error. Or vice versa — you pick ESP_AUTH_AND_CIPHER but only specify integrity.

Another common root cause: the old Suite B or RFC 4309 cipher suites that Windows dropped support for in recent updates. The firewall literally can't translate what you're asking for into a valid cipher set.

The Fix — Step by Step

Step 1: Identify the Rule

Open Windows Firewall with Advanced Security (wf.msc). Go to Connection Security Rules. Find the rule that's failing. Right-click it and pick Properties. Under the IPsec Tunneling or Authentication tab, look for the cipher settings.

If you can't find the rule in the GUI, run this in PowerShell as admin:

Get-NetIPsecQuickModeCipherSet | Where-Object {$_.Name -like '*failing*'}

Replace *failing* with part of the rule name.

Step 2: Check the Cipher Type

In the rule properties, look for Encryption and Integrity dropdowns. If the rule uses Custom, click Customize. You'll see a window with two tabs: Data protection and Key exchange. Under Data protection, check the cipher suite entries.

The cipher type is determined by what you select:

• ESP (Encapsulating Security Payload) — expects both encryption and integrity
• AH (Authentication Header) — expects only integrity, no encryption
• Combined mode (like AES-GCM) — uses a single algorithm for both

If you pick AH but also specify an encryption algorithm, you'll get error 0xC0220039. Easy fix: remove the encryption algorithm, or switch to ESP.

Step 3: Fix via PowerShell (The Real Fix)

I prefer PowerShell here because the GUI sometimes doesn't show the full cipher set details. Run this to list all cipher sets:

Get-NetIPsecQuickModeCipherSet | Format-List Name, CipherType

Look for the offending set. If the CipherType is ESP_AUTH but the set includes an encryption algorithm, that's your problem. Or if it's ESP_AUTH_AND_CIPHER but only has integrity, same issue.

To fix a specific set, you can recreate it with the correct type. For example, to create an ESP set with AES-128 and SHA-256:

New-NetIPsecQuickModeCipherSet -Name "MyFixedCipherSet" -CipherType ESP_AUTH_AND_CIPHER -EncryptionAlgorithm AES128 -IntegrityAlgorithm SHA256

Then update your rule to use this new set:

Set-NetIPsecQuickModeCipherSet -Name "OldFailingSet" -AssociatedNetIPsecRule "YourRuleName"

Or just reassign the rule:

Set-NetIPsecRule -Name "YourRuleName" -QuickModeCipherSet "MyFixedCipherSet"

Step 4: Remove Obsolete Cipher Suites

If you imported old rules that reference SuiteB or RFC4309 cipher sets, delete them and create fresh ones. These legacy sets were removed in Windows 10 20H2 and later. Run:

Remove-NetIPsecQuickModeCipherSet -Name "ObsoleteSuiteBSet"

Then rebuild with supported algorithms: AES-128/256, SHA-256/384, DH group 14 or higher.

Still Failing? Check These

• Group Policy — If your IPsec rules are pushed via GPO, the same mismatch can exist in the GPO itself. Check the GPO under Computer Configuration > Windows Settings > Security Settings > Advanced Security Windows Firewall > Connection Security Rules. Fix the cipher sets there.
• Third-party VPN clients — Some VPNs (like Cisco AnyConnect or FortiClient) install their own IPsec policies. They might override Windows Firewall's cipher settings. Disable the VPN client's firewall module temporarily to test.
• Check the Windows Event Log — Open Event Viewer, go to Applications and Services Logs > Microsoft > Windows > Windows Firewall with Advanced Security. Look for event ID 5378 or 5379 around the time the error occurred. The details usually name the failing cipher set.
• Update Windows — If you're still on Windows 10 1809 or earlier, cipher support is different. Upgrade to at least 21H2.

Honestly, 9 times out of 10, this error is just a cipher type mismatch that's easy to fix once you know where to look. Start with the PowerShell check and save yourself the GUI headache.