A government blocks a VPN with a one-line SNI rule. The fix is a custom relay on port 443. Tailscale could make this trivial for millions — but they haven't.
There's a lot of confusion about how Myanmar actually blocks Tailscale. Some say it's DNS poisoning. Others claim the coordination server is blackholed. A few insist the WireGuard protocol itself is detected and dropped.
None of that is correct. The block is simpler and stupider than most people think — and because of that, the counter is simpler too. This matters because Tailscale is genuinely important networking middleware. It's used by journalists, remote workers, distributed teams, and anyone who needs secure machine-to-machine connectivity. Blocking it isn't just censorship theater — it disrupts legitimate infrastructure.
This time, I worked on the problem with the support of a capable agentic AI. I trained its substantial capacity for research and systematic debugging on the task, and together we burned through the misconceptions, tested the actual failure points, and built a working counter. What follows is what we found.
Myanmar operates deep packet inspection (DPI) at the ISP level. But they're not doing anything sophisticated. They're running what amounts to a single SNI filter:
Block TLS ClientHello where SNI matches *.tailscale.com
That's it. One wildcard rule.
This hits Tailscale in three places:
| Component | Blocked? | Why |
|---|---|---|
Coordination server (controlplane.tailscale.com ) |
||
| No | Different SNI, survived past block waves | |
Default DERP relays (derpN.tailscale.com ) |
||
| Yes | ||
| All match the wildcard | ||
| Direct WireGuard (UDP 41641) | Sometimes | Symmetric NAT without relay = dead |
When all DERP relays are unreachable, nodes behind carrier-grade NAT in Myanmar have no path to each other. The mesh collapses. Every node is an island.
The cruel part: the coordination server still works. The client can see its peers. It knows they exist. It just can't reach them. It's like being locked in a glass box — you can see everyone, but you can't touch them.
The agent and I verified this step by step: DNS resolution from inside Myanmar, successful — the IPs resolve fine. TCP handshake to the coordination server, successful — it's not IP-blocked. TLS ClientHello to derpN.tailscale.com
, dropped at the SNI. TLS ClientHello to a custom domain on the same VPS, passed cleanly. The filter is exactly one rule deep.
Peer Relays (NAT-PMP/PCP). Tailscale's own documentation suggests custom DERP isn't needed if you set up a peer relay. But peer relays use raw UDP on arbitrary ports. DPI boxes flag non-standard UDP instantly. Port 40000 looks nothing like web traffic.
Waiting for it to get better. Myanmar's filtering isn't going away. It's getting more aggressive, not less.
Commercial VPNs. Most are blocked at the same DPI layer. The ones that work today won't work tomorrow.
The insight is simple: TLS on port 443 looks like HTTPS to a DPI box. Every website uses it. Blocking it would break the internet.
A custom DERP relay listening on TCP 443, with a valid Let's Encrypt certificate on a domain you control, is indistinguishable from a web server. The SNI matches your domain, not *.tailscale.com
. The traffic is standard TLS. The DPI box shrugs and passes it through.
You can deploy this in 30 minutes:
cmd/derper
on a VPS outside the censored countryBut here's where Tailscale's product decision bites you.
You can add custom DERPs to your tailnet. But you cannot remove the default ones.
This isn't a technical limitation. Tailscale's admin console simply doesn't expose DERP controls. The ACL syntax has some undocumented, CLI-only support for DERP filtering — but it's fragile, barely documented, and not something a normal user would discover. The product team made a choice: DERP is infrastructure, not configuration. You don't get to touch it.
The consequence: your client will try the blocked default DERPs first. Each attempt times out after 5-10 seconds. Only after cycling through every blocked relay does it fall back to your custom one.
The result: Tailscale does connect eventually. But every connection attempt has a 20-40 second penalty. Every reconnect. Every network change. Every time your phone switches from WiFi to cellular.
It's functional but miserable — like a car that stalls three times before starting.
Headscale is the open-source implementation of the Tailscale coordination server. Self-hosting it gives you one thing Tailscale's SaaS doesn't: control over the DERP map.
With Headscale, you can:
No timeouts. No cycling through blocked relays. Your custom DERP is the only option, so clients go there immediately.
The deployment takes an afternoon:
VPS in Singapore
├── nginx :443 (SNI router)
│ ├── derp.yourdomain.com → derper container
│ └── hs.yourdomain.com → Caddy → Headscale
├── Headscale (coordination server)
├── Custom DERP relay (port 443, LE cert)
└── Headplane (web UI for management)
On the client side, joining is one command:
tailscale up --login-server=https://hs.yourdomain.com --authkey=YOUR_KEY
Add a Tailscale node as an exit node on the Singapore VPS, and every device on the tailnet can route its internet traffic through Singapore — free of Myanmar's filtering.
Total cost: one $5/month VPS.
If you're reading this and planning to deploy Headscale, consider forking or mirroring the repository before you need it. The *.tailscale.com
wildcard block works because it's easy. There's nothing stopping the same filter from being extended to github.com/juanfont/headscale
— and after this article, that's a real possibility. Install from an alternate source. Host the binaries on your own domain. The pattern you use to beat the DERP block is the same pattern that keeps the tools themselves available.
Tailscale's engineering is excellent. The product decisions around DERP management are the problem.
Three changes would make Tailscale censorship-resistant for millions of people:
This is the single highest-impact change. Right now the admin console has no DERP controls at all. Adding a "DERP relays" section where users can disable defaults and add customs would solve the timeout problem without self-hosting anything.
The ACL syntax already partially supports this — but it's undocumented, CLI-only, and fragile. Make it a first-class feature.
One toggle that:
This isn't hypothetical. Iran, China, Russia, Turkey, and Myanmar all block Tailscale infrastructure. That's hundreds of millions of people who can't use the product because of a single wildcard SNI rule.
Tailscale's documentation on censorship circumvention is scattered across forum posts and GitHub issues. A single page — "Using Tailscale in Censored Networks" — would tell users what they need before they spend hours debugging timeouts.
*.tailscale.com
is a convenient wildcard for DPI boxes. Custom domains break that pattern.controlplane.tailscale.com
was reachable from Myanmar when we tested. This can change. Self-hosting Headscale removes the last dependency on tailscale.com
.Written with Hermes Agent. Follow me on X: @MariaTanBoBo