NetBird vs. Tailscale: Mesh VPN for Distributed Teams

WireGuard has reshaped the VPN landscape over the last few years. It is well supported in the Linux kernel, on Windows, macOS and iOS, fast, slim in code and easy to audit. The only things WireGuard does not bring out of the box are solutions for two of the hardest VPN problems: NAT traversal and key management across many devices.

This is exactly where mesh VPN platforms like Tailscale and NetBird come in. Both build on WireGuard, both create a meshed network in which every node talks directly to every other — and both solve NAT traversal via STUN/TURN-like mechanisms. The difference lies in the business model, in the self-hosting option, and in a few details that can be decisive depending on the use case.

What Does “Mesh VPN” Even Mean?

Classic VPN means: a central gateway with all clients connected to it. If a laptop at home wants to reach a server in the office, traffic flows from the laptop to the gateway, then from the gateway to the server, and back the same way. With distributed teams of 20+ endpoints, the gateway quickly becomes the bottleneck.

Mesh VPN inverts this: every node knows every other and builds a direct WireGuard connection as needed. The central server only maintains the directory (which node holds which key, which IP, which tags) — no payload traffic flows through it, unless NAT traversal fails and a relay steps in.

NetBird and Tailscale in Direct Comparison

Criterion	NetBird	Tailscale
License	BSD-3-Clause (most components open source)	Open-source client, proprietary control plane
Self-host control plane	Yes, officially and free	Not directly — possible via third-party Headscale
SaaS option	Available	Available, with free tier
Protocol	WireGuard	WireGuard
NAT traversal	STUN + TURN (Coturn)	DERP relays (proprietary, Tailscale-hosted)
Identity provider	OIDC (Google, Azure, Keycloak, Authentik etc.)	OIDC (Google, Microsoft, Apple etc.)
ACLs	JSON / policy-based in WebUI	”tailnet policy” in HuJSON file
Clients	Linux, macOS, Windows, iOS, Android, Docker	Linux, macOS, Windows, iOS, Android
Exit node / subnet router	supported	supported
MagicDNS / service names	supported	supported
Auditability	full source incl. control plane	only clients fully open

Key difference: NetBird is a real open-source platform that can be fully self-hosted. Tailscale is excellent for SaaS convenience but has a proprietary control plane. If you want to self-host Tailscale clients, you go via Headscale — a community project that re-implements the Tailscale control plane.

When Which Tool?

Tailscale is the right choice when:

• Fast onboarding without self-hosting matters more than full control
• The free-tier limits are enough (check user/device count)
• A commercially supported SaaS solution is desired
• Apple platform integration matters a lot (Tailscale is very polished here)

NetBird is the right choice when:

• The full infrastructure must run in-house (GDPR, data residency, own sovereignty)
• Free self-hosting without license limits is desired
• OIDC federation with your own IdP (e.g. Authentik) is required
• You want to place your own TURN/relay in your data center

Headscale is an option when:

• You like the Tailscale clients but need to self-host the control plane
• Existing Tailscale scripts/tooling should keep working
• Compliance audits require a fully auditable stack

If none of the three conditions weighs heavily, Tailscale is the fastest path — onboarding overhead is minimal.

Typical Use Cases

1. Employees working from home

A laptop gets a WireGuard tunnel into the company subnet without the company firewall needing a classic VPN concentrator. With Tailscale/NetBird this runs via a subnet router in the office: a small Linux host (or OPNsense directly) becomes the subnet router and exposes its local network in the mesh.

2. Multi-site connectivity

Three small branch offices each with a firewall, without configuring site-to-site tunnels at the firewall level. Each firewall (or a Linux host behind it) becomes a subnet router and advertises its subnet in the mesh. Upside: connecting another site becomes a three-click operation.

3. Admin access to servers

A data-center server gets a mesh node installed and is only reachable through the mesh — no SSH open to the internet, no bastion host. ACLs control which users can even see which servers.

4. Dev environments

Developer laptops get automatic access to internal database dev instances without IPs in YAML files. MagicDNS makes db-dev resolvable in the mesh.

NAT Traversal: The Hardest Problem

Both platforms primarily try to establish a direct connection between peers. The handshake is coordinated through the control plane (STUN-like: each node reports its external IPs/ports). If symmetric NAT or restrictive firewalls block the direct connection, a relay jumps in:

• Tailscale: DERP (Designated Encrypted Relay for Packets) — proprietary, hosted worldwide by Tailscale, free
• NetBird: Coturn as default TURN server — either NetBird-hosted or self-operated

Both relays only see encrypted WireGuard traffic — content stays end-to-end encrypted. But if for compliance reasons you do not want even encrypted traffic to traverse a third-party relay, NetBird with your own Coturn is the clean option.

Setup Example: NetBird with OPNsense as Subnet Router

Scenario: A small company has three employees working from home and an office with an OPNsense firewall. The internal subnet 192.168.10.0/24 should be reachable for the employees through the mesh.

Step 1: Provide the NetBird management server

Either sign up for the SaaS at netbird.io, or self-host via Docker Compose:

# on a publicly reachable server
git clone https://github.com/netbirdio/netbird.git
cd netbird/infrastructure_files
./getting-started-with-zitadel.sh   # bootstraps management + IdP

Step 2: NetBird client on OPNsense (or a Linux host behind it)

There is no official NetBird plugin on OPNsense itself. The clean variant: a small Linux system (e.g. Debian VM or LXC on Proxmox) behind the OPNsense:

curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --setup-key <key-from-management-ui>

In the management UI this host is marked as a routing peer and the subnet 192.168.10.0/24 is assigned. OPNsense gets a static route to this host for the mesh subnet (typically 100.x.x.x).

Step 3: Employee clients

Each employee installs the NetBird client on their laptop (Windows/macOS/Linux GUI available). One-off login via OIDC at the own IdP — the mesh runs permanently from then on. The employee sees subnet 192.168.10.0/24 as if they were in the office.

Step 4: ACLs

In the management UI you assign tags (e.g. office, home, admin) and define policies: home may reach office, but home-group laptops cannot see each other. Despite the mesh, this gives you sensible segmentation.

Tailscale Variant: Setup in Comparison

Building the same scenario with Tailscale takes fewer steps:

1. Create a tailscale.com account with OIDC
2. tailscale up on every client
3. On the subnet router: tailscale up --advertise-routes=192.168.10.0/24, then approve the route in the admin panel
4. Write ACLs in the HuJSON policy

That is clearly faster — but costs the self-hosting aspect. If you want the same convenience with self-hosting, go to Headscale; steps 2-4 are identical, only the control plane runs in your own data center.

Security Aspects

• No trust in relays required, because WireGuard is end-to-end encrypted — relays see only bytes
• Pre-auth keys / setup keys should be time-limited and single-use
• OIDC login with mandatory MFA — the mesh account is the key to the whole infrastructure
• ACLs as default-deny — explicitly allow rather than accidentally exposing all peers
• Monitor the audit log — new peers, key rotation, ACL changes
• Exit node is not a full internet gateway replacement — speed, logging and compliance differ from a classic firewall solution

Performance in Practice

For a direct connection (without relay), WireGuard typically reaches near the line rate of the link — the mesh overhead (NAT traversal, key exchange, heartbeats) is minimal. As soon as a relay steps in, achievable bandwidth depends on the relay and the latency to it.

We deliberately did not publish our own benchmarks — values depend too strongly on NAT configuration, ISP and endpoint to be reproducible. Anyone wanting performance numbers for their own environment should run a lab test with their actual sites.

Conclusion

NetBird and Tailscale solve the same problem — modern mesh VPN on top of WireGuard — from different directions. Tailscale wins on time-to-value, NetBird wins on infrastructure sovereignty. For SMBs with compliance requirements, GDPR sensitivity or a desire for self-control, NetBird is the better choice today. For teams that want to get started fast and do not want to run their own control plane, Tailscale is hard to beat — and Headscale is there for later if requirements change.

In any case, the decision should not be “VPN concentrator vs. mesh” but “where do we need mesh, where does classic site-to-site suffice?”. Hybrid setups, where OPNsense WireGuard VPN handles classic site-to-site and a mesh complements it for employees and admin access, are often the most robust solution in practice.

Related Articles

• OPNsense WireGuard VPN Setup
• OPNsense OpenVPN Remote Access
• Authentik: Single Sign-On for Self-Hosted Services
• Network Segmentation with VLAN and OPNsense