The fastest way to lose sleep as a sysadmin is to forward UDP 51820 to a server with a publicly routable IP, then forget about it. The fastest way to lose a weekend is to manually distribute WireGuard configs to twenty laptops scattered across hotel Wi-Fi, mobile hotspots, and a relative’s CGNAT-trapped home network. Both problems describe the same gap: WireGuard is a brilliant tunnel protocol with no opinions about how peers find each other, and that gap is exactly what Tailscale and Headscale exist to fill.
The three names are often listed as alternatives, but they sit at different layers. WireGuard is the cryptographic engine. Tailscale is a managed mesh product built on top of it. Headscale is an open-source reimplementation of Tailscale’s coordination server that lets you run that mesh without sending control-plane metadata to a SaaS vendor. Choosing between them is less about features and more about how much operational overhead — and how much vendor dependency — you are willing to absorb to avoid opening inbound ports.
What Each Tool Actually Does
WireGuard is a VPN protocol and a Linux kernel module. The codebase is roughly 4,000 lines, small enough that one researcher can audit it in a day, compared with OpenVPN’s 100,000-plus. It uses a fixed cryptographic suite — Curve25519, ChaCha20-Poly1305, BLAKE2s, SipHash — with no cipher negotiation, which means it cannot be downgraded or misconfigured into weakness. Authentication is public key only: no usernames, no certificates, no PKI. To connect two devices you generate keypairs on each, write a config naming the peer’s public key and endpoint, and bring up the interface with wg-quick. That is the entire model.
The model breaks down precisely where most modern networks live. WireGuard requires at least one peer to have a publicly reachable endpoint. Behind symmetric NAT, CGNAT, or a hotel router, it will not establish a connection without external help. There is no built-in NAT traversal, no peer discovery, no key rotation, and no concept of identity beyond “I have your public key.” For two laptops and a server, this is fine. For twenty devices and five users, key management becomes the job.
Tailscale is a commercial product that wraps WireGuard with a coordination layer. Devices authenticate to Tailscale’s control plane through an identity provider — Google, Microsoft, GitHub, Okta, your SSO of choice — and the control plane brokers public key exchange between authorized peers. Once keys are exchanged, traffic flows directly between devices over a standard WireGuard tunnel. The control plane never sees your data; it only sees who is allowed to talk to whom. NAT traversal is handled automatically using STUN-style hole punching, with fallback to Tailscale’s DERP relay servers when a direct path cannot be established. The relays carry only encrypted WireGuard packets and cannot decrypt them.
Headscale is an open-source, self-hosted implementation of Tailscale’s coordination server, maintained by juanfont and a small team of contributors. One of the active maintainers is a Tailscale employee who contributes during work hours, but the project is independent. The official Tailscale clients on every platform speak to Headscale exactly as they would to Tailscale’s hosted control plane. You get the mesh, the ACLs, MagicDNS, exit nodes, and SSO integration — running on hardware you own. The current release line as of this writing is 0.28.x, with 0.29.0 in active development; recent changes include extensive ACL compatibility work to match Tailscale’s reference behavior and a new SSH check action for OIDC-prompted access.
How NAT Traversal Works Without Open Ports
The phrase “without exposing ports” is the entire point. Traditional VPN gateways — OpenVPN, IPsec, even raw WireGuard — assume one side has a publicly reachable IP and an open inbound port. That assumption fails in three increasingly common scenarios: residential CGNAT (your ISP shares one IPv4 address across many customers), mobile carriers, and corporate guest networks that block inbound connections entirely.
Tailscale and Headscale solve this with a two-stage trick. First, both clients reach out to the coordination server over an outbound HTTPS connection — outbound is almost always allowed. The coordinator hands each client the other’s public key, current candidate endpoints, and DERP relay assignments. Second, the clients attempt simultaneous outbound UDP connections to each other’s apparent public addresses. If both NATs cooperate, a direct WireGuard tunnel forms and the coordinator drops out of the data path. If they don’t — symmetric NAT on both sides is the classic blocker — traffic falls back to a DERP relay, which forwards encrypted WireGuard packets without being able to read them.
Raw WireGuard has none of this. The protocol’s PersistentKeepalive option can hold a tunnel open through stateful NAT once it’s established, but establishing it from behind symmetric NAT on both ends requires external coordination — exactly what Tailscale and Headscale provide. For homelabbers behind Starlink, 5G internet, or any CGNAT setup, raw WireGuard is effectively unusable without a publicly reachable jump host. This is the single biggest reason teams adopt the coordinated tools.
Performance: The 3% Question
WireGuard’s performance ceiling is high. On Linux, the kernel module routes packets directly through the network stack with negligible CPU overhead, saturating gigabit links on modest hardware. Tailscale and Headscale clients on Linux currently use a userspace WireGuard implementation, which adds measurable but small overhead — independent benchmarks consistently put the throughput gap at under 3 percent on direct peer-to-peer connections. Latency on direct paths is essentially identical because the data path is the same WireGuard tunnel either way.
The gap widens when traffic falls back to a DERP relay. Relayed traffic adds the round-trip time to whichever DERP server is geographically nearest both peers, and throughput is constrained by the relay’s capacity. For interactive SSH or low-bandwidth HTTPS this is usually invisible. For bulk file transfer or video streaming over a relayed connection, the difference is noticeable. The good news is that direct connections succeed in roughly 95 percent of real-world cases once both endpoints have NAT traversal working.
For the Linux kernel module purists: a kernel-mode Tailscale client has been a long-running request on the project tracker, but as of the current release the userspace daemon is what ships. If you genuinely need every last megabit on Linux and you control both endpoints’ network paths, raw WireGuard is faster. For everyone else, the performance argument is mostly theoretical.
Access Control and Identity
WireGuard’s access model is binary: you either have a peer’s public key in your config or you don’t. There are no users, no groups, no role-based rules. You can layer the operating system firewall on top — iptables, nftables, pf — to restrict which subnets a peer can reach, and many production deployments do exactly this. It works, but it scales linearly with team size and doesn’t survive a key rotation cleanly.
Tailscale’s ACL system is the feature most teams actually pay for. Policies are written in a HuJSON file describing which users, groups, and tags can reach which destinations on which ports. A typical rule might allow group:engineering to SSH to anything tagged tag:dev-server, while group:contractors only reaches a single internal web app on port 443. Identity comes from your SSO provider, so removing someone from a Google Workspace group or Okta application revokes their tailnet access on the next token refresh. Tags are attached to devices at registration and can be reassigned via CLI without rotating keys.
Headscale implements the same ACL grammar with steadily improving fidelity. The 0.29.0 development branch includes substantial work — driven by systematic test generation against the official Tailscale clients and SaaS — to align packet filter behavior with Tailscale’s reference implementation, including changes to how wildcard sources resolve and how ICMP protocols are matched. Recent versions also added support for SSH check actions, which prompt the user for OIDC re-authentication before granting an SSH session. Not every ACL feature reaches Headscale on day one; if you adopt Headscale, plan to track the upstream changelog.
Key Commands and Setup Reference
The day-to-day surface of each tool is small enough to summarize. WireGuard work happens through wg and wg-quick. Tailscale and Headscale clients share the tailscale CLI; Headscale operators run an additional headscale binary on the coordination server.
A minimum viable Headscale install is a Debian 12 or Ubuntu 22.04+ VPS with the official .deb package, a config.yaml pointing at your domain and a Postgres or SQLite backend, and a reverse proxy terminating TLS in front of port 8080. From there you create a user, mint a pre-auth key, and run tailscale up --login-server=https://your.domain --authkey=<key> on each device. The whole flow is 15 minutes if you’ve done it before, an evening if you haven’t.
Pitfalls and Operational Limits
The Tailscale-is-just-a-better-WireGuard framing hides a few sharp edges. Tailscale’s free tier is generous — 3 users and 100 devices — but the moment you need more than three named users or you want commercial support, you’re on a paid plan. Pricing scales per user, and procurement at larger organizations sometimes balks at a SaaS networking dependency for reasons that have more to do with vendor risk policy than with anything Tailscale is doing wrong.
Headscale’s costs are different but not zero. The binary is free, the operational burden isn’t. Someone owns uptime, upgrades, OIDC integration, certificate rotation, and database backups. The project explicitly does not support running Headscale behind a reverse proxy with the official documentation’s blessing — you can do it, many people do, but you’re outside the supported configuration if something breaks. Database migrations have also tightened: as of recent releases, you cannot skip minor versions when upgrading, and direct upgrades from anything before 0.25.0 are blocked entirely. Plan upgrade windows accordingly.
Raw WireGuard’s pitfall is the one everyone underestimates: key rotation across a real fleet. Generating a new keypair for one peer means updating the config on every other peer that talks to it, then reloading. Tools like wg-easy smooth the UI, but the underlying model is still “edit config, restart interface.” Teams that grow past about ten devices and three administrators almost always migrate to something with a control plane.
The DERP relay assumption deserves its own caveat. Tailscale’s public DERP servers are free and globally distributed, and they cannot decrypt your traffic — but they do see metadata: which nodes are talking, when, and how much. Headscale lets you self-host DERP if that metadata leak matters to your threat model, but most deployments rely on Tailscale’s public DERP fleet for convenience. For environments under GDPR pressure or strict data locality requirements, the control-plane question and the DERP question are separate decisions. You can run Headscale with public DERP, or Tailscale with self-hosted DERP, or any combination.
Frequently Asked Questions
Can Tailscale or Headscale decrypt my traffic? No. The data path is a standard WireGuard tunnel between peers; private keys never leave the device. The coordination server only brokers public keys and routing metadata. DERP relays carry encrypted WireGuard packets they cannot read.
Will my throughput suffer compared to raw WireGuard? On direct peer-to-peer paths, the difference is under 3 percent. On relayed paths through DERP, throughput is constrained by relay capacity and adds geographic round-trip time. For SSH and most web traffic this is invisible; for bulk file transfer it is not.
Can I switch from Tailscale to Headscale later? Yes — the clients are identical. You re-authenticate each device against the new control plane with tailscale up --login-server=.... ACL policy needs to be ported, and any Tailscale-specific features Headscale doesn’t yet implement need workarounds.
What happens if the coordination server goes down? Existing direct WireGuard tunnels keep working until keys need to be re-exchanged or new peers join. New device registrations and policy updates pause until the coordinator returns. This is true for both Tailscale and Headscale.
Picking Between Them
The honest decision tree is short. If you have two endpoints, both with a publicly reachable IP, and you don’t anticipate growing past a handful of peers, raw WireGuard is faster, simpler, and has zero external dependencies. If you have laptops behind hotel Wi-Fi, servers behind CGNAT, family members you want to share a NAS with, or any team larger than five, the coordination layer earns its keep ten times over. The choice between Tailscale and Headscale then reduces to a question about your relationship with vendor dependencies. Tailscale costs money at scale and puts metadata on someone else’s infrastructure; Headscale costs operator time and puts that infrastructure on you. There is no universally correct answer, only a correct answer for your team’s compliance posture, ops capacity, and tolerance for SaaS billing.
The protocol war is over — WireGuard won. What remains is the operational question of how much glue you build yourself and how much you rent.
