0x35F0: IKE SA deleted before established – fix VPN

First attempt: restart the VPN service (30 seconds)

What's happening here is that Windows sometimes leaves a half-baked IKE SA in memory after a failed connection attempt. The next attempt sees that stale SA and kills the new one before it finishes. The simplest fix: flush that garbage out.

1. Open Command Prompt as administrator.
2. Run net stop IKEEXT && net start IKEEXT
3. Try your VPN connection again.

If that restarts the IKE service successfully and your connection works, you're done. The reason this works is that stopping the service kills every active and pending IKE SA, including the zombie one that triggered the error. A clean slate.

This fails if the service won't stop or start, or if the error returns immediately. In that case, the problem isn't a one-off stale SA — it's a config mismatch that repeats every time.

Moderate fix: align authentication lifetimes (5 minutes)

The real cause of 0x000035F0 in most environments is a time window mismatch. Your VPN client and the server don't agree on how long the IKE SA should live, or how long they're allowed to take negotiating it. The server times out and deletes the SA before the client finishes.

Check your VPN client settings — usually in the advanced IPsec configuration of your VPN adapter.

1. Open Network Connections → right-click your VPN adapter → Properties.
2. Select the Security tab.
3. Click Advanced Settings (or IPsec Settings depending on your Windows version).
4. Set IKE SA lifetime to 480 minutes (8 hours) — this is the default Windows expects. Don't go above 1440 unless you really know your server supports it.
5. Set Quick Mode (IPsec SA) lifetime to 60 minutes.
6. Set Diffie-Hellman group to Group 2 (1024-bit) for compatibility. Group 14 is stronger but some older servers choke on it.

Why these numbers? Microsoft's default IKE SA lifetime is 480 minutes. If your VPN server expects 360 or 1440, the SA gets deleted when Windows tries to rekey at a time the server considers invalid. The 0x35F0 error fires because the deletion happens during the negotiation, not after.

If your VPN uses a pre-shared key, also verify the key itself hasn't been rotated on the server without updating the client. A wrong PSK triggers a different error code usually, but in some cases the server just silently drops the SA — and you get 0x35F0.

Advanced fix: registry tweak for aggressive rekey (15+ minutes)

Some VPN servers — especially older Cisco, Check Point, or Linux strongSwan setups — have a stupidly short timeout for IKE negotiation. Windows by default waits longer than the server does, so the server gives up and reaps the SA. You need to shrink Windows's patience to match.

1. Open Regedit as Administrator.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters
3. Create a new DWORD (32-bit) value named MaxIKEInitTickets. Set it to 5 (decimal).
4. Create another DWORD named MaxIKEInitRetransmits. Set it to 3 (decimal).
5. Restart the IKE service: net stop IKEEXT && net start IKEEXT
6. Try the VPN again.

The effect: Windows now sends fewer retransmits during IKE negotiation. If the server kills the SA after, say, 30 seconds, Windows won't waste time sending packets into the void — it will fail fast and clean up. The error 0x35F0 disappears because the SA gets deleted after Windows has already stopped trying.

If that doesn't work, you might have a certificate problem. Check the Certificates MMC (certlm.msc) for the VPN machine certificate. If it's expired, revoked, or the private key is missing, the IKE SA will get deleted during the certificate authentication phase. Re-issue the cert from your CA and try again.

One last thing: if you're on Windows 10 22H2 or Windows 11 23H2, there's a known bug where the IPsec driver doesn't handle rapid reconnects properly. Microsoft issued a hotfix in KB5031354 — make sure you have that update or later installed. You can check in Settings → Windows Update → Update History.

I've seen this error on a client's Remote Access server when someone fat-fingered the pre-shared key on a site-to-site VPN. They spent 4 hours messing with lifetimes and retransmits — the fix was retyping the PSK. So before you dive into registry edits, double-check the shared secret. It's always the simple thing first.