WireGuard vs Tailscale vs Headscale vs NetBird: la decisión sobre tu VPN mesh autoalojada

La respuesta primero: no es «WireGuard vs Tailscale»

WireGuard es un protocolo, lo que realmente cifra y mueve tus paquetes. Tailscale, Headscale y NetBird son control planes construidos sobre ese protocolo: gestionan la distribución de claves, el descubrimiento de peers, el NAT traversal y la política de acceso, para que no tengas que editar archivos de configuración a mano. Así que la popular búsqueda «WireGuard vs Tailscale» compara un protocolo con un producto. La decisión real es quién gestiona tu control plane. Aquí va la versión corta:

• Tailscale: quieres una VPN mesh que simplemente funcione, gestionada por otro, con la mejor experiencia de cliente y sin gestión de control plane. A cambio: un servidor de coordinación cerrado y alojado, y precios por usuario.
• Headscale: quieres exactamente la experiencia de cliente de Tailscale, pero con el servidor de coordinación autoalojado. Open source, gestionado por la comunidad, limitado a un único tailnet.
• NetBird: quieres un stack completamente abierto y completamente autoalojable (cliente y control plane), con identity/SSO integrados y política de acceso basada en grupos, y estás dispuesto a hacer funcionar más piezas móviles.
• WireGuard puro: tienes una topología pequeña y estática, quieres el máximo control y el data path más ligero posible, y gestionas las claves y la configuración tú mismo.

El resto de este artículo es el mapa, la tabla de decisión, la realidad del rendimiento (con un mecanismo real, no vaguedades), y un veredicto desde la perspectiva de un operador.

El mapa: protocolo, control plane, relay

Casi todas las comparativas en los resultados de búsqueda se saltan el único diagrama que hace que todo este espacio encaje. Aquí está como modelo por capas; cada producto toma decisiones distintas en cada capa:

De este modelo se derivan de inmediato dos consecuencias:

• Como todas las opciones usan el mismo data plane de WireGuard, el cifrado y el camino bruto de los paquetes son, en esencia, idénticos. Las diferencias de throughput vienen de cómo está implementado WireGuard (kernel vs userspace) y de si el tráfico va directo o por un relay, no del protocolo.
• «Autoalojado» significa algo distinto según el producto. Con Headscale autoalojas el servidor de coordinación, pero sigues usando los clientes oficiales de Tailscale. Con NetBird puedes autoalojarlo todo. Con Tailscale no autoalojas nada (aunque puedes hacer funcionar tu propio relay DERP). Esa distinción es toda la decisión, y la tabla de abajo la convierte en criterios.

La tabla de decisión

Estos son los criterios sobre los que la gente realmente decide. Los precios corresponden a las páginas de los proveedores en julio de 2026 y cambian a menudo; compruébalos de nuevo antes de comprometerte.

Algunas celdas merecen una explicación más amplia, porque es ahí donde la gente se lleva sorpresas.

Que los clientes sean abiertos no significa que el control plane lo sea. Los clientes de Tailscale son open source; su servidor de coordinación no lo es. Ahí es exactamente donde entra Headscale; es una reimplementación open source de ese servidor que tú mismo gestionas, combinada con los clientes oficiales de Tailscale. NetBird es open source de principio a fin (con los componentes de management, signal y relay bajo AGPLv3, y el resto bajo BSD-3-Clause).

La implementación de WireGuard es distinta, y se puede medir. El cliente de Tailscale usa un WireGuard en userspace (wireguard-go); NetBird usa el módulo de WireGuard en kernel en Linux cuando está disponible, y solo recurre a userspace cuando no lo está. Ese único hecho explica la mayoría de las diferencias de throughput entre ambos, como se explica a continuación.

Rendimiento: de dónde vienen realmente las diferencias

Todo el mundo repite: «todos usan WireGuard, así que el throughput es idéntico». Eso es cierto para el protocolo y falso en la práctica, por dos razones concretas: kernel vs userspace, y directo vs con relay.

Kernel vs userspace en WireGuard

El módulo de WireGuard en kernel procesa los paquetes dentro del kernel. Una implementación en userspace como wireguard-go tiene que mover cada paquete a través de la frontera user/kernel, y ese overhead de syscall por paquete (no el cifrado en sí) es el peaje que se paga. Escala con la tasa de paquetes, así que se nota más en cargas de trabajo con throughput alto y paquetes pequeños.

¿Cuál es la magnitud de esa diferencia? Toma los números de la gente que escribió la propia implementación en userspace. El blog técnico de Tailscale informa de una base de referencia de WireGuard en kernel de 2.66 Gbit/s frente a wireguard-go con 2.42 Gbit/s en la misma prueba, y tras añadir optimizaciones de segmentation-offload y batching, su camino en userspace alcanzó 5.36 Gbit/s, superando incluso la base de referencia del kernel sin optimizar. También mostraron que subir la MTU de 1500 a 9001 por sí solo hizo pasar a wireguard-go de 2.42 a 7.88 Gbit/s. Interpreta eso con honestidad: con una MTU por defecto y sin optimizar, el userspace paga una penalización real; con jumbo frames y offloads modernos, el camino en userspace puede ser muy rápido. La regla general de la comunidad, una penalización de ~10-15 % para el userspace en configuraciones por defecto, apunta en la dirección correcta, pero depende de la configuración.

Las conclusiones prácticas:

• Si necesitas saturar un enlace rápido con un solo flujo y quieres el camino más ligero, WireGuard en kernel puro (o el modo kernel de NetBird en Linux) tiene la ventaja en una configuración por defecto.
• La MTU importa más que la elección del producto. Una MTU de overlay mal configurada (el valor por defecto de la interfaz de WireGuard ronda los 1420, para dejar espacio a la encapsulación) te cuesta más throughput que kernel-vs-userspace. Ajusta primero la MTU correctamente.
• Para la inmensa mayoría del tráfico real (muchos flujos pequeños, muy por debajo de un gigabit) la diferencia es imperceptible, y deberías elegir en función de la operación y las funcionalidades, no de benchmarks.

Benchmarks independientes confirman esas conclusiones. Un estudio de la Universidad de Ámsterdam sobre un enlace de 1 Gbit/s descubrió que WireGuard en kernel y wireguard-go en userspace saturaban ambos el enlace (~900 Mbit/s), pero wireguard-go quemaba para ello el 230 % de un núcleo de CPU, frente a bastante menos de un núcleo para el módulo del kernel. El peaje del userspace se paga en CPU, y solo se convierte en un techo de throughput cuando la CPU es el cuello de botella (enlaces más rápidos, paquetes más pequeños). En hardware real de 10 GbE, Protectli midió WireGuard en kernel puro a 4.15-5.01 Gbit/s (iperf3, cuatro flujos) en sus equipos de gama media; en un equipo de escritorio modesto de 2016 sobre gigabit, TechOverflow midió Tailscale a 354/194 Mbit/s, aproximadamente la mitad de lo que el mismo enlace lograba sin él, exactamente el caso de CPU débil en el que el camino en userspace se convierte en el límite.

La única comparación directa que merece la pena citar es la del propio NetBird, y resulta refrescantemente honesta: al probar NetBird 0.68.3 contra Tailscale 1.96.4 en hosts cloud, ambos alcanzaron ~1.26-1.30 Gbit/s en un enlace de centro de datos dentro del mismo país, y el autor (que escribe en el blog de NetBird) concluyó que los dos son «básicamente iguales… sin ventaja consistente y repetible». Ese es el balance honesto: en hardware capaz, todos estos productos van a la par; la diferencia kernel-vs-userspace solo aparece cuando la CPU es el cuello de botella, y la MTU suele importar más que el producto elegido.

Directo vs con relay, y NAT traversal

Cuando dos peers pueden abrir una conexión directa, WireGuard funciona peer-to-peer y obtienes los números de arriba. Cuando no pueden (CGNAT en ambos extremos, firewalls estrictos, UDP bloqueado), el tráfico recurre a un relay, y un relay es un salto extra, compartido y ubicado geográficamente, que añade latencia y puede limitar el throughput.

• Tailscale y Headscale usan DERP (Designated Encrypted Relay for Packets). DERP reenvía paquetes de WireGuard ya cifrados, así que no puede descifrar tu tráfico; es un respaldo, no un man-in-the-middle. Puedes autoalojar un nodo DERP para controlar hacia dónde va el tráfico que pasa por relay.
• NetBird usa ICE (STUN para descubrir mappings públicos, TURN para hacer de relay) y ha ido pasando de Coturn a su propio relay basado en WebSocket.

¿Con qué frecuencia ocurre realmente ese respaldo, y qué cuesta? Tailscale es el único que publica cifras concretas, y son tranquilizadoras: la empresa informa de un «NAT traversal directo muy por encima del 90 %» en condiciones típicas, más de nueve de cada diez conexiones acaban siendo directas en lugar de pasar por relay, aunque no lo desglosa para los casos difíciles (CGNAT en ambos extremos, NAT simétrico), donde las probabilidades bajan. Cuando una conexión sí pasa por un relay, el coste en latencia depende de a qué distancia esté ese relay: en un estudio de caso de Tailscale sobre una ruta India-Estados Unidos, enrutar a través de un nodo DERP lejano dio 452 ms frente a 298 ms de una ruta más cercana y casi directa, un desvío evitable de unos 150 ms. NetBird no publica una cifra equivalente de tasa de éxito, así que para NetBird (y para tu propia red, sea cual sea la herramienta) el resultado directo-vs-relay y la penalización de latencia del relay son cosas que hay que medir, no dar por hecho.

Las cuatro opciones, con honestidad

WireGuard puro

Punto fuerte: la opción más ligera, más rápida y más auditable: una base de código diminuta dentro del kernel, sin control plane en el que confiar ni que gestionar. Para un puñado de peers estáticos (unos pocos servidores, un enlace site-to-site), nada la supera en simplicidad y rendimiento. Nosotros la usamos exactamente así en nuestra guía sobre una VPN site-to-site con WireGuard en VyOS.

Limitación más clara: no tiene control plane, y eso va bien hasta que deja de ir bien. Pasados unos diez peers, gestionar a mano las claves, la asignación de IP y el mesh de AllowedIPs se convierte en trabajo de verdad, y no hay NAT traversal integrado; los peers detrás de un CGNAT necesitan un relay que tienes que construir tú mismo. En cuanto quieres SSO, ACL o descubrimiento automático de peers, estás reconstruyendo lo que las otras tres ya son.

Tailscale

Punto fuerte: la mejor experiencia de la categoría. Los clientes son excelentes en todas las plataformas, el NAT traversal «simplemente funciona» vía DERP, el SSO y las ACL son de primera categoría, y no hay ningún control plane que gestionar. Si tu objetivo es un mesh funcionando esta misma tarde y no quieres gestionar infraestructura, este es el camino más corto.

Limitación más clara: el servidor de coordinación es de código cerrado y está alojado por Tailscale, y el precio es por usuario: un nivel Personal gratuito (6 usuarios, dispositivos ilimitados a julio de 2026), luego Standard a $8/user/month y Premium a $18/user/month. Para un equipo de infraestructura eso no es problema; para una flota grande o sensible al coste, el modelo por asiento y el control plane cerrado son las dos cosas que empujan a la gente hacia Headscale o NetBird.

Headscale

Punto fuerte: la experiencia de cliente de Tailscale con un control plane que es tuyo. Gestionas un único servidor open source (actualmente v0.29.x a julio de 2026) y apuntas a él los clientes oficiales de Tailscale, de modo que conservas las aplicaciones pulidas mientras la coordinación, las claves y las ACL viven en tu propio hardware, sin factura por asiento. El soporte de ACL (el motor policy v2) y un relay DERP integrado ya están ahí.

Limitación más clara: es un proyecto comunitario limitado a un único tailnet, deliberadamente no el producto multiinquilino con consola empresarial que vende Tailscale. No hay una GUI de administración oficial (las interfaces son de terceros), y el proyecto dice explícitamente que no soporta ejecutarse detrás de proxies inversos o en contenedores, aunque la gente lo haga igualmente. Encaja de maravilla para un equipo o una organización; no pretende ser una plataforma gestionada.

NetBird

Punto fuerte: la opción autoalojada más abierta y más completa en funcionalidades. El cliente y el control plane son ambos open source y completamente autoalojables, incluye identity/SSO (un IdP integrado en el stack autoalojado por defecto, más OIDC hacia Keycloak/Authentik/Entra/Okta), políticas de acceso basadas en grupos, y usa WireGuard en kernel en Linux para el data path más rápido. Las versiones recientes incluso añadieron un proxy inverso integrado para exponer servicios internos sin abrir puertos (beta). Si el objetivo es «autoalojarlo todo, con la identity integrada», NetBird es la respuesta más completa.

Limitación más clara: es el más joven y el más pesado de gestionar: servicios de management, signal y relay, más un IdP, frente al binario único de Headscale. Avanza rápido (v0.74.x a julio de 2026, con versiones frecuentes y algunas funcionalidades todavía en beta), lo cual es estupendo para las capacidades, pero también significa que estás siguiendo un objetivo que se mueve más deprisa. Reserva más tiempo para la configuración y las actualizaciones que con Tailscale o Headscale.

El ángulo del operador que ignoran los resultados de búsqueda de los proveedores

La mitad de los resultados de búsqueda sobre este tema los escribe el propio NetBird (su knowledge hub) o un partner proveedor, y ninguno cubre el caso que le importa a un operador de infraestructura: usar un mesh para llegar de forma segura a redes de management y fuera de banda.

El patrón es un mesh basado en WireGuard con enrutamiento de subred: un relay/nodo de salida dentro de una red protegida anuncia rutas hacia ella, de modo que los miembros autorizados del mesh pueden llegar a una VLAN de IPMI/BMC, un segmento de management OOB, o una red de servicios interna, sin exponer nada de eso a la internet pública. Bien hecho, esto sustituye el patrón del «servidor de salto sobre IP pública» por un overlay cuyo acceso está condicionado a la identidad: el acceso está ligado al SSO y se revoca de forma centralizada, el management plane nunca tiene un listener público, y cada salto va cifrado con WireGuard de extremo a extremo. Tailscale, Headscale y NetBird soportan todos el enrutamiento de subred; la elección entre ellos es la misma pregunta sobre la propiedad del control plane que en todos los demás casos, con el peso añadido de que, específicamente para el acceso a infraestructura, muchos operadores quieren el servidor de coordinación en su propio hardware (Headscale o NetBird autoalojado) en lugar de en el de un tercero.

El consejo práctico para ese caso de uso: anuncia solo la subred de management específica que necesitas en lugar de una ruta amplia, protégela detrás de una ACL ligada al grupo más pequeño posible, y mantén el propio router de subred parcheado y monitorizado; acaba de convertirse en un puente hacia tu red más sensible, así que merece el mismo escrutinio que un servidor bastión.

Veredicto, con condiciones

• Elige Tailscale si quieres la menor carga operativa y los mejores clientes, te sientes cómodo con un control plane cerrado y alojado, y el precio por usuario encaja con el tamaño de tu equipo. Es la opción por defecto adecuada para equipos zero-ops.
• Elige Headscale si te encanta la experiencia de Tailscale pero necesitas el servidor de coordinación en tu propio hardware: un equipo u organización, un único tailnet, sin factura por asiento. La respuesta más clara para «la UX de Tailscale, con control autoalojado».
• Elige NetBird si quieres todo abierto y autoalojado, con identity/SSO y política de acceso integrados, y puedes hacer funcionar unos cuantos servicios más para conseguirlo. La mejor opción para un mesh zero-trust completamente propio.
• Elige WireGuard puro si tu topología es pequeña y estática y quieres el camino más ligero, más rápido y más auditable, y no te importa gestionar tú mismo las claves y la configuración.

Para un operador de infraestructura en concreto, el factor decisivo suele ser la propiedad del control plane para el acceso a la red de management: eso empuja hacia Headscale o NetBird autoalojado por encima de la opción SaaS, incluso cuando Tailscale sería la opción más fácil desde el primer día.

Preguntas frecuentes

¿Tailscale es solo WireGuard?

No. Tailscale usa el protocolo WireGuard para su data plane, pero le añade todo un control plane encima: un servidor de coordinación para la distribución de claves y el descubrimiento de peers, relays DERP para el NAT traversal, SSO y ACL. Y su cliente usa una implementación de WireGuard en userspace (wireguard-go) en lugar del módulo del kernel. Así que Tailscale es WireGuard más todo lo que WireGuard deja fuera a propósito.

¿Está Headscale listo para producción?

Para el alcance para el que está pensado, sí: un único tailnet para un equipo u organización, gestionado por gente cómoda administrando un servidor open source por su cuenta. Soporta ACL y un relay DERP integrado, y funciona con los clientes oficiales de Tailscale. Lo que no es: una plataforma empresarial multiinquilino gestionada por GUI; ese es el producto de pago de Tailscale. Reserva Headscale para un despliegue dentro de una sola organización y funciona de maravilla; cuenta con manejarlo por CLI/API y aportar tu propio OIDC.

¿Se puede autoalojar NetBird por completo?

Sí. Esa es su característica definitoria. Tanto los clientes como el control plane (los servicios de management, signal y relay) son open source y autoalojables, y el stack de autoalojamiento por defecto incluye un proveedor de identidad integrado, así que puedes hacer funcionar todo el mesh (SSO incluido) en tu propia infraestructura, sin depender de la nube de ningún proveedor.

¿Cuál es el más rápido?

En una configuración por defecto, WireGuard en kernel puro (y el modo kernel de NetBird en Linux) tiene una pequeña ventaja sobre implementaciones en userspace como la de Tailscale, porque evita los cruces user/kernel en cada paquete; los propios benchmarks de Tailscale sitúan WireGuard en kernel en 2.66 Gbit/s frente a 2.42 para wireguard-go sin optimizar. Pero la MTU y que una conexión sea directa o pase por un relay influyen mucho más en el throughput que la elección del producto, y para el tráfico típico por debajo del gigabit la diferencia es imperceptible. Elige en función de la operación y las funcionalidades, no de un benchmark, a menos que estés saturando enlaces rápidos.

Dónde hacer funcionar el control plane, el relay o el nodo de salida

Todas las opciones aquí, salvo el Tailscale SaaS puro, necesitan un host: el servidor de coordinación de Headscale, el stack de management/signal/relay de NetBird, un nodo DERP autoalojado, o un exit/subnet-router de WireGuard, todos quieren una máquina pequeña, always-on, de baja latencia y con una IP pública estable. Eso encaja de forma natural con un VPS en nuestra nube, suficiente para un control plane y un relay, en la misma red ASN 55285 con mitigación DDoS permanente por delante del listener público. Si estás enrutando hacia infraestructura más pesada o haciendo funcionar nodos de salida a velocidad de línea, un servidor dedicado te da el ancho de banda no compartido y el control a nivel de kernel que WireGuard recompensa.

¿Ya estás construyendo directamente con WireGuard? Nuestras guías sobre una VPN site-to-site con WireGuard en VyOS y sobre una red troncal de router y VPN flexible en VyOS cubren el extremo de protocolo puro de este espectro, y nuestra guía de distribuciones Linux cubre el sistema operativo para hacer funcionar debajo de cualquiera de ellas.