How a Tailscale Mesh VPN Works: Coordination, NAT and ACLs

Traditional VPNs are hub and spoke. Every client dials a concentrator, all traffic crosses it, and two clients sitting in the same building still route through a box somewhere else. A mesh overlay inverts that. Each device builds direct encrypted tunnels to the peers it needs, and the central service handles only coordination, not data.

Control plane and data plane are separate

Tailscale uses WireGuard for the tunnels themselves. Each device generates a private key that never leaves it and publishes only the public key. The coordination server maintains the map of who belongs to the tailnet, which public keys they hold, and where they were last seen, then distributes that map to authorized peers.

The consequence worth internalizing is that the coordination service can tell devices about each other but cannot decrypt their traffic, because it never holds a private key. Your data path is device to device.

The addresses and names a tailnet hands out

Every node receives an overlay address from the carrier-grade NAT block 100.64.0.0/10, which is why tailnet addresses all start with 100.. That range was set aside for provider-side NAT rather than for private LANs, so it rarely collides with the 192.168.x.x and 10.x.x.x space already in use at home or in an office. The address is bound to the device, not to the network it is sitting on, which is what makes a laptop’s permissions survive a move from home Wi-Fi to a hotel.

On top of the addresses sits an overlay DNS zone: each device gets a name of the form device.tailnet-name.ts.net, resolvable from any other node in the tailnet without a hosts file or a local DNS server. Prefer those names over the raw 100. addresses in scripts and config, because a device that is re-enrolled keeps its name and does not necessarily keep its address.

NAT traversal and relays

Most devices sit behind NAT with no inbound port open. Peers discover their own external addresses and attempt a coordinated simultaneous connection so both sides’ firewalls see the session as outbound. This succeeds often but not always, particularly behind strict or symmetric NAT and on some carrier networks.

Three mechanisms carry most of that work. Peers learn their public address and port by talking to a discovery server, the same STUN-style trick used by voice and video applications. Where the router supports an automatic port-mapping protocol, the client asks for a mapping directly. And where neither helps, both sides fire packets at each other simultaneously so that each one’s outbound packet opens the return path in its own firewall state table. Opening UDP port 41641 on a device that does have a public address removes the guesswork entirely: peers can then reach it directly whenever their own side permits it.

When a direct path cannot be established, traffic falls back to encrypted relays, which Tailscale calls DERP servers. A relay is reached over an ordinary outbound HTTPS connection, which is deliberate: any device that can open HTTPS to an arbitrary host on the internet can still join the mesh, even on a guest network that blocks everything else. Relays also do the initial introduction between two peers while a direct path is still being negotiated, so a connection typically starts relayed and upgrades itself in the background once hole punching succeeds.

The relay never becomes a security problem, because it forwards WireGuard-encrypted packets it has no key for. It is a performance problem. Every packet takes a detour to a third location and back, so a relayed link between two machines in the same building can easily be slower than a direct link between continents.

Three commands settle the question rather than guessing at it. tailscale status labels each peer direct or relay, tailscale ping <peer> shows the path in real time as it negotiates and upgrades, and tailscale netcheck reports what the local network looks like from the client’s point of view, including which relay regions are closest. If a link feels unexpectedly slow, check whether that peer is relayed before blaming anything else. Common causes are restrictive firewall policy blocking the UDP path and double NAT. The diagnostic order and the fixes are covered in why Tailscale throughput is slow and how to fix it, and the mesh latency and throughput estimator puts rough numbers on the difference between the two path types.

Identity replaces IP allowlists

Access rules are written against users, groups and device tags rather than addresses. That is the real shift. A laptop that moves between home, office and mobile networks keeps the same overlay address and the same permissions, so policy stops depending on where a device happens to be.

Write policy as default deny and grant only the specific destinations and ports each group needs. The mistake that undoes the whole model is building a mesh and then allowing every device to reach every other device, which is simply a flat network with better encryption, and it is the state a brand-new tailnet ships in. Closing it is the step most installations skip; the Tailscale setup guide walks through it in sequence.

Tags are the part worth understanding before the policy file grows. A tag such as tag:prod-db is applied to a machine at enrollment and declared in the policy file with an owner list saying which users are allowed to apply it. From then on the machine’s access derives from the tag, not from the person who happened to run the install command. That distinction matters on the day that person leaves: an untagged server enrolled under a departing employee’s identity leaves the tailnet with them, while a tagged one does not. Tagging also changes key lifetime, covered below.

A workable policy shape for a small tailnet looks like this in prose: administrators reach everything; ordinary members reach the services they need on the ports those services actually listen on; tagged infrastructure reaches other tagged infrastructure only where a real dependency exists; and nothing else is permitted. Review it the same way you would review firewall rules, because that is what it is. Rules referencing devices that no longer exist are the usual source of drift.

Names, subnet routers and exit nodes

Overlay DNS gives devices stable names, which is far more usable than tracking assigned addresses. Be aware of how it interacts with your existing local resolver, since search domain conflicts are a frequent source of confusing name resolution.

A subnet router advertises an entire physical network into the tailnet, which is how you reach equipment that cannot run a client, such as switches, printers or appliances. Three things have to line up for it to work: the node advertises the range, the host has IP forwarding enabled at the kernel level, and an administrator approves the route in the admin console. Approval is a deliberate gate rather than a formality, because an advertised route is an offer to carry traffic for an entire address block and nothing stops a compromised node from offering one.

On the client side, routes are opt-in as well. A peer that has not been told to accept subnet routes will reach the router itself but not the machines behind it, which is the most common reason a correctly configured subnet router appears to do nothing.

Overlapping ranges across sites cause routing ambiguity. If several locations all use the same common private range, renumber before meshing them. Where renumbering is genuinely impossible, Tailscale’s 4via6 addressing maps each site’s copy of the same IPv4 range into a distinct IPv6 address, which works but adds a layer of indirection worth avoiding when a renumber is on the table.

An exit node sends all of a device’s internet traffic through another node. It is the right tool for egressing from a specific location, and the wrong tool for general use, because it forces every packet through one machine’s uplink. An exit node also has to be approved, and it needs IP forwarding for the same reason a subnet router does.

Operational details that bite later

Device keys expire by design. Tailscale’s default for new tailnets is 180 days, adjustable down to as little as one day, and an expired key stops that device’s connections until somebody re-authenticates it. The failure mode is unpleasant precisely because it is scheduled: a headless server enrolled today works perfectly for six months and then drops off the network on a date nobody wrote down.

There are two clean answers. Tag the machine, since applying a tag for the first time and authenticating disables key expiry on that device by default, which is exactly the behaviour you want for a subnet router or a rack server. Or disable expiry explicitly per device in the admin console. When a key has already lapsed, tailscale up --force-reauth on the device renews it. Reaching for that command on a machine you can only reach through the tailnet is the problem, which is the whole argument for deciding the policy before the machine is remote.

Use ephemeral nodes for short-lived containers and build agents so stale entries do not accumulate; an ephemeral node removes itself from the device list shortly after it goes offline. Review the device list periodically and remove what no longer exists, because every stale entry is a name that still resolves and a set of ACL rules that still evaluates.

Every overlay network in this category shares the same shape: encrypted peer links, a coordination service, and a relay for when hole punching fails. What differs is who holds the control plane, whether the overlay runs at Layer 3 or emulates Ethernet, and how policy is written. Tailscale compared with ZeroTier and NetBird works through those three questions and where each system lands on them.