Fix ERROR_IPSEC_IKE_SA_DELETED (0X000035EF) Fast
VPN connection drops with this IKE SA deleted error. Usually a timing or certificate mismatch. Here's how to fix it, from quickest to deepest.
30-Second Fix: Restart the VPN Service
You'd be surprised how often this works. The IKE SA got deleted because something timed out or got stuck in a half-open state. Just restart the VPN client or the entire VPN service.
On Windows, hit Win + R, type services.msc, find "IKE and AuthIP IPsec Keying Modules", right-click and select Restart. Or just reboot the machine - I had a client last month whose VPN wouldn't reconnect after a network change, reboot fixed it instantly.
If that doesn't do it, move on.
5-Minute Fix: Verify Credentials and Preshared Key
This error often means the other side (the VPN server) said "nope" and deleted the SA before it fully established. Usually a mismatch in the preshared key (PSK) or certificate.
Check the PSK first. One character wrong and it fails silently. Had a client who copied the key from an email and got an extra space at the end - took me 20 minutes to spot it. Delete and retype the PSK manually. No copy-paste.
If you're using certificates, check that the certificate chain is valid and not expired. Open certmgr.msc, look under Personal/Certificates. Expired cert? Renew it. Also make sure the server certificate matches the server name you're connecting to - a wildcard mismatch will kill the SA dead.
15-Minute Fix: Firewall and NAT Traversal
If the quick stuff didn't work, it's a firewall or NAT issue. The IKE SA gets deleted because the server thinks the client dropped off - often because UDP ports 500 and 4500 are blocked or NAT traversal isn't set right.
Step 1: Check Windows Firewall. Allow inbound UDP port 500 and 4500 for IPsec. Also check your router - if it's doing NAT, make sure IPsec passthrough is enabled. Some older routers like the Netgear WNR2000 had a bug where they'd drop IPsec packets after a few minutes - I replaced one last year, problem gone.
Step 2: Enable NAT traversal on the VPN client. In Windows, open an elevated command prompt (cmd as admin) and run:
netsh advfirewall firewall add rule name="IPsec NAT-T" protocol=udp dir=in localport=4500 action=allow
Then reboot the VPN service again.
Step 3: Check the server-side NAT traversal settings. If you control the VPN server, make sure it's set to allow NAT-T. On a Windows server, run:
netsh advfirewall firewall add rule name="IKE" protocol=udp dir=in localport=500 action=allow
Also check the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent and set AssumeUDPEncapsulationContextOnSendRule to 2 (DWORD). That forces Windows to assume NAT is present. Restart the machine after.
Still getting the error? It's probably a certificate authority issue. Make sure both sides trust the same root CA. Use certlm.msc on the client to verify the server cert is issued by a trusted authority. If you're using self-signed certs, import the root CA into Trusted Root Certification Authorities on both sides.
Real talk: I've seen this error more times than I can count, and 9 out of 10 times it's a stupid typo in the preshared key or a firewall zone blocking UDP 500. Start there, save yourself the headache.
Was this solution helpful?