Fix ERROR_IPSEC_IKE_NO_MM_POLICY 0X0000361A Windows

You click Connect on your VPN, the little spinner spins, and then Windows throws Error 0X0000361A: ERROR_IPSEC_IKE_NO_MM_POLICY. Nobody changed anything on your laptop. The server admin swears nothing changed on their side either. And yet here you are, staring at a red X.

This one usually shows up right after a Windows Update, a group policy refresh, or a firewall vendor pushed a new profile to your endpoint. I've seen it most on Windows 10 22H2 and Windows 11 23H2 machines joined to a domain where the IPsec policy got scoped to the wrong OU. You also hit it on standalone clients where someone ran netsh advfirewall reset and wiped the custom IPsec rules the VPN relied on.

What's actually happening

IPsec negotiates in two phases. Phase 1 is main mode. Phase 2 is quick mode. Before either machine exchanges a single encrypted packet, they have to agree on how to protect the main mode negotiation itself: which encryption algorithm, which hash, which authentication method, which Diffie-Hellman group, and how long the security association lives.

That agreement is called a main mode policy — sometimes a main mode filter plus a main mode rule, depending on which Microsoft tooling you're looking at. When the initiator sends its first IKE proposal (the SA payload) and the responder looks at it and says I have no policy that matches any of these proposals, it drops the packet and logs 0X0000361A. No policy, no phase 1, no VPN.

Common mismatches I've chased down over the years:

Client is offering AES-256/SHA-256/DH Group 14, server only accepts AES-128/SHA-1/DH Group 2
Client has certificate auth enabled, server is configured for pre-shared key only
Someone deleted the Connection Security Rule in Windows Defender Firewall with Advanced Security
Group Policy assigned an IPsec policy but the client's domain profile never applied it

Fix it — the steps that actually work

Confirm it's a policy mismatch, not a network block. Open Event Viewer and look under Applications and Services Logs → Microsoft → Windows → Security → Windows Firewall With Advanced Security. You want events with ID 4653 or the IKE-specific logs. If you see the error paired with a dropped SA, keep going. If you see nothing at all, the IKE packets aren't reaching the machine — check UDP 500 and UDP 4500 aren't blocked upstream.
Dump the current IPsec policy so you know what you're working with. Open an elevated Command Prompt and run:
```
netsh advfirewall monitor show mmsa
netsh advfirewall consec show rule name=all
netsh ipsec static show policy all
```
The first command shows active main mode SAs (usually empty when this error fires). The second shows your connection security rules. The third shows the legacy IPsec policy store — which is where the problem usually hides on older domain setups.
Find the mismatched proposals. Compare the client's offered algorithms against what the server expects. On the client, the fastest check is the Firewall MMC. Press Win+R, type wf.msc, hit Enter. Go to Connection Security Rules, right-click your VPN rule, choose Properties, then the Advanced tab, then Customize under Integrity and Encryption. Write down the exact algorithms and DH group.

Ask the server admin for their IKE crypto profile. FortiGate, Palo Alto, Cisco ASA, and Windows RRAS all expose this. If the client offers DH Group 14 and the server's profile is DH Group 2, that alone reproduces this error.
Recreate the matching rule on the client. If the server is the authority (it usually is), don't argue — match it. In the Firewall MMC:
- Right-click Connection Security Rules, pick New Rule
- Choose Custom
- Endpoints: both IPs
- Requirements: Request encryption (or Require if the server insists)
- Authentication: pick the same method the server uses — certificate, Kerberos, or pre-shared key
- Advanced: set the exact same integrity and encryption algorithms, and the same DH group
- Name it something you'll recognize in six months, like VPN-MainMode-Match-Server
If the old rule was corrupted (which happens after a botched GPO merge), delete it first. A rule with a null or blank algorithm list is a classic cause of 0X0000361A.
Force a policy refresh. If this machine gets its IPsec policy from Group Policy, don't fight it — sync it:
```
gpupdate /force
netsh advfirewall consec show rule name=all
```
Reboot if the show output still doesn't match what you configured. IPsec policy changes don't always apply to live SAs without a restart of the IKEEXT service:
```
net stop IKEEXT
net start IKEEXT
```
Test the negotiation. Open the Firewall MMC log settings (right-click Windows Defender Firewall with Advanced Security → Properties → Logging → Customize) and turn on logging for dropped packets. Try the VPN again. If IKE is now completing main mode, you'll see the SA establish and the error stops. If you're still seeing it, the log will tell you exactly which proposal the responder rejected.

If it still fails

At this point nine times out of ten you've got a server-side problem, not a client one. Things to check:

Does the server's IKE profile actually include the DH group the client is offering? Some appliances default to Group 2 only and never got updated. That's a server fix, not a client one.
Is there a NAT device between you and the server changing the source port? IKE over NAT needs NAT-T (UDP 4500). If the appliance's NAT-T setting is off, main mode will fail and you'll get this error even though the proposals line up.
Check the responder's logs. On Windows RRAS: Event Viewer → Applications and Services Logs → Microsoft → Windows → IKEEXT. On FortiGate: diagnose debug application ike -1 followed by diagnose debug enable. The responder will tell you which proposal it rejected and why.
Certificate trust. If you're using cert auth and the server's CA chain isn't trusted on the client, you'll get this error too — main mode has no policy that works because the auth method can't validate. Confirm the root CA is in certlm.msc → Trusted Root Certification Authorities.

The frustrating part of 0X0000361A is that Windows blames the client when the real answer usually lives on the other end. Match the policies, verify the auth method, and this error stops firing.