Tools: Tailscale Deep Dive: Why Developers Are Ditching Traditional VPNs

Tools: Tailscale Deep Dive: Why Developers Are Ditching Traditional VPNs

The Foundation: WireGuard

What Tailscale Adds on Top of WireGuard

1. Coordination Server (The Control Plane)

2. NAT Traversal (The Hard Part)

3. DERP Relay Servers (The Fallback)

Zero Trust: Not Just a Buzzword

Why Developers Love Tailscale (Speaking from Experience)

Tailscale vs. Traditional VPNs: The Architecture Difference

When NOT to Use Tailscale Every developer I know who tries Tailscale has the same reaction: "Wait, that's it? It just... works?" That reaction is the entire product thesis. VPN setup has been painful for decades — configuring OpenVPN, managing certificates, debugging NAT traversal, opening firewall ports. Tailscale makes it feel like connecting to WiFi. But the engineering underneath is anything but simple. Here's what's actually happening when you install Tailscale and everything "just works." Tailscale is built on WireGuard, and understanding WireGuard is essential to understanding why Tailscale performs so well. WireGuard is a VPN protocol created by Jason Donenfeld. Compared to its predecessors: The "fixed cryptography" decision is the most important design choice. OpenVPN and IPsec let you configure cipher suites, which means every deployment is a snowflake, and misconfigurations create vulnerabilities. WireGuard uses exactly one cryptographic construction — no negotiation, no downgrade attacks, no configuration. The result: WireGuard achieves 3-4x the throughput of OpenVPN on the same hardware, with sub-100ms connection establishment. It's so fast that you can have it running permanently without noticing any overhead. WireGuard alone is a point-to-point VPN protocol. You need to manually configure each peer's public key, IP address, and endpoint. For two machines, this is fine. For 20 machines, it's a spreadsheet. For 200 machines, it's a full-time job. Tailscale adds three critical layers: Tailscale runs a coordination server that manages the mesh network. When you install Tailscale on a device: Key point: The coordination server never sees your traffic. It only distributes public keys and endpoint information — the same role a DNS server plays, but for WireGuard peers. All actual data flows through direct, encrypted WireGuard tunnels. This is the fundamental difference from traditional VPNs: there's no central server that all traffic routes through. It's a mesh network where every device connects directly to every other device. Most devices are behind NAT — your laptop at a coffee shop, your home server behind a consumer router, your phone on a carrier network. NAT was designed to prevent direct incoming connections, which is exactly what a mesh VPN needs. Tailscale's NAT traversal uses a technique called STUN (Session Traversal Utilities for NAT): This "UDP hole punching" works for about 94% of NAT configurations. For the remaining 6% (symmetric NAT, carrier-grade NAT, particularly aggressive firewalls), Tailscale has a fallback. When direct connection fails, traffic routes through Tailscale's DERP (Designated Encrypted Relay for Packets) servers. These are relay servers deployed globally — currently in 20+ cities worldwide. Critically, DERP relays see only encrypted WireGuard traffic. They relay packets but cannot decrypt them. It's like a postal service that carries sealed envelopes — they know the source and destination, but not the contents. DERP is designed as a fallback, not the primary path. Tailscale aggressively tries to establish direct connections, and the client continuously re-attempts direct paths even while using DERP. In practice: Traditional VPNs create a "trusted zone" — once you're connected, you can access everything on the network. This is the castle-and-moat model, and it's why VPN credentials are such a high-value target for attackers. Tailscale's ACL (Access Control List) system operates differently. You define rules about which devices can access which services: A developer can reach port 443 (HTTPS) on production servers but nothing else. An ops engineer gets full access. Compromising a developer's laptop doesn't give an attacker access to SSH on production — the network-level access simply doesn't exist. I use Tailscale to connect a Chromebook (ARM64, always-on development machine) to a desktop with an RTX 5090 (GPU inference server). Here's what the experience is actually like: Setup took 3 minutes. Install on both machines, log in with the same account, done. No port forwarding on the router. No dynamic DNS. No SSH tunnel management. SSH just works. ssh [email protected] connects to my desktop whether I'm at home, at a coffee shop, or on mobile data. The Tailscale IP never changes regardless of the physical network. It's invisible. Tailscale runs as a background service and uses essentially zero CPU. I forget it's there until I need to access a machine remotely, at which point it's just... available. MagicDNS. Instead of remembering 100.109.56.59, I can use desktop.tail-net.ts.net. Tailscale runs a local DNS resolver that maps machine names to Tailscale IPs. The mesh approach means: no bandwidth bottleneck at a central server, latency is minimized (one hop instead of two), and there's no single point of failure. If the coordination server goes down, existing connections continue working — they just can't add new peers until it comes back. Tailscale's client is open source (BSD 3-Clause license) and available on GitHub. The coordination server is proprietary, but there's an open-source alternative called Headscale that you can self-host. If you want the Tailscale architecture without depending on Tailscale the company, Headscale gives you that option. This is a smart business model: the client being open source means security researchers can audit it, and the self-hostable alternative means large organizations aren't locked in. Tailscale's actual value proposition is the managed coordination server, DERP infrastructure, and the admin dashboard — operational overhead that most teams would rather pay for than maintain. Tailscale isn't always the answer: For everything else — developer access to servers, IoT device management, remote work infrastructure, connecting cloud and on-prem resources — Tailscale is the obvious choice. It's one of those tools where the main regret is not adopting it sooner. I'm a semi-retired patent lawyer in Japan who started coding in December 2024. I build AI-powered search tools including PatentLLM (3.5M US patent search engine) and various local-LLM applications on a single RTX 5090. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Code Block

Copy

{ "acls": [ {"action": "accept", "src": ["group:dev"], "dst": ["tag:production:443"]}, {"action": "accept", "src": ["group:ops"], "dst": ["tag:production:*"]} ] } { "acls": [ {"action": "accept", "src": ["group:dev"], "dst": ["tag:production:443"]}, {"action": "accept", "src": ["group:ops"], "dst": ["tag:production:*"]} ] } { "acls": [ {"action": "accept", "src": ["group:dev"], "dst": ["tag:production:443"]}, {"action": "accept", "src": ["group:ops"], "dst": ["tag:production:*"]} ] } ssh [email protected] 100.109.56.59 desktop.tail-net.ts.net Traditional VPN (Hub-and-Spoke): Device A --> VPN Server --> Device B Device C --> VPN Server --> Device D (All traffic routes through one server = bottleneck + single point of failure) Tailscale (Mesh): Device A <--> Device B (direct) Device A <--> Device C (direct) Device B <--> Device D (direct) (Traffic goes directly between devices = no bottleneck, no SPOF) Traditional VPN (Hub-and-Spoke): Device A --> VPN Server --> Device B Device C --> VPN Server --> Device D (All traffic routes through one server = bottleneck + single point of failure) Tailscale (Mesh): Device A <--> Device B (direct) Device A <--> Device C (direct) Device B <--> Device D (direct) (Traffic goes directly between devices = no bottleneck, no SPOF) Traditional VPN (Hub-and-Spoke): Device A --> VPN Server --> Device B Device C --> VPN Server --> Device D (All traffic routes through one server = bottleneck + single point of failure) Tailscale (Mesh): Device A <--> Device B (direct) Device A <--> Device C (direct) Device B <--> Device D (direct) (Traffic goes directly between devices = no bottleneck, no SPOF) - The device generates a WireGuard keypair - It registers the public key with the coordination server - The coordination server distributes peer information to all other devices in your network - Each device establishes direct WireGuard tunnels to every other device - Both devices send packets to a STUN server to discover their public IP and port mapping - The coordination server shares these discovered endpoints - Both devices simultaneously send packets to each other's discovered endpoints - NAT routers on both sides see the outgoing packets and create firewall holes - Direct connection established - ~94% of connections are direct (peer-to-peer) - ~5% start on DERP and upgrade to direct within seconds - ~1% stay on DERP for the duration (truly hostile NAT environments) - High-throughput data transfer: WireGuard adds encryption overhead. For terabytes of data transfer between machines on the same LAN, a direct connection is faster. - Network-level isolation requirements: Some compliance frameworks require physically separate networks. Tailscale's logical separation might not satisfy auditors. - Extremely latency-sensitive applications: The NAT traversal and occasional DERP relay add milliseconds. For sub-millisecond requirements (HFT, real-time audio), dedicated infrastructure is better.