0X00003614

Fix ERROR_IPSEC_IKE_LOAD_SOFT_SA (0x00003614)

Windows Errors Intermediate 👁 0 views 📅 Jun 9, 2026

IPsec soft SA loaded? This happens when Windows can't negotiate a hard security association. Usually a certificate or policy mismatch.

Quick Answer

Check your IPsec certificate trust chain and policy filter matches. The most common fix is re-importing the correct root CA certificate to both sides and ensuring the policy doesn't use a mismatched filter list.

Why This Happens

I know this error is infuriating — you're staring at Event ID 4285 in the System log, and the connection drops to a fallback soft SA instead of establishing a proper hard SA. This tripped me up the first time too, back when I was running a help desk for a financial firm. The 0x00003614 error means the IKE (Internet Key Exchange) protocol couldn't negotiate a secure, authenticated main mode SA. Instead, it falls back to a "soft" SA — which is basically a default, unsecured placeholder that Windows logs to tell you something went wrong.

This usually pops up in one of two scenarios:

  • You're setting up a site-to-site VPN between two Windows Server machines (2016, 2019, or 2022).
  • You're using IPsec with certificate authentication for a remote access VPN on a domain-joined Windows 10/11 client.
The root cause? The certificates don't chain up to a trusted root on the receiving end. Or the IPsec policy's filter list doesn't match the traffic you're trying to secure. A subtle mismatch — like using the wrong authentication method in the rule — also triggers this.

Step-by-Step Fix

Step 1: Verify Certificate Chain Trust

Open the Certificates MMC (certlm.msc for local machine) on both the initiator and responder. Check:

  • Your machine certificate is in Personal > Certificates.
  • The issuing root CA certificate is in Trusted Root Certification Authorities.
  • The certificate subject matches the IP address or DNS name in the IPsec policy (yes, Windows checks this — I've seen it break because of a trailing dot in the subject).
If the root isn't trusted, export it from the CA server as a .cer file and import it into the target machine's Trusted Root store. A quick way: double-click the .cer file and choose Install Certificate > Local Machine > Trusted Root Certification Authorities.

Step 2: Check Certificate Validity

A certificate that's expired or not yet valid (system clock drift, anyone?) will cause a soft SA. Right-click the certificate in the MMC, go to All Tasks > Properties, and check the Validity period. If it's expired, request a new one from your CA. Also verify both machines' clocks are synced to the same NTP server — a difference of more than 5 minutes breaks Kerberos-based IPsec too.

Step 3: Audit IPsec Policy Settings

Open the Windows Defender Firewall with Advanced Security MMC (wf.msc). Go to Connection Security Rules. Right-click your rule and select Properties. Check:

  • Authentication mode: Should be Require authentication for inbound and outbound connections.
  • Second authentication: Set to Do not authenticate unless you're layering Kerberos. If it's set to User (Kerberos) and you're using certificates, the soft SA appears.
  • First authentication method: Should be Computer certificate. Click Add and make sure the correct certificate authority is selected (not just "Any CA").
I once spent three hours on a call with Microsoft support because the rule had a filter that specified UDP port 500 and 4500 only, but the client was using TCP. The fix: change the filter to Any IP address and Any port. Yes, it seems broad, but IPsec handles the port selection automatically.

Step 4: Reset IPsec and Restart Services

Open an elevated Command Prompt and run these commands in order:

netsh ipsec static reset all
net stop IKEEXT && net start IKEEXT
net stop PolicyAgent && net start PolicyAgent
Then reboot both machines. This clears any corrupt SA bundles from the IKE cache. You'll lose the existing soft SA, which is fine — you want a fresh negotiation.

Alternative Fixes

If the steps above don't work, try these less common but effective solutions:

  • Check Group Policy overlap: If you're in a domain, a GPO might be applying a conflicting IPsec policy. Run gpresult /h gp.html and look for multiple Connection Security Rules. Remove any duplicates.
  • Disable Windows Defender Firewall temporarily: Not a long-term fix, but it isolates whether the firewall is blocking IKE traffic. On the server, run netsh advfirewall set allprofiles state off. Re-enable it after testing.
  • Use a pre-shared key instead of certificates: Change the authentication method in the rule to Pre-shared key (yes, it's less secure, but it bypasses certificate issues). If that works, your certificate setup is the problem.

Prevention Tips

To stop this error from recurring:

  • Automate certificate renewal with a GPO that auto-enrolls computer certificates. If you're using a domain, configure an auto-enrollment policy for the Computer certificate template.
  • Monitor the System event log for Event ID 4285 — that's the soft SA warning. Set up an alert in your monitoring tool (like SCOM or even a simple PowerShell script) to catch it early.
  • Document your IPsec filter list exactly. I've seen admins create a rule that secures traffic to a subnet but then add a filter that excludes that subnet. Keep filters as simple as possible — Any is your friend unless you need granularity.

Was this solution helpful?

ERROR_IPSEC_IKE_LOAD_SOFT_SA 0x00003614 IPsec soft SA Windows IPsec error VPN IKE error soft SA loaded IPsec policy mismatch certificate authentication failure IKE negotiation failed Windows Server IPsec VPN connection failure