Never bring up a full-tunnel VPN client on your mesh hub

One wg-quick up with AllowedIPs = 0.0.0.0/0 on the wrong box, and you lock yourself out of your own hub. Here’s the failure and the self-healing that stops it repeating.

The five-second outage you cause yourself

To “just test” a client config, you bring it up on the mesh hub itself. The config carries 0.0.0.0/0. WireGuard dutifully installs a default route through the tunnel — whose endpoint is the hub’s own public IP. Every packet now hairpins into the tunnel. SSH drops mid-command, so your down never runs. The hub — which every spoke relays through — is gone. Recovery: provider console.

Never test a full-tunnel client on an infrastructure node. Ever. Use a throwaway host, or scope AllowedIPs to a test subnet.

Make the box heal itself

Humans forget; watchdogs don’t. A one-minute timer that: pings the outside world, and if it’s unreachable twice in a row, tears down any tunnel interface not on an allow-list and restores the real default route.

# pseudo-logic
if ! reachable_twice(external); then
  for i in $(wg_interfaces); do
    case $i in allowed_list) ;; *) wg-quick down "$i" ;; esac
  done
  ip route replace default via $REAL_GW dev $REAL_IF
fi

Now the same mistake fixes itself in ~2 minutes with no console trip. The priority the owner set was simple: the hub must always work. So the hub was taught to insist on it.