WireGuard o IPsec: qué ponemos en cada sitio

Cada vez que alguien abre esta discusión acaba en religión: un bando dice que IPsec es un fósil y el otro que WireGuard es un juguete. Nosotros operamos red propia y montamos los dos. Y la conclusión honesta, después de años de túneles que hay que levantar a las tres de la mañana, es aburrida: WireGuard gana en el código y en el día a día; IPsec gana en todo lo que rodea al túnel. Lo interesante es que en 2026 se ha metido en la conversación un tercer factor que en 2020 no estaba, y va con fecha.

Las 4.000 líneas que ganaron la discusión

El argumento fuerte de WireGuard nunca fue el rendimiento: fue el tamaño. Unas 4.000 líneas de código frente a las más de 100.000 de OpenVPN, y una pila IPsec que en la práctica son dos cosas distintas (un demonio de negociación en espacio de usuario y el motor de cifrado dentro del kernel) mantenidas por gente diferente. Entró en el kernel de Linux en la versión 5.6, marzo de 2020, y la frase que Linus Torvalds escribió en la lista del kernel en agosto de 2018, pidiendo que lo fusionaran de una vez, se cita tanto porque resume el sentimiento de todo el que ha depurado una fase 2: «puede que el código no sea perfecto, pero lo he ojeado, y comparado con los horrores que son OpenVPN e IPsec, es una obra de arte».

Toca el matiz, porque la cifra se usa con demasiada alegría: comparar 4.000 líneas de un módulo de kernel con la suma de una pila IPsec completa no es comparar lo mismo. IPsec hace cosas que WireGuard directamente no intenta hacer, y algunas de ellas las necesitas. Dicho esto, el orden de magnitud es real y tiene una consecuencia práctica que no es estética: superficie que auditar, y probabilidad de que el fallo de la semana te toque a ti.

El rendimiento no es el argumento (y lo dice WireGuard)

Aquí hay que ser justos con el proyecto, porque es más honesto que la mayoría de sus fans. En su propia página de rendimiento, los números que todo el mundo sigue citando —medidos sobre un Linux 4.6.1— vienen con esta advertencia escrita por ellos mismos: «estos benchmarks son viejos, cutres y no están muy bien hechos». En la misma nota añaden que desde entonces WireGuard e IPsec han mejorado los dos, que WireGuard sigue sacando ventaja en algunos casos por su multihilo, que OpenVPN sigue siendo extremadamente lento, y que sustituir esas cifras por datos nuevos es trabajo pendiente. Es decir: la tabla de megabits que has visto en veinte artículos no la avala ni quien la publicó.

En nuestra experiencia, en enlaces de empresa el cuello de botella casi nunca es el cifrado: es el enlace, el equipo del extremo barato, la MTU mal calculada o un proveedor que hace cosas raras por el camino. Si estás eligiendo protocolo de túnel mirando una tabla de Mbps, estás optimizando la variable equivocada.

Lo que WireGuard hace mejor de verdad

• No hay nada que negociar. La construcción criptográfica es una sola y está fijada en el protocolo: Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s. Ni fase 1 ni fase 2, ni proposals que no casan, ni el clásico «por su lado ven el túnel arriba y por el nuestro no». Si las dos claves públicas y el AllowedIPs están bien, sube; si no, no sube.
• Roaming de verdad. La documentación oficial lo describe sin adornos: cada extremo envía al último punto del que descifró correctamente, así que hay «roaming de IP completo en ambos extremos». En la práctica, un portátil que salta de la oficina al 4G o una sede con IP dinámica dejan de ser un tema de conversación.
• Se lee entero. Una configuración de WireGuard cabe en pantalla y la entiende quien entra de guardia sin haberla montado él. Eso, el día del incidente, vale más que cualquier prestación. Es el mismo criterio con el que miramos cuándo compensa una SD-WAN y cuándo sobra: cada capa que añades hay que saber depurarla de madrugada, no solo dibujarla en la propuesta.
• Detrás de NAT se comporta. Un PersistentKeepalive de 25 segundos —el valor que recomienda el propio manual para interfaces que hablan poco y están detrás de NAT— mantiene viva la traducción del router y se acabó el problema. No hay dead peer detection que ajustar ni temporizadores de tres sitios distintos.

Lo que IPsec sigue haciendo mejor (y no es nostalgia)

• Al otro lado del túnel no siempre mandas tú. El firewall que ya tiene el cliente, el router del proveedor de la otra sede, la nube pública: todos hablan IKEv2 y no todos hablan WireGuard. La documentación de AWS lo dice sin rodeos —«Site-to-Site VPN admite conexiones VPN IPsec», con IKEv2 en la lista de características—, y lo mismo vale para el resto de VPN gestionadas del mercado. Elegir WireGuard exige que los dos extremos sean tuyos o quieran serlo.
• WireGuard no sabe qué es una persona. No hay concepto de usuario ni de sesión: hay claves públicas y rangos permitidos, y punto. Para acceso remoto de empleados eso significa que la identidad corporativa, el MFA, el alta y —sobre todo— la baja te los montas tú por encima, con lo que eso implica el día que alguien se va. IKEv2 trae EAP de serie y se enchufa a RADIUS y a certificados de usuario sin inventar nada.
• Solo UDP, y a veces eso importa. La documentación de WireGuard es explícita: «WireGuard no admite deliberadamente el túnel sobre TCP, por el rendimiento clásicamente terrible de encapsular TCP sobre TCP». Técnicamente tienen razón. Operativamente, la Wi-Fi del hotel que solo deja salir por 443/TCP no atiende a razones —y de lo hostiles que son esas redes ya hemos escrito. Añaden además que «WireGuard no se centra en la ofuscación»: donde alguien filtra a conciencia, no es la herramienta.
• Lo que no se negocia, tampoco se cambia. La criptografía fija de WireGuard evita las suites malas y los downgrades, que es exactamente el pecado histórico de IPsec. El precio es simétrico: el día que haya que cambiar de algoritmo, no hay dónde tocar — hay que cambiar de versión de protocolo.

El factor de 2026: los dos llegan tarde a lo post-cuántico

Este es el punto por el que hoy volvemos a abrir la comparativa, porque ha dejado de ser teórico y tiene calendario. En junio de 2025, el grupo de cooperación NIS de la Unión Europea publicó una hoja de ruta coordinada que recomienda a los Estados miembros arrancar su estrategia nacional de transición a criptografía post-cuántica antes de finales de 2026 y tener migrados los casos de uso de alto riesgo como muy tarde a finales de 2030. Al otro lado del Atlántico, el borrador público del NIST IR 8547 (noviembre de 2024, todavía sin versión final) le pone fecha de caducidad al mismo intercambio de claves que usan hoy tus túneles: ECDH queda desaconsejado tras 2030 en sus parámetros de 112 bits y prohibido —en todas sus variantes, también las de 128 bits o más— a partir de 2035.

Ninguno de los dos protocolos, tal y como está montado hoy en la mayoría de sitios, es resistente a un ordenador cuántico. WireGuard lo dice él mismo, con esa honestidad que le honra: «WireGuard no es, por defecto, post-cuánticamente seguro», y ofrece como remedio una clave precompartida que se mezcla con el intercambio de claves. Lo curioso es que IPsec tiene exactamente el mismo apaño, y además con número de RFC: el RFC 8784, de junio de 2020, «Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security». El mismo parche que WireGuard ya llevaba encima desde su artículo de 2017, pero estandarizado.

Y aquí está el giro que nos parece la parte interesante de todo esto. La agilidad criptográfica, que durante veinte años fue el pecado de IPsec, es hoy su salida. Desde el RFC 9370 (mayo de 2023), IKEv2 puede encadenar varios intercambios de clave dentro de la propia negociación y combinar el clásico con uno post-cuántico, de forma que el secreto final se calcula a partir de todos ellos: basta con que uno resista. WireGuard resolvió el problema de ayer —que se negociara basura— y por eso tiene el problema de mañana: no hay nada que negociar cuando lo que toca es cambiar. Su camino pasa por una versión nueva del protocolo o por montar un handshake post-cuántico por encima; ninguna de las dos cosas se hace un martes por la tarde.

Sin dramatizar, que es fácil vender miedo con esto: para la mayoría de empresas, 2030 no es una emergencia, es una fecha de renovación. El riesgo real hoy tiene nombre —«recolectar ahora, descifrar después»— y solo aprieta si por ese túnel viaja algo que siga siendo sensible dentro de diez años: expedientes clínicos, propiedad industrial, secretos contractuales largos. Si por el tuyo pasa tráfico de ERP que caduca en un trimestre, respira. Pero el equipo que compres este año probablemente siga ahí en 2030, y esa sí es una pregunta para hoy: ¿el fabricante tiene camino post-cuántico, o te está vendiendo hierro con fecha de caducidad criptográfica?

Qué ponemos nosotros, y dónde

Somos operador con red propia y no vendemos licencias de nadie, así que aquí no hay comisión que defender. Este es el criterio de la casa, tal cual:

• Entre máquinas y sedes donde controlamos los dos extremos: WireGuard. Linux contra Linux, nodos de virtualización, servicios internos que se hablan entre datacenters. Menos piezas, menos madrugadas.
• Contra el equipo de un tercero o una nube gestionada: IPsec/IKEv2, sin discusión. El túnel que hay que documentar para que lo entienda el proveedor del otro lado se hace con lo que ese proveedor sabe leer. Pelearse con esto es perder tiempo y quedar mal.
• Acceso remoto de personas: el túnel es lo de menos. Ahí el problema no es el protocolo, es la identidad — quién entra, con qué factor y qué pasa cuando esa persona deja la empresa. Elegir WireGuard o IPsec sin resolver eso es decorar.
• Lo que NO hacemos: cambiar un IPsec que funciona porque WireGuard es más moderno. Un túnel estable que nadie toca desde hace tres años vale más que cuarenta líneas menos de configuración. Migrarlo tiene un coste real —ventana, pruebas, documentación, el susto— y el beneficio, si el actual no da guerra, es cero.

Y un recordatorio que damos siempre, porque el túnel se lleva toda la atención y luego pasa lo que pasa: cifrar el tráfico no defiende el enlace. Si alguien te satura la línea, da igual qué protocolo lleve dentro; eso se resuelve aguas arriba y con quien opera la red, no en tu extremo.

Lo que preguntamos antes de decidir

• ¿De quién es el otro extremo? Si no es tuyo, la respuesta ya está decidida y no es WireGuard.
• ¿Conecta máquinas o personas? Máquinas, WireGuard encaja. Personas, necesitas identidad, y ahí el túnel es solo la mitad del problema.
• ¿Desde qué redes se va a levantar? Si tiene que funcionar desde hoteles, aeropuertos y clientes con salida filtrada, cuenta con que el UDP no siempre pasa.
• ¿Cuántos años tiene que seguir siendo secreto lo que pasa por dentro? Si la respuesta pasa de cinco, el calendario post-cuántico ya es tuyo y conviene mirar qué camino tiene tu equipo.

El túnel nunca fue el proyecto

Después de todo esto, la conclusión que nos sale es poco épica: la elección de protocolo es la decisión menos importante de tu VPN. Lo que decide si esa conexión te da problemas es quién la documenta, quién la monitoriza, quién revoca el acceso cuando alguien se va y quién sabe qué hacer cuando deja de subir. Nada de eso lo arregla WireGuard, y nada de eso lo estropea IPsec.

Así que la pregunta que dejamos no es cuál de los dos es mejor. Es esta: ¿sabrías decir hoy cuántos túneles tiene levantados tu empresa, contra quién, quién los montó y cuál de ellos dejó de tener sentido hace dos años? Ese inventario casi nadie lo tiene al día, y cuando se hace de verdad suele aparecer algún túnel abierto hacia un proveedor con el que ya no se trabaja. Eso preocupa más que el nombre del protocolo.

Fuentes (verificadas): primitivas y construcción fija Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s, y el modo de clave precompartida, en wireguard.com/protocol; el «roaming de IP completo en ambos extremos», en wireguard.com; la ausencia de TCP («WireGuard no admite deliberadamente el túnel sobre TCP…»), la falta de ofuscación y el «WireGuard no es, por defecto, post-cuánticamente seguro», en limitaciones conocidas; la advertencia «estos benchmarks son viejos, cutres y no están muy bien hechos» —junto con la nota de que WireGuard e IPsec han mejorado desde entonces y que WireGuard sigue por delante en algunos casos por su multihilo—, en wireguard.com/performance; el keepalive de 25 segundos y la ausencia de concepto de usuario o sesión, en el manual de wg(8). La cifra de ~4.000 líneas frente a las más de 100.000 de OpenVPN y la entrada en el kernel 5.6 (marzo de 2020), en BleepingComputer; la cita de Linus Torvalds (lista del kernel, agosto de 2018, pidiendo que se fusionara), recogida en The Register. IPsec: RFC 8784 (junio de 2020, «Mixing Preshared Keys in IKEv2 for Post-quantum Security»; el modo de clave precompartida de WireGuard es anterior, de su artículo de 2017) y RFC 9370 (mayo de 2023, múltiples intercambios de clave en IKEv2, que permiten combinar clásico y post-cuántico). Soporte de IPsec/IKEv2 en la VPN site-to-site de AWS, en su documentación oficial. Calendario europeo (estrategia nacional iniciada antes de finales de 2026, casos de alto riesgo migrados como muy tarde a finales de 2030), en la hoja de ruta coordinada del grupo de cooperación NIS; ECDH desaconsejado tras 2030 en sus parámetros de 112 bits y prohibido en todas sus variantes tras 2035, en el borrador público (noviembre de 2024, sin versión final) de NIST IR 8547. Citas traducidas por nosotros del original en inglés. El criterio, los ejemplos y las opiniones son nuestros.