Kill Switch or LAN Access? Two WireGuard Answers

The handshake completes, browsing works, and the printer, the NAS and the local SSH hosts vanish. On the Windows client this is usually not a routing failure at all: a peer whose allowed prefixes include the literal default activates Block untunneled traffic, and that option is implemented as firewall rules that drop packets leaving by any other interface. The route table still lists the local subnet as on-link, which is why the symptom feels like a lie. Three conditions decide what to do about it, and only one of them is about routing.

Two Failures Wear the Same Symptom

The first failure is the client's fail-closed mode, and its signature is that everything outside the tunnel stops while the tunnel itself works perfectly. The second is a genuine reachability problem: a missing route, a missing entry on the server for a subnet behind the client, or two networks that share the same address range. Both produce a machine that can browse and cannot print, and they have opposite fixes, so the diagnosis has to come before the configuration.

The distinguishing observation is whether the local subnet is still present in the route table while traffic to it is dropped.

Three Conditions Decide the Answer

First, does this machine need to fail closed? If the answer is yes, a dropped tunnel must stop traffic rather than let it fall back to the physical interface, and that requirement outranks local convenience. Second, must local devices stay reachable while the tunnel is up? Printing, network storage and local management consoles are the usual reasons, and they are legitimate requirements rather than exceptions to be apologised for. Third, does the profile express the default as a literal 0.0.0.0/0? That detail is what triggers the client's rules, and it is editable.

Answer those three in writing before touching a profile, because each answer points at a different configuration.

Choose Fail-Closed and Give Up the LAN

If leakage matters more than local reachability, keep the literal default and leave Block untunneled traffic enabled. That is a coherent position: the machine is treated as a device that is either inside the tunnel or offline, and local services are reached from another device or through the tunnel if the server routes them. The cost is real and should be stated in the deployment notes rather than discovered by the person who needs to print.

This is the right choice for machines that handle work that must not appear on a café network when the tunnel drops. It is a poor default for a home laptop that also needs the scanner.

Choose LAN Access and Express the Default Differently

If local devices must remain reachable, express the same coverage without the literal default prefix. Two half prefixes cover every IPv4 address, the equivalent pair covers IPv6, and the client no longer inserts the blocking rules because the string it looks for is absent.

[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820

Clearing that checkbox makes the client write the same two pairs into the profile, so comparing the generated file with the block above is a quick way to confirm the mechanism rather than guess at it. Two consequences follow. Coverage is identical, so nothing else about the tunnel changes. Protection is not identical: with the rules gone, a tunnel that drops leaves the machine using its physical interface, which is precisely what fail-closed was preventing.

Check the Other Two Suspects Either Way

Once the firewall question is settled, confirm that the local subnet is actually routed and that the far end knows about anything behind this client. A server that must reach a LAN behind a client needs that prefix in the client's allowed list on the hub; leave it out and the hub cannot choose a peer for those addresses, and no amount of client configuration creates one.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0

The network category matters more than people expect: a newly created tunnel adapter classified as public changes which rules apply to it, and the result can look like a firewall block on the far side. The route print shows whether a default is present at all, which separates a policy problem from a missing route.

Then test three things in one sitting: the internet, one local host by address, and one host across the tunnel. A handshake proves only that keys agree, so the three tests are what demonstrate the policy. Should the local host still refuse with the switch cleared, the remaining suspects are the route, the far-end allowed list and the duplicate subnet, in that order.