0X00003649

Fix ERROR_IPSEC_IKE_NEG_STATUS_END (0x00003649) in 3 Steps

This IKE negotiation error usually means a firewall or VPN config mismatch. Fix the most common cause first, then the others.

1. Firewall or Security Software Is Blocking IKE Ports

Most of the time, this error pops up when a third-party firewall—or the Windows Defender Firewall—blocks UDP ports 500 and 4500. These are the ports IPsec uses for IKE negotiations. If they're blocked, the negotiation never gets off the ground, and you'll see the 0x00003649 status before the VPN even connects.

You'll most often hit this on Windows 10 or Windows 11 after a fresh install, or after updating your antivirus with a new firewall module. Sometimes it's the VPN client itself—I've seen it with Cisco AnyConnect and OpenVPN. But first, let's check the simplest thing.

Check and add firewall rules

  1. Press Win + R, type wf.msc, and hit Enter.
  2. Click Inbound Rules in the left pane.
  3. Look for rules named IPsec or IKE. If you see them, right-click and Enable Rule if it's disabled.
  4. If you don't see any, click New Rule… in the right pane.
  5. Choose Port and click Next.
  6. Select UDP and enter 500, 4500 in the specific local ports box.
  7. Click Next, then Allow the connection, then Next again.
  8. Check all three profiles (Domain, Private, Public) and click Next.
  9. Name it IKE Ports and click Finish.

After adding the rule, try your VPN again. You should see the connection succeed within a few seconds if this was the issue. If it still fails, move on to the next cause.

Also, if you're running a third-party firewall like Norton or McAfee, disable its firewall temporarily to test. I'm not saying keep it off, just test. If the VPN connects with that firewall off, you need to add the VPN client to its allowed programs list.

2. Preshared Key Mismatch or Wrong Authentication Method

The second most common cause is a simple config mismatch. You or your network admin typed the preshared key wrong, or the VPN server expects certificate authentication while your client is set to use a preshared key. This happens more than you'd think, especially after a password change on the server side.

You'll usually see this error right after you enter your credentials, and the log might show a message about IKE authentication failed if you dig through the event viewer.

How to fix it

  1. Open your VPN client's settings.
  2. Find the part that says Authentication or Security. It's usually under a tab called IPsec Settings or Advanced.
  3. Confirm that the preshared key exactly matches what your admin gave you. Watch for trailing spaces—they're invisible but they'll kill the negotiation.
  4. Check the authentication method dropdown. If your company uses certificates, select Certificate and make sure the correct certificate is installed in the Windows certificate store.
  5. If you're using a built-in Windows VPN (the one you set up in Settings > Network & Internet > VPN), go edit the connection and click Advanced options. There you'll see the preshared key field.

After you fix the key or switch the method, try to connect. The error should disappear if this was the root cause. But if you're still stuck, there's one more thing to check.

3. IKE Proposal Mismatch (Encryption or Integrity Algorithms)

Sometimes the problem isn't a firewall or a key—it's the negotiation parameters themselves. The client and server can't agree on which encryption algorithm to use (like AES vs 3DES), or which integrity algorithm (SHA1 vs SHA2). This is common when you connect to an older VPN server that only supports SHA1, but your Windows machine is set to prefer SHA2.

You'll see this error after a Windows update, because Microsoft changed the default proposal order. Windows 10 version 2004 and later, and all Windows 11 versions, use stronger algorithms by default. If your VPN server hasn't been updated, it can't keep up.

Change the IKE proposal order

There's a registry tweak that can force Windows to try the older algorithms first. Here's what I do:

  1. Press Win + R, type regedit, and hit Enter.
  2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent.
  3. Right-click on the right side, select New > DWORD (32-bit) Value.
  4. Name it AssumeUDPEncapsulation and set its value to 2. This helps if the server only supports UDP encapsulation, but it's worth trying.
  5. Close Regedit and restart your computer.

That tweak doesn't always solve the proposal mismatch, but it's the one that works for the UDP-encapsulation issue. For the actual algorithm mismatch, you might need to update your VPN client or contact the admin to enable SHA256 on the server. If you're managing the server, go into the IPsec policy and add AES256 and SHA256 to the proposal list.

After a restart, try connecting again. If it still fails, look at the server's logs—they'll tell you exactly which proposal it rejected.

Quick Reference Table

Cause Fix Time to Test
Firewall blocking UDP 500/4500 Add inbound rules for those ports Immediate
Wrong preshared key or auth method Verify key, switch to certificate if needed Immediate
IKE proposal mismatch Registry tweak for encapsulation, update server After restart

That covers the top three things I've seen cause this error. Start with the firewall—it's the most common and the easiest to test. Then double-check your key, and if you're still stuck, mess with the registry tweak. You'll likely have your VPN back up in no time.

Related Errors in Windows Errors
0x80070002 Fix Windows Error 0x80070002 – Missing Files 0XC00D119B Fix NS_E_WMP_PLAYLIST_EXISTS 0XC00D119B in Windows Media Player 0X0000048E Fix ERROR_DEVICE_DOOR_OPEN (0x0000048E) on Windows 0X00000535 Too Many LUIDs Requested (0x535) – Quick Fixes

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.