SSH to the WireGuard Server's Public IP Fails on Windows

Tunnels that come up while SSH to the server's public address stops working look like a server rejecting the connection. On Windows the likelier cause is local: a full-tunnel AllowedIPs of /0 switches on restrictive firewall rules that permit the tunnel's own transport and very little else. Encrypted packets reaching that address say nothing about whether a separate TCP connection to the same address may leave.

Separate the endpoint's public address from its inner tunnel address before touching the peer list. Almost every attempt to fix this by editing AllowedIPs makes the policy weaker rather than the route correct.

Routing Permission and Firewall Permission Are Different

A route decides where a packet would be sent, and a firewall rule decides whether it may be sent at all. Adding a route for the endpoint's public IP therefore produces a path that the filter can still block, which is exactly the confusion this symptom creates. On Windows the filter is part of the implementation rather than an add-on, so no route entry changes it. The two decisions are separate elsewhere too, though the defaults differ.

That is why a traceroute to the endpoint can succeed while an SSH attempt fails. The first is carried by the service that owns the exception, and the second is not.

What /0 Does on Windows

With a single peer whose allowed addresses cover the whole IPv4 space, WireGuard for Windows applies a restrictive firewall posture that blocks traffic which would otherwise leave outside the tunnel. The tunnel service's own transport is permitted, because the VPN could not function otherwise. Another application to the same public address receives no such permission, since the exception belongs to the transport rather than to the address. The Windows networking notes describe this behaviour and the related control in the editor.

Those rules are the mechanism behind the phrase kill switch. They are activated by the shape of the configuration rather than by a checkbox labelled as one.

Exceptions Change the Protection Model

Replacing /0 with two half-default prefixes is the documented way to keep broad routing without the restrictive semantics, and it is a different protection model rather than a shorter spelling. Subtracting the endpoint address from the allowed prefixes is the other common workaround, which lengthens the list and also changes which rules activate. Neither is a local edit with a local effect. Each one moves the boundary for every flow on the machine, not only for the connection you were repairing.

Where direct public SSH is genuinely required, the profile owner has to design both the outside route and its firewall permission, and decide what happens to unrelated traffic when the tunnel drops. Reviewing IPv4 and IPv6 separately belongs to that, since the rules are expressed per family. A broad bypass added to rescue one management session usually exposes more than the session.

Test the Management Path You Chose

Decide first whether management should travel inside the tunnel or outside it, then test that choice rather than both at once. The commands below check the client's addresses, the peer state and a connection to each target. Run them from the Windows client while the tunnel is up.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

A successful SSH to the inner address proves the tunnel carries management traffic and that the server's own firewall accepts it from the peer range. A failure on both targets is a server-side or key problem rather than a Windows routing one. If the inner address works and the outer one does not, the local firewall posture is doing precisely what it was designed to do. Read the three results in that order before editing a profile.

Record the management path, the address used and the behaviour when the tunnel is down. That note is what stops the next person from widening the bypass to save five minutes.