Tailscale: A Zero-Config Mesh VPN for People Who Hate Networking

Setting up a traditional VPN is one of those tasks that looks simple in the brochure and turns into a weekend of misery in practice. You allocate subnets, open ports on a router you may not control, wrestle with NAT, distribute keys, and then discover that two clients behind the same carrier-grade NAT cannot talk to each other no matter how politely you ask. Tailscale exists because someone got tired of all that. It promises a private network where every device can reach every other device, with essentially no configuration, and for the most part it delivers.

1 The pain Tailscale is solving

Classic VPNs follow a hub-and-spoke model. Every client dials into a central concentrator, and all traffic flows through that single chokepoint. That design has obvious downsides: the hub is a bottleneck, a single point of failure, and a juicy target. Worse, getting clients to connect at all means dealing with the modern internet’s least pleasant feature, network address translation. Most devices sit behind at least one layer of NAT, sometimes several, with no stable public address and no inbound ports.

The result is a familiar checklist of suffering: port-forwarding rules, dynamic DNS, firewall exceptions, and certificate management. Get one of them wrong and nothing works, usually with an error message that tells you nothing. Tailscale’s pitch is that you should never have to think about any of this.

2 What Tailscale actually is

Under the bonnet, Tailscale is WireGuard. The data plane, the part that actually encrypts and moves your packets, is the same fast, modern, audited protocol covered in our WireGuard guide. What Tailscale adds is the part WireGuard deliberately leaves out: coordination.

Raw WireGuard expects you to manually tell each peer about every other peer, including its public key and current endpoint. Tailscale runs a coordination server that handles all of this for you. When a device joins your network (a “tailnet”), it authenticates against an identity provider, registers its public key, and learns about every other device it is allowed to reach. Crucially, the coordination server only exchanges metadata, the public keys and connection hints. Your actual traffic is encrypted end-to-end between devices and, wherever possible, flows directly peer-to-peer.

That last point is the clever bit. Tailscale performs NAT traversal automatically, using STUN-style techniques and a set of relay servers called DERP. When two devices can establish a direct connection, they do, and the relays drop out of the path. When they genuinely cannot, the encrypted traffic falls back to a relay so the connection still works. You never configure any of it.

3 Installing and connecting

On most Linux distributions, installation is a single script, and bringing a machine online is a single command:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

That tailscale up prints a URL. Open it, sign in with your identity provider, and the device joins your tailnet. That is genuinely the whole setup. To check the state of your network:

tailscale status
tailscale ip -4

The first lists every device, its address, and whether the connection is direct or relayed. The second prints this machine’s stable Tailscale address.

4 Stable private IPs and MagicDNS

Every device gets an address from the 100.64.0.0/10 range, the block reserved for carrier-grade NAT, which Tailscale repurposes because it never appears on the public internet. The important property is that these addresses are stable. A laptop keeps the same 100.x.y.z whether it is on home broadband, a café’s Wi-Fi, or tethered to a phone in another country. You can hard-code that address into a config file and it will keep working.

Memorising addresses is still tedious, so Tailscale offers MagicDNS. Enable it and every device becomes reachable by its hostname:

ssh user@my-laptop
curl http://nas:8080

No /etc/hosts editing, no internal DNS server to run. The names resolve only inside your tailnet.

5 ACLs, sharing, exit nodes and subnet routers

By default every device in a tailnet can reach every other device. For anything beyond a personal setup you will want to tighten that with access control lists, expressed as a policy document. A simple rule might let a group of developers reach a database host on one port and nothing else:

{
  "acls": [
    { "action": "accept", "src": ["group:dev"], "dst": ["tag:db:5432"] }
  ]
}

Tags and groups let you reason about roles rather than individual machines, which scales far better than a pile of IP-based firewall rules. You can also share a single device with another user’s tailnet without merging the two networks, which is handy for contractors or cross-team access.

Two features extend Tailscale beyond device-to-device links. An exit node routes all of a device’s internet traffic through another node, turning any machine into a privacy gateway or a way to appear to be in a particular location:

sudo tailscale up --advertise-exit-node     # on the gateway
sudo tailscale up --exit-node=100.x.y.z      # on the client

A subnet router advertises a whole local network into the tailnet, so a single Tailscale-connected box can expose printers, IoT devices, or legacy servers that cannot run the client themselves:

sudo tailscale up --advertise-routes=192.168.1.0/24

6 How it compares to raw WireGuard

If you have already read our WireGuard guide, the trade-off is clear. Raw WireGuard gives you total control and zero dependencies. You own every key, every endpoint, every line of config, and nothing phones home. The cost is that you own all of that, including the NAT traversal you now have to solve yourself, the peer list you must update by hand whenever the topology changes, and the key distribution.

Tailscale trades a slice of that control for enormous convenience. The encryption is identical; the difference is who manages the metadata. For a static server-to-server tunnel, raw WireGuard is lean and perfect. For a fleet of laptops, phones, and servers that roam across networks and change constantly, Tailscale’s automatic coordination is the difference between a feature you use and a chore you avoid.

7 Self-hosting with Headscale

The honest catch is that the default Tailscale setup relies on a coordination server you do not run. The data is end-to-end encrypted and the server never sees it, but the control plane is still someone else’s infrastructure, and for some organisations that is a non-starter.

Headscale is an open-source reimplementation of the Tailscale coordination server. You run it yourself, point the standard clients at it, and keep the entire control plane in-house:

tailscale up --login-server=https://headscale.example.com

You lose the polished admin console and some commercial features, and you take on the job of keeping the server up, but you gain full sovereignty over your network’s coordination. For a homelab or a privacy-conscious team, it is an excellent middle ground.

8 The trade-offs

Tailscale is not magic, and it is worth naming what you give up. You depend on an external coordination service for the default experience, which means a third party gates whether new connections can form, even though it cannot read your traffic. There is a relay fallback that, in awkward network conditions, can add latency compared with a tuned direct tunnel. And like any tool that makes something easy, it can encourage sprawl: a flat network where everything can reach everything unless you take the time to write ACLs.

None of that undermines the core proposition. For the overwhelmingly common case of wanting your devices on one private network without a networking degree, Tailscale is close to the platonic ideal. Install it, run tailscale up, and the thing that used to eat a weekend is done before your coffee goes cold.