1. Firewall Blocking UDP 500 and 4500
This is the #1 cause. I've seen it on maybe 30 different networks. The IKE negotiation uses UDP port 500 for initial handshake and UDP 4500 for NAT traversal. If either port is closed on the firewall between the two peers, the negotiation just hangs and eventually times out with 0x000035ED.
Had a client last month whose entire branch office VPN dropped after a firewall firmware update. The update reset the rules and silently blocked UDP 500. Took me two hours to find it because the firewall logs were full of generic denials. Check both sides — the local firewall and the remote one, plus any intermediary firewalls.
How to test: from the Windows machine, run this command in an admin PowerShell:
Test-NetConnection -ComputerName <remote-ip> -Port 500If it says TcpTestSucceeded : False, the port is blocked. You can also test UDP specifically with a tool like psping, but honestly the TCP test is a strong indicator. If the firewall admin tells you "It's open," ask them to confirm using a packet capture. I've run into too many cases where "open" really meant "we didn't explicitly block it" but the stateful inspection was dropping the packets anyway.
The fix: open UDP 500 and UDP 4500 on both firewalls. If you're behind NAT, also make sure the NAT device has IPsec passthrough enabled. That's usually a checkbox in the router settings — don't assume it's on by default.
2. IPsec Policy Mismatch — Main Mode and Quick Mode
IKE negotiation happens in two phases: Main Mode (Phase 1) and Quick Mode (Phase 2). If the two sides don't agree on the encryption algorithms, hash methods, or key lifetimes, the negotiation fails. The error code 0x000035ED is the generic "I gave up" message, but the root cause is often a config mismatch.
I had a client running Windows Server 2019 connecting to a Cisco ASA. The Cisco was set to use AES-256 with SHA-256 and a key lifetime of 28800 seconds. The Windows box was using the default — AES-128 with SHA-1 and 480 minutes. The main mode would start, then the Cisco would reject the proposal and Windows would retry until it timed out.
To check the current Windows IPsec policy, open an admin command prompt and run:
netsh ipsec static show policy allThis shows you the filter lists and filter actions. If you see anything with "default" or "medium" security, that's usually the problem. You need to match exactly what the other side expects, or at least have a set of proposals that overlap.
The fix: create a custom IPsec policy using the Windows Firewall with Advanced Security console (wf.msc). Under Connection Security Rules, create a new rule. In the Properties, go to the Advanced tab, then Customize for the IPsec settings. Set the key exchange (main mode) and data protection (quick mode) algorithms to match the remote device. Common combos that work with most modern devices:
- Main Mode: AES-256, SHA-256, Diffie-Hellman Group 14
- Quick Mode: AES-256, SHA-256, ESP (no AH)
- Key lifetime: 480 minutes (28800 seconds) for main mode, 60 minutes for quick mode
If you control both sides, just pick a standard and stick to it. Don't get fancy with custom combinations unless you have to.
3. Certificate or Pre-Shared Key Issues
This is less common than the first two, but I've seen it bite people. If you're using certificates for authentication and they're expired, revoked, or not trusted by the other side, the negotiation will hang. Same with a wrong pre-shared key (PSK) — the first two messages of main mode will look OK, but then the authentication exchange fails and it times out.
I had a case where a client was using a PSK that had a trailing space. The PSK was stored in the router config as "mysecret" but typed in Windows as "mysecret " (with a space). The hash didn't match, so the IKE negotiation started but couldn't complete. It took me three tries of retyping the key to notice the extra space. Always check for hidden characters if you're copying and pasting from an email or document.
To troubleshoot certificates: check the certificate store on the Windows machine using certlm.msc. Look under Personal and Trusted Root Certification Authorities. The certificate must have a corresponding private key and must not be expired. The remote device must trust the issuing CA. For PSK, verify it's identical on both sides — case-sensitive, no extra spaces. Use a simple test: copy the PSK into a notepad file, highlight it, and check the status bar for any spaces at the end.
The fix: regenerate the certificate if expired, or re-enter the PSK exactly as configured on the remote end. If you're using Active Directory, make sure the computer object has the right Kerberos authentication enabled — some IPsec deployments rely on Kerberos and that can fail if the computer account is stale.
Quick-Reference Summary Table
| Cause | Symptom | Fix |
|---|---|---|
| Firewall blocking UDP 500/4500 | Negotiation never starts, Test-NetConnection shows port closed | Open UDP 500 and 4500 on both firewalls, enable IPsec passthrough on NAT |
| IPsec policy mismatch | Negotiation starts but fails after a few seconds | Create custom IPsec rule matching remote device's algorithms and lifetimes |
| Invalid certificate or PSK | Negotiation starts but authentication fails silently | Check certificate expiration and trust chain, re-enter PSK exactly |
I've seen 0x000035ED dozens of times. Nine times out of ten, it's a firewall rule. If you're in a hurry, start there. The few minutes you spend verifying UDP 500 and 4500 will save you from chasing phantom config issues. If that doesn't fix it, then look at the policies and authentication. Don't waste time rebuilding the whole VPN connection — those three causes cover almost every case.