Fix ERROR_IPSEC_IKE_MM_EXPIRED 0X0000363D in 3 Steps

What's Actually Happening Here

The error 0x0000363D — ERROR_IPSEC_IKE_MM_EXPIRED — fires when Windows thinks the main mode security association (SA) has timed out or the remote VPN server sent a delete notification. This usually happens during rekeying or when the lifetime settings on both ends don't match. You'll see it most often when connecting to a Cisco ASA, FortiGate, or a Windows RRAS server and the connection drops after a few hours or days. The ugly part: once this error appears, new connections may fail until you clear the old SA state.

The fix depends on whether it's a one-time glitch or a persistent mismatch. I've ordered the fixes from least to most invasive. Stop when the problem's gone.

Step 1: Restart the IPsec Services (30 Seconds)

Don't overthink this. Half the time, the SA got stuck in a half-deleted state and just needs a kick. Open an admin PowerShell or CMD and run:

net stop IKEEXT & net stop PolicyAgent & net start PolicyAgent & net start IKEEXT

What that does: IKEEXT is the IKE and AuthIP IPsec Keying Modules service—it handles main mode negotiations. PolicyAgent is the IPsec Policy Agent that enforces rules. Restarting both flushes any orphaned SAs. Then try your VPN connection again.

If the error disappears, you're done. If not, the mismatch lives on the remote peer or in persistent configuration.

Step 2: Delete Stale Main Mode SAs (5 Minutes)

When a restart doesn't cut it, Windows holds onto expired SAs longer than it should. Use netsh to nuke them manually.

First, list all active main mode SAs:

netsh advfirewall monitor show mmsa

Find the one matching your VPN's destination IP (look under Peer IP Address). Note the Local and Peer IPs and the MM SA ID. Then delete it:

netsh advfirewall monitor delete mmsa LocalIp=192.168.1.10 PeerIp=203.0.113.5

Replace the IPs with yours. If you have multiple SAs to the same peer, add MMSAId=X to target one specifically.

After deletion, Windows will renegotiate a fresh main mode SA on the next connection attempt. This works 90% of the time when the previous fix didn't.

Step 3: Align Main Mode Lifetime Settings (15+ Minutes)

If steps 1 and 2 only give you temporary relief, the root cause is a mismatch in main mode lifetime between your client and the VPN server. Windows defaults to 480 minutes (8 hours) for IKEv2. Many Cisco and Fortinet devices default to 1440 minutes (24 hours). When the server thinks the SA is still valid but the client rekeys early—or vice versa—you get this error.

You have two options here. Option A is to change the client-side lifetime to match the server. Option B is to increase it beyond the server's lifetime so the server always initiates the delete.

I recommend Option A because it's cleaner. Here's how:

1. Open Local Security Policy (secpol.msc).
2. Navigate to Security Settings → Advanced Audit Policy Configuration → System Audit Policies – Local Group Policy Object → Object Access — wait, that's not right. Actually, for IPsec settings, go to Connection Security Rules on the left pane, then right-click the rule your VPN connection uses and choose Properties.
3. Click the Authentication Methods tab, then select the line showing IKE (Main Mode) and click Edit.
4. Click the Advanced button, then Configure under Key Exchange (Main Mode) settings.
5. Set Lifetime (minutes) to match the VPN server. Common values: 1440 (24 hours), 480 (8 hours), or 360 (6 hours). If you don't know the server's value, set it to 1440 and test.

On a Windows RRAS server, you'd change this in Routing and Remote Access → right-click the server → Properties → Security tab → Authentication → IKEv2 settings. But for client machines, the secpol method above works.

Another angle: if you see this error in the event log alongside 0x0000007A (IKE negotiation failure), the server might be rejecting your quick mode settings—not main mode. In that case, check the Data Protection (Quick Mode) settings in the same rule properties and reduce the lifetime to something shorter, like 600 seconds (10 minutes). Quick mode expiration is separate from main mode but often misdiagnosed.

When None of These Work

If the error persists, the real problem is likely certificate validation or mismatched IKE versions. The server may require IKEv2 while the client negotiates IKEv1. You can force IKEv2 in Windows by setting this registry key:

reg add HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters /v NegotiateDH2048_AES256 /t REG_DWORD /d 1 /f

That forces stronger DH groups and AES-256, which some strict servers demand. Reboot after adding it.

Also check the server logs. The error 0x0000363D is a client-side translation—the server will have a different error code that tells you exactly why it deleted the SA. If you can't access server logs, you're flying blind.

A final sanity check: make sure both sides have synchronized time. Kerberos-based authentication (common in Windows-to-Windows IPsec) fails silently if the clock skew exceeds 5 minutes. Use w32tm /query /status to verify.