the mesh, explained
Two jobs, one private network.
Two data centres, 100 miles apart, behave like one system — because every tunnel here has one of two deliberate jobs. A backbone joins the servers to each other; an exit sends a device's whole connection out through one of them, where AdGuard Home filters every name it looks up. Here's both, in plain language. All addresses shown are placeholders.
the mesh in numbers
the two jobs
Two jobs, at a glance
Every WireGuard tunnel on the mesh does one of two jobs — a backbone that joins the servers, and an exit that carries a device's whole connection. Here they are side by side.
the backbone · wg0
The backbone — one private network across two cities
The two machines live in different UK data centres, each with its own internet connection. WireGuard lays a private network on top — the wg0 backbone — joining them as if they shared a switch.
Identity is cryptographic, not password-based: each server holds a private key that never leaves the machine and knows the other's public key. A packet that isn't sealed by the expected key simply doesn't exist to WireGuard — no login prompt to attack, no password to guess. To the rest of the internet, the tunnel port is silent.
Every couple of minutes the peers redo a fresh handshake and derive brand-new session keys — forward secrecy, so even a future key compromise couldn't decrypt yesterday's traffic. That recent handshake doubles as the health signal: it means the artery is alive right now. Everything inside the tunnel is ChaCha20-Poly1305 — authenticated encryption that scrambles the data and proves it wasn't tampered with; the public internet carries the packets but sees only opaque ciphertext.
interface: wg0 # backbone
address: 198.51.100.1 # srv01 · coventry
peer: 198.51.100.2 # srv02 · maidenhead
key: (pinned, never leaves the box)
$ wg show wg0 latest-handshakes
peer srv02 · handshake 47s ago · ok
transport: chacha20-poly1305 · ciphertext onlyOnly four things cross wg0 — the nightly backup pull, the per-minute health probes, intranet-only services that exist nowhere public, and administration bound to the tunnel and loopback, never present on the public internet.
the exit + adguard
The exit tunnels, filtered on the way out
The backbone joins the servers. An exit tunnel does something different: a trusted device sends all of its traffic out through one of our servers, so to the wider internet it appears at that server, not on café Wi-Fi. That's why SRV02 sits in the middle of the map — exit gateway and backbone peer at once. The map shows the Maidenhead exit; Coventry runs one too.
And because a full-tunnel device leaves through one of our servers, the first step of almost every connection — the DNS lookup that turns a name into an address — is answered right there by AdGuard Home. Ad, tracker and telemetry domains are refused on the spot; legitimate names go upstream. The Maidenhead exit has no IPv6 route, so it withholds AAAA answers — nothing is handed an address it can't reach. The Coventry exit does carry IPv6. Filtering happens once, at the edge, for every device on the tunnel — not app by app. The resolver listens on the tunnel interface only; it is never reachable from the public internet.
interface: wg1 # exit
gateway: 203.0.113.1 # srv02 · maidenhead
device: 203.0.113.24 # full-tunnel client
resolver: 203.0.113.1:53 # adguard · tunnel only
routes: 0.0.0.0/0 # all traffic leaves herelive
Watch it breathe
The mesh isn't a diagram, it's a live thing — the monitoring site pings the primary through the tunnel every minute, and that reading is published. The WireGuard Mesh row on the status page is that probe, in real time.
probe: srv02 -> tunnel -> srv01
published: status page · live