VPN 809 Error on Windows 11: What It Means and How to Fix It

VPN error 809 on Windows 11 means your PC sent a connection request and the VPN server never replied, so Windows gave up. In practice it is almost always caused by something in the network path, typically a router or firewall blocking UDP ports 500 and 4500, an L2TP/IPsec connection that has to cross NAT, or (with IKEv2) dropped packet fragments.

The full message usually reads “The network connection between your computer and the VPN server could not be established because the remote server is not responding.” Below is what triggers it and how to fix it, from the quickest checks to the registry change that solves most L2TP cases.

What error 809 actually means

On Microsoft Q&A, an answer about Always On VPN describes error 809 as a VPN timeout: the server failed to respond. It recommends checking that the server’s public hostname resolves correctly and that the edge firewall is configured properly. VyprVPN’s support page says the same thing in plainer terms and suggests opening UDP ports 500 and 4500 on your router.

Error 809 only shows up with Windows’ built-in VPN client (Settings > Network & internet > VPN), not with VPN provider apps that run their own protocols. It is most common with L2TP/IPsec, but it can also hit IKEv2 connections.

The common causes

Quick checks before you change anything

1. Confirm the server address. Open the VPN connection’s settings and check the server name or IP character by character. In one Microsoft Q&A thread about Windows 11 L2TP, correcting the server IP was part of the fix.
2. Try another network. Connect your laptop to a phone hotspot and try again. If it works there, the problem is your local router or firewall, not Windows.
3. Restart the router and the PC. Cheap, and it clears stuck NAT sessions.
4. Install pending Windows updates. In January 2022, Patch Tuesday updates broke L2TP and IPsec IKE connections on Windows 10 and 11, and Microsoft shipped an out-of-band fix (KB5010795 for Windows 11) days later. That particular bug is long fixed, but it shows that updates can affect the built-in VPN client, so stay current.
5. Look for network-filtering software. A post on the Cisco Meraki community names SmartByte as one program known to cause error 809. Temporarily disabling third-party firewalls or “network optimizer” tools is a fair test.

Fix 1: Open UDP ports 500 and 4500

IPsec-based VPNs (L2TP/IPsec and IKEv2) need UDP 500 for the key exchange and UDP 4500 for NAT traversal. If your router, a corporate firewall or a hotel network blocks them, the server never hears you and Windows reports 809.

1. Sign in to your router’s admin page using the address and credentials printed on the router or in its manual.
2. Look for a firewall, “VPN passthrough” or “IPsec passthrough” section and make sure it is enabled.
3. If you run the VPN server yourself, forward UDP 500 and UDP 4500 to it.
4. On a work or school network, ask IT whether those ports are allowed outbound. You can’t fix that one yourself.

If you use a load balancer in front of an IKEv2 server, Richard Hicks notes that UDP 500 and 4500 from the same client must reach the same backend server.

Fix 2: Allow L2TP/IPsec through NAT (registry)

This is the fix most people searching for “vpn 809 error windows 11” need. By default, Windows does not set up L2TP/IPsec security associations when the VPN server sits behind a NAT device, and almost every home and office router is a NAT device. Microsoft documents a registry value that changes this in its article Configure an L2TP/IPsec server behind a NAT-T device.

Setting the value to 2 lets Windows establish security associations when both the server and the client are behind NAT devices. Microsoft’s article says to set it on the VPN client and the VPN server (if the server also runs Windows), then restart.

Steps

You need an administrator account. Create a restore point first (search “Create a restore point” in the Start menu).

1. Press Win + R, type regedit and press Enter. Approve the UAC prompt.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent.
3. Right-click in the right pane and choose New > DWORD (32-bit) Value.
4. Name it exactly AssumeUDPEncapsulationContextOnSendRule.
5. Double-click it, set Value data to 2 and click OK.
6. Restart the PC and try the VPN again.

If you prefer the command line, this does the same thing from an elevated Command Prompt or Terminal:

reg add HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f

The PolicyAgent path is the one VyprVPN and the Meraki community also give for Windows 7 and later. Older versions of Microsoft’s own article mention an IPSec subkey instead, which is why you’ll see both paths online; PolicyAgent is the one used on current Windows versions.

Be realistic about results: this fixes NAT-related failures, not blocked ports or a wrong server address. A Zyxel community thread reports the registry change did not help on some laptops, so work through the other fixes too.

Fix 3: IKEv2 connections and fragmentation

If your connection uses IKEv2 and it seems to start and then fail with 809, fragmentation is a likely cause. During the IKEv2 handshake, packets can exceed the network path’s MTU and get split into IP fragments, and routers, NAT devices or firewalls often drop those fragments, as Richard Hicks explains.

The fix is IKE-level fragmentation, which must be supported on both ends:

• Client side (your Windows 11 PC): According to Hicks, Windows clients have supported IKEv2 fragmentation since Windows 10 1803, and it is on by default. You don’t need to change anything.
• Server side (Windows RRAS): An admin enables it by creating a DWORD named EnableServerFragmentation with value 1 under HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2 on Windows Server 1803 or later.

If you are not the server admin, send them that article. That guidance dates from 2019, so admins should check it against current Microsoft documentation.

Fix 4: Recreate the connection or switch protocols

A corrupted or mis-set connection profile can also cause trouble. Remove the VPN under Settings > Network & internet > VPN, then add it again with the server address, VPN type and sign-in details your provider or IT team gave you. Make sure the VPN type matches what the server actually runs (L2TP/IPsec with pre-shared key, IKEv2, SSTP and so on). Picking “Automatic” can leave Windows trying protocols the server doesn’t offer.

If you can choose, consider moving off L2TP altogether. Microsoft has deprecated PPTP and L2TP for future Windows Server releases and recommends SSTP or IKEv2. Per that coverage, outgoing L2TP connections from Windows will keep working, but Windows’ own VPN server role will eventually stop accepting them. Microsoft hasn’t given a removal date, so as of November 2026 L2TP still works but is on its way out.

If you use a commercial VPN service, the simplest route is usually its own Windows app instead of a manually configured built-in connection. Those apps use their own protocols and don’t rely on the Windows L2TP/IKEv2 client, so error 809 doesn’t apply in the same way.

Which fix to try first

• Fails on every network: check the server address, then recreate the connection.
• Fails at home, works on a hotspot: open UDP 500/4500 and enable IPsec passthrough on the router.
• L2TP/IPsec through any home router: apply the AssumeUDPEncapsulationContextOnSendRule = 2 registry fix.
• IKEv2 that starts then fails: ask the server admin about IKEv2 fragmentation.
• Fails on one PC only: compare registry settings and look for interfering network software.

Most people are fixed by the registry change or the router ports. If you’ve done both and tested on a second network without success, the problem is almost certainly on the server side, and that’s a conversation for whoever runs it.