WireGuard vs Tailscale vs Headscale vs NetBird: de keuze voor je self-hosted mesh-VPN

Eerst het antwoord: het is geen "WireGuard vs Tailscale"

WireGuard is een protocol, het onderdeel dat je packets daadwerkelijk versleutelt en verplaatst. Tailscale, Headscale en NetBird zijn control planes die bovenop dat protocol zijn gebouwd: ze regelen keydistributie, peer-discovery, NAT-traversal en toegangsbeleid, zodat jij niet handmatig configbestanden hoeft te bewerken. De populaire zoekopdracht "WireGuard vs Tailscale" vergelijkt dus een protocol met een product. De echte beslissing is wie je control plane beheert. Hier de korte versie:

• Tailscale: je wilt een mesh-VPN die gewoon werkt, beheerd door iemand anders, met de beste clientervaring en zonder control-plane-beheer. De prijs die je daarvoor betaalt is een gesloten, gehoste coördinatieserver en prijzen per gebruiker.
• Headscale: je wilt precies dezelfde clientervaring als Tailscale, maar met de coördinatieserver self-hosted. Open source, community-beheerd, beperkt tot één tailnet.
• NetBird: je wilt een volledig open, volledig self-hostable stack (client en control plane), met ingebouwde identity/SSO en groepsgebaseerd toegangsbeleid, en je bent bereid meer bewegende onderdelen te draaien.
• Kale WireGuard: je hebt een kleine, statische topologie, wilt maximale controle en het meest kale datapad, en beheert keys en config liever zelf.

De rest van dit artikel bestaat uit de kaart, de beslistabel, de prestatierealiteit (met een concreet mechanisme, niet met vage beweringen) en een oordeel vanuit operatorperspectief.

De kaart: protocol, control plane, relay

Bijna elke vergelijking in de zoekresultaten slaat precies het ene diagram over waardoor dit hele domein op zijn plek valt. Hier is het als gelaagd model; elk product maakt op elke laag andere keuzes:

Uit dit model volgen meteen twee gevolgen:

• Omdat elke optie dezelfde WireGuard data plane gebruikt, zijn de versleuteling en het kale packetpad in essentie identiek. Verschillen in doorvoer komen voort uit hoe WireGuard is geïmplementeerd (kernel vs userspace) en of verkeer direct gaat of via een relay, niet uit het protocol.
• "Self-hosted" betekent per product iets anders. Bij Headscale host je de coördinatieserver zelf, maar gebruik je nog steeds Tailscale's officiële clients. Bij NetBird kun je alles self-hosten. Bij Tailscale host je niets zelf (al kun je wel je eigen DERP-relay draaien). Dat onderscheid is de hele beslissing, en de tabel hieronder vertaalt het naar criteria.

De beslistabel

Dit zijn de dimensies waarop mensen daadwerkelijk kiezen. Prijzen zijn zoals vermeld op de pagina's van de vendors in juli 2026 en veranderen regelmatig; controleer ze opnieuw voordat je een keuze maakt.

Een paar cellen verdienen uitleg, want dat is waar mensen verrast worden.

Open clients betekent niet een open control plane. Tailscale's clients zijn open source; de coördinatieserver niet. Precies daar speelt Headscale op in; het is een open-source herimplementatie van die server die je zelf draait, gecombineerd met Tailscale's officiële clients. NetBird is end-to-end open source (met de management-, signal- en relaycomponenten onder AGPLv3 en de rest onder BSD-3-Clause).

De WireGuard-implementatie verschilt, en dat is meetbaar. Tailscale's client gebruikt een userspace-WireGuard (wireguard-go); NetBird gebruikt de kernel-WireGuard-module op Linux wanneer die beschikbaar is, en valt alleen terug op userspace als dat niet zo is. Dat ene feit is de bron van de meeste doorvoerverschillen tussen beide, hierna uitgelegd.

Prestaties: waar de verschillen daadwerkelijk vandaan komen

Iedereen herhaalt: "ze gebruiken allemaal WireGuard, dus de doorvoer is identiek." Dat klopt voor het protocol en klopt niet in de praktijk, om twee concrete redenen: kernel vs userspace, en direct vs via een relay.

Kernel vs userspace WireGuard

De kernel-WireGuard-module verwerkt packets binnen de kernel. Een userspace-implementatie zoals wireguard-go moet elk packet over de user/kernel-grens heen bewegen, en die syscall-overhead per packet (niet de versleuteling zelf) is de tol die je betaalt. Dat schaalt met het packet-tempo, dus het valt vooral op bij workloads met hoge doorvoer en kleine packets.

Hoe groot is dat verschil? Gebruik de cijfers van de mensen die de userspace-implementatie hebben geschreven. Tailscale's eigen engineeringblog meldt een in-kernel-WireGuard-baseline van 2.66 Gbit/s tegenover wireguard-go op 2.42 Gbit/s in dezelfde test, en na het toevoegen van segmentation-offload- en batching-optimalisaties haalde hun userspace-pad 5.36 Gbit/s, wat de ongeoptimaliseerde kernel-baseline daadwerkelijk verslaat. Ze lieten ook zien dat het optrekken van de MTU van 1500 naar 9001 wireguard-go alleen al van 2.42 naar 7.88 Gbit/s bracht. Lees dat op waarde: bij een standaard-MTU, ongeoptimaliseerde setup betaalt userspace een reële straf; met jumbo frames en moderne offloads kan het userspace-pad erg snel zijn. De in de community gebruikelijke vuistregel van zo'n ~10–15% straf voor userspace bij standaardconfiguraties klopt qua richting, maar is configuratieafhankelijk.

De praktische conclusies:

• Moet je een snelle link met één enkele flow verzadigen en wil je het meest kale pad, dan heeft kale kernel-WireGuard (of NetBirds kernelmodus op Linux) de voorsprong bij een standaardconfiguratie.
• MTU is belangrijker dan de productkeuze. Een verkeerd geconfigureerde overlay-MTU (WireGuard's interface-standaard ligt rond de 1420, om ruimte te laten voor encapsulatie) kost je meer doorvoer dan kernel-versus-userspace. Zorg dat de MTU eerst goed staat.
• Voor de overgrote meerderheid van echt verkeer (veel kleine flows, ruim onder een gigabit) is het verschil niet merkbaar, en kies je beter op basis van beheer en features dan op benchmarks.

Onafhankelijke benchmarks bevestigen die conclusies. Een onderzoek van de Universiteit van Amsterdam over een 1 Gbit/s-link liet zien dat kernel-WireGuard en userspace-wireguard-go de link allebei verzadigden (~900 Mbit/s), maar wireguard-go verbrandde daarvoor 230% van een CPU-core, tegenover ruim minder dan één core voor de kernelmodule. De userspace-tol is CPU, en die wordt pas een plafond voor de doorvoer zodra de CPU het knelpunt is (snellere links, kleinere packets). Op echte 10GbE-hardware mat Protectli kale kernel-WireGuard op 4.15–5.01 Gbit/s (iperf3, vier streams) over zijn middenklasse-appliances; op een bescheiden desktop uit 2016 over gigabit mat TechOverflow Tailscale op 354/194 Mbit/s, ongeveer de helft van wat diezelfde link zonder Tailscale haalde, precies het scenario met een zwakke CPU waarin het userspace-pad de beperkende factor is.

De enige directe vergelijking die het vermelden waard is, is die van NetBird zelf, en die is verfrissend eerlijk: bij het testen van NetBird 0.68.3 tegen Tailscale 1.96.4 op cloudhosts haalden beide ~1.26–1.30 Gbit/s over een datacenterlink binnen hetzelfde land, en concludeerde de auteur (schrijvend op NetBirds eigen blog) dat de twee "in essentie hetzelfde" zijn, "geen consistent, herhaalbaar voordeel." Dat is de eerlijke conclusie: op capabele hardware houden ze allemaal gelijke tred met elkaar; het kernel-versus-userspace-verschil duikt alleen op zodra de CPU het knelpunt is, en MTU is meestal belangrijker dan het gekozen product.

Direct vs via relay, en NAT-traversal

Wanneer twee peers een directe verbinding kunnen opzetten, draait WireGuard peer-to-peer en krijg je de cijfers hierboven. Kan dat niet (CGNAT aan beide kanten, strikte firewalls, geblokkeerde UDP), dan valt het verkeer terug op een relay, en een relay is een gedeelde, geografisch geplaatste extra hop die latency toevoegt en de doorvoer kan beperken.

• Tailscale en Headscale gebruiken DERP (Designated Encrypted Relay for Packets). DERP stuurt al versleutelde WireGuard-packets door, dus het kan je verkeer niet ontsleutelen; het is een fallback, geen man-in-the-middle. Je kunt zelf een DERP-node hosten om te bepalen waar gerelayed verkeer naartoe gaat.
• NetBird gebruikt ICE (STUN om publieke mappings te ontdekken, TURN om te relayen) en is bezig over te stappen van Coturn naar een eigen WebSocket-gebaseerde relay.

Hoe vaak gebeurt die fallback daadwerkelijk, en wat kost het? Tailscale is de enige die harde cijfers publiceert, en die zijn geruststellend: het meldt "directe NAT-traversal ruim boven de 90%" onder normale omstandigheden, meer dan negen van de tien verbindingen komen direct tot stand in plaats van via een relay, al wordt dat niet uitgesplitst voor de lastige gevallen (CGNAT aan beide kanten, symmetrische NAT), waar de kansen dalen. Loopt een verbinding wel via een relay, dan is de latencykost afhankelijk van hoe ver die relay vandaan staat: in één Tailscale-casestudy over een pad van India naar de VS mat een route via een verafgelegen DERP-node 452 ms tegenover 298 ms voor een dichterbij gelegen, bijna-directe route, zo'n 150 ms vermijdbare omweg. NetBird publiceert geen vergelijkbaar succespercentage, dus voor NetBird (en voor je eigen netwerk, welk gereedschap je ook gebruikt) zijn de uitkomst direct-versus-relay en de latencystraf van de relay dingen om te meten, niet om aan te nemen.

De vier opties, eerlijk bekeken

Kale WireGuard

Sterkste punt: de meest kale, snelste, best controleerbare optie: een kleine, in-kernel codebase zonder control plane om te vertrouwen of te draaien. Voor een handvol statische peers (een paar servers, een site-to-site-link) is niets beter qua eenvoud en prestaties. Wij gebruiken het precies zo in onze gids over een site-to-site-VPN met WireGuard op VyOS.

Scherpste beperking: het heeft geen control plane, en dat is prima totdat het niet meer prima is. Voorbij een graad of tien peers wordt het handmatig beheren van keys, IP-allocatie en de AllowedIPs-mesh echt werk, en er is geen ingebouwde NAT-traversal; peers achter CGNAT hebben een relay nodig die je zelf moet bouwen. Zodra je SSO, ACL's of automatische peer-discovery wilt, ben je aan het herbouwen wat de andere drie al zijn.

Tailscale

Sterkste punt: de beste ervaring in deze categorie. De clients zijn uitstekend op elk platform, NAT-traversal "werkt gewoon" via DERP, SSO en ACL's zijn eersteklas, en er is geen control plane om te beheren. Is je doel een werkende mesh vanmiddag nog, zonder zelf infrastructuur te draaien, dan is dit de kortste weg.

Scherpste beperking: de coördinatieserver is closed source en wordt gehost door Tailscale, en de prijs is per gebruiker: een gratis Personal-tier (6 gebruikers, onbeperkt aantal devices per juli 2026), daarna Standard voor $8/user/month en Premium voor $18/user/month. Voor een infrastructuurteam is dat prima; voor een grote of kostengevoelige fleet zijn het per-seat-model en de gesloten control plane de twee dingen die mensen richting Headscale of NetBird duwen.

Headscale

Sterkste punt: Tailscale's clientervaring met een control plane die van jou is. Je draait één open-source server (momenteel v0.29.x per juli 2026) en wijst de officiële Tailscale-clients daarnaartoe, zodat je de gepolijste apps behoudt terwijl de coördinatie, keys en ACL's op je eigen hardware staan, zonder rekening per seat. ACL-ondersteuning (de policy-v2-engine) en een ingebouwde DERP-relay zijn aanwezig.

Scherpste beperking: het is een community-project, beperkt tot één tailnet, bewust niet het multi-tenant enterprise-consoleproduct dat Tailscale verkoopt. Er is geen officiële admin-GUI (UI's komen van derden), en het project zegt expliciet dat het draaien achter reverse proxy's of in containers niet wordt ondersteund, ook al doen mensen dat wel. Het is een uitstekende fit voor één team of één organisatie; het probeert geen managed platform te zijn.

NetBird

Sterkste punt: de meest open en meest feature-complete self-hosted optie. Client en control plane zijn allebei open source en volledig self-hostable, het levert identity/SSO (een ingebouwde IdP in de standaard self-host-stack, plus OIDC naar Keycloak/Authentik/Entra/Okta), groepsgebaseerd toegangsbeleid, en het gebruikt kernel-WireGuard op Linux voor het snelste datapad. Recente releases voegden zelfs een ingebouwde reverse proxy toe om interne diensten te ontsluiten zonder poorten te openen (beta). Is "alles self-hosten, met identity ingebouwd" het doel, dan is NetBird het meest complete antwoord.

Scherpste beperking: het is de jongste en de zwaarste om te draaien: management-, signal- en relaydiensten plus een IdP, tegenover Headscale's ene binary. Het beweegt snel (v0.74.x per juli 2026, met frequente releases en sommige features nog in beta), wat goed is voor de mogelijkheden maar betekent dat je een sneller bewegend doelwit volgt. Reserveer meer tijd voor setup en upgrades dan bij Tailscale of Headscale.

De operatorinvalshoek die de vendor-zoekresultaten negeren

De helft van de zoekresultaten over dit onderwerp is geschreven door NetBird zelf (hun eigen knowledge hub) of een vendor-partner, en geen daarvan behandelt de use case die er voor een infrastructuuroperator toe doet: een mesh gebruiken om veilig bij management- en out-of-band-netwerken te komen.

Het patroon is een WireGuard-gebaseerde mesh met subnet routing: een relay/exit-node binnen een beschermd netwerk adverteert routes ernaartoe, zodat geautoriseerde mesh-leden bij een IPMI/BMC-VLAN, een OOB-managementsegment of een intern servicenetwerk kunnen komen zonder daar iets van bloot te stellen aan het publieke internet. Goed uitgevoerd vervangt dit het patroon van "jump box op een publiek IP" door een identity-gated overlay: toegang is gekoppeld aan SSO en wordt centraal ingetrokken, de management plane heeft nooit een publieke listener, en elke hop is end-to-end WireGuard-versleuteld. Tailscale, Headscale en NetBird ondersteunen allemaal subnet routing; de keuze daartussen is dezelfde vraag over eigenaarschap van de control plane als overal elders, met als extra gewicht dat, specifiek voor infrastructuurtoegang, veel operators de coördinatieserver op hun eigen hardware willen (Headscale of self-hosted NetBird) in plaats van die van een derde partij.

Het praktische advies voor die use case: adverteer alleen het specifieke managementsubnet dat je nodig hebt in plaats van een brede route, plaats er een ACL voor die is gekoppeld aan de kleinst mogelijke groep, en houd de subnet router zelf gepatcht en gemonitord; die is zojuist een brug geworden naar je meest gevoelige netwerk, en verdient dus dezelfde mate van aandacht als een bastion host.

Oordeel, met voorwaarden

• Kies Tailscale als je de minste operationele last en de beste clients wilt, je geen probleem hebt met een gesloten, gehoste control plane, en prijzen per gebruiker passen bij je teamgrootte. Het is de juiste standaardkeuze voor zero-ops-teams.
• Kies Headscale als je dol bent op de Tailscale-ervaring maar de coördinatieserver op je eigen hardware nodig hebt: één team of organisatie, één tailnet, geen rekening per seat. Het schoonste antwoord voor "Tailscale-UX, self-hosted control".
• Kies NetBird als je alles open en self-hosted wilt, met identity/SSO en toegangsbeleid ingebouwd, en je bereid bent een paar extra diensten te draaien om dat te krijgen. De beste fit voor een volledig in eigen beheer zijnde zero-trust-mesh.
• Kies kale WireGuard als je topologie klein en statisch is en je het meest kale, snelste, best controleerbare pad wilt, en je prima zelf keys en config beheert.

Voor een infrastructuuroperator specifiek is de doorslaggevende factor meestal het eigenaarschap van de control plane voor toegang tot het managementnetwerk: dat trekt richting Headscale of self-hosted NetBird boven de SaaS-optie, ook als Tailscale op dag één de makkelijkere keuze zou zijn.

Veelgestelde vragen

Is Tailscale gewoon WireGuard?

Nee. Tailscale gebruikt het WireGuard-protocol voor zijn data plane, maar voegt er een hele control plane aan toe: een coördinatieserver voor keydistributie en peer-discovery, DERP-relays voor NAT-traversal, SSO en ACL's. En het gebruikt in zijn client een userspace-implementatie van WireGuard (wireguard-go) in plaats van de kernelmodule. Tailscale is dus WireGuard plus alles wat WireGuard bewust weglaat.

Is Headscale productierijp?

Voor het beoogde toepassingsgebied wel: één tailnet voor een team of organisatie, beheerd door mensen die het prima vinden om zelf één open-source server te draaien. Het ondersteunt ACL's en een ingebouwde DERP-relay, en werkt samen met de officiële Tailscale-clients. Wat het niet is: een multi-tenant, GUI-beheerd enterpriseplatform; dat is Tailscale's betaalde product. Zet Headscale in voor een deployment binnen één organisatie en het staat als een huis; reken erop dat je het via CLI/API aanstuurt en je eigen OIDC meebrengt.

Kan NetBird volledig self-hosted draaien?

Ja. Dat is precies waar het om draait. Zowel de clients als de control plane (management-, signal- en relaydiensten) zijn open source en self-hosted te draaien, en de standaard self-host-stack bevat een ingebouwde identity provider, dus je kunt de hele mesh (inclusief SSO) op je eigen infrastructuur draaien, zonder afhankelijkheid van de cloud van een vendor.

Wat is het snelst?

Bij een standaardconfiguratie heeft kale kernel-WireGuard (en NetBirds kernelmodus op Linux) een klein voordeel ten opzichte van userspace-implementaties zoals die van Tailscale, omdat het geen user/kernel-overgangen per packet nodig heeft; Tailscale's eigen benchmarks zetten kernel-WireGuard op 2.66 Gbit/s tegenover 2.42 voor ongeoptimaliseerde wireguard-go. Maar MTU en of een verbinding direct is of via een relay loopt, beïnvloeden de doorvoer veel sterker dan de productkeuze, en bij typisch verkeer onder de gigabit is het verschil niet merkbaar. Kies op basis van beheer en features, niet op basis van een benchmark, tenzij je snelle links wilt verzadigen.

Waar je de control plane, relay of exit node draait

Elke optie hier, behalve pure SaaS-Tailscale, heeft een host nodig: Headscale's coördinatieserver, NetBirds management/signal/relay-stack, een self-hosted DERP-node, of een WireGuard-exit/subnet-router willen allemaal een kleine, always-on, low-latency machine met een stabiel publiek IP. Dat is een natuurlijke fit voor een VPS in onze cloud, genoeg voor een control plane en een relay, op hetzelfde ASN 55285-netwerk met always-on DDoS-mitigatie voor de publieke listener. Route je naar zwaardere infrastructuur, of draai je exit nodes op line rate, dan geeft een dedicated server je de onbetwiste bandbreedte en kernel-level controle waar WireGuard baat bij heeft.

Bouw je al direct met WireGuard? Onze gidsen over een site-to-site-VPN met WireGuard op VyOS en een flexibele router- en VPN-backbone op VyOS behandelen het kale-protocol-uiteinde van dit spectrum, en onze Linux-distributiegids behandelt het OS om eronder te draaien, wat je ook kiest.