NetBird vs. Tailscale: Mesh-VPN für verteilte Teams

WireGuard hat in den letzten Jahren die VPN-Landschaft komplett umgekrempelt. Es ist im Linux-Kernel, in Windows, macOS und iOS gut unterstützt, schnell, schlank im Code und einfach zu auditen. Das einzige, was WireGuard nicht von Haus aus mitbringt, ist eine Lösung für zwei der schwierigsten VPN-Probleme: NAT-Traversal und Key-Management auf vielen Geräten.

Genau hier setzen Mesh-VPN-Plattformen wie Tailscale und NetBird an. Beide bauen auf WireGuard auf, beide bauen ein vermaschtes Netz, in dem jeder Knoten direkt mit jedem reden kann — und beide lösen NAT-Traversal über STUN/TURN-ähnliche Mechanismen. Der Unterschied liegt im Geschäftsmodell, in der Self-Hosting-Option und in einigen Details, die je nach Anwendungsfall entscheidend sein können.

Was bedeutet “Mesh-VPN” überhaupt?

Klassisches VPN bedeutet: ein zentraler Gateway, an dem alle Clients hängen. Will ein Notebook im Homeoffice mit einem Server im Büro reden, geht der Traffic vom Notebook zum Gateway, dann vom Gateway zum Server, dann den gleichen Weg zurück. Bei verteilten Teams mit 20+ Endpunkten wird der Gateway schnell zum Engpass.

Mesh-VPN dreht das um: Jeder Knoten kennt jeden anderen und baut bei Bedarf eine direkte WireGuard-Verbindung auf. Der zentrale Server pflegt nur das Verzeichnis (welcher Knoten hat welchen Schlüssel, welche IP, welche Tags) — über ihn fliesst kein Nutzdaten-Traffic, ausser der NAT-Traversal scheitert und ein Relay aushilft.

NetBird und Tailscale im direkten Vergleich

Kriterium	NetBird	Tailscale
Lizenz	BSD-3-Clause (Komponenten meist Open-Source)	Open-Source-Client, proprietäre Control Plane
Self-Hosting Control Plane	Ja, offiziell und kostenfrei	Nicht direkt — über Drittprojekt Headscale möglich
SaaS-Variante	Vorhanden	Vorhanden, mit Free-Tier
Protokoll	WireGuard	WireGuard
NAT-Traversal	STUN + TURN (Coturn)	DERP-Relays (proprietär, Tailscale-gehostet)
Identity-Provider	OIDC (Google, Azure, Keycloak, Authentik etc.)	OIDC (Google, Microsoft, Apple etc.)
ACLs	JSON-/Policy-basiert in WebUI	”tailnet policy” in HuJSON-Datei
Clients	Linux, macOS, Windows, iOS, Android, Docker	Linux, macOS, Windows, iOS, Android
Exit-Node / Subnet-Router	unterstützt	unterstützt
MagicDNS / Service-Names	unterstützt	unterstützt
Auditierbarkeit	komplette Quelle inkl. Control Plane	nur Clients vollständig offen

Kernunterschied: NetBird ist eine echte Open-Source-Plattform, die komplett selbst gehostet werden kann. Tailscale ist hervorragend für SaaS-Bequemlichkeit, hat aber eine proprietäre Control Plane. Wer Tailscale-Clients selbst hosten will, geht den Umweg über Headscale — ein Community-Projekt, das die Tailscale-Control-Plane reimplementiert.

Wann welches Tool?

Tailscale ist die richtige Wahl, wenn:

• Schnelle Inbetriebnahme ohne Self-Hosting wichtiger ist als volle Kontrolle
• Der Free-Tier-Umfang reicht (Anzahl User und Devices prüfen)
• Eine kommerziell unterstützte SaaS-Lösung gewünscht ist
• Apple-Plattform-Integration besonders relevant ist (Tailscale ist hier sehr ausgereift)

NetBird ist die richtige Wahl, wenn:

• Die komplette Infrastruktur im eigenen Haus laufen soll (DSGVO, Data Residency, eigene Hoheit)
• Kostenfreies Self-Hosting ohne Bindung an Lizenzlimits gewünscht ist
• OIDC-Federation mit eigenem IdP (z.B. Authentik) gefordert ist
• Ein eigenes TURN/Relay im Datacenter platziert werden soll

Headscale ist eine Option, wenn:

• Die Tailscale-Clients gefallen, aber die Control Plane selbst gehostet werden muss
• Bestehende Tailscale-Skripte/Tooling weiter genutzt werden sollen
• Compliance-Audits einen vollständig auditierbaren Stack verlangen

Wer keine der drei Bedingungen stark gewichtet, fährt mit Tailscale am schnellsten — der Onboarding-Aufwand ist minimal.

Typische Use Cases

1. Mitarbeiter im Homeoffice

Notebook bekommt einen WireGuard-Tunnel ins Firmen-Subnetz, ohne dass die Firmen-Firewall einen klassischen VPN-Konzentrator braucht. Bei Tailscale/NetBird läuft das über einen Subnet-Router im Büro: Ein kleiner Linux-Host (oder die OPNsense direkt) wird Subnet-Router und gibt sein lokales Netz im Mesh frei.

2. Multi-Site-Connectivity

Drei kleine Niederlassungen mit je einer Firewall, ohne Site-to-Site-Tunnel auf Firewall-Ebene konfigurieren zu müssen. Jede Firewall (oder ein Linux-Host dahinter) wird Subnet-Router und annonciert ihr Subnetz im Mesh. Vorteil: Anbindung weiterer Standorte wird zum Drei-Klick-Vorgang.

3. Admin-Zugang zu Servern

Ein Server im RZ bekommt einen Mesh-Knoten installiert und ist nur über das Mesh erreichbar — kein offenes SSH ins Internet, kein Bastion-Host. ACLs steuern, welche User welche Server überhaupt sehen.

4. Entwicklungsumgebungen

Developer-Laptops bekommen automatisch Zugriff auf interne Datenbank-Dev-Instanzen, ohne dass IPs in YAML-Files gepflegt werden. MagicDNS sorgt dafür, dass db-dev im Mesh auflöst.

NAT-Traversal: das schwierigste Problem

Beide Plattformen versuchen primär eine direkte Verbindung zwischen den Peers herzustellen. Dazu wird über die Control Plane ein Handshake koordiniert (STUN-artig: jeder Knoten meldet seine externen IPs/Ports). Wenn Symmetric-NAT oder restriktive Firewalls die direkte Verbindung verhindern, springt ein Relay ein:

• Bei Tailscale: DERP (Designated Encrypted Relay for Packets) — proprietär, weltweit von Tailscale gehostet, kostenfrei
• Bei NetBird: Coturn als Standard-TURN-Server — entweder NetBird-gehostet oder selbst betrieben

Beide Relays sehen nur verschlüsselten WireGuard-Traffic — die Inhalte bleiben Ende-zu-Ende verschlüsselt. Wer aus Compliance-Gründen jedoch nicht will, dass auch verschlüsselter Traffic über einen Drittanbieter-Relay läuft, hat bei NetBird mit eigenem Coturn die saubere Option.

Setup-Beispiel: NetBird mit OPNsense als Subnet-Router

Szenario: Eine kleine Firma hat drei Mitarbeiter im Homeoffice und ein Büro mit OPNsense-Firewall. Das interne Subnetz 192.168.10.0/24 soll für die Mitarbeiter im Mesh erreichbar sein.

Schritt 1: NetBird-Management-Server bereitstellen

Entweder als SaaS bei netbird.io anmelden, oder per Docker Compose selbst hosten:

# auf einem öffentlich erreichbaren Server
git clone https://github.com/netbirdio/netbird.git
cd netbird/infrastructure_files
./getting-started-with-zitadel.sh   # bootstrapt Management + IdP

Schritt 2: NetBird-Client auf OPNsense (oder Linux-Host dahinter)

Auf OPNsense selbst gibt es kein offizielles NetBird-Plugin. Saubere Variante: ein kleines Linux-System (z.B. Debian-VM oder LXC auf Proxmox) hinter der OPNsense:

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

In der Management-UI wird dieser Host als Routing-Peer markiert und das Subnetz 192.168.10.0/24 zugewiesen. OPNsense bekommt eine statische Route Richtung diesem Host für das Mesh-Subnetz (typischerweise 100.x.x.x).

Schritt 3: Clients der Mitarbeiter

Jeder Mitarbeiter installiert den NetBird-Client auf seinem Notebook (Windows/macOS/Linux GUI verfügbar). Einmaliger Login per OIDC am eigenen IdP — danach läuft das Mesh permanent. Der Mitarbeiter sieht das Subnetz 192.168.10.0/24 so, als wäre er im Büro.

Schritt 4: ACLs

In der Management-UI werden Tags vergeben (z.B. office, homeoffice, admin) und Policies definiert: homeoffice darf office erreichen, aber Notebooks der homeoffice-Gruppe dürfen sich nicht gegenseitig sehen. So entsteht trotz Mesh eine sinnvolle Segmentierung.

Tailscale-Variante: Setup im Vergleich

Wer dasselbe Szenario mit Tailscale baut, hat weniger Schritte:

1. Bei tailscale.com einen Account mit OIDC anlegen
2. tailscale up auf jedem Client
3. Auf dem Subnet-Router: tailscale up --advertise-routes=192.168.10.0/24, dann im Admin-Panel die Route bestätigen
4. ACLs in der HuJSON-Policy schreiben

Das ist deutlich schneller — kostet aber den Self-Hosting-Aspekt. Wer denselben Komfort mit Self-Hosting will, geht zu Headscale; dann sind Schritte 2-4 identisch, nur die Control Plane läuft im eigenen RZ.

Sicherheits-Aspekte

• Kein Vertrauen in Relays nötig, weil WireGuard Ende-zu-Ende verschlüsselt — Relays sehen nur Bytes
• Pre-Auth-Keys / Setup-Keys sollten zeitlich begrenzt und einmal nutzbar konfiguriert werden
• OIDC-Login mit MFA-Pflicht — der Mesh-Account ist der Schlüssel zur ganzen Infrastruktur
• ACLs als Default-Deny — lieber explizit freigeben als versehentlich alle Peers sehen
• Audit-Log überwachen — neue Peers, Schlüssel-Rotation, ACL-Änderungen
• Exit-Node ist kein vollwertiger Internet-Gateway-Ersatz — Geschwindigkeit, Logging und Compliance unterscheiden sich von einer klassischen Firewall-Lösung

Performance in der Praxis

Bei direkter Verbindung (ohne Relay) bewegt sich WireGuard typischerweise nahe am Linerate des Anschlusses — die Mesh-Overhead-Komponenten (NAT-Traversal, Key-Exchange, Heartbeats) verursachen nur minimalen Overhead. Sobald ein Relay einspringt, hängt die erzielbare Bandbreite am Relay und an der Latenz zum Relay.

Eigene Benchmarks haben wir bewusst nicht ausgewiesen — die Werte hängen zu stark von NAT-Konfiguration, ISP und Endgerät ab, als dass sie reproduzierbar wären. Wer Performance-Zahlen für die eigene Umgebung will, sollte einen Lab-Test mit den eigenen Standorten machen.

Fazit

NetBird und Tailscale lösen dasselbe Problem — moderne Mesh-VPN auf WireGuard-Basis — aus unterschiedlichen Richtungen. Tailscale gewinnt bei Time-to-Value, NetBird gewinnt bei Hoheit über die Infrastruktur. Für KMU mit Compliance-Anforderungen, DSGVO-Sensitivität oder dem Wunsch nach eigener Kontrolle ist NetBird heute die bessere Wahl. Für Teams, die schnell loslegen wollen und keine eigene Control Plane betreiben möchten, ist Tailscale unschlagbar — und Headscale steht für später bereit, falls sich die Anforderungen ändern.

In jedem Fall sollte die Entscheidung nicht “VPN-Konzentrator vs. Mesh” lauten, sondern “wo brauchen wir Mesh, wo reicht klassisches Site-to-Site”. Hybride Setups, in denen das OPNsense-WireGuard-VPN für klassische Site-to-Site läuft und ein Mesh für Mitarbeiter und Admin-Zugang ergänzt, sind in der Praxis oft die robusteste Lösung.

Verwandte Artikel

• OPNsense WireGuard VPN einrichten
• OPNsense OpenVPN Remote-Access
• Authentik: Single Sign-On für Self-Hosted-Dienste
• Netzwerksegmentierung mit VLAN und OPNsense