Handshake Yes, Internet No: What to Fix First on Windows 11

Recent handshakes sit beside browsers that open nothing all the time on Windows 11. The handshake only proves the UDP exchange with the peer completed. It says nothing about the route Windows installed, the resolver it uses, or whether the exit forwards anything.

Four conditions decide which of those layers failed. Working them in order takes minutes, while rewriting keys takes longer and changes nothing.

Decide the Layer Before Touching the Keys

Work through three destinations, in this sequence. Start with a tunnel-side address, then a public IP by number, and finish with a hostname. Where the sequence breaks names the layer. A failure at the first step is routing, at the second it is forwarding or NAT, and at the third it is name resolution.

That ordering is the whole method. It stops a DNS fault from being diagnosed as a broken tunnel, which is the most common wrong turn here.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

If the Handshake Time Is Empty

When the handshake time is empty, the encrypted exchange never completed. The fault therefore sits earlier than routing. Look at the endpoint address and port first, then at whether the network filters UDP. A hosting provider that drops WireGuard traffic produces exactly this, and so does a client that copied an endpoint from an old profile.

Bytes leaving with none arriving is a different case. That points at NAT or a firewall returning traffic to the wrong place.

If the Route Loses to the Physical Adapter

For a full tunnel the peer section has to cover the destinations you expect to use. Windows sometimes keeps the physical adapter's default route even with a catch-all configured. Splitting the catch-all into 0.0.0.0/1 plus 128.0.0.0/1 creates two more specific prefixes that win the lookup. The split is a documented workaround rather than a preference.

Confirm with route print or a lookup for a public address. The chosen interface should be the tunnel adapter. If the physical one still wins, fix the peer ranges before touching the server.

If Addresses Work and Names Fail

WireGuard carries IP packets and has no opinion about DNS. Put a DNS = line in the interface section, or set the adapter through Windows. Without one, a ping by address succeeds while every hostname fails, and users report that as no internet.

Check which servers Windows actually uses after connecting. A leftover resolver on the physical adapter explains a partial failure, where some names resolve and others do not. Clear it instead of adding a second one on top.

If the Windows Machine Is the Exit

Internet Connection Sharing rewrites addressing when it is enabled, which can move the shared adapter to a different range. A client still pointing at the original address then stops working. The registry values ScopeAddress and StandaloneDHCPAddress control that range, and the setting can revert after a reboot.

Two other Windows-specific conflicts are worth a look. The Routing and Remote Access service can interfere with the tunnel. An installer built for the wrong architecture fails with a message that never mentions architecture.

Fix the layer the test named, then rerun the same three destinations. A change that repairs the hostname test but breaks the tunnel address was applied to the wrong layer.