VPN Not Working on Windows 11: Fix It by Elimination, Not by Guessing (2026)

Most advice for a broken VPN on Windows 11 is a list of things to try in no particular order: restart, reinstall, switch servers, disable the firewall. It works eventually, the way pressing every button eventually works. The order below is different — each step splits the problem in half, so five minutes of it leaves you with one suspect instead of ten.

Everything here is for Windows 11 as of August 2026, which by now means 22H2 through 25H2. That matters more than usual: every one of those feature updates has touched the network adapter stack, and a tunnel that worked on Friday and not on Monday is very often a driver that survived the update in name only.

The thirty seconds that decide everything else

There are exactly two failure families: packets are not moving and names are not resolving. Nearly every symptom — pages that never load, apps that hang, “connected but no internet” — belongs to one of them, and the two need completely different fixes. Tell them apart before touching anything.

1. 1Connect the VPN, then open Terminal or PowerShell.
2. 2Run ping 8.8.8.8. This is an address, not a name, so it tests routing only.
3. 3Run nslookup example.com 8.8.8.8. This tests name resolution against a server that is definitely reachable.
4. 4Run nslookup example.com with no server. This tests the resolver Windows actually chose for you.

Connected, but nothing loads: the DNS case

Windows does not simply “use the VPN's DNS”. It keeps a per-interface list and a rule table called the NRPT, and a tunnel that sets one but not the other leaves you resolving names through a server that no longer has a route. The tunnel is up; the questions are going nowhere.

1. 1Get-DnsClientServerAddress -AddressFamily IPv4 — see which resolver each adapter holds. The VPN adapter should have one, and it should not be your router's address.
2. 2Get-DnsClientNrptPolicy -Effective — if your client uses split DNS, the rules live here. An empty result on a split-DNS setup is the bug.
3. 3ipconfig /flushdns — clears answers cached from before the tunnel came up. Cheap, and it genuinely fixes the “only some sites work” variant.
4. 4Get-NetRoute -DestinationPrefix 0.0.0.0/0 — more than one default route is normal with a VPN; the tunnel's should have the lower metric. If it does not, traffic is leaving through your normal adapter.

If names resolve but the answers look wrong — you reach a site and it greets you in the wrong language, or a streaming service still sees your real country — the resolver is outside the tunnel even though packets are inside it. That is a DNS leak rather than a broken VPN, and it has its own diagnosis and fix.

Error 809, 789, 691, 800: what the built-in client is telling you

These come from Windows' own VPN client — the one under Settings, speaking L2TP/IPsec, IKEv2 or SSTP. Third-party apps rarely show them. The numbers look interchangeable and are not:

• 809 — the negotiation never got through. Something between you and the server is dropping UDP 500 and 4500, or the server sits behind NAT. On the client side the classic fix is one registry value: AssumeUDPEncapsulationContextOnSendRule set to 2 under HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent, followed by a reboot. It tells Windows to accept IPsec with a NAT device in the path, which it refuses to do by default.
• 789 — the IPsec layer failed before authentication. Wrong pre-shared key, a mismatched proposal, or the IKEEXT service not running. Check the service first; it is disabled more often than anyone expects.
• 691 — credentials rejected. Genuinely the password, or a domain prefix the server does not want, or an account that requires a certificate you have not installed.
• 800 — no tunnel could be established at all. Usually the address is wrong, or the protocol the profile asks for is not the one the server speaks.
• 619 and 720 — the port opened and then closed, or the PPP negotiation collapsed. On Windows 11 these two point at the WAN Miniport adapters more often than at the server.

After a feature update: resetting the network stack

The pattern is recognisable. The VPN worked, Windows installed 24H2 or 25H2, and now the client either hangs at “connecting” or reports an adapter error. The virtual adapters are still listed, so nothing looks broken — but the miniport drivers under them were rebound to a stack that changed.

1. 1In an administrator terminal: netsh interface ip reset, then netsh winsock reset, then reboot. Do the reboot — half of this does nothing until you do.
2. 2Still failing: open Device Manager, View → Show hidden devices, expand Network adapters, and uninstall every WAN Miniport entry. They are recreated on the next scan or reboot, and they come back bound correctly.
3. 3Restart Remote Access Connection Manager (rasman) and IKE and AuthIP IPsec Keying Modules (IKEEXT). Both must be running for the built-in client; a stopped RasMan produces errors that look like server faults.
4. 4For a third-party client, reinstall the app rather than repairing it — the tunnel driver (Wintun, TAP or a vendor's own) is installed by the app and is what actually broke.

WireGuard: “Handshake did not complete after 5 seconds”

This message reads like a cryptographic failure and almost never is one. WireGuard's handshake is a single UDP exchange; if it does not complete, the packet did not arrive or the reply did not come back. Work the list in this order, because it is ordered by how often each is the answer:

• UDP is blocked. Corporate networks, hotel Wi-Fi and some mobile carriers pass TCP 443 and little else. Test from a phone hotspot: if it works there, the network is the answer, not the config.
• The endpoint port is wrong or moved. A server that changed address will not tell you; the client keeps trying the old one forever.
• Keys do not match. A regenerated key on either side produces exactly this symptom, silently.
• The clock is wrong. More than a couple of minutes of skew breaks the handshake. Check that Windows Time is actually running.
• Windows Defender Firewall is dropping the outbound UDP. Rare on a default install, common after a security suite has been installed and removed.

If UDP turns out to be the blocker, no amount of WireGuard configuration will help — the fix is a protocol that lives inside a TCP TLS session, which is the entire reason VLESS Reality exists. The same reasoning explains why QUIC and UDP get blocked in the first place.

The tunnel is up and everything is slow or half-loaded

The signature is unmistakable once you know it: small pages open, large ones stall halfway, SSH sessions freeze on long output, file downloads die at a random percentage. That is not bandwidth. That is a packet too large to pass with the tunnel's headers added, and a path that is not reporting it back.

1. 1Find the ceiling: ping -f -l 1400 8.8.8.8, then lower the number until the “Packet needs to be fragmented” message stops. Add 28 to the largest size that works — that is your real MTU.
2. 2See what Windows currently uses: netsh interface ipv4 show subinterfaces.
3. 3Set it on the tunnel adapter: netsh interface ipv4 set subinterface "WireGuard Tunnel" mtu=1380 store=persistent, substituting the adapter name from the previous command.

1380 is a safe starting point for most tunnels over most home connections. The full explanation of why the number lands where it does — and why the symptom is “some sites” rather than “all sites” — is in MTU and fragmentation. If the connection is merely slower than you hoped rather than broken, measure it properly first; the number people quote is usually from a test that measured their own Wi-Fi.

Security software, and how to test it without turning it off

Antivirus suites with HTTPS inspection sit between your applications and the network and terminate TLS to look inside it. A VPN client that pins certificates sees a certificate it did not expect and refuses to connect — correctly. Disabling the whole suite to test this is unnecessary and leaves you unprotected while you experiment.

1. 1Look for a setting named HTTPS scanning, SSL inspection or encrypted-traffic scanning, and exclude the VPN client's executable from it.
2. 2Check that the client is listed under Windows Security → Firewall & network protection → Allow an app through firewall, for both Private and Public profiles. Public is the one that matters on hotel and café networks.
3. 3If a suite was uninstalled recently, its filter driver may still be bound to the adapter. netsh winsock reset and a reboot removes the leftovers.

When the network is the problem, not the computer

Two checks settle this in a minute. Tether to a phone and try again: if the tunnel comes straight up, the fault is the network you were on, and no amount of Windows repair will change that. Then try the same account on a second device on the original network: if that fails too, it is the network or the server, not this machine.

Captive portals deserve their own mention. Hotel and airport Wi-Fi holds you at a sign-in page until you accept it, and a VPN that connects automatically at boot prevents the portal from ever loading — the portal cannot see you, and you cannot see the internet. Disconnect, sign in, then reconnect. A kill switch makes this worse in exactly the same way, and knowing that is the difference between a ten-second fix and an evening.

Frequently asked

One habit worth keeping after all this: when a tunnel breaks, write down which of the two families it was — packets or names. Almost nobody does, and almost everybody re-diagnoses the same problem from scratch the third time it happens.