Fix ERROR_IPSEC_IKE_DROP_NO_RESPONSE (0X000035F5)

You're stuck with a VPN that won't connect

I get it — you've got a VPN tunnel that's failing, and the only clue is ERROR_IPSEC_IKE_DROP_NO_RESPONSE. This happens when the IKE (Internet Key Exchange) packets never reach the peer. The fix is usually straightforward, so let's cut to it.

The fix: Open ports and enable NAT-T

Step 1: Open firewall ports for IKE

The default port for IKE is UDP 500. A lot of firewalls block it. Check both your local Windows Firewall and any edge firewall between the peers.

# Allow IKE traffic on Windows Firewall
netsh advfirewall firewall add rule name="IKE UDP 500" protocol=udp localport=500 action=allow dir=in
netsh advfirewall firewall add rule name="IKE UDP 4500" protocol=udp localport=4500 action=allow dir=in

If you're running Windows Server 2016 or later, also verify that the IPsec Policy Agent service is running:

# Check service status
sc query PolicyAgent

If it's stopped, start it and set it to automatic:

net start PolicyAgent
sc config PolicyAgent start= auto

Step 2: Enable NAT Traversal (NAT-T)

The most common cause of this error is that one or both peers are behind a NAT device. IKE uses UDP 500 normally, but NAT routers mangle that traffic. NAT-T wraps IKE in UDP 4500 to avoid that.

On Windows, it's controlled via the registry:

Registry location:
HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent

Key: AssumeUDPEncapsulationContextOnSendRule
Type: REG_DWORD
Value: 2

Set it to 2 (enables UDP encapsulation for all connections). Reboot the machine or restart the Policy Agent service.

Step 3: Verify the remote peer is reachable

Before blaming the config, confirm basic connectivity. Ping the remote IP. If ping fails, check routing. If ping works but IKE still times out, the remote firewall is dropping UDP 500/4500.

# Test basic connectivity
test-netconnection  -port 500
test-netconnection  -port 4500

Why this works

ERROR_IPSEC_IKE_DROP_NO_RESPONSE means the local machine sent IKE packets but never got a reply. The firewall rules ensure the packets aren't killed by Windows Defender Firewall. NAT-T solves the common issue where NAT routers break IKE negotiation. Without it, the IKE initiator sends on UDP 500, but the response goes to UDP 4500 — and if NAT-T isn't enabled, the two sides can't talk. Setting AssumeUDPEncapsulationContextOnSendRule to 2 forces Windows to always use UDP encapsulation, bypassing NAT headaches.

Less common variations of this issue

Variant 1: IKEv2 vs. IKEv1 mismatch

If your remote peer uses IKEv2 and you're configured for IKEv1 (or vice versa), you'll see this error. Check your IKE version in the VPN settings or the IPsec policy. On Windows, you can force IKEv2 in the registry:

HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters
Key: NegotiateDH2048_AES256
Type: REG_DWORD
Value: 1

Variant 2: Certificate revocation check hanging

In some cases, the client tries to check the peer's certificate revocation list (CRL) and the CRL distribution point is unavailable. This can cause a timeout that looks like IKE dropping. Disable CRL checking in the VPN connection properties or via Group Policy:

# Disable CRL check for IPsec (requires admin rights)
netsh advfirewall set global statefulftps disable
# Then restart PolicyAgent

Variant 3: Fragmentation issues

If your IKE packets are larger than the MTU of the path, they get fragmented and lost. This is especially common with jumbo frames or VPN over PPPoE. Force IKE to use smaller packets:

HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent
Key: MaxPacketSize
Type: REG_DWORD
Value: 1200

Set to 1200 bytes (or lower if needed). Restart the service.

Prevention

Keep the firewall rules aligned

If you're managing multiple VPN peers, standardize on the same port rules. Document which ports are open. Use a script to apply the firewall rules during deployment so you don't have to chase this later.

Always enable NAT-T by default

Don't wait for the error. On any Windows machine that acts as an IPsec client or server, set AssumeUDPEncapsulationContextOnSendRule to 2 preemptively. It causes zero harm and prevents a ton of headaches.

Monitor for changes

If a third party manages your edge firewall, make sure they log any changes to ACLs. I've seen this error reappear months after a network upgrade because someone opened new ports without checking IPsec. Set up a simple ping test from both sides of the tunnel — alert if it fails.

Test IKE with a quick warm-up

Before you rely on a VPN tunnel for production, run a manual IKE test using Test-NetConnection on both UDP 500 and 4500. Saves you from finding out at 2 AM.