Fix IPsec IKE Kerberos error 0x00003603

What triggers this error

You're trying to connect a VPN using IPsec with IKE authentication over Kerberos. The client talks to the domain controller, but the Kerberos ticket exchange fails. This usually happens after a password change, a clock skew, or when the domain controller's SPN (Service Principal Name) gets misconfigured. I've seen it most often on Windows 10 22H2 and Windows Server 2022 after a DC migration.

Quick fix (30 seconds) – check the clock

Kerberos is brutal about time. If your computer's clock is off by more than 5 minutes from the domain controller, the authentication gets rejected with this exact error.

Click the clock in the taskbar, then select "Date and time settings."
Turn on "Set time automatically" if it's off. Then click "Sync now."
After syncing, you should see a message saying "Your clock is synced" with a timestamp.
Try the VPN connection again. If it works, you're done.

If the clock keeps drifting, check your motherboard battery. A dying CMOS battery is the #1 cause of recurring time issues on desktops.

Moderate fix (5 minutes) – renew the Kerberos ticket and check SPN

If the clock was fine, the Kerberos ticket might be stale or missing. Run these commands as an administrator.

Press Win+X, select "Terminal (Admin)" or "Command Prompt (Admin)."
Type klist purge and press Enter. This wipes all cached Kerberos tickets. You'll see "Current LogonId is 0:0x..." and then a success message.
Type klist and press Enter to confirm the cache is empty. It should say "No entries found."
Reboot the computer. This forces a fresh Kerberos ticket grant at logon.
Test the VPN again.

Still failing? The VPN server's SPN might be missing or duplicated. On the domain controller (not your client), run this:

setspn -L VPN-Server-Name

Replace VPN-Server-Name with the actual hostname of your VPN server. You should see entries like host/vpn-server.domain.com. If nothing shows up, the SPN is missing. Add it with:

setspn -A host/vpn-server.domain.com VPN-Server-Name

If you see duplicate SPNs (same entry listed twice), remove the duplicate with setspn -D host/vpn-server.domain.com VPN-Server-Name and re-add it cleanly.

Advanced fix (15+ minutes) – reset the IPsec policy and registry

This is the nuclear option. I've used it on maybe 10% of cases where nothing else worked. It wipes your local IPsec policy and rebuilds it from scratch.

Step 1 – Backup the current IPsec policy

Open an admin command prompt again. Run:

netsh ipsec static show policy

Write down any policy names you see. Then export the policy:

netsh ipsec static export "C:\ipsec-backup.ipsec"

Step 2 – Reset the IPsec service

Type these commands one by one, pressing Enter after each:

net stop ipsec

After this, you should see "The IPsec Policy Agent service was stopped successfully."

net start ipsec

Expected: "The IPsec Policy Agent service was started successfully."

Step 3 – Clear the IKE negotiation data

This is the part most people miss. The IKE negotiation cache can get corrupted. Run:

netsh ipsec dynamic delete all

No output is normal. Then run:

netsh ipsec static delete policy name="YourPolicyName"

Replace YourPolicyName with whatever you saw in step 1. If no policy existed, skip this.

Step 4 – Fix the registry key that stores Kerberos settings for IPsec

Open Regedit (Win+R, type regedit, press Enter). Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters

Look for a value named AllowDHStrongMITM. If it exists, double-click it and set the value to 0. If it doesn't exist, right-click the Parameters key, select New > DWORD (32-bit), name it AllowDHStrongMITM, and leave it at 0.

Also check for DisableIKEv2 – if it's set to 1, change it to 0. This forces the client to use IKEv1 which some older VPN servers still require.

Step 5 – Reboot and test

Restart the machine. After it comes back up, try the VPN connection. If it still fails, you're looking at a deeper issue – possibly a missing root certificate on the client or a domain controller that isn't reachable over the network.

Still stuck?

At this point, check the VPN server's event log for the same IKE error. On the server side, open Event Viewer, go to Applications and Services Logs > Microsoft > Windows > IKE. Look for error ID 0x00003603 there. If the server log shows the same error, the problem is between the two domain controllers, not your client.

One last thing: if you're using a third-party VPN client (like Cisco AnyConnect or Pulse Secure) with IPsec, update the client to the latest version. I've seen old clients send malformed Kerberos tickets that trigger this exact error code.