Firezone lanza sanstun: WireGuard en Rust paralelo

Firezone anunció sanstun, una implementación en Rust de la máquina de estados de WireGuard con diseño sans-IO, disponible en crates.io bajo licencia Apache 2.0. La decisión llega después de más de dos años manteniendo un fork propio de boringtun que acumuló más de 70 pull requests entre correcciones de bugs y APIs nuevas.

Para quien construye producto sobre WireGuard —una VPN, una malla de dispositivos, un gateway de acceso remoto— la noticia no es solo una librería nueva. Es un cambio en cómo se puede paralelizar el trabajo criptográfico sin tocar el estado compartido, y una señal de que el ecosistema de infraestructura en Rust está madurando hacia APIs más explícitas.

¿Qué es sanstun y por qué Firezone dejó de usar boringtun?

Firezone es una plataforma de acceso remoto construida sobre WireGuard, fundada en 2021 en Mountain View y participante de la camada W22 de Y Combinator, según TechCrunch. Su cofundador, Jamil Bou Kheir, pasó ocho años en Cisco antes de lanzar lo que la compañía describe como una alternativa open source a OpenVPN y Cisco AnyConnect.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Durante años el equipo usó boringtun como implementación de WireGuard. El problema fue acumulativo: cada requisito nuevo del producto obligaba a parchear el fork, y mantener compatibilidad total con el upstream se volvió cada vez más difícil. El resultado es sanstun, que reemplaza a ese fork —ahora deprecado— y que la compañía publicó como proyecto abierto.

El detalle que importa para un equipo de infraestructura: no es una reescritura por gusto estético. Es el destilado de dos años de parches en producción convertidos en una API pensada desde cero.

¿Qué significa sans-IO y por qué importa para tu infraestructura?

Un diseño sans-IO separa la entrada/salida y los efectos secundarios del estado y la lógica de negocio. En este contexto, «IO» no significa solo archivos o red: incluye también el tiempo y la aleatoriedad. Un componente sans-IO no consulta el reloj del sistema ni genera números aleatorios por su cuenta; se los entrega quien lo usa.

Esa separación tiene dos consecuencias prácticas. Primero, los componentes se vuelven testeables de forma determinista: puedes simular una red completa sin esperar a que pase el tiempo real. Segundo, se evita el problema de «function coloring», donde una función asíncrona contamina a todo lo que la llama.

En sanstun la API refleja esa filosofía. Interface::receive es el único punto público que parsea un datagrama crudo: aplica los límites de tasa y devuelve un ReceivedMessage que se despacha a Tunnel::handle_handshake_initiation, handle_handshake_response o handle_cookie_reply. Los constructores de esos tipos son privados del crate, así que la única forma de obtenerlos es pasar por Interface::receive. En términos simples: es imposible olvidarse del rate limiter.

La segunda decisión de diseño es la ausencia de buffering interno. boringtun resolvía el buffer pendiente pidiéndote llamar decapsulate con un datagrama de longitud cero, algo poco intuitivo que además generaba asignaciones extra. sanstun simplemente no bufferea: si no tienes sesión activa, tú decides qué hacer con el paquete.

Cifrado en paralelo: hasta dónde llega la ganancia

WireGuard no comparte estado entre túneles, así que paralelizar entre distintos peers es trivial. El cuello de botella real está dentro de un mismo túnel: el contador de paquetes es monótono y está atado a la sesión, por lo que leerlo desde varios hilos exigiría sincronización.

sanstun separa la contabilidad de la criptografía. Tunnel::begin_encapsulate no cifra nada: reserva un contador de paquete, avanza el estado de los timers y devuelve un PendingEncapsulate que implementa Send y puede viajar a otro hilo para hacer el trabajo pesado.

Los benchmarks del repositorio muestran la asimetría con claridad. Con paquetes de 1280 bytes, la parte de contabilidad de begin_encapsulate tarda alrededor de 20,8 ns, mientras que el cifrado tarda cerca de 933,5 ns. La contabilidad representa apenas el 2% del trabajo total. Firezone señala que mover el cifrado a otro hilo apunta a una aceleración potencial de más de 45x, aunque la propia compañía aclara que ese número es teórico: no descuenta el costo de transferir el PendingEncapsulate entre hilos ni otros overheads.

El punto clave del diseño es que Interface permanece single-threaded. Eso permite que el rate limiter funcione sin locks ni contadores atómicos, aprovechando el borrow checker de Rust.

WireGuard ya es el estándar: qué hacen Tailscale y Mullvad

WireGuard fue presentado por Jason Donenfeld en junio de 2016 con unas 4.000 líneas de código, según LWN.net, y se integró al kernel de Linux en 2020. Sobre esa base se construyó un mercado entero de acceso remoto.

Tailscale, fundada en 2019 y con US$275 millones acumulados en financiamiento según Network World, eligió la implementación en espacio de usuario para poder usar el mismo código en todas las plataformas. Entre sus usuarios figuran Perplexity, Mistral, Cohere, Groq y Hugging Face, según el mismo medio.

Mullvad tomó otro camino: escribió su propia implementación en Rust, GotaTun, y la sometió a una auditoría de Assured Security Consultants realizada entre el 19 de enero y el 15 de febrero de 2026, según CNET. Fue la auditoría número 18 de la compañía desde 2017 y no encontró vulnerabilidades mayores, aunque sí dos hallazgos de riesgo bajo: identificadores de sesión generados con un registro de 24 bits en lugar de los 32 bits aleatorios que pide la especificación, y falta de padding a 16 bytes antes del cifrado. Ambos se corrigieron en releases posteriores.

El patrón se repite: las empresas que construyen producto sobre WireGuard terminan escribiendo o manteniendo su propia implementación en Rust. sanstun es la apuesta de Firezone por dejar de mantener un fork y, al mismo tiempo, por posicionar su capa de datos como pieza reutilizable.

¿Qué significa esto para tu startup?

Evalúa sanstun antes de escribir tu propia capa WireGuard. Si tu producto necesita control fino sobre handshakes, rate limiting o paralelización del cifrado, la librería ya resuelve esos casos con licencia Apache 2.0 y publicación en crates.io. Escribir eso desde cero son meses de trabajo y, sobre todo, meses de bugs de borde.
Copia el patrón begin/commit aunque no uses Rust. La idea de separar la reserva de estado (contador de paquete, timers) del trabajo criptográfico pesado es transferible a cualquier lenguaje. Si tu cuello de botella es el throughput de cifrado, esa división es lo que te permite mandar solo la parte pesada a un pool de hilos sin sincronizar el estado compartido.
Mide antes de asumir el 45x. El propio autor del benchmark aclara que el número es teórico. Antes de rediseñar tu arquitectura, corre tu propia prueba con el tamaño de paquete real de tu tráfico: la ganancia depende de cuánto pese el cifrado frente al resto del pipeline.
Usa el throughput publicado como vara de comparación. El repositorio oficial de Firezone reporta más de 2 Gbps en iOS y Android y más de 5 Gbps en Windows y macOS para su capa de datos en Rust. Es una referencia útil para saber si tu implementación está dejando rendimiento sobre la mesa.

Conclusión

sanstun no es solo una librería nueva: es la evidencia de que el patrón sans-IO dejó de ser una curiosidad académica y se volvió una decisión de arquitectura defendible en producción. Para un founder que construye infraestructura de red, la lección más valiosa no está en el código, sino en el método: dos años de parches identificaron exactamente dónde dolía la API anterior, y la nueva se diseñó alrededor de esos puntos de dolor.

Si tu equipo usa WireGuard hoy, vale la pena revisar si sigue manteniendo un fork propio por costumbre. Y si estás diseñando cualquier componente con estado compartido y trabajo pesado, el split entre contabilidad y ejecución es un patrón que puedes adoptar esta semana.