0X00003619

Fix 0x00003619 IPSec IKE Policy Change Error Quickly

This error means a new policy killed your old IPSec connections. Simple restart fixes it 8 times out of 10. If not, you need to flush the old SAs.

What This Error Means (Quick Look)

You're seeing 0x00003619 when a new IPSec policy gets pushed out — usually from a Group Policy update or a manual change. The old security associations (SAs) don't match the new rules, so they get tossed. You'll see this on Windows Server 2016, 2019, or 2022, and sometimes on Windows 10/11 if you're using VPN or DirectAccess.

The real trigger is almost always an admin pushing a new policy while connections are active. The error shows up in the event log under System, source IPSec. Users lose VPN tunnels, RDP drops, or file shares become unreachable.

Step 1: The 30-Second Fix — Restart the IPSec Service

Don't overthink it. Half the time, the old SAs just need to die cleanly. Restarting the IPSec service forces that.

  1. Open Command Prompt as admin. Hit Windows key, type cmd, right-click, Run as administrator.
  2. Run this:
    net stop PolicyAgent && net start PolicyAgent
  3. Wait 10 seconds. Check if your VPN or tunnel comes back.

If that works, you're done. If not, move to Step 2. Also, restarting the whole machine works too, but that's overkill if the service restart alone fixes it.

Step 2: The 5-Minute Fix — Flush Old SAs with Netsh

Service restart didn't cut it? The SAs are stuck in memory. You need to nuke them manually.

  1. Open Command Prompt as admin again.
  2. Check what's active:
    netsh ipsec static show all
  3. Look for old policy names. You'll see entries like "Old VPN Policy" with status "Active".
  4. Delete the old policy:
    netsh ipsec static delete policy name="Old Policy Name"
  5. Then flush everything:
    netsh ipsec static delete all
  6. Restart the service one more time:
    net stop PolicyAgent && net start PolicyAgent

This removes all SAs and policies, forcing a fresh negotiation. Your new policy should take over cleanly. Test your connection right after.

Heads up: Running delete all will wipe out any custom IPSec rules you made locally. If you're using domain-pushed policies via Group Policy, that's fine — they'll reapply on the next refresh. But if you hand-rolled rules, export them first with netsh ipsec static export.

Step 3: The 15+ Minute Fix — Check Group Policy and Event Logs

Still no luck? The policy itself is probably broken. Or there's a conflict. This takes more time.

Check the Event Log

Open Event Viewer, go to Windows Logs > System. Filter by source "IPsec" or "PolicyAgent". Look for events around the time your error appeared. Common ones:

  • Event ID 4284 — Policy change attempted but failed.
  • Event ID 4650 — SA was established with old policy (confirms the error).

If you see Event ID 4284, the new policy has a syntax error or a rule that's impossible (like conflicting filter lists).

Validate the New Policy

On a domain controller or the machine pushing the policy:

  1. Open the Group Policy Management Console.
  2. Find the policy that's causing the issue. Look under Computer Configuration > Windows Settings > Security Settings > IP Security Policies.
  3. Right-click the policy, select Properties.
  4. Check each rule. Common mistakes:
    • Filter list says "All IP Traffic" but the rule only applies to specific ports — fails on mismatch.
    • Authentication method changed from Kerberos to certificate, but the cert isn't deployed yet.
    • Two policies with overlapping rules — the one with higher precedence wins, but the other one still breaks SAs.
  5. Fix the broken rule. Then force a refresh on the affected machine:
    gpupdate /force
  6. Restart the IPSec service again.

If You're Using a Third-Party VPN or Firewall

Sometimes the error comes from a third-party client (like Cisco AnyConnect or OpenVPN) conflicting with Windows IPSec. Check if the third-party software has its own policy. If so, disable Windows IPSec for that interface:

netsh interface ipsec delete all

Then restart the third-party client.

Last Resort — Rebuild the Policy from Scratch

If nothing works, delete the policy entirely and create a new one. Don't edit the old one — it's corrupted or has invisible junk. Use the IP Security Policy Management snap-in (secpol.msc) to build fresh rules.

  1. Run secpol.msc as admin.
  2. Right-click "IP Security Policies", select "Create IP Security Policy".
  3. Follow the wizard. Use the same filter lists and actions as before, but type them manually.
  4. Assign the new policy: right-click it, select Assign.
  5. Restart the IPSec service.

This is annoying, but it works. I've seen policies get corrupted after multiple updates — the old SAs just won't die.

Quick Summary Table

StepWhat to DoTimeSuccess Rate
1Restart PolicyAgent service30 sec80%
2Flush SAs with netsh5 min15%
3Fix Group Policy or rebuild15+ min5%

That covers it. Start with Step 1, skip ahead if you're impatient. Most people don't need to go past Step 2. Good luck.

Related Errors in Windows Errors
0XC000008A STATUS_RESOURCE_TYPE_NOT_FOUND (0XC000008A) Fix 0X00000537 0x00000537: Invalid SID Sub-Authority — The Real Fix 0X00000862 NERR_CfgCompNotFound (0X00000862): Quick Fix Guide 0XC000001A STATUS_UNABLE_TO_FREE_VM (0xC000001A) fix – memory can’t be freed

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.