Fix ERROR_IPSEC_IKE_UNEXPECTED_MESSAGE_ID (0X00003640)

You're working from home, trying to connect to the office VPN. The connection starts, you see "Verifying your sign-in info," and then bang — error 0x00003640. "Received unexpected message ID." The VPN client says it connected, but the tunnel drops before you get an IP address. This happens most often with Windows built-in VPN (IKEv2) against a Windows RRAS server or a third-party VPN gateway. I've seen it a ton with SonicWall and Fortinet boxes too.

What's happening behind the scenes

The IKE (Internet Key Exchange) protocol uses message IDs to keep track of which packet is which during negotiation. Both sides agree on a sequence. When one side gets a message ID it didn't expect — say, it gets ID #4 when it was waiting for #2 — the whole negotiation blows up. This mismatch happens for three main reasons:

• Stale security associations (SAs): Old partial connections from a previous failed attempt are still lingering in the IKE cache. The new connection picks up a stale ID.
• Certificate or preshared key mismatch: The VPN server and client don't agree on authentication material. The handshake starts, then fails halfway, leaving orphaned SAs.
• NAT traversal or firewall issues: A router or firewall is rewriting packets, scrambling the ID sequence. This is rare but happens with double NAT.

In my experience, 80% of the time it's stale SAs. You connect, it fails, you try again, and each retry adds more garbage to the cache. Eventually the server says "I've never seen that ID before" and kills the connection.

Fix 1: Clear the IKE security association cache

This is your first and most likely fix. It wipes out all those dead connections.

1. Press Windows Key + R, type cmd, then press Ctrl + Shift + Enter to run Command Prompt as Administrator. You'll see a User Account Control prompt — click Yes.
2. In the command prompt, type this and press Enter:
   

   net stop IKEEXT && net start IKEEXT

   You'll see "The IKE and AuthIP IPsec Keying Modules service is stopping" followed by "The service is starting." Wait about 5 seconds. The service must fully restart.
3. Now type this and press Enter:
   

   netsh advfirewall reset

   You'll see "Ok." This resets the Windows Firewall rules that govern IPsec policies. It doesn't remove your custom inbound/outbound rules — just the IPsec-related ones.
4. Reboot your computer. You don't have to, but I've seen cases where the reset doesn't fully take without a restart. After reboot, try your VPN connection again.

If the error is gone, you're done. If not, move to the next step.

Fix 2: Remove old VPN connection and recreate it

Sometimes the VPN profile itself is corrupted. The IKE parameters stored in the profile don't match what the server expects.

1. Open Settings (Windows Key + I).
2. Go to Network & Internet > VPN.
3. Click on the VPN connection that's failing. You'll see a Remove button — click it.
4. Confirm the removal. Wait 10 seconds.
5. Click Add a VPN connection and re-enter the server address, VPN type (IKEv2), and your login info. Do not check "Remember my sign-in info" — that sometimes carries over the old corrupted settings. Type everything fresh.
6. Try connecting. If it works, great. If not, the problem is likely on the server side.

Fix 3: Check certificate and preshared key on server

This is for admins who control the VPN server. If you're a user, skip this and ask your IT team to check.

1. Log into your VPN server (Windows Server 2019/2022 RRAS, or your firewall's web interface).
2. For Windows RRAS: Open Routing and Remote Access MMC. Right-click the server, choose Properties, go to the Security tab. Check the Authentication provider — it should match what the client uses. If you're using certificates, make sure the server certificate hasn't expired. Run certlm.msc on the server and check the personal certificate store.
3. For third-party firewalls (SonicWall, Fortinet, pfSense): Go to the IKE configuration for the phase 1 settings. Verify that the IKE version is set to IKEv2 (not auto-negotiate). Also check the Dead Peer Detection interval — if it's too short (less than 10 seconds), it can cause message ID conflicts.
4. If you use a preshared key, ensure it's identical on client and server. A single typo causes this error.

Fix 4: Disable IPv6 on the VPN adapter

IPv6 sometimes interferes with IKE negotiation. It's a long shot, but I've seen it work.

1. Open Control Panel > Network and Sharing Center > Change adapter settings.
2. Find your VPN adapter (it's usually named after your VPN connection). Right-click it, select Properties.
3. Uncheck Internet Protocol Version 6 (TCP/IPv6). Click OK.
4. Try connecting again. If it works, leave IPv6 off for that adapter.

What to check if it still fails

If you've done all four fixes and the error keeps coming back, the issue is almost certainly on the server side. Here's what to look for:

• Server logs: On Windows RRAS, open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > RasRoutingProtocols/Operational. Look for Event ID 20225 or 20226 — those describe the exact IKE message ID that failed.
• NAT device: If you're behind carrier-grade NAT (common with cellular hotspots), the VPN server might see your IP address changing mid-negotiation. Try connecting from a different network — a wired home connection, not a phone hotspot.
• VPN server load: Too many simultaneous connections can cause the IKE daemon to drop message IDs. Reboot the VPN server if possible.

One last thing: if you're using a split tunnel configuration, check that the route table doesn't have overlapping subnets. That's a rarer trigger, but I've seen it with FortiGate boxes where the internal network subnet matches the client's home subnet. Adjust the tunnel routes to avoid the collision.