I paused the Alienware in eero, expected it to go dark, and then reached it anyway.
That's the whole thing. It took me longer than I'd like to admit to work out what was going on.
The Setup
The Alienware runs a self-hosted transcription service: Speaches on an RTX 2080, using faster-whisper-large-v3. I reach it from my Mac over Tailscale.
I needed to run some tests that required cutting the machine off from the open Internet. The eero app has a "Pause" button. I hit it, assumed the machine was effectively offline, and moved on.
My Mac then sent a job to the transcription service. It worked.
So either the pause didn't actually do anything, or "paused" didn't mean what I thought it meant.
Wait, How Is That Possible
My first guess was that the pause just didn't stick. Maybe it's best-effort and something slipped through.
So I checked. On the Alienware, tailscale netcheck came back with this:
- UDP: false
- No normal IPv4 address found
- CaptivePortal: true
- No direct connection established
That CaptivePortal flag was the tell. The machine wasn't offline. Something was intercepting outbound traffic and redirecting it, the way airport Wi-Fi does before you log in. Not blocking cleanly. Redirecting.
I ran curl against Google and api.ipify from the Alienware to double-check. Both timed out. No usable general Internet there.
Then I ran tailscale ping from my Mac, targeting the Alienware. The reply came back, but the path wasn't direct LAN. It was going through a DERP relay called "headscale."
DERP is Tailscale's fallback relay. When two machines can't connect directly (NAT, firewalls, or in this case a router that's eaten the normal IP stack), traffic bounces through a relay server instead of going machine-to-machine. Slower, but it works. The Alienware couldn't open new outbound connections. The relay path that was already up before I hit pause just... kept going.
That's the mechanism, near as I can tell. The eero pause blocked normal web traffic. It didn't tear down a relay session already in flight.
Testing It Properly
I wanted numbers, not vibes. So I tested an external financial data API (EODHD) from the Alienware, before and after pausing. Eight endpoints: /eod/AAPL.US, /intraday/AAPL.US, /exchange-symbol-list/US, /real-time/AAPL.US, /search/AAPL, /div/AAPL.US, /splits/AAPL.US, and /calendar/earnings.
| Observation | Unpaused | Paused |
|---|---|---|
| EODHD API (8 endpoints) | 8/8 worked | 8/8 failed (http_code 000) |
| curl TLS state (EODHD) | Normal | Hostname mismatch for eodhistoricaldata.com |
| Google / api.ipify reachability | Reachable | Timed out |
| Tailscale reachable from Mac | Yes | Yes |
| Tailscale path | Not checked | DERP relay (headscale) |
| CaptivePortal flag (netcheck) | False | True |
The TLS mismatch is the most telling thing in that table. A hostname mismatch on eodhistoricaldata.com means something in the path is presenting a different certificate than the one that host should serve. A real block gives you a timeout or a connection refused. A cert mismatch means something is answering, and it isn't the server you asked for.
That's not offline. That's a captive portal.
What I Didn't Test
I didn't kill Tailscale on the Alienware and try to reconnect from scratch while it was paused. Couldn't justify it: the transcription path was in use and I wasn't about to break a working relay to run experiments on a machine I depend on. So I genuinely don't know whether a fresh Tailscale tunnel would establish from a paused state. My guess is no, since the initial handshake needs outbound UDP and tailscale netcheck reported that as false. But I haven't confirmed it.
What I can say is that the existing relay path survived the pause. Anything that had connectivity before the pause hit had a decent shot at staying reachable over DERP, as long as nothing on either end reset the session.
The Actual Lesson
A "Pause" button is a label on a network control, not a guarantee of isolation.
In this case, pausing blocked normal HTTPS and API traffic but did not terminate an established overlay tunnel. The Alienware had no usable general Internet, but it still had enough of a network path for Tailscale relay connectivity, and everything behind that relay was still reachable.
If you depend on a service, test the actual dependency path. Not what the UI label says. Not what you assume "paused" means.
A pause button is not an air gap. An air gap means physically pulling a cable or killing a radio, not tapping a button in a phone app.
And if you're trying to simulate network loss for a Tailscale-backed service, the eero pause button won't get you there. You've simulated "can't reach the open Internet" while leaving the overlay intact. Those are very different failure modes.
Results will vary with your router, your Tailscale config, and whether you have DERP relays in reach. But the principle holds: test the path, not the label.
I'm some guy on the internet who paused a router and spent an hour figuring out why his transcription service still worked. Don't architect production systems off my blog.
Enjoyed this post?
Get notified when I publish something new. No spam, unsubscribe anytime.