Self-Healing Architecture

Privacy isn't a setting you turn on once. It's a live system. And live systems fail.

The moment a privacy router goes offline — for any reason, for any duration — your ISP sees raw traffic again. DNS queries hit their resolver. Your browsing patterns land in their logs. Your devices announce themselves to the open internet without a tunnel in the way. That exposure doesn't announce itself. There's no alarm. Your browsing just keeps working, because your home network keeps working. You'd never know unless you went looking.

We call this the exposure window: the gap between when something breaks and when automated recovery closes it. For most routers, that window is "until the owner notices." For a privacy router, that's not acceptable. So we built three layers to close it automatically.

This is the technical story of what we built, how it works, and what we learned.

What happens when the tunnel drops

A WireGuard tunnel is peer-to-peer. If the Pi loses contact with the exit node, it doesn't fail loudly — traffic just stops flowing through the encrypted path. The kernel's routing table still shows the tunnel interface as up. Applications have no idea anything changed. Your browser will eventually time out, but by then packets may have already leaked.

On the radio side, the situation is worse. A wireless AP restart takes seconds. A client reconnects. No one in the house noticed anything happened. Meanwhile, if the tunnel was down during that restart, a burst of traffic went out unprotected. The exposure window can be thirty seconds and leave no trace in any log a customer would ever see.

The answer isn't to pretend tunnels don't fail. They do. Hardware fails, packets get dropped, uplinks hiccup, power blinks. The answer is to know about failures faster than a human would notice them, and recover before the exposure window grows.

Layer 1 — The WireGuard tunnel watchdog

At the 3-minute mark, a stale handshake gets flagged and logged. This is the yellow zone — a brief gap in handshake timing is normal during network transitions, and triggering alerts at 3 minutes would generate noise. So this threshold writes a warning and keeps watching.

At 5 minutes dark, the watchdog considers the peer genuinely unreachable and sends an alert through our operations bridge. That notification reaches on-call in seconds. Separately, WireGuard's own keepalive mechanism begins attempting to re-establish the tunnel from the client side.

When handshakes resume, recovery is logged automatically with a timestamp, so the full outage duration is recorded even if no human saw the alert before recovery completed.

Why handshakes and not ping?

WireGuard is deliberately stateless from the OS's perspective — a "connected" WireGuard interface and a dead one look identical to the kernel's routing layer. Pinging the tunnel endpoint only tells you whether the IP is reachable at the network layer; it doesn't tell you whether the cryptographic session is alive. A handshake timestamp tells you the last time both parties agreed on session keys. That's the actual health signal.

Layer 2 — The compound-trigger dual-radio watchdog

Before this work, GhostPort devices ran a single radio. One radio means one point of failure, and a hard throughput ceiling determined by that radio's physical capabilities. Early operator testing hit that ceiling at around 40 Mbps on the 2.4 GHz band under normal home conditions. That's enough for most uses, but it's not where modern Wi-Fi 6 hardware should land.

The T-0228 upgrade brought in a second radio: a MediaTek MT7921 handling a dedicated 5 GHz AX channel. Both radios are bridged at Layer 2 — from a client's perspective, they appear as two SSIDs backed by the same network. Traffic can flow through either band based on client capability and signal quality.

The compound trigger is the key design choice. In dense residential environments, it's common for a single band to drop clients temporarily due to interference, channel congestion, or a neighbor's router stomping on the same channel. A single-radio trigger would fire watchdog recovery constantly in those environments, cycling the AP unnecessarily and introducing its own instability.

The compound trigger requires both radios to confirm failure before escalating. If the 5 GHz radio drops clients but the 2.4 GHz band is still active, the watchdog logs the single-radio anomaly but holds. If both radios go dark within the threshold window, the compound condition is satisfied and recovery fires. This means a genuine AP failure gets caught quickly, while transient single-band interference generates a log entry and nothing else.

The upload investigation (an honest update)

The 590 Mbps download number is real and reproducible. We've validated it across multiple test sessions. What we haven't solved yet: upload.

The ISP delivers roughly 200 Mbps upload measured directly from the test device, bypassing GhostPort entirely. Routed through GhostPort's 5 GHz path and the WireGuard tunnel, the same link caps at approximately 71 Mbps. That's about a third of what the pipe can carry.

The gap comes from multiple compounding factors — Wi-Fi half-duplex overhead, WireGuard's per-packet encryption and encapsulation, and some behavior in how the laptop's radio negotiates rates under sustained upload load. We've isolated it to those three layers but haven't fully attributed the split between them. We're continuing the investigation and will publish findings when we have them. The short version: if you're a GhostPort customer doing large uploads, you'll notice a throughput difference compared to your raw ISP speed. That's real, it's being worked on, and we'd rather tell you about it directly than have you find it on a speed test.

Layer 3 — Multi-region data plane failover

Why separate them? A control plane failure shouldn't affect active tunnels. And a data plane failure shouldn't require rebuilding your device's configuration. The two concerns are independent, so the infrastructure treats them independently.

The data plane runs in multiple US regions. When a regional relay has a problem — uplink issues, EC2 maintenance, infrastructure events — the operator can switch the exit node by issuing a single command from the Pi's management interface. The Pi rewrites the WireGuard endpoint and public key, and traffic begins flowing through the new region within seconds. No re-provisioning, no factory reset, no waiting on support.

We'll be direct about what this isn't yet: it's not fully automated. The region switch is one command, not zero commands. We've evaluated automatic failover based on tunnel health metrics, and we'll ship it when we're confident the decision logic is reliable enough that automatic switches don't create more problems than they solve. False automatic failovers during transient network events would be worse than a human-initiated switch on a confirmed outage. The architecture is ready for automation; the confidence threshold isn't there yet.

How the layers work together

The three layers are independent and complementary. A tunnel watchdog event doesn't automatically trigger a region switch, and a radio restart doesn't affect tunnel health. Each layer handles its own failure domain. Together, they cover the main causes of an exposure window:

• NormalWireGuard handshakes within 180s — tunnel healthy, radio healthy, no action
• t+3minHandshake goes stale — watchdog logs warning, begins close monitoring
• t+5minPeer dark — alert fires to ops, client-side keepalive attempts recovery
• RecoveryHandshake resumes — logged with outage duration, alert closed
• EscalationRecovery fails — operator switches data plane region in one command

The radio layer runs in parallel. A Wi-Fi restart takes seconds. By the time a radio failure would cause a tunnel stale event, the AP is already back up and clients have reconnected. The radio watchdog's job is to make that restart fast and deliberate rather than relying on hardware's own recovery behavior.

The net result: an exposure window that used to be "until someone notices" is now bounded to the watchdog polling interval plus the time to execute a recovery action. For most failure modes, that's under five minutes. For minor glitches, it's under thirty seconds.

What was happening while other routers were down

The reason we take exposure windows seriously is that the threats on the other side of them are concrete, documented, and ongoing. Here's a representative sample of what happened in 2026 while gaps in network privacy protection were open.

None of these incidents required the victim to do anything wrong. No bad passwords, no phishing clicks, no misconfigured apps. Some of them required nothing from the victim at all — just being a customer of a company that decided their data was an asset to be monetized or that had a security posture that didn't hold up.

The exposure window problem sits in the same category. The threat isn't hypothetical. The question is whether your infrastructure closes the window before the other side can use it.

What this means for you

If you're running GhostPort hardware, the three-layer watchdog stack is active automatically. You don't configure it. You don't maintain it. When a failure happens, the watchdog handles the response. If recovery requires a human action — a region switch, a hardware restart — operations is alerted before you'd notice anything was wrong.

If you're not running GhostPort hardware and you're relying on another privacy tool — a VPN app, a Pi-hole, a manual WireGuard setup on a spare router — ask yourself honestly: how long would a failure of that tool go undetected? Do you have a health monitor on it? Does it send you an alert if the tunnel drops? What's the recovery path if it does?

Most DIY privacy setups have no answer to those questions. That's not a criticism of the people who built them. It's a category of work that's easy to skip when you're focused on getting the privacy function right. But self-healing is part of getting it right.