Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Mesh VPNs Are A Different Thing

This is the chapter many readers will recognize most immediately, because Tailscale is on their work laptop. Mesh VPNs are the category most working engineers in 2026 already use — knowingly or otherwise — and that they probably call “mesh” without having thought hard about whether the word means the same thing it means for Reticulum or Yggdrasil.

It does not, quite. The word mesh is doing real work here, but for a different problem than the previous chapters were about. This chapter unpacks that, walks through the four major projects (Tailscale, Nebula, ZeroTier, Headscale), and is honest about when each is the right tool.

What mesh VPNs are solving

The classical VPN model is a hub-and-spoke. Your laptop opens a VPN connection to a corporate gateway. All traffic from the laptop to other office resources flows through that gateway, even if the destination is another laptop on the same VPN. This is operationally simple and architecturally lousy: the gateway is a bandwidth bottleneck, a latency bottleneck, and a single point of failure. If you and a colleague on the same VPN want to share a file, the bytes leave your machine, traverse the Internet to the corporate gateway, traverse it back to your colleague’s machine — even if the colleague is sitting next to you.

The mesh-VPN model says: every node should be able to connect directly to every other node. The control plane (key distribution, ACLs, identity, peer discovery) is centralized — there is a coordinator, somewhere, that helps nodes find each other and decides who is allowed to talk to whom. The data plane — actual user traffic — flows directly between peers, peer-to-peer, with no central relay involved unless NAT traversal forces one.

The traffic shape is mesh-like (point-to-point between any pair of nodes, no central forwarder for the data). The control plane is centralized (a coordinator service decides who’s allowed in the network). The substrate is the public Internet (no LoRa, no Bluetooth, no off-grid). Hence: mesh VPN. Mesh in the same sense Reticulum is — peer-to-peer data flow with no central relay — and not in the same sense — substrate is the regular Internet, control plane has a coordinator.

The structural test from chapter 1: does the network function when the public Internet is unavailable? For mesh VPNs, no — that is what makes them a different category from Reticulum and Meshtastic. They are solving zero-trust networking over the existing Internet, not networking that doesn’t depend on the existing Internet.

Both categories legitimately use the word mesh. Both deserve the word. They are not the same category. Keep them separate in your head.

Tailscale

Tailscale is the dominant project in this category in 2026 by a wide margin. The founding team came from previous work on Wireguard and Google’s enterprise networking, and the project’s design choices reflect that lineage.

The architecture in summary:

  • WireGuard for the data plane. Tailscale doesn’t reinvent the encryption layer. WireGuard is a tight, well-audited, modern VPN protocol; Tailscale uses it for actual peer-to-peer traffic.
  • A coordinator service for the control plane. Each Tailscale node connects to a Tailscale-operated coordinator (in the hosted product) which handles key distribution, peer discovery, ACL enforcement, and so on. The coordinator does not see actual user traffic — it sees only the metadata necessary to set up the WireGuard sessions.
  • DERP relays for fallback. When two nodes can’t establish a direct WireGuard connection (because of NAT, firewall, or other obstructions), Tailscale falls back to relaying their traffic through DERP relays. The relays still don’t see plaintext — the WireGuard encryption is end-to-end — but they do carry the encrypted bytes. In practice, the project reports the large majority of connections succeed peer-to-peer, with DERP only as fallback.
  • Tailnet identity model. Every node belongs to a tailnet (typically one per organization or per user), with ACLs that determine which nodes can reach which others. Identity is via OAuth-shaped logins (Google, GitHub, Microsoft, etc.).

What Tailscale gets right:

  • The setup is essentially zero-friction. Install the client, log in via OAuth, the node appears in your tailnet and can reach every other node it’s allowed to. This is the experience that has driven the project’s adoption: it’s easier to set up than it is to not set up, for the homelab and small-business case.
  • NAT traversal is genuinely well-engineered. Tailscale’s NAT-traversal logic is some of the best in the industry. It handles symmetric NATs, double NATs, CGNATs, and the various other obstructions that have historically made peer-to-peer connectivity hard.
  • The free tier is real. Personal use up to a certain number of nodes is free, indefinitely. This has driven a lot of homelab adoption.
  • MagicDNS, exit nodes, subnet routing. The product features around the core mesh have been thoughtfully developed: every node gets a memorable DNS name in the tailnet, you can designate exit nodes (for routing all your traffic out a specific node), you can advertise subnets (for reaching non-Tailscale resources behind a Tailscale node).

What Tailscale gets wrong, or is honestly limited about:

  • The coordinator is a centralization point. It is run by Tailscale Inc. If they go down, your existing peer connections continue to work, but new connections and key rotations don’t. If the company changes its policies or pricing in ways you don’t like, your options are limited. Headscale (below) addresses this.
  • It is a SaaS product. Tailscale is an open-source client connecting to a proprietary coordinator. The client is open. The control plane is not. For users who need full control of the stack, this is a real limitation.
  • Pricing for serious commercial use is non-trivial. Free for personal, paid above; the paid tiers can be expensive for large organizations. This is fair (the company has to make money) but it is also a thing to be aware of.

Where Tailscale fits in the recommendation tree (chapter 12 has the explicit version): for almost any “I want a flat network among my devices, including some that are behind NAT” use case, Tailscale is the right answer in 2026. Homelab, small business, even some enterprise. If you don’t have a specific reason to pick something else, pick Tailscale.

Headscale

Headscale is the open-source, self-hosted reimplementation of Tailscale’s coordinator. The Tailscale clients (which are open-source) talk to Headscale instead of to Tailscale’s hosted coordinator; everything else works the same.

This solves the “the coordinator is a SaaS centralization point” concern at the cost of operating the coordinator yourself. Headscale runs as a Go binary against a SQLite or PostgreSQL database; the operational overhead is real but not prohibitive. The project is alive in 2026, has a healthy contributor community, and is the standard way to run Tailscale-shaped infrastructure without depending on Tailscale Inc.

When to pick Headscale: when you specifically want full control of the control plane, can operate the service yourself, and are comfortable being responsible for the security and uptime of that service. For most users, the hosted Tailscale product is the right tool. For users who specifically need self-hosting, Headscale is the answer.

Nebula

Nebula is Slack’s open-source mesh-VPN project, with a different design philosophy from Tailscale. The architectural choices:

  • Lighthouses, not coordinators. Nebula uses lighthouse nodes that help other nodes discover each other, but the lighthouses are operated by the user, not by a third-party SaaS. You designate one or more nodes (typically with public IPs) as lighthouses; other nodes register with them.
  • Certificate-based identity. Nebula uses a PKI-shaped identity system where you have a CA certificate and issue node certificates from it. This is more rigorous than OAuth-based identity but more operational overhead.
  • Custom protocol, not WireGuard. Nebula doesn’t use WireGuard; it has its own UDP-based protocol with similar properties (modern crypto, designed for peer-to-peer).
  • Designed for larger-scale deployments. Slack uses Nebula internally to connect tens of thousands of nodes; the project’s design choices reflect that scale.

Nebula is more in the self-hosting direction than Headscale, by design. There’s no “managed Nebula” SaaS in the way there’s a Tailscale SaaS. You operate everything. The benefit is full control; the cost is operational complexity.

When to pick Nebula: when you want a self-hosted mesh VPN with a more rigorous identity model than the OAuth-based one, when you’re operating at a scale where the Tailscale pricing or design isn’t a fit, or when you specifically prefer a certificate-based identity model.

ZeroTier

ZeroTier predates Tailscale and approaches the problem differently. The core ZeroTier model is a virtual Ethernet: you create a network in ZeroTier, every node that joins gets a virtual Ethernet interface in that network, and Ethernet frames flow between the nodes as if they were on the same LAN.

This is operating at OSI layer 2, where Tailscale operates at layer 3. The consequence is that ZeroTier networks behave like Ethernet — broadcasts work, ARP works, mDNS works, things that depend on layer-2 visibility work — in ways that Tailscale networks don’t.

ZeroTier has a SaaS coordinator (ZeroTier Central) and an open-source self-hostable controller (the same way Tailscale and Headscale relate). The free tier is real. The pricing for paid use is similar to Tailscale’s in shape.

When to pick ZeroTier: when you specifically need layer-2 mesh behavior. For most modern use cases, layer 3 is sufficient and Tailscale is the better choice; for legacy applications, AppleTalk-shaped requirements, or specific industrial uses, ZeroTier’s layer-2 model is the right tool.

What “mesh” is doing in this category

Stepping back: the word mesh in mesh-VPN context is doing two specific things, and it is worth seeing them clearly.

  1. The traffic flows peer-to-peer. No central relay in the data path (modulo NAT-traversal fallback). This is real, it is structurally important, and it is what distinguishes mesh VPNs from classical hub-and-spoke VPNs. The word mesh is correct here.

  2. The control plane is centralized. Tailscale’s coordinator. ZeroTier Central. Even Nebula’s lighthouses are nodes you specifically designate. This is not mesh in the sense of chapter 7’s Yggdrasil or chapter 6’s Reticulum, where there is no central authority at all. The word mesh is partially misleading here.

A more precise word for the category might be hybrid mesh — peer-to-peer data, centralized control. The industry doesn’t use that term, so we’re stuck with the ambiguous mesh VPN. As long as you keep the structural distinction in mind, you’ll know what people mean when they use the word.

How this category interacts with the rest of the book

A reader of this book might run both — a Tailscale network for their homelab and a Reticulum network for off-grid messaging — without contradiction. They are not competing tools; they are tools for different problems.

A productive way to think about it:

  • Tailscale (and the family) is the right tool when the existing Internet is the substrate you want to use, and you want a flat, encrypted, peer-to-peer overlay on top of it.
  • Reticulum, Yggdrasil, Meshtastic are the right tools when you do not want to depend on the existing Internet, either for off-grid use, for resilience, or for political reasons.

Both legitimately use the word mesh. Both are described in this book. Both are useful. Conflating them is the most common confusion in this space, and the goal of this chapter is to leave you not making that mistake.

A worked example: Tailscale in five minutes

Tailscale is, by a wide margin, the easiest project in this book to install and use. The shape of the experience:

# Linux (Debian/Ubuntu)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# Click the OAuth link printed in the terminal, authenticate
# That's it. Your machine has a Tailscale IP.

# Now, on your phone (after installing the app, OAuth login)
ssh user@your-laptop-tailnet-name
# This works. Without port forwarding. Without DDNS. Without an IP.

If you have not done this and you are a working engineer in 2026, you are part of a smaller and smaller set of working engineers. The product has the kind of adoption that comes from being unambiguously easier than the alternative.

For Headscale, the equivalent is: install Headscale on a server, point your Tailscale clients at your Headscale instance via the --login-server flag, run the same command. The clients don’t know the difference.

Where to go next

  • Tailscale at tailscale.com. Documentation is excellent.
  • Headscale at github.com/juanfont/headscale.
  • Nebula at github.com/slackhq/nebula.
  • ZeroTier at zerotier.com and github.com/zerotier.
  • WireGuard itself at wireguard.com if you want to understand the underlying protocol Tailscale builds on.

What to take from this chapter

You should now be able to:

  • Position mesh VPNs correctly: peer-to-peer data plane, centralized control plane, public-Internet substrate.
  • Explain why this is legitimately mesh in one sense and not in another, and not be confused when both senses come up in the same conversation.
  • Pick between Tailscale (the default), Headscale (self-hosted control plane), Nebula (certificate-based, large-scale), and ZeroTier (layer-2 virtual Ethernet) based on what you actually need.
  • Stop being confused about why a book that surveys both Reticulum and Tailscale is not a category error.

The final chapter is the recommendations one. Indexed by what you want to feel, what to install this weekend, what hardware to buy, and what an evening with each looks like.