Tailscale

Why Tailscale exists

Traditional VPNs (Virtual Private Networks — encrypted tunnels that extend a private network across a public one) use a hub-and-spoke topology: every device connects to a central VPN server, and all traffic routes through it. This creates two problems:

1. Bottleneck — the central server must handle all traffic, so bandwidth and latency degrade as devices increase.
2. Single point of failure — if the VPN server goes down, every device loses connectivity.

For homelab users (people running servers at home for personal projects, media, or development), remote access traditionally required one of:

• Port forwarding — configuring the home router to expose internal services directly to the internet, which creates an attack surface.
• Dynamic DNS (DDNS) — mapping a hostname to a home IP that changes periodically, which is fragile and still requires port forwarding.
• A self-hosted VPN server (e.g., OpenVPN, IPsec) — which demands setup, maintenance, certificate management, and still funnels everything through a single gateway.

Tailscale eliminates all of these by building a mesh VPN: devices connect directly to each other, peer-to-peer, with no central traffic bottleneck.

WireGuard — the underlying protocol

Tailscale is built on top of WireGuard, an open-source VPN protocol. WireGuard is not a Tailscale product — it is an independent protocol that anyone can use directly (via wg-quick, for example) without Tailscale.

WireGuard’s key properties:

• Kernel-level implementation: WireGuard is a Linux kernel module (~4,000 lines of code), with userspace implementations for macOS, Windows, iOS, and Android. Being in the kernel means lower overhead and higher throughput than userspace VPN implementations like OpenVPN.
• Modern cryptography: Curve25519 for key exchange, ChaCha20-Poly1305 for symmetric encryption, BLAKE2s for hashing. No configuration knobs for cipher selection — this eliminates misconfiguration vulnerabilities.
• Stateless design: WireGuard peers are identified by public keys. There is no “connection” to establish or maintain — if a peer has your public key and you have theirs, you can exchange packets. This makes WireGuard inherently roaming-friendly (your phone can switch between WiFi and cellular without dropping the tunnel).
• UDP-based: All WireGuard traffic is UDP, which simplifies NAT traversal compared to TCP-based VPNs.

What WireGuard does NOT provide: WireGuard handles encryption and tunneling. It does not handle key distribution, NAT traversal, device discovery, access control, or identity management. You must manually configure each peer’s public key and endpoint on every device. This is where Tailscale adds value.

What Tailscale adds on top of WireGuard

Tailscale is a commercial service and open-source client that solves everything WireGuard leaves out:

Concern	WireGuard alone	Tailscale (service + client)
Key distribution	Manual: copy public keys to every peer’s config	Automatic: coordination server distributes keys
NAT traversal	None: you must configure endpoints manually, open ports	Automatic: STUN + UDP hole punching + DERP relay
Device discovery	None: you must know every peer’s IP	Automatic: coordination server maintains topology
Identity / auth	None: keys only	SSO integration (Google, Microsoft, GitHub, Okta)
Access control	None: any peer can reach any other	ACLs (Access Control Lists) with default-deny
DNS	None	MagicDNS: automatic hostname.tailnet.ts.net names

Every device that joins a Tailscale network (called a tailnet) receives a stable IP address in the 100.x.y.z range. This range comes from CGNAT (Carrier-Grade NAT) space — the 100.64.0.0/10 block reserved by RFC 6598 for use by ISPs (Internet Service Providers) to perform NAT between their customers and the public internet. Tailscale borrows this range because it is guaranteed to never appear on the public internet, avoiding conflicts with real public IPs.

Devices discover each other and establish direct, encrypted WireGuard tunnels — even when both are behind NATs (Network Address Translation — the process by which a router rewrites private source IPs to a single public IP, allowing many devices to share one public address) and firewalls.

How it works — the coordination server

The coordination server is the only centralized component. It never touches user traffic. Its role is purely control-plane:

1. Key registration — when a device first joins the tailnet, its Tailscale agent generates a WireGuard keypair (a Curve25519 public/private key pair). The agent sends the public key to the coordination server.
2. Topology distribution — the coordination server maintains a map of all devices: their public keys, known IP addresses, and NAT endpoints. It distributes this map to every device in the tailnet.
3. Authentication — the coordination server integrates with identity providers (Google, Microsoft, GitHub, Okta, etc.) to verify that only authorized users can add devices.

With the topology map in hand, each device knows every other device’s public key and last-known endpoint. The devices then establish direct WireGuard tunnels to each other without any further involvement from the coordination server.

The coordination server never sees your traffic. All data flows device-to-device, encrypted with WireGuard. If the coordination server goes offline, existing connections continue to work — only adding new devices or updating the topology requires it.

NAT traversal

NAT traversal is the hardest problem Tailscale solves. Most devices sit behind at least one layer of NAT, meaning they do not have a publicly routable IP address. Two devices behind separate NATs cannot simply send packets to each other — neither knows the other’s real address, and the NAT will drop unsolicited inbound packets.

STUN — discovering your public endpoint

STUN (Session Traversal Utilities for NAT, defined in RFC 5389) is a protocol that lets a device discover its own public IP address and port as seen from outside its NAT. The process:

1. The device sends a UDP packet to a STUN server on the public internet.
2. The NAT rewrites the source address (replacing the private IP and port with a public IP and a mapped port).
3. The STUN server reads the source address from the received packet and reflects it back to the device.
4. The device now knows its public IP and the port its NAT assigned.

Tailscale runs its own STUN servers and uses this information to populate the topology map.

UDP hole punching

Once both devices know each other’s public endpoint (from the coordination server, which got it from STUN), they perform UDP hole punching:

1. Device A sends a UDP packet to Device B’s public endpoint. A’s NAT creates an outbound mapping (allowing replies from B’s address).
2. Simultaneously, Device B sends a UDP packet to Device A’s public endpoint. B’s NAT creates an outbound mapping (allowing replies from A’s address).
3. When A’s packet arrives at B’s NAT, B’s NAT recognizes it as a reply to B’s outbound packet (because B already sent to A’s address). The packet is forwarded to B.
4. The same happens in reverse. A bidirectional UDP channel is now open.

This works reliably through three of the four NAT types:

• Full cone NAT — any external host can send to the mapped port. Easiest case.
• Restricted cone NAT — only hosts that the internal device has sent to can reply, but any port from that host works.
• Port-restricted cone NAT — only the exact IP:port combination the device sent to can reply. Hole punching still works because both devices send to each other’s exact endpoints.
• Symmetric NAT — the NAT assigns a different external port for every destination. STUN reveals the port used to reach the STUN server, but the port for reaching the peer will be different and unpredictable. Hole punching fails here.

Fallback — DERP relay

When direct connections fail (symmetric NAT, restrictive firewalls, or corporate networks that block UDP entirely), Tailscale falls back to DERP.

DERP — Designated Encrypted Relay for Packets

DERP is Tailscale’s relay protocol, purpose-built for forwarding WireGuard packets when peer-to-peer connections cannot be established. Key properties:

• End-to-end encryption preserved — DERP servers relay opaque WireGuard ciphertext. They cannot decrypt the traffic because they do not possess the devices’ private keys.
• Higher latency — packets travel device-to-DERP-server-to-device instead of device-to-device. This adds a round-trip through the relay.
• Always available — DERP ensures that connectivity never completely fails. Even in the worst network conditions, devices can communicate.
• Globally distributed — Tailscale operates DERP servers in multiple regions to minimize relay latency.

DERP runs over HTTPS (TCP port 443), which means it can traverse even the most restrictive corporate firewalls that only allow web traffic.

Key features (Tailscale service)

All features in this section are part of the Tailscale commercial service — they are not part of the WireGuard protocol. If you use WireGuard directly (via wg-quick) or through an alternative like Headscale, these features are either unavailable or must be replicated separately.

MagicDNS

Each device in the tailnet gets a DNS name following the pattern hostname.tailnet-name.ts.net. MagicDNS is Tailscale’s built-in DNS resolver that automatically maps these names to Tailscale IP addresses. This eliminates the need to remember or look up 100.x.y.z addresses — you refer to devices by name.

Subnet routers

A subnet router is a device running Tailscale that advertises routes to an entire LAN (Local Area Network) subnet. For example, a device on a 192.168.1.0/24 network can advertise that subnet to the tailnet. Other Tailscale devices can then reach any host on that LAN — including devices that do not have Tailscale installed — by routing traffic through the subnet router.

This is useful for accessing printers, IoT devices, NAS (Network-Attached Storage) appliances, or any device where installing Tailscale is impractical.

Exit nodes

An exit node routes all of a device’s internet traffic (not just tailnet traffic) through another device in the tailnet. This replicates traditional VPN behavior: your public IP becomes the exit node’s IP, and all traffic is encrypted between you and the exit node. Use cases include accessing geo-restricted content or securing traffic on untrusted networks (coffee shop Wi-Fi).

ACLs — Access Control Lists

Tailscale ACLs define which devices and users can communicate with which services. They are written in HuJSON (Human JSON — a superset of JSON that allows comments and trailing commas) and enforced by the coordination server, which distributes the rules to all devices.

Example: you can allow your phone to reach your homelab’s SSH port but deny it access to your work laptop entirely. ACLs operate on a default-deny model — only explicitly permitted traffic flows.

Taildrop

Taildrop is a peer-to-peer file transfer mechanism built into Tailscale. Files are sent directly between devices over the existing WireGuard tunnel, with no intermediate server. It works across platforms (Linux, macOS, Windows, iOS, Android).

Funnel

Funnel exposes a local service to the public internet via Tailscale’s infrastructure. Unlike subnet routers (which expose services within the tailnet), Funnel makes a service accessible to anyone on the internet by assigning it a public https://hostname.tailnet-name.ts.net URL. Tailscale terminates TLS (Transport Layer Security) at their edge and forwards traffic to your device over the WireGuard tunnel.

Pricing

Tailscale is a commercial product with a free tier. Pricing is per user (not per device), and all plans include unlimited devices per user.

Plan	Price	Users	Key limits
Free (Personal)	$0	1 user + 2 shared users	100 devices, 1 subnet router, 1 admin
Personal Plus	$48/year	1 user + 5 shared users	Unlimited devices, custom domain, more subnet routers
Starter	$6/user/month	Up to 10 users	ACLs, SSO (OIDC), audit logs
Premium	$18/user/month	Unlimited users	SCIM provisioning, posture checks, SLA
Enterprise	Custom	Unlimited	Custom contracts, dedicated support

Prices as of early 2025. Check tailscale.com/pricing for current details.

For homelab use: the Free tier is sufficient for most individuals. You get one tailnet with up to 100 devices, MagicDNS, NAT traversal, DERP relay, exit nodes, Taildrop, and basic ACLs. The main limitation is the number of users who can share the tailnet (3 total on the free plan).

Why it matters: Tailscale’s coordination server is proprietary — you depend on Tailscale Inc. for key distribution, topology updates, and authentication. If the free tier’s limits become restrictive or you want to eliminate this dependency, see the Headscale section below for the self-hosted alternative.

Homelab use case

A typical homelab setup with Tailscale:

1. Install Tailscale on the homelab server (e.g., a machine running Proxmox, a hypervisor for virtual machines). It receives an address like 100.100.1.1.
2. Install Tailscale on your laptop. It receives 100.100.1.2.
3. Both devices register with the coordination server and exchange public keys.
4. NAT traversal establishes a direct WireGuard tunnel between them.

Now, from a coffee shop or while traveling, you can access:

• Proxmox web UI at homelab.tailnet-name.ts.net:8006
• Any service running on the homelab, using its Tailscale IP or MagicDNS name

No port forwarding on the home router. No dynamic DNS. No services exposed to the public internet. The homelab is invisible to anyone not in your tailnet.

If the homelab also acts as a subnet router for 192.168.1.0/24, you can additionally reach other devices on the home LAN (a NAS at 192.168.1.50, a printer at 192.168.1.100) without installing Tailscale on each one.

Headscale — self-hosted coordination server

Headscale is an open-source, self-hosted implementation of Tailscale’s coordination server. It implements the same control-plane protocol, so standard Tailscale clients connect to it without modification.

What Headscale replaces: only the coordination server. The WireGuard data plane, NAT traversal, STUN, and DERP all work identically — Headscale distributes the same topology maps and public keys that Tailscale’s hosted coordination server would.

Why use it:

• Full control over the coordination server and its data (device keys, topology, ACLs).
• No dependency on Tailscale Inc.’s infrastructure for the control plane.
• Useful for environments where sending device metadata to a third party is unacceptable.

Trade-offs:

• You must host, secure, and maintain the coordination server yourself.
• No official support from Tailscale Inc.
• Some features (e.g., Funnel, certain SSO integrations) may lag behind or be unavailable.
• DERP relay servers are separate from the coordination server — you can use Tailscale’s public DERP servers or run your own.

See also

• DNS — MagicDNS builds on DNS resolution concepts
• The TCP Stack — Tailscale’s NAT traversal operates at the UDP layer alongside the TCP/IP stack