Mesh VPN: Part 1 — What is a WireGuard mesh network and when do you need one

Mesh VPN — is a private network in which devices connect to each other directly rather than through a single central server. A laptop, a home server, an office computer and a phone see each other by internal addresses wherever they are, and traffic between them takes the shortest path. Most modern services of this kind — Tailscale, NetBird, Headscale — are built on the WireGuard protocol.

Classic VPN: “star” topology

A conventional VPN is arranged like a star: a server in the center, clients connect to it. Any traffic—even between two clients sitting in neighboring rooms—passes through the center. This topology has three weak points:

• Latency. If the server is in Moscow and two employees are in Novosibirsk, their traffic to each other crosses the country twice.
• Bottleneck. Network throughput is limited by the channel and CPU of a single server.
• Single point of failure. If the server is unavailable, the whole network doesn’t work.

In addition, each client needs keys and routes configured manually, and a port must be opened on the server.

How a mesh network is organized

In a mesh network data goes directly between devices. But it doesn’t work completely without a center: it still has one for coordination, not for carrying traffic. Usually such a system has three roles.

Coordination server (control plane). Stores the list of devices and their WireGuard public keys, verifies who joined the network, distributes information about other participants and access rules to each device. User traffic does not pass through it. In Tailscale this server runs in the company cloud; in NetBird and Headscale it can be deployed on-premises.

NAT traversal mechanism. Most devices are behind home and office routers without public IP addresses. For two such devices to connect directly, they use auxiliary servers to discover their external addresses and simultaneously send packets toward each other—so routers on both sides allow the connection. NetBird uses ICE and STUN protocols and a separate Signal service for this, and user traffic also does not go through it.

Relays. Sometimes a direct connection cannot be established—for example, with strict NAT at a mobile operator or a strict corporate firewall. Then traffic goes through a relay: for Tailscale these are DERP servers, for NetBird it’s the Relay service. The data remains encrypted from device to device: according to Tailscale documentation, private keys do not leave the device, so the DERP server only forwards already encrypted packets and cannot decrypt them.

From this comes an important clarification: a mesh network does not “work without a center.” Already established direct connections will survive a temporary unavailability of the coordination server, but you cannot add a new device or change rules without it. If the coordination server is yours, you are responsible for its availability.

Why WireGuard

WireGuard is a VPN protocol built into the Linux kernel and available on all major systems. It is convenient for mesh networks for several reasons:

• Simple model. Each device is described by a key pair and a list of addresses reachable through it. The coordination service only needs to distribute this data—WireGuard handles the rest.
• Small codebase and modern fixed cryptography without algorithm selection, which is often misconfigured in older protocols.
• Runs over UDP and quickly restores connections when the network changes, for example when a phone switches from Wi-Fi to mobile data.

WireGuard performance in practice depends on CPU, network and implementation (in-kernel or user-space), so don’t expect universal numbers like “N times faster than OpenVPN”: it’s better to compare on your own hardware.

What the mesh approach gives

• Shorter traffic paths. Two devices in the same city communicate directly rather than via a server on the other side of the country.
• No single throughput bottleneck. Each connection uses only the channels of the two participants.
• Easy onboarding. A new device joins the network via an account or an authorization key, without manual configuration changes on other nodes.
• No public IPs or port forwarding needed. NAT traversal handles that.
• Access rules in one place. The coordination server distributes policies like “the accounting department can see only the 1C server.”

Limitations

• Dependence on the coordination server. In cloud services—on another company, its pricing and availability; in self-hosted solutions—on your administration.
• Relays slow things down. If a direct connection is not established, speed is limited by the relay.
• Not for all traffic. A mesh VPN connects devices with each other. To funnel all internet traffic through a specific point you need a separate feature—e.g., an exit node in Tailscale.
• Attention to access rules. By default many services allow all devices to see all others. In a company this almost always needs tightening.

When a mesh VPN is needed

• Remote access to multiple sites: office, warehouse, employees’ home computers, servers at different providers.
• Access to servers without open ports. SSH, admin panels and databases available only to network participants.
• A small team without a network administrator that needs a VPN that works “out of the box.”
• A cloud-and-office setup where a classic tunnel between routers is overkill.

When mesh is not the best choice: if you just need to connect two offices with fixed addresses—it’s simpler to set up a tunnel between routers; if you need full control over every parameter—manual WireGuard configuration. Another approach to the same task is a self-hosted network on VPNCloud.

How to choose a solution

Each option is covered in a separate part of the series.