Wi-Fi and VPN, on speaking terms

Everyone who works from hotels knows the ritual: join the Wi-Fi, get nothing, turn the VPN off, it connects, turn the VPN back on. NomadWiFi does that for you — at the right moment, and only when it is needed.

Why it breaks in the first place

A VPN tunnel installs a default route of its own and points your DNS at the tunnel's resolver. That is the whole point of it. But it means the tunnel keeps owning where your packets go while the network underneath it changes, and three things go wrong at once.

The default route survives a network that did not

You associate with a new access point and get a new gateway, but traffic is still being handed to a tunnel whose remote endpoint is no longer reachable over that path. Nothing is obviously broken — Windows shows a connected network, the tunnel shows connected — and nothing works.

DNS answers from the old network are still cached

The resolver cache does not know the network changed. Even after the route recovers, names keep resolving to answers that belonged to the previous network until the entries age out.

A captive portal cannot be reached through a tunnel

Hotel and airport networks intercept your first request and redirect it to a sign-in page. If every packet is going into a tunnel, there is no first request to intercept. The portal never appears; with a kill switch on, you get silence instead of an explanation.

Toggling the VPN off and on works because it tears down the route and DNS state and rebuilds them against the network you are actually on now. That is the correct fix — it is just manual, and it has to happen in the right order.

What NomadWiFi does around a switch

Hold. Before touching Wi-Fi, the tunnel is paused if it can be paused, so the switch happens over the real network.
Switch. Connect to the chosen access point and wait for association.
Verify. Check the gateway answers, then that the internet is genuinely reachable, then whether a sign-in page is in the way.
Roll back if it failed. If the new access point does not carry traffic within the deadline, the previous network is restored and the failed one is penalised.
Resume and repair. Bring the tunnel back, flush the DNS resolver cache, refresh the route metrics, and probe once more to confirm.

Step five happens whether or not the tunnel could be paused. Flushing DNS and refreshing routes needs no cooperation from the VPN client, and it is most of what the manual off-and-on-again actually achieves.

Which clients can be controlled

NomadWiFi identifies tunnels by their network adapter, which works without elevation and without assuming any particular client is installed. Detected today: NordVPN (both NordLynx and OpenVPN adapters), Tailscale, WireGuard and Wintun tunnels, OpenVPN and TAP adapters, Mullvad, Proton VPN, ExpressVPN, Surfshark, Cloudflare WARP, ZeroTier, and Windows' own VPN via WAN Miniport.

Being able to see a tunnel and being able to pause it are different things.

Client	Control	How
Tailscale	Full	Its own command line, no elevation.
WireGuard	Full	`wireguard.exe /deactivate` on the tunnel.
NordVPN	None on Windows	The Windows client ships no supported command line. NomadWiFi says so plainly and offers the adapter route below.
Anything else	With administrator rights	Disabling and re-enabling the tunnel adapter. Offered as one explicit action with one prompt, never attempted silently.

When a tunnel cannot be paused, NomadWiFi tells you rather than failing quietly. The card reads “This client has no command line on Windows. Run NomadWiFi as administrator to let it pause the tunnel for you, or toggle the VPN yourself when prompted.” Everything else — the roam, the verification, the rollback, the DNS flush — still happens.

Captive portals with a tunnel up

When a portal is detected while a tunnel is up, guessing is not useful: the page cannot load and no amount of retrying changes that. NomadWiFi offers Pause VPN and sign in, which holds the tunnel, opens the portal, waits for you to get through, and then resumes and repairs. If it cannot pause your client, it gives you the sequence with the reason, so you are not guessing either.

From the terminal:

$ nomadwifi vpn hold      # pause the tunnel
$ nomadwifi status        # shows the portal URL to open
$ nomadwifi vpn resume    # bring it back and flush DNS

A portal is never treated as a degraded link. Roaming away from a network you have not signed in to yet only loses your place.

Why the health numbers stay honest

Latency measured through a tunnel is the tunnel's latency, not the Wi-Fi's — and roaming on that number would mean switching access points because a VPN exit node in another country was slow. NomadWiFi binds its probes to the Wi-Fi adapter's own source address, so what it measures is the link you are actually deciding about. Gateway latency reads the same with the tunnel up or down.

If you would rather it left the tunnel alone

$ nomadwifi watch --no-vpn
$ nomadwifi optimize --no-vpn

Roaming, verification and rollback all still work; only the hold and resume steps are skipped. The DNS flush and route refresh still run, because those help regardless.