0X00003636

IPsec IKE 0x3636: Benign Reinit After VPN Reconnect

Windows Errors Intermediate 👁 9 views 📅 May 26, 2026

This error means Windows IPsec temporarily restarted a key exchange—usually harmless after a network change or VPN reconnect. Rarely needs a fix.

What this error actually means

Error 0x00003636 (ERROR_IPSEC_IKE_BENIGN_REINIT) shows up in Windows security event logs—typically Event ID 4283 or 4284 under Microsoft-Windows-Windows Firewall With Advanced Security. The message says "A temporary state was created to perform reinitialization."

What's actually happening here is the IKE (Internet Key Exchange) service detected a network change—like a VPN tunnel dropping and reconnecting, or a routing table update—and decided to renegotiate the security association. It created a temporary placeholder state so the new negotiation can proceed without disrupting existing traffic. The error code itself is informational, not critical.

I've seen this most often after a VPN client reconnects (Cisco AnyConnect, WireGuard, native Windows VPN), or when a laptop switches between Wi-Fi and Ethernet. The log might look worrying, but in 95% of cases, you can ignore it.

Cause 1 — Normal VPN reconnect behavior

Most common trigger: Your VPN tunnel dropped briefly (maybe 2-5 seconds) and re-established. The IKE service created a new negotiation state while the old one was still cleaning up.

What to do

  1. Check if your VPN actually works right now. Can you ping an internal resource or browse a page that requires the VPN?
  2. If traffic flows fine, do nothing. This error is benign—it doesn't affect connectivity or security.
  3. If you're troubleshooting a VPN that doesn't work, look elsewhere: check DNS, routing tables with route print, or the VPN client logs.

The reason step 3 is important: chasing this error code when the real problem is DNS resolution will waste hours. I've helped three people this year who spent days on this error while their actual issue was a stale DNS cache.

Cause 2 — Aggressive IPsec policy reauth timers

Some organizations configure IPsec security associations with very short reauthentication intervals (under 30 minutes). Combined with a VPN that has its own keepalive, the two can step on each other. The IKE service sees the quick reauth request as a "reinit" and logs 0x3636.

This is especially common on Windows Server 2019/2022 acting as a VPN gateway with both IKEv1 and IKEv2 policies active.

Fix — Check your IPsec policy timers

Open an elevated PowerShell console and run:

netsh ipsec static show policy all

Look for SoftSATimeout and SATimeout values. If either is under 30 minutes (1800 seconds), consider raising them to 480 minutes (28800 seconds) or higher.

To modify a policy timer (replace MyPolicyName with your actual policy name):

netsh ipsec static set policy name="MyPolicyName" assign=yes softSALifetime=28800 salifetime=28800

If you're using Windows Defender Firewall with Advanced Security connection security rules instead of legacy IPsec policies, check the Authentication Method tab—make sure you're not using "Advanced" settings that force reauth every 5 minutes.

What's actually happening here is the policy forces the IKE service to renegotiate before the previous negotiation fully completes. The temporary state is the service trying to keep the tunnel alive while it processes the new request. Raising the timers gives the negotiation time to finish cleanly.

Cause 3 — Race condition with routing table updates

Less common but worth checking if the error appears frequently (multiple times per minute) across multiple network interfaces. This happens when something—a third-party firewall driver, a routing service like RIP or OSPF, or even a misconfigured DHCP server—flaps routes constantly.

How to confirm

Run this command every few seconds to see if routes change:

route print -4 | findstr /i "0.0.0.0"

If the gateway IP hops between interfaces, you've found the issue. Common culprits:

  • Hyper-V or VMware virtual switches injecting extra routes
  • NIC teaming drivers that report link state changes
  • Windows Mobile Hotspot feature turning on/off

Fix — Stabilize the route

If you find a flapping route, two approaches work:

  1. Disable the offending adapter (virtual switch, hotspot). Go to Control Panel > Network and Sharing Center > Change adapter settings, right-click the adapter, Disable.
  2. Add a persistent static route that overrides the flapping one:
route add -p 0.0.0.0 mask 0.0.0.0 192.168.1.1 metric 10

Replace 192.168.1.1 with your actual gateway. The -p flag makes it persistent across reboots. This tells Windows to use that route even if dynamic routes change—the IKE service won't see a routing change and won't need to reinitialize.

The reason this works: Windows routes based on the lowest metric. A static route with metric 10 beats any dynamically learned route with higher metrics. The IPsec stack sees a stable routing table and stops triggering benign reinits.

Quick-reference summary

Cause What to check Fix action
VPN reconnect or network change Can you actually reach internal resources? Ignore the error if connectivity works
Short IPsec reauth timers netsh ipsec static show policy all Increase SATimeout to 28800 seconds
Flapping routing table route print for gateway changes Disable offending adapter or add static route

Bottom line: 0x00003636 is Windows saying "I'm doing my job." Unless you have a real connectivity problem, move on. If you do have a problem, the error code is almost never the root cause—look at the VPN itself, DNS, or routing first.

Was this solution helpful?