Tailscale: A Zero-Config Mesh VPN for People Who Hate Networking
Every device on one private network, no firewall rules required
Contents
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.
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.
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 I use for a hand-rolled tunnel in The Tunnel Home: WireGuard homelab access. 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.
Installing and connecting
On most Linux distributions, installation is a single script, and bringing a machine online is a single command:
| |
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:
| |
The first lists every device, its address, and whether the connection is direct or relayed. The second prints this machine’s stable Tailscale address.
Stable private IPs and MagicDNS
Every device gets an address from the CGNAT range (the 100.64/10 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 Tailscale address 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, which is a small miracle if you have ever tried to script against a machine that changes IP every time it moves network.
Memorising addresses is still tedious, so Tailscale offers MagicDNS. Enable it and every device becomes reachable by its hostname:
| |
No /etc/hosts editing, no internal DNS server to run. The names resolve only inside your tailnet.
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:
| |
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:
| |
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:
| |
Serving and sharing services
Two features I reach for constantly turn a private mesh into a genuinely convenient way to publish things. tailscale serve puts an HTTPS front end, with a valid certificate, in front of a local port — reachable only inside your tailnet, no reverse proxy to configure:
| |
That gives you a real TLS URL for a service running on localhost, which is a small luxury the first time you skip the certificate dance. Its riskier sibling, tailscale funnel, exposes the same service to the public internet through Tailscale’s relays — useful for a webhook receiver, but a thing to enable deliberately and never by reflex, because you’ve just punched a hole from the open internet into your machine.
The other quiet win is tailscale ssh. Enable it and SSH access between tailnet nodes is authenticated and authorised by your tailnet identity and ACLs rather than by scattered authorized_keys files. Key rotation, offboarding a user, and access logging all move from “a chore you forget” to “a policy line”, which for a small team is worth a surprising amount.
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.
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:
| |
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. If self-hosting the control plane is a firm requirement rather than a nice-to-have, it is worth weighing Headscale against a project built for self-hosting from the start — I put the two head to head in Tailscale vs Netbird.
Troubleshooting: when the mesh misbehaves
For all its polish, Tailscale still runs on the real internet, and the real internet is hostile. The failures you’ll actually hit:
Peers connect but only via a relay. Run tailscale status and look for relay instead of direct next to a peer. Relayed connections work but add latency, because traffic is bouncing through a DERP server rather than going point to point. The usual culprit is a firewall blocking the UDP that NAT traversal needs. Tailscale prefers UDP; if your network drops it, direct connections can’t form. Check with tailscale netcheck, which reports your NAT type, whether UDP is working, and your nearest relay. A “hard NAT” or a firewall that blocks outbound UDP is the thing to fix.
MagicDNS names don’t resolve. MagicDNS works by installing Tailscale as your system resolver. If another tool (a corporate VPN client, a heavy-handed resolv.conf manager, or systemd-resolved misconfigured) fights for control of DNS, names stop resolving even though tailscale status looks healthy. Confirm with tailscale ip -4 my-laptop; if the IP resolves but the name doesn’t, it’s a DNS-ownership fight, not a Tailscale fault.
A subnet router advertises routes but clients can’t reach the subnet. Advertising is only half the job — the routes must also be approved in the admin console (or auto-approved via ACL), and the router box must have IP forwarding enabled in the kernel (net.ipv4.ip_forward=1). Forget either and the route is offered but never used.
Everything worked, then a key expired. By default, device keys expire on a schedule and the device drops off the tailnet until you re-authenticate. For an unattended server this is a nasty surprise at 3am. Disable key expiry for that specific machine in the admin console, or use an auth key with the right lifetime.
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.
Related Content
