What Is a Mesh VPN? How It Works, Uses and Limits

A mesh VPN is a private network in which devices connect directly to each other through encrypted tunnels, instead of sending all traffic through one central VPN server. A coordination service authorises devices and helps them find each other. When a direct path is blocked, traffic can pass through a relay.

A mesh VPN links devices you control, such as laptops, phones, home servers and cloud machines, into one private network. It is an architecture, not a protocol, and it works differently from the consumer and business VPNs explained in What Is a VPN?

How does a mesh VPN work?

A mesh VPN separates coordination from traffic: a coordination service tells each device which peers it may reach and how to find them, and the devices then send encrypted traffic directly to one another. Tailscale calls these two layers the control plane and the data plane.

In tools with a coordination service, such as Tailscale and NetBird, a device joins the network and connects in five steps:

1. Enrolment. You install the client on a device and enrol it in the network. Depending on the tool, that means signing in, using a pre-issued key, being approved by an administrator, or installing a certificate signed by the network’s certificate authority, which signs certificates to vouch for each device.
2. Registration. Each device has a key pair: a public key it can share and a private key it keeps secret. The device registers its public key and network addresses with the coordination service; the private key stays on the device.
3. Peer list. The coordination service sends back the public keys and addresses of the peers the device may reach, together with the access rules.
4. Direct tunnel. The device tries to open an encrypted tunnel directly to each peer it needs, even when either device sits behind NAT (network address translation, which lets many devices share one public IP address).
5. Relay fallback. If no direct path works, a relay forwards the encrypted packets between the two devices.

Traffic stays encrypted between the two devices either way.

Nebula handles enrolment, registration and the peer list differently, because it has no coordination server: its certificate authority and lighthouses share that role.

How devices join a mesh VPN

Tools admit a new device by sign-in, a pre-issued key, an administrator’s approval or a signed certificate:

What the coordination service sees

The coordination service holds and distributes the list of devices, their public keys, network addresses and network policies, but not the traffic between them. In Tailscale, no traffic passes through the coordination service, device keys are stored on the devices, and each device caches its network policies. Tailscale’s coordination service also stores each device’s operating system, client version and geographic location.

Mesh VPN vs traditional VPN

A mesh VPN differs from both designs that “traditional VPN” usually covers: a consumer VPN, which sends your internet traffic through a provider’s server, and a hub-and-spoke business VPN, which connects users to an internal network through a gateway.

In a hub-and-spoke design, traffic between two devices goes through the central gateway, even when the devices are close to each other and the gateway is far away. Tailscale’s example is a worker in New York reaching a server in New York through a VPN concentrator at the company’s head office in San Francisco. A mesh VPN sends that traffic directly between the two devices when the network allows.

Is a mesh VPN decentralised?

Only the data path is: data travels peer to peer, but Tailscale, NetBird, ZeroTier, Netmaker and Meshnet rely on a central coordination service. Nebula is the exception, because it has no coordination server: a certificate authority signs each host’s certificate, and lighthouses help hosts find each other. In self-run Nebula, the network owner runs both; in Managed Nebula, a hosted version run by Defined Networking, that company holds the CA key and runs the lighthouses.

NetBird combines peer-to-peer connectivity with centralised access control. ZeroTier offers hosted controllers or a controller you run yourself, but either way one controller manages the network. Self-hosting moves the coordination service onto your own server; it does not remove it. Tailscale says it creates a peer-to-peer mesh network.

Mesh VPN vs a site-to-site full mesh

A site-to-site full mesh links gateways; a mesh VPN links devices. In a full mesh, each site’s VPN gateway keeps a tunnel to every other site’s gateway, and the devices behind the gateways run no VPN software. In a mesh VPN, each device runs the client. In ZeroTier, and in NetBird with its lazy connections setting (on by default for accounts created on v0.74.0 or later), a device sets up a connection to a peer only when traffic needs it, rather than keeping a connection to every device in the network.

A mesh VPN can also link whole networks through a subnet router, which makes the network behind it reachable without a client on each device.

Is a mesh VPN faster than a traditional VPN?

For traffic between your own devices, a direct mesh connection can take a shorter route, because it goes straight between the two devices instead of through a provider’s server or a company gateway. A relayed connection is usually slower than a direct one, since the traffic also passes through the relay.

What is a mesh VPN used for?

A mesh VPN is used when devices in different places need to reach each other privately without sending all their traffic through one server.

• Reaching a home server or NAS. This works even behind carrier-grade NAT (CGNAT), usually without port forwarding on the router. Both NetBird and Tailscale support this use.
• Connecting a small team. Team members reach shared servers and each other’s devices through one private network.
• Connecting servers across clouds and data centres. Servers join one private network wherever they run.
• Linking office networks. Tailscale and NetBird support site-to-site connections through a routing device at each site, and so does Netmaker. Tailscale’s version uses layer 3 routing and requires both subnet routers to run Linux.
• Playing LAN games over the internet. ZeroTier emulates Ethernet, so broadcast and multicast can work across it. It treats Ethernet broadcast as a multicast group that every member of the network subscribes to.
• Protecting traffic on untrusted Wi-Fi. In a café or on other untrusted Wi-Fi, internet traffic can be sent through an exit node at home or in the cloud. The traffic is encrypted as far as the exit node and then leaves from the exit node’s connection.

Subnet routers and exit nodes

A subnet router lets mesh devices reach a whole network without a client on every device in it; an exit node sends a device’s internet traffic out through another device in the mesh.

• Subnet router. The subnet router runs the client and forwards traffic between the mesh and the local network behind it, so devices that don’t or can’t run the client become reachable. Tailscale’s subnet routers follow its access rules, so a rule has to allow access to the advertised subnet.
• Exit node. Websites see the exit node‘s IP address instead of the device’s own. NetBird exit nodes route all internet-bound traffic through a designated routing peer, Meshnet can route traffic through another device so you use that device’s IP address, and ZeroTier can send all internet traffic through a node you set up as an exit node, once a device is set to allow a default route.

Both put another device in the path, and traffic leaves the encrypted tunnel at that device.

Sending only some traffic through an exit node is a form of split tunnelling. Tailscale, for example, can keep local network access while an exit node is in use, and its Android app can exclude chosen apps.

Mesh VPN examples

Tailscale, ZeroTier, NetBird, Nebula, Netmaker and NordVPN Meshnet show the range of mesh VPN designs, and Headscale is a self-hosted coordination server for Tailscale clients.

Tailscale

Tailscale runs the coordination service and uses WireGuard to move encrypted data between devices. Each connection starts through a DERP (Designated Encrypted Relay for Packets) server, and Tailscale then tries to upgrade it to a direct connection; if that fails, it tries a peer relay, if the tailnet (Tailscale’s name for one private network) has one. Its client is published under the BSD 3-Clause licence (Tailscale licence), but the graphical interface on Windows, macOS and iOS is not open source, and its coordination server is closed source.

Headscale

Headscale is an open-source, self-hosted implementation of the Tailscale control server, released under the BSD 3-Clause licence. It runs a single tailnet, which its README describes as suitable for personal use or a small open-source organisation. Its README states: “This project is not associated with Tailscale Inc.” Its example configuration also leaves off the client logging that Tailscale’s own service turns on by default.

ZeroTier

ZeroTier uses its own protocol in two layers. VL1 is the peer-to-peer transport, which ZeroTier calls the “virtual wire”, and VL2 is an emulated Ethernet layer with VLAN-like boundaries, multicast and rules. Root servers help devices find each other and relay traffic when a direct path fails. A network is managed by a controller, either hosted by ZeroTier or run by you. The client is under the Mozilla Public License 2.0, while the controller code sits in a separate directory under a source-available licence that requires a commercial licence for any commercial use, including use by non-profits and charities.

NetBird

NetBird builds a WireGuard-based overlay network with three server components: Management registers devices and distributes their public keys, Signal passes connection candidates between devices, and Relay forwards traffic when no direct path works. NetBird is available as a hosted service or self-hosted. Its licence file puts the project under BSD 3-Clause, with the server components under AGPLv3.

Nebula

Nebula was created at Slack by Nate Brown and Ryan Huber, and Slack announced it as open source in November 2019. It is a mutually authenticated peer-to-peer network built on the Noise Protocol Framework, released under the MIT licence. A network has three parts, all run by the network owner: a certificate authority, which acts as the root of trust; lighthouses, which are hosts with a routable IP address that help other hosts find each other; and the hosts themselves. Each host’s certificate states its Nebula IP address, its name and the groups it belongs to. Defined Networking offers Managed Nebula for users who prefer not to manage their own certificate authority and lighthouses, and describes its service as a management plane rather than a control plane.

Netmaker

Netmaker builds networks on WireGuard and can be used as a managed service or self-hosted. Its self-hosting quick start begins with a cloud virtual machine with a static public IP address. The code is mostly under Apache 2.0, with a separate licence for its pro directory.

NordVPN Meshnet

Meshnet is a feature of the NordVPN app: you install NordVPN and turn on Meshnet on each device, and the devices connect over NordLynx. NordVPN describes Meshnet as open source and completely free to use, and its networking library, libtelio, is published under GPL-3.0. NordVPN runs the coordination, and its Meshnet documentation describes no self-hosted version.

Older tools

Older tools such as tinc and LogMeIn Hamachi also connected devices directly, and Hamachi marketed itself to gamers. tinc sends VPN traffic directly to the destination where possible, without intermediate hops.

What addresses and protocols does a mesh VPN use?

A mesh VPN gives each device its own address inside an overlay network and carries traffic between devices over a VPN protocol, most often WireGuard.

An overlay network with its own addresses

RFC 7890 defines an overlay network as a network built on top of another network, whose nodes are joined by virtual links that each correspond to a path through the underlying network. Tailscale, NetBird and Nebula are overlay networks in this sense.

Tailscale gives each device an address from 100.64.0.0/10. RFC 6598 reserves that range as shared address space for internet providers’ carrier-grade NAT (CGNAT) equipment, and Tailscale reuses it for addresses inside a tailnet. Each device also gets an IPv6 address from Tailscale’s own range, fd7a:115c:a1e0::/48. MagicDNS registers a DNS name for each device automatically. In Nebula, the address is written into each host’s certificate.

Where WireGuard fits

In plain WireGuard, each peer’s public key and allowed addresses are written into the configuration of every device it talks to. WireGuard leaves key distribution and pushed configuration to other tools, and a peer’s public key is usually sent out of band to whoever writes the configuration file. A mesh VPN built on WireGuard adds that layer, with a coordination service that distributes the keys and addresses each device would otherwise need written in by hand.

Tailscale, NetBird and Netmaker use WireGuard, and Meshnet uses NordLynx, NordVPN’s WireGuard-based protocol. ZeroTier and Nebula use protocols of their own. Whichever protocol a tool uses, the tunnel relies on encapsulation: each packet between two devices is encrypted and carried inside an ordinary packet sent across the internet.

How mesh VPNs get through NAT

A device behind NAT usually cannot accept unsolicited connections from the internet: the NAT drops incoming packets that are not part of a session the device started, unless port forwarding is set up. Mesh VPNs work around this with hole punching, and most fall back to a relay when it fails.

Hole punching works in three stages:

1. Each device learns its public address. It asks a server on the internet which public IP address and port its NAT has given it. STUN (RFC 8489) is the standard protocol for this.
2. The devices exchange addresses. They pass those addresses to each other through a rendezvous server that both can reach.
3. Both devices send at once. Each sends packets to the other’s public address. Each outgoing packet creates a mapping in the sender’s own NAT, so the other device’s packets arrive as replies and are let through. Ford, Srisuresh and Kegel described this technique for UDP, the internet’s lightweight connectionless transport protocol, in 2005.

In a mesh VPN, a service run for the network plays the rendezvous role:

• Tailscale uses its coordination server and DERP relays as a side channel for exchanging connection details (How NAT traversal works).
• NetBird agents exchange connection candidates through the Signal service in end-to-end encrypted messages (How NetBird works).
• ZeroTier root servers can send a device a “rendezvous” message with hints about how to reach the other device (ZeroTier protocol).
• Nebula lighthouses let hosts find each other and, optionally, use UDP hole punching.

ICE (RFC 8445) is the IETF protocol that uses STUN and TURN (RFC 8656), a standard relay protocol, to find a working path between two devices. NetBird uses ICE, through the pion/ice library. Tailscale uses a similar approach of its own, which departs from the ICE specification in places, and tries to create a direct connection between each pair of devices that communicate.

A path that has been opened stays open only while packets keep using it, so idle connections need keepalive packets. In plain WireGuard, this persistent keepalive is off by default.

Do you need to open router ports?

Usually not. Tailscale usually needs no firewall ports opened, NordVPN Meshnet needs no firewall rules or port forwarding, and ZeroTier advises against manual port forwarding, leaving the client to handle it with UPnP, NAT-PMP and IPv6. In Tailscale, allowing connections to the UDP port one device listens on may help two devices connect directly instead of through a relay. A Nebula lighthouse or a self-hosted coordination server is different: it must be reachable from the internet.

When hole punching fails

Hole punching can fail in three situations:

• A different public port for each destination. Some NATs give a device a new public port for every address it contacts, so the port the device learned through STUN is not the port its peer would need. RFC 4787 describes NAT mapping as endpoint-independent, address-dependent or address-and-port-dependent, and RFC 5128 groups the last two as endpoint-dependent mapping. The older term is symmetric NAT; Tailscale calls it “hard NAT”. Hole punching fails with this kind of NAT, and Tailscale and NetBird now say a relay is needed when both devices are behind such a NAT.
• UDP blocked. Hole punching relies on UDP, so a network that blocks it sends every connection through a relay (Tailscale connection types). NetBird relays traffic in that case if WebSocket over TCP is allowed.
• Several layers of NAT. Internet providers that use CGNAT add a layer of NAT in their own network, in front of the home router. ZeroTier advises that no more than one layer of NAT should sit between its endpoints and the internet. CGNAT does not rule out a direct connection: apart from port mapping protocols, Tailscale’s traversal techniques still work behind CGNAT, although two devices behind the same CGNAT may need a relay. Mobile carrier-grade NAT is one case where NetBird’s traversal can fail and its relay takes over.

Relays

When no direct path works, a relay forwards the encrypted traffic:

When a direct connection is not possible, Tailscale tries peer relays before DERP: devices in your own tailnet that you set up to relay traffic at high throughput when, for example, a strict NAT blocks a direct path. Tailscale released peer relays in beta on 29 October 2025 and made them generally available on 18 February 2026. They use UDP and are off until you set one up. Tailscale’s reason: DERP servers can add latency, especially for applications that move a lot of data.

Without a peer relay, the connection stays on DERP, where every Tailscale connection starts. Because private keys never leave the devices, a DERP server cannot decrypt the traffic. NetBird’s relay cannot decrypt it either, because of WireGuard’s point-to-point encryption. A DERP server carries WireGuard packets inside HTTPS connections. NetBird’s relay uses QUIC, and falls back to WebSocket over TCP when UDP is blocked.

Relayed connections are usually slower than direct ones, because traffic must travel to and from the relay server. Tailscale’s DERP servers also have limited quality of service, so they may offer lower maximum throughput.

What a relay can see

A relay that cannot decrypt traffic still sees that it is passing. Nebula relays can see packet routing metadata but cannot read or modify the contents (Defined Networking architecture). A lighthouse that acts as a relay learns which hosts are talking and how much.

How to tell whether a connection is direct or relayed

Each tool reports which path a connection is using. In Tailscale, tailscale ping shows whether a peer answered directly, through a peer relay or through a DERP relay, and tailscale status lists each peer’s connection as direct, peer relay or relay. In NetBird, netbird status -d shows each peer’s connection type as P2P or relayed. In ZeroTier, zerotier-cli peers shows whether each peer is reached directly or through a relay.

Who controls a mesh VPN?

The coordination service cannot read your traffic, because the private keys stay on the devices: Tailscale’s private keys never leave the device that generated them. NIST’s guide to IPsec VPNs (SP 800-77 Rev. 1) describes the opposite design, which it calls IKEless: a security controller negotiates the keys on its hosts’ behalf. NIST says this is not the preferred method, because the controllers then know every secret key their hosts use and can decrypt all the traffic between them.

But the coordination service hands out the keys, so whoever runs it decides which devices your devices trust, and could add a device to your network. In Nebula, that power sits with whoever holds the certificate authority’s key.

Tailscale says Tailnet Lock removes the need to trust its coordination server for distributing public keys to the devices in a tailnet.

Ways to limit that control

• Tailnet Lock (Tailscale). No new device can join unless devices you already trust sign it. Tailnet Lock and device approval cannot be used at the same time.
• Self-hosting Headscale. Headscale replaces Tailscale’s coordination server with one you run, for a single tailnet.
• Self-hosting NetBird. NetBird’s server components can run on your own server.
• Running Nebula yourself. You keep the certificate authority. Its private key should not be distributed, and it can be kept offline when it is not being used to add hosts. In Managed Nebula, Defined Networking holds the CA key.
• Running a ZeroTier controller. ZeroTier lets you run your own controller, but any commercial use of it needs a commercial licence.
• Self-hosting Netmaker. Netmaker’s server can run on your own infrastructure.

A self-hosted coordination server must be reachable from the internet, and its owner keeps it running and up to date. By default, a self-hosted Headscale network still relays traffic through Tailscale’s public DERP servers when devices cannot connect directly; Headscale’s built-in relay server is off unless its owner turns it on (example configuration).

What happens if the coordination service goes down?

Existing connections keep working for a while, but nothing in the network can change. Tailscale documents the effects for its own service:

• Existing connections between devices keep working until one of the devices’ keys expires.
• New users and devices cannot be added.
• Keys cannot be refreshed or exchanged, so existing devices gradually lose access to each other.
• Firewall rules cannot be updated.
• Existing users cannot have their keys revoked.

Tailscale’s control and data planes page adds that devices cannot establish new connections until the service is back.

Because keys cannot be revoked during an outage, a lost or compromised device keeps its access until its key expires, or for the whole outage if key expiry has been turned off for that device.

Depending on a vendor

A hosted coordination service exists only while its operator keeps running it. Meshnet is an example:

• 18 August 2025. In a post now headed Saying goodbye to our Meshnet feature, NordVPN said Meshnet would be fully shut down from 1 December 2025.
• 29 September 2025. In a second post, NordVPN said Meshnet was not going anywhere and that it would open-source it.
• October 2026. NordVPN describes Meshnet as open source and free.

With a self-hosted coordination service, that decision stays with whoever runs the server.

How secure is a mesh VPN?

A mesh VPN encrypts every connection between devices, but how far a compromised device can reach depends on the access rules, and new Tailscale and NetBird networks let every device reach every other device until you restrict them.

The encryption covers relayed traffic too. Tailscale encrypts all network communication end to end, whether devices connect directly or through a relay, and Nebula is mutually authenticated: both hosts prove their identity with certificates.

These controls limit what a compromised or stolen device can do:

• Access rules. Access rules (grants or ACLs in Tailscale) can restrict which devices, and which ports, each device reaches. Without restrictive rules, the mesh is one flat network in which every device can reach every other. Tailscale now recommends grants as its policy syntax, and ACLs continue to work.
• Port rules in each tool. Tailscale, NetBird and Nebula all support port-level rules. A Tailscale grant can name ports and protocols. A NetBird policy can allow, for example, only TCP port 5432, the PostgreSQL port. A Nebula rule combines a protocol, a port, and a host, group or address range.
• Host firewalls (Nebula). Each Nebula host enforces its own firewall rules, which can allow traffic based on the groups listed in the other host’s certificate. The firewall is default deny, and there is no way to write a deny rule.
• Device approval and key expiry. In Tailscale, an administrator can require that each new device is approved before it can join, and device keys expire, so users must re-authenticate on each device from time to time.

Tailnet Lock limits what the coordination service itself can add.

Who can see what in a mesh VPN

Each party along the path sees something different: the coordination service knows which devices exist and, in Tailscale’s case, receives logs of their connections by default; a relay knows which devices are talking through it; and your internet provider sees encrypted packets but not their contents.

Tailscale uses HTTPS on port 443 to reach its coordination and DERP servers, and UDP for direct tunnels. By default, each Tailscale client also streams logs to Tailscale that include open and close events for every connection between devices; each device can opt out.

Mesh traffic and network firewalls

Traffic between mesh devices is encrypted end to end, so a firewall on the network between them cannot inspect it. NIST makes this point about IPsec mesh encryption: “A full mesh encryption bypasses all network-based firewalls and intrusion detection systems because those systems can only accept or reject the encrypted stream without being able to inspect the data that has been encrypted. This could mean a reduction of security.” Filtering by what the traffic contains therefore happens in the mesh’s access rules and on the devices themselves.

Limitations of a mesh VPN

A mesh VPN depends on its coordination service, slows down when traffic is relayed, and does not hide your IP address from websites by default.

• Dependence on the coordination service. Whoever runs it controls which devices are trusted, and while it is down, nothing in the network can change.
• Slower relayed connections. When both devices sit behind NATs that change the port for each destination, or the network blocks UDP, traffic goes through a relay, which is usually slower than a direct path and may carry less data per second.
• One VPN app at a time on phones. On iOS, only one VPN app built on Apple’s packet tunnel framework can be enabled at a time. Android allows one active VPN service per user or profile. A mesh VPN app and another VPN app therefore usually cannot run together on a phone. There are narrow exceptions: Apple allows one Personal VPN configuration alongside an enterprise VPN, with the enterprise VPN taking precedence, and on Android a separate work profile can run its own VPN.
• No change to browsing by default. A mesh VPN changes the IP address websites see, and protects browsing on an untrusted network, only if you send internet traffic through another device, which Tailscale and NetBird call an exit node.
• A client on every device. Each device needs the client, unless it sits on a network behind a subnet router.
• Limited access for outsiders. By default, a service on a mesh VPN is reachable only from devices in it. Tailscale can share a device with people outside the tailnet, who sign in with their own Tailscale account. Tailscale Funnel and NetBird Reverse Proxy, both in beta, can expose a service to the public internet.
• No inspection by network firewalls. Network firewalls and intrusion detection systems between devices see only encrypted traffic, so filtering depends on the mesh’s own rules.
• Work for self-hosters. A self-hosted coordination server must be reachable from the internet and kept running by its owner. Headscale serves a single tailnet, and ZeroTier’s controller needs a commercial licence for commercial use.
• Local VPN rules. Rules on VPN use vary by country; the country-by-country guide shows where VPN use is restricted.

Terms that sound like mesh VPN

Several terms share the word “mesh” or describe something close to a mesh VPN, but they name different things.

• Mesh Wi-Fi. Several wireless access points work together to form one local Wi-Fi network, as in Wi-Fi EasyMesh. It covers a building; it does not connect devices across the internet.
• Peer-to-peer VPN. The term has two meanings. It can mean a mesh VPN, whose devices send traffic to each other peer to peer. Some consumer VPN providers also label servers “P2P” to show that they allow file-sharing traffic; traffic through those servers still goes through the provider’s server, not directly between your devices.
• Site-to-site full mesh. VPN gateways at several sites, each with a tunnel to every other site’s gateway.
• NIST’s mesh. NIST’s IPsec guide lists mesh among four primary architectures for IPsec-based VPNs. It describes it as “a large-scale host-to-host IPsec deployment”, also called mesh encryption, that “can be combined with the gateway-to-gateway architecture”. NIST’s use case is encrypting all connections within a network, cloud or data centre, and it notes that such meshes often authenticate hosts with certificates.
• Multi-hop or double VPN. A double VPN routes internet traffic through two VPN servers instead of one, as in Mullvad’s multihop feature.
• SD-WAN. A mesh VPN and SD-WAN are both overlays, but they do different jobs. A mesh VPN connects devices to each other. SD-WAN steers traffic between sites over one or more WAN connections according to policy. MEF 70.2 defines SD-WAN as an overlay built over one or more underlay connectivity services. NIST’s IPsec guide uses “SDWAN” more loosely, for networks in which a security controller configures IPsec between hosts.
• P2P file sharing. Peer-to-peer file sharing uses the same idea for a different job: devices share files with each other, rather than forming a private network. RFC 5694 describes a system as peer to peer when its elements share their resources to provide the service it was designed for.

Frequently asked questions

What is the difference between a VPN and a mesh VPN?

A consumer VPN routes your internet traffic through a provider’s server, and a business VPN gives users access to an internal network through a gateway. A mesh VPN connects your own devices directly to each other. A coordination service sits outside the data path (in Nebula, a certificate authority and lighthouses), and relays are used only when needed.

Do I need a mesh VPN or a regular VPN?

It depends on the job. To reach your own devices, such as a home server, a NAS or machines in different clouds, a mesh VPN is built for that. To change the IP address websites see or protect browsing on public Wi-Fi, a consumer VPN does that by default; a mesh VPN does it only through an exit node.

Is Tailscale a mesh VPN?

Yes. Tailscale builds WireGuard tunnels directly between your devices, coordinated by a service that Tailscale runs. When devices cannot connect directly, traffic goes through a peer relay, if you have set one up, or otherwise through one of Tailscale’s DERP servers. Headscale, an independent open-source project, can replace the coordination server for a single network.

Does a mesh VPN hide my IP address?

Not by default. In Tailscale and ZeroTier, for example, browsing leaves through your own connection, so websites see your own IP address. That changes only if you send internet traffic through an exit node. Websites then see the exit node’s address, such as that of your home connection or a cloud server.

Can the mesh VPN provider see my traffic?

Not the contents. Tailscale, NetBird, ZeroTier and Nebula encrypt traffic between devices, and their relays cannot decrypt it. The provider can see metadata: Tailscale clients, for example, send connection logs to Tailscale by default. The provider also decides which devices your devices trust, because its coordination service hands out the keys.

What is the main disadvantage of a mesh VPN?

Dependence on the coordination service: whoever runs it controls which devices can join, and while it is down no device can be added or have its access revoked. The other limits are slower relayed connections, no change to your IP address without an exit node, and, on phones, usually one VPN app at a time.

Is there a free mesh VPN?

Yes. Tailscale and ZeroTier offer free personal plans, both for non-commercial use only; NetBird has a free plan, and NordVPN Meshnet is free. Headscale, NetBird and Nebula can be self-hosted free of charge, including for business use, so the main cost is the server. ZeroTier’s self-hosted controller is free only for non-commercial use.

Is a mesh VPN the same as WireGuard?

No. WireGuard is a VPN protocol that encrypts traffic between peers and leaves key distribution to other tools. A mesh VPN adds a coordination service that distributes keys and addresses. Tailscale, NetBird and Netmaker build on WireGuard, Meshnet uses NordLynx, and ZeroTier and Nebula use protocols of their own.

Can you build a mesh VPN with plain WireGuard?

Yes, but by hand. Each device needs every peer’s public key and allowed addresses written into its configuration. WireGuard has no coordination service and no relay, and documents no NAT traversal of its own. In practice, at least one of two devices needs an address and port the other can reach.

Is a mesh VPN the same as mesh Wi-Fi?

No. Mesh Wi-Fi uses several wireless access points to cover a home or office with one local Wi-Fi network. A mesh VPN connects devices through encrypted tunnels over the internet, wherever they are. The two can be used together: a device on mesh Wi-Fi can also be part of a mesh VPN.

Can a mesh VPN connect devices behind CGNAT?

Yes. A mesh VPN connects directly when hole punching works. When it fails, for example because UDP is blocked or both devices sit behind NATs that change the port for each destination, traffic can go through a relay. The devices need no public or static IP address, but a self-hosted coordination server must be reachable from the internet.

Can I self-host Tailscale?

Not Tailscale’s own coordination server, which is closed source. Headscale, an independent open-source project (BSD 3-Clause), implements the Tailscale control server for a single tailnet and works with Tailscale clients. By default it still relays through Tailscale’s public DERP servers; its built-in relay is off, and turning it on adds it to those servers rather than replacing them.

Is there an open-source mesh VPN?

Yes. Nebula (MIT), Headscale (BSD 3-Clause) and Netmaker (mostly Apache 2.0) publish their code under open-source licences, and NetBird uses BSD 3-Clause with its server components under AGPLv3. Tailscale’s client is open source apart from the graphical interface of its Windows, macOS and iOS apps, and its coordination server is closed. ZeroTier’s client is open source; its controller is source-available.

Can I run a mesh VPN and another VPN on the same phone?

Usually not. Phones normally allow one active VPN app at a time: iOS enables only one app built on Apple’s packet tunnel framework, and on Android starting a new VPN service stops the one already running. The exceptions are narrow: one Personal VPN configuration on iOS, and a separate work profile on Android.

Is NordVPN Meshnet still available?

Yes. NordVPN announced in August 2025 that Meshnet would shut down on 1 December 2025, then reversed the decision in September 2025. As of October 2026, NordVPN describes Meshnet as open source and free to use. It runs inside the NordVPN app and uses NordLynx, and NordVPN documents no self-hosted version.