ERROR_IPSEC_IKE_POLICY_MATCH (0x362C): Fix IPsec Policy Mismatch

So you're staring at ERROR_IPSEC_IKE_POLICY_MATCH (0x362C) in Event Viewer or the output of a VPN client, and the connection just won't come up. What's actually happening here is that the two IPsec peers completed their initial handshake but couldn't agree on the rules for protecting the traffic. One side proposed an encryption algorithm, a hash, or an authentication method the other side doesn't accept, so the IKE negotiation failed and Windows threw 0x362C.

The tricky part is that this error covers a lot of ground. It shows up during main mode, during quick mode, or when one side's filter list doesn't line up with the other's. Below are the three causes I see most often, in the order I check them.

1. Mismatched encryption, integrity, or DH group in the main mode policy

This is the number one reason you'll see 0x362C. Windows IPsec main mode has a list of proposals — encryption (AES-128, AES-256, 3DES), integrity (SHA-1, SHA-256), and Diffie-Hellman group (Group 2, Group 14, Group 24). If the initiator offers something the responder doesn't have in its list, the responder sends back a NO_PROPOSAL_CHOSEN notify and Windows logs the policy match error.

A real trigger I've run into more than once: someone hardens a Server 2019 box with a GPO that only allows AES-256 and SHA-256 with DH Group 14, then tries to connect to an older Cisco ASA still configured for 3DES, SHA-1, and DH Group 2. Main mode fails immediately and 0x362C lands in the Security log with Event ID 4653 or 5451 depending on the stage.

Check the current policy on each side. On Windows:

netsh ipsec dynamic show mm policy
netsh ipsec dynamic show qm policy

On the other end, whatever the platform is, dump the equivalent. Then line them up. You want at least one common combination in the proposal list. The real fix is to add the missing proposal rather than downgrade the whole policy — but if you're stuck on legacy hardware, you might have to meet it where it is temporarily.

Also check the order of proposals. Windows picks the first match, so if you've got a hardened proposal listed after a weak one, you're still negotiating weak. Reorder so the strongest acceptable algorithm is first.

2. Quick mode selector mismatch (traffic selectors don't overlap)

Main mode succeeds, then quick mode blows up with 0x362C. What's actually happening here is that phase 2 selectors — the source and destination subnets that define what traffic gets protected — don't overlap between the two peers.

Concrete example: your Windows server has a quick mode filter for 10.0.1.0/24 to 10.0.2.0/24. The remote firewall has 10.0.1.0/24 to 10.0.2.0/24 too, but it's also expecting 0.0.0.0/0 as a fallback. If your server only sends the narrow filter and the remote is only willing to accept the broad one, quick mode can't find a common selector and you get the same policy match error.

Dump the filters on the Windows side:

netsh ipsec static show filterlist all level=verbose

And on the remote side, however it's configured. What you're looking for is exact parity, or at least a subset relationship where one side's selector is contained in the other's. Asymmetric selectors are a common cause when someone changes a subnet on one end and forgets the other.

The fix is to make the filter lists match. If you're doing this via Group Policy, that's under Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Connection Security Rules. Edit the rule, check the Endpoints section, and align them with what the peer expects.

3. Authentication method mismatch (cert vs. pre-shared key)

Third most common, and the most annoying to diagnose because the error surfaces the same way. One peer is configured to authenticate with a certificate, the other is using a pre-shared key. Or both use certs but from different CAs, or the peer's cert doesn't have the right EKU (Client Authentication or Server Authentication depending on role). Or the PSK is simply wrong — a trailing space or a case difference after a copy-paste.

I've seen this bite people after a certificate renewal. The new cert gets a different subject or SAN, IPsec still has the old thumbprint pinned, negotiation fails, and 0x362C shows up in the log with no other obvious clue. The Security event log entry for the failed negotiation will usually indicate the failure stage — main mode with authentication failure is a strong signal here.

Check the authentication method on the Windows side:

netsh ipsec static show policy all
netsh ipsec static show rule name="Your Rule Name"

The output will show AuthMethod — either preshared key, Kerberos, Certificate, or a combination. Verify it matches the peer. If you're using certificates, confirm the cert is in Local Computer > Personal store, has a private key, isn't expired, and chains to a CA the peer trusts. Wrong-CA certs are the classic silent killer here — the cert looks fine in certlm.msc but the peer rejects it during IKE auth.

One more thing to watch: if you've got multiple connection security rules with different auth methods, Windows may pick one you didn't expect. Explicit rule ordering or a more specific filter helps pin down which rule applies.

Quick reference

Pro tip: turn on IPsec auditing before you start guessing. auditpol /set /subcategory:"IPsec Main Mode" /success:enable /failure:enable (and repeat for IPsec Quick Mode and IPsec Extended Mode). The Security log then tells you exactly which phase failed, which cuts the diagnostic time in half.

If you've checked all three of these and you're still getting 0x362C, look at the timestamps. A peer with a clock more than five minutes off will fail Kerberos-based auth in a way that looks like a policy mismatch. Time skew trips up more IPsec deployments than people admit.