IPsec fue una buena idea. Es hora de apagarlo.

IPsec fue una buena idea. Pon el cifrado en la capa de red, debajo de todo, y cada protocolo que va sobre IP hereda confidencialidad e integridad sin que se lo digan. Ninguna biblioteca que enlazar. Ningún certificado por aplicación. Nada que reescribir en lo que ya has entregado. El paquete sale protegido y llega protegido, y los routers intermedios lo llevan sin saber ni querer saber qué hay dentro.

Ese diseño se apoya en una suposición, y está escrita en la norma en vez de sobrentendida: la dirección de un paquete identifica la máquina de la que vino. Una asociación de seguridad se busca por la dirección de destino, el número de protocolo y el SPI¹. La Authentication Header va más lejos y firma la propia cabecera IP, origen y destino incluidos². Para IPsec la dirección no son metadatos de encaminamiento. Es parte de la identidad y parte del control de integridad.

Luego este sector se pasó treinta años quitando la dirección.

Primero el NAT, para que una oficina cupiera detrás de una línea. Después el NAT de operador, para que varios cientos de hogares cupieran detrás de una dirección, porque activar IPv6 era trabajo y comprar una caja era compras — que es todo el asunto de Nunca nos quedamos sin direcciones. Nos quedamos sin ganas. y no lo voy a repetir aquí. Lo que importa para esta entrada es la consecuencia. Lo único sobre lo que se construyó IPsec es justo lo que la red de acceso moderna ya no ofrece.

Así que a IPsec se le pusieron parches. Envuelve el paquete cifrado en UDP para que un traductor tenga un puerto que reescribir. Pon la suma de comprobación a cero para que nadie la revise. Manda un paquete de un byte cada veinte segundos, para siempre, para que una tabla en el equipo de otro no olvide que existes. Despega la identidad de la dirección y cuélgala de un nombre. Abandona la Authentication Header, porque por construcción no puede sobrevivir a una cabecera reescrita. Y cuando un hotel bloquea UDP, envuélvelo todo además en TCP³.

Cada uno de esos puntos es una solución real, normalizada y respaldada por los fabricantes. Juntos son un protocolo sostenido por su propio andamiaje. Y el andamiaje es el argumento: uno no se pasa un cuarto de siglo apuntalando algo porque sea sano de raíz.

La conclusión a la que he llegado es que IPsec debe retirarse por completo. No ajustado, no vuelto a proponer con cifrados mejores, no conservado para el sitio a sitio porque esa parte aún funciona. Retirado, con fechas, igual que PPTP debió retirarse una década antes de que alguien se pusiera a ello. Lo que sigue son las pruebas, los diagramas, la documentación de los fabricantes que dice todo esto con sus propias palabras y — porque la mayoría de quienes leen esto tienen que mantener esas cosas funcionando el lunes — un método utilizable para diagnosticar averías de IPsec mientras tanto.

Lo que de verdad te cuesta, en tickets

Antes de las normas, aquí está la factura, en el orden en que te la vas a encontrar.

El túnel se cae a reloj. Cada hora, o cada ocho, o tras veinte minutos sin tráfico. Vuelve en cuanto alguien abre un archivo, así que la mitad de los usuarios no lo reporta nunca y la otra mitad lo reporta como «la VPN va lenta». Nadie ha cambiado nada.

Dos personas en la misma casa no pueden conectarse a la vez. La segunda sube, la primera se cae. Llaman al servicio de asistencia por separado, así que los tickets nunca se cruzan y nadie ve el patrón en quince días.

Lo pequeño funciona y lo grande se queda colgado. El inicio de sesión funciona. Teams funciona. El ping funciona. Copiar un archivo se para siempre en el mismo punto, y abrir una página grande en una aplicación interna se queda ahí hasta que expira.

El túnel está levantado y no pasa tráfico. Los dos extremos dicen «establecido». Los dos extremos están contentos consigo mismos. No se mueve nada.

No entra nada desde fuera. El sitio a sitio con la delegación que se pasó a un operador de fibra alternativo ya no se establece en el sentido en que lo hacía, y nadie sabe decir por qué, solo que «les ha cambiado la IP».

Activar la QoS rompió el cifrado. Alguien priorizó la voz, y ahora el extremo remoto descarta paquetes como si fueran repeticiones.

Ninguno de esos casos es un error de configuración en el sentido corriente. Cada uno es IPsec encontrándose con la red tal y como es hoy. El resto de esta entrada explica por qué, en orden, y cómo demostrar cuál te ha tocado.

IPsec no lo transporta la red. IPsec es la red.

Empieza por lo que era, porque el diseño es realmente bueno y las averías solo cobran sentido frente a él.

ESP no es un protocolo que corre sobre TCP o UDP. Es un protocolo de transporte, número de protocolo IP 50, asentado directamente sobre IP, en la misma ranura donde se sientan TCP y UDP. AH es el protocolo 51. Ninguno tiene campo de puerto, porque ninguno lo necesita: en el internet para el que se diseñó IPsec, la dirección de destino ya nombra exactamente una máquina, y el SPI en la cabecera ESP nombra qué asociación de seguridad de esa máquina. Dirección más protocolo más SPI. Ese trío es la búsqueda¹.

Fíjate en lo que eso da. Ningún puerto de negociación que exponer, ninguna capa de sesión que equivocar, ninguna aplicación que tenga que apuntarse. Cualquiera de los dos extremos puede empezar. El centro de la red es tonto, que es exactamente lo que debe ser el centro de una red. Un router reenvía el protocolo 50 igual que reenvía el protocolo 6, y que no pueda leer la carga útil es el propósito y no una limitación.

Es un diseño limpio. Y es también, en 2026, la descripción de un internet que la mayoría de quienes leen esto no pueden comprar.

Luego alguien puso un traductor en cada camino

Un NAT reescribe la dirección de origen, y a menudo el puerto de origen, para que varias máquinas compartan una dirección. Eso es todo lo que hace. Contra IPsec es casi una demolición completa, y el IETF fue lo bastante franco como para publicar un documento entero que enumera las piezas: RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements⁴. Dieciséis incompatibilidades distintas. Estas son las que importan.

AH está acabado, por construcción. En las propias palabras del RFC 3715: «Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check.»⁴ — la cabecera AH mete las direcciones de origen y destino en el control de integridad, así que cualquier cambio de dirección lo invalida. No hay arreglo para eso, y nunca lo iba a haber. Un protocolo que firma la cabecera no cruza una caja cuyo trabajo entero es reescribir la cabecera. AH no se esquivó. Se abandonó.

No hay puertos que traducir. Un NAT que hace traducción de puertos necesita un puerto. ESP no tiene ninguno. Cisco lo escribe sin rodeos en la guía de configuración de Catalyst: «If PAT found a legislative IP address and port, it would drop the Encapsulating Security Payload (ESP) packet.»⁵ El paquete no se rechaza por política. Se tira porque la caja no tiene dónde escribir lo que necesita escribir.

La identidad deja de corresponder al paquete. De nuevo del RFC 3715: «Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header.»⁴ — si las direcciones se usan como identificadores, tras la traducción el identificador ya no cuadra con la cabecera. Un esquema de identidad que nombra máquinas por dirección no sobrevive a un aparato que se gana la vida renombrando máquinas.

Dos máquinas pueden elegir el mismo SPI. El SPI lo elige el receptor y solo tiene que ser único para él. Pon dos hosts detrás de una dirección y el traductor tiene dos asociaciones sin nada que las distinga.

Nada puede entrar primero. Un NAT construye su tabla a partir de los paquetes salientes. No hay paquete saliente hasta que alguien empieza, y en una línea con NAT solo puede empezar el interior. La mitad de la simetría del protocolo se ha ido.

El arreglo era real, y cada parte de él costó algo

La traversía de NAT funciona. Eso no se discute y no voy a fingir lo contrario. He explotado muchos túneles a través de muchos NAT. Lo que quiero dejar por escrito es la factura, porque la paga todo el mundo todos los días y casi nadie la desglosa.

El mecanismo es el RFC 3948: detectar un traductor durante el intercambio de claves y meter luego el paquete ESP entero en un datagrama UDP en el puerto 4500 para que el traductor tenga algo que entienda⁶. La descripción del formato en el cable que hace Cisco es exacta: tras el cifrado, «a UDP header and a non-IKE marker (which is 8 bytes in length) are inserted between the original IP header and ESP header»⁵ — se insertan una cabecera UDP y un marcador no-IKE de ocho bytes entre la cabecera IP original y la cabecera ESP. La de Juniper es más corta y dice lo mismo: «NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port.»⁷

Ahora la factura desglosada.

La Authentication Header ha desaparecido. No desaconsejada con cortesía. Inservible. El RFC 8221 dice ya con claridad que usar ESP junto con AH es NOT RECOMMENDED⁸, y la razón honesta es que lo único que hacía AH y no hace ESP es justo lo que el NAT destruye.

La suma de comprobación UDP se pone a cero deliberadamente. El RFC 3948 lo exige: con las direcciones reescritas, una suma calculada sobre ellas fallaría, así que la respuesta de la norma es dejar de calcularla. «If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header.»⁶ Una capa de detección de errores retirada para que siga funcionando una capa de reescritura de direcciones.

Ahora mandas paquetes para mantener caliente una tabla. El RFC 3948 define un keepalive como un byte, 0xFF, enviado cuando no ha salido nada más durante un intervalo configurable cuyo valor por defecto son veinte segundos⁶. Juniper da la razón sin adornos: «Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.»⁷ Un portátil en un tren, sin hacer absolutamente nada, emite pues cada veinte segundos, para siempre, porque una tabla en una caja que no es de ninguno de los dos extremos olvidaría si no que existe. Multiplícalo por una flota. Eso es la radio despertándose, la batería bajando y la red móvil llevando tráfico cuyo único propósito es impedir el olvido.

Ahora filtras dos puertos en lugar de un protocolo, y la propia lista de restricciones de Cisco exige reglas de traducción estáticas para el 500 y el 4500 antes de que nada de esto funcione⁵.

Y lee el resto de esa lista de restricciones, porque ahí el fabricante te describe la forma del asunto. Políticas de NAT dinámico: no admitidas. Tráfico IPv6: incompatible con la función. IPsec y NAT en el mismo equipo: no pueden funcionar los dos⁵. Eso no es una guía de configuración. Es la lista de sitios a los que el andamiaje no llega.

Nada de esto es elegante, y tampoco es culpa de nadie en particular. Es lo que pasa cuando mantienes vivo un protocolo de capa 3 sobre una red que dejó de honrar la capa 3.

El NAT de operador quitó lo que quedaba

El NAT corriente le quitó la dirección a la máquina y se la dio a la sede. El traductor seguía siendo tuyo, así que podías redirigir un puerto, fijar una asociación, alargar un temporizador o poner el concentrador delante.

El NAT de operador le quita la dirección a la sede y se la da a varios cientos de desconocidos, y el traductor es de tu proveedor. Todo lo que antes podías hacer al respecto, ahora no puedes.

Y ten claro qué hay de verdad en el camino, porque esta es la parte que la gente se equivoca. El router de casa sigue haciendo NAT. No se ha apagado. Sigue traduciendo tu portátil en 192.168.1.20 a la dirección que tenga la línea — salvo que la línea tiene ahora 100.64.12.7, espacio compartido, no una dirección pública. El operador traduce eso otra vez. El paquete cruza pues dos traductores antes de llegar a internet, y ese es el caso corriente, no una rareza.

Estás bajo doble NAT, y solo una de las tablas es tuya. Dos traducciones significan dos tablas de asociación, dos temporizadores de caducidad y dos ocasiones de que la asociación desaparezca. Tu keepalive tiene que ganarle a la que expire antes, y solo puedes leer una de ellas. Peor aún, las dos se entrometen: el router de casa puede tener sus propias ideas sobre IPsec e intentar ayudar con una pasarela de aplicación, de modo que el puerto de origen que tu cliente cree usar no es el que sale de la casa, ni el que sale del operador.

La redirección de puertos sigue funcionando, y no sirve absolutamente de nada. Este es el ticket que más tiempo se come. Alguien redirige UDP 500 y 4500 en el router doméstico, el router lo acepta, la página de ajustes dice que la regla está activa — y nada puede usarla, porque redirige desde una dirección a la que internet no llega. UPnP y PCP se comportan igual: el cliente pide una asociación, el router se la concede, y el puerto se abre a un pasillo. Todo informa de éxito y nada funciona. La caja te contará lo que quieras oír.

La forma más rápida de zanjarlo no cuesta nada. Lee la dirección WAN en el router. Si empieza por 100.64, ese es el espacio compartido reservado en el RFC 6598, estás detrás de un NAT de operador, y media página de ajustes es decorativa.

El papel de respondedor ya no existe. Un equipo detrás de CGNAT no puede ser el extremo al que alguien llama. El sitio a sitio entre dos delegaciones con fibra doméstica — normal, barato y justo lo que quiere una empresa pequeña — exige que al menos un extremo tenga una dirección real, o un tercero en medio que los presente. Ese tercero es una empresa de la que ahora dependes porque tu proveedor no quiso darte una dirección.

El temporizador es de otro. El RFC 4787 dice a los operadores de NAT que una asociación UDP «MUST NOT expire in less than two minutes» y recomienda cinco o más⁹. Ese es el suelo y el consejo, no una promesa, y no puedes inspeccionar lo que hace de verdad tu operador. Como tal, el keepalive deja de ser un ajuste. Es portante, sobre un temporizador que estás adivinando.

La identidad de tu par no puede ser su dirección. Varios abonados llegan al extremo remoto como una sola dirección. Sea lo que sea lo que el concentrador use para distinguirlos, no es la cabecera IP — y es justo la que IPsec iba a usar.

Hay un techo duro, y los fabricantes lo publican. Juniper documenta que en SRX5400, SRX5600 y SRX5800, «the total number of tunnels from a given public translated IP cannot exceed 1000 tunnels»⁷. Léelo como operador y no como línea de especificación. Tu concentrador VPN tiene un límite por dirección compartida, el reparto lo hace un operador con el que no tienes contrato, y lo cerca que estés de ese límite depende de cuántos de tus usuarios estén por casualidad detrás del mismo. No hay contador que consultar. Solo está el día en que empieza a fallar para unos y no para otros.

Todo lo de esta sección viene de una decisión que este país tomó y siguió tomando. Ese expediente lo he desarrollado entero en otro sitio y no lo repito. El punto aquí es más estrecho: la suposición central de IPsec la borró la red de acceso, y IPsec vive desde entonces de apaños.

Y la red solo IPv6 tampoco lo salva

Aquí tengo que ser honesto contra mi propio argumento, porque la respuesta obvia a todo lo anterior es: muy bien, dale a cada máquina una dirección IPv6 real y IPsec vuelve a funcionar como está especificado.

Y así es, entre dos extremos que tengan una. Esa no es la red en la que está la mayoría de la gente.

Las redes de acceso solo IPv6 que existen de verdad, el móvil en particular, llegan a internet IPv4 a través de NAT64, que en el sentido corriente no es un NAT en absoluto. Es un traductor de protocolo, que reescribe un paquete IPv6 como paquete IPv4. Y el RFC 6146 nombra lo que transportará, y nombra lo que no, sin ambigüedad ninguna:

«The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification.»¹⁰

IPsec, por su nombre, fuera del alcance. Y los paquetes que lleven cualquier cosa fuera de esa lista «SHOULD be discarded»¹⁰.

Así que en un teléfono o portátil solo IPv6 que intenta alcanzar un concentrador IPv4 — y esos son la mayoría de los concentradores —, el ESP nativo no lo tira un cortafuegos ni lo estropea un traductor. Es que no se transporta en absoluto. El traductor hace exactamente lo que su norma le dice.

La respuesta del sector a eso es, inevitablemente, otra capa más: 464XLAT, que le da al dispositivo una pila IPv4 local y traduce dos veces, fuera de IPv4 y de vuelta, para que lo que NAT64 no puede llevar funcione igualmente¹¹. Ya está en la lista de añadidos de la entrada sobre IPv6 y no lo voy a volver a argumentar. Lo que merece decirse aquí es la forma: un protocolo que se rompió con el NAT en 2004 también se rompe con la traducción construida para la transición a IPv6 en 2011, y las dos veces la respuesta es envolverlo en otra cosa.

Esa es la prueba que un protocolo tiene que pasar para tener sitio en 2026. ¿Funciona en la red que la gente tiene de verdad — detrás de la dirección compartida de un operador, en una red móvil solo IPv6, a través de un hotel que solo deja pasar TCP 443? Cualquier cosa construida sobre un puerto UDP pasa las tres sin que haya que decírselo. IPsec necesita un apaño distinto para cada una, y para la tercera además encapsulación TCP³.

Sin puertos tampoco hay segundo enlace

Aquí hay una avería que no tiene nada que ver con el NAT, que es puramente moderna y de la que casi no se habla.

Routers y conmutadores reparten el tráfico entre caminos paralelos. Agregación de enlaces, multicamino de igual coste: los dos funcionan igual, aplicando un hash a la quíntupla. Dirección de origen, dirección de destino, protocolo, puerto de origen, puerto de destino. ESP no tiene puertos. Así que cada paquete de un túnel entre las mismas dos direcciones da el mismo hash, y el túnel entero cae en un solo enlace del grupo, por muchos que hayas comprado.

Dos enlaces de 10G y un túnel IPsec te dan 10G. Cuatro te dan 10G. El equipo funciona exactamente como está diseñado.

El apaño tiene la forma de siempre. Algo de silicio sabe aplicar el hash al SPI en su lugar, ya que cada SPI nombra una asociación y por tanto un flujo, pero eso es una función que hay que haber comprado y no algo que puedas suponer de un camino que no es tuyo. Hay un borrador del IETF activo cuyo único propósito es envolver ESP en otra cabecera UDP para que los routers corrientes puedan aplicarle el hash, y dice por qué en una frase: «Although the ESP SPI field within the IPsec packets can be used as the load-balancing key, but it cannot be used by legacy switches and routers.»¹² Su planteamiento del problema es igual de directo sobre lo que la gente hace en su lugar: «Many cloud service providers allow customers to establish multiple IPsec VPN tunnels in parallel to enable ECMP and increase aggregate bandwidth. However, this approach is not ideal, as each tunnel typically requires its own public IP address, leading to higher public IP consumption and increased operational overhead.»¹²

Deja que eso repose un segundo. La forma recomendada de hacer más rápido un enlace cifrado es construir varios, cada uno quemando una dirección IPv4 pública — durante una escasez de direcciones — porque el protocolo no tiene número de puerto al que aplicar el hash. Mientras tanto, un túnel basado en UDP consigue el multicamino gratis, en equipos entregados hace quince años, porque tiene un puerto como todo lo demás en el internet moderno.

Eso no es un problema heredado que se vaya a apagar solo. Es un límite vivo para instalaciones nuevas, hoy, exactamente a las velocidades que la gente está comprando ahora.

El impuesto de la MTU, y quién lo paga

Todo túnel cuesta bytes. IPsec cuesta más que la mayoría, y su forma de fallar cuando se queda sin sitio es el peor tipo de avería: intermitente, dependiente del tamaño e invisible para cualquier prueba que uno lance primero.

Calcúlalo para una configuración en vez de agitar las manos. ESP en modo túnel sobre IPv4 con AES-GCM: 20 bytes de cabecera IP externa, 8 de cabecera ESP, 8 de nonce, 2 como mínimo de cola, 16 de marca de integridad. 54 bytes antes de que entre nada de tu paquete. Envuélvelo para la traversía de NAT y la cabecera UDP lo deja en 62. En un camino de 1500 bytes quedan 1438, y en cuanto haya PPPoE a 1492 más arriba vuelves a quedarte por debajo.

Y luego viene lo que lo convierte en avería y no en un problema de aritmética. Un emisor se entera de que un paquete era demasiado grande solo porque le vuelve un error ICMP — Fragmentation Needed en IPv4, Packet Too Big en IPv6. Si algo del camino tira esos errores, el emisor no se entera nunca y sigue mandando paquetes que siguen muriendo. Ese es el agujero negro clásico: la negociación pasa porque las negociaciones son pequeñas, y la transferencia se cuelga porque las transferencias no lo son.

Cisco mantiene un documento entero sobre esto desde la época de GRE e IPsec, y sigue siendo una de las mejores explicaciones de esa interacción en la biblioteca de cualquiera¹³. Si hay que mantenerlo es porque la gente sigue bloqueando ICMP en bloque y luego se pregunta por qué los túneles se comportan raro.

Las dos mitades de ese argumento ya las he escrito y valen aquí sin repetirlas: qué mensajes ICMP son portantes y cuál no, en Ping: la herramienta de diagnóstico que abre mucho más, y cómo encontrar el salto exacto que se está comiendo tu tráfico, en El firewall está a once saltos. La versión corta para esta entrada: los errores son el mecanismo, el eco no lo es, y una política de frontera que tira todo ICMP ha roto tu VPN de una forma que se le achacará a la VPN.

Y tu propia calidad de servicio puede romperlo

Uno más, porque pilla a buenos ingenieros haciendo lo correcto.

ESP lleva un número de secuencia y el receptor mantiene una ventana antirrepetición de 64 paquetes por defecto en plataformas Cisco¹⁴. Prioriza ahora la voz en el router emisor. La cola de baja latencia hace lo que pediste y reordena los paquetes respecto a la secuencia en que se cifraron. Si un paquete cae fuera de la ventana al llegar, el extremo remoto lo descarta como repetición, y el contador que sube es un contador de seguridad.

Las propias palabras de Cisco: «Certain QoS features, such as Low Latency Queueing (LLQ), could cause IPsec packet delivery to become out-of-order and dropped by the receiving endpoint due to a replay check failure.»¹⁴ Su respuesta es ampliar la ventana a 1024 donde la plataforma lo permita, o adoptar una extensión con varios espacios de números de secuencia que asigna clases de QoS a espacios de secuencia separados dentro de una misma asociación¹⁴.

Así que: activar una función estándar de tu propia red rompe tu propio túnel, y el remedio es otra extensión de protocolo. La misma forma que todo lo anterior.

L2TP: tramado de acceso telefónico, cifrado, en 2026

L2TP no es un protocolo de seguridad y nunca lo pretendió. El RFC 2661 es un protocolo de túnel para transportar sesiones PPP, publicado en 1999, sin confidencialidad propia — su propia sección de seguridad te manda a IPsec para la protección a nivel de paquete¹⁵. Ese emparejamiento es el RFC 3193, y el resultado es la pila del diagrama de arriba: una cabecera IP externa, una cabecera UDP para la traversía de NAT, ESP, y luego dentro del cifrado otra cabecera UDP en el puerto 1701, una cabecera L2TP y una cabecera PPP.

PPP. El tramado de los módems de acceso telefónico, transportado dentro de un túnel cifrado, por internet, en 2026, porque eso es lo que L2TP se escribió para llevar.

Cuenta lo que cuesta en un ejemplo — IP externa 20, UDP 8, cabecera ESP e IV 24, UDP interno 8, L2TP 6, PPP 4, cola y marca 18 — y estás gastando unos 88 bytes por paquete para mover datos que el ESP nativo mueve por 54. Treinta y cuatro bytes, en cada paquete, por una capa de sesión que no añade nada de lo que querías y una capa de enlace diseñada para una línea telefónica.

La sobrecarga es lo de menos.

Multiplica el problema del NAT en vez de dividirlo. L2TP/IPsec usa habitualmente ESP en modo transporte, que es el modo al que el NAT más daño hace, y el resultado conocido es que muchas implementaciones no admiten en absoluto dos clientes detrás de una dirección. Dos personas en una casa, o cuarenta en una oficina, o varios cientos detrás de la dirección compartida de un operador. El extremo remoto ve una dirección y no puede distinguir las sesiones, así que la segunda conexión sustituye a la primera. Ese es el ticket del principio de esta entrada, y no es un fallo del producto de nadie — es el problema de la identidad por dirección llegando al sitio donde más gente se lo encuentra.

Y sobre el terreno se despliega casi siempre con un único secreto compartido para todos. Como el secreto se configura en el perfil del cliente y se reparte con las instrucciones de instalación, la clave precompartida está en el documento de bienvenida, en la página del wiki, en el correo a los recién llegados y en cada portátil que ha salido alguna vez. No es un segundo factor. Es una contraseña que autentica la pasarela ante nadie en particular y que no se ha cambiado jamás.

L2TP no es un protocolo que haya envejecido mal. Es un protocolo que llevaba lo que no debía desde el primer día y que se atornilló a IPsec para compensar lo que no sabía hacer en absoluto.

PPTP nunca fue seguro, y sigue a la venta

PPTP merece dos párrafos, no una sección, y los recibe solo porque hay quien lo sigue entregando.

Nunca fue una norma. El RFC 2637 es Informational. Un protocolo de fabricante puesto por escrito, no algo que el IETF recomendara nunca. Lleva PPP dentro de GRE, protocolo IP 47, que como ESP no tiene puertos, así que necesita un tratamiento especial en cada NAT del camino — la casilla «PPTP passthrough», que en muchísimos routers domésticos admite exactamente una sesión a la vez.

La seguridad se acabó en público en 2012. Marlinspike y Hulton demostraron que la seguridad de MS-CHAPv2 se reduce a una sola operación DES sea cual sea la longitud de la contraseña, escribieron chapcrack para extraer la negociación y lo conectaron a un servicio de descifrado que devolvía la clave en menos de un día por veinte dólares — una tasa de éxito del 100 %, no una probabilidad¹⁶. Su conclusión fue que el tráfico PPTP debe considerarse sin cifrar. Apple votó con los pies y retiró PPTP del cliente integrado de macOS Sierra e iOS 10 en 2016, y sigue publicando el aviso¹⁷.

Diez años después, PPTP sigue siendo una entrada de menú en routers que se venden este año, sigue en las guías de los fabricantes, sigue siendo lo que alguien activa porque es el que funciona a la primera. Funciona a la primera porque no está haciendo el trabajo.

Todo lo que se llama VPN IPsec

«VPN IPsec» no es un protocolo. Es una familia, y la longitud de la lista de abajo es el argumento, porque no hay dos productos que implementen el mismo subconjunto, y en los huecos entre esos subconjuntos vive cada trabajo de interoperabilidad que has odiado.

Mira ahora las dos filas en negrita, porque son las que deberían pararte.

Durante casi dos décadas, la forma normal de conectar a un usuario a una VPN IPsec corporativa fue XAUTH — tu usuario y contraseña, tu token, tu servidor RADIUS — con Mode-Config dándole al cliente su dirección, sus servidores DNS y sus rutas. Entre los dos son toda la experiencia de acceso remoto. Cada cliente «Cisco IPsec», cada icono de VPN en una bandeja, cada instrucción de alta.

Ninguno de los dos es una norma. XAUTH fue un borrador de internet individual que caducó en 2001 y se archivó sin llegar nunca a ser RFC²⁶. La razón que se da merece leerse, porque es un comité explicando por qué no iba a hacer su trabajo: el borrador deja constancia de que el grupo de trabajo IPSRA no aceptaría ningún protocolo que extendiera ISAKMP o IKE, y de que el grupo de trabajo IPsec rechazaba todo lo que tuviera que ver con el acceso remoto²⁶. Así que la parte más desplegada del protocolo VPN más desplegado se quedó sin casa, la implementó igualmente cada fabricante según su propia lectura de un borrador caducado, y se entregó a millones de usuarios.

IKEv2 acabó arreglando ambas cosas, y merece decirse: la autenticación pasó a EAP y las cargas de configuración del cliente entraron en la especificación principal²⁰. Pero lee las fechas. La función más usada del protocolo VPN más usado funcionó sobre un borrador caducado durante una década aproximadamente antes de tener norma alguna, y el parque instalado siguió con la versión borrador años después. Una familia de protocolos no se lleva mérito por normalizar al final la parte que ya usaba todo el mundo.

Esa es la familia que estás explotando. Parte es Standards Track y vigente. Parte es Historic. Parte no llegó nunca a ser nada. Y un producto cuya ficha técnica dice «VPN IPsec» no te ha dicho prácticamente nada sobre cuáles de estas dieciocho cosas sabe hacer, que es la razón de que juntar dos de ellos sean quince días, una hoja de cálculo de propuestas y una llamada a alguien que ya lo ha hecho antes.

El Fisher-Price OS (Windows) nunca ha interoperado de verdad

Esta es la parte en la que alguien dice que el problema es en realidad Linux, así que hagámoslo con fuentes.

Por defecto, el cliente de Windows no se conecta en absoluto a un servidor IPsec que esté detrás de un NAT. No «le costará». Se negará. El arreglo es un valor del registro llamado AssumeUDPEncapsulationContextOnSendRule bajo HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent, puesto a 1 si el servidor está detrás de un traductor o a 2 si lo están ambos extremos, en cada cliente y en el servidor, seguido de un reinicio³¹. Las propias palabras de Microsoft: «By default, Windows Vista and Windows Server 2008 don’t support Internet Protocol security (IPsec) network address translation (NAT) Traversal (NAT-T) security associations to servers that are located behind a NAT device.»³¹

Dos cosas sobre eso. La primera es que Microsoft coescribió la norma de traversía de NAT que se niega a usar. Su nombre está en el RFC 3947 y en el RFC 3948⁶. La segunda es que la página que te dice que edites el registro se revisó por última vez en febrero de 2026³¹. Veinte años después, un apaño de registro en cada equipo sigue siendo la respuesta, y se sigue manteniendo como respuesta.

Y lee la frase que Microsoft pone justo encima: «If you must use IPsec for communication, use public IP addresses for all servers that you can connect to from the Internet.»³¹

Eso es esta entrada entera, en la documentación del fabricante. No pongas IPsec detrás de un NAT. Dale a cada máquina una dirección real. Lo dejaron escrito, y luego el sector se pasó dos décadas haciendo lo contrario y facturando la diferencia.

No acaba en el NAT. Ve a leer lo que una pasarela de código abierto tiene que documentar para aceptar un cliente de Windows.

• El certificado de la pasarela necesita un uso extendido de clave que existe para esto y para nada más. serverAuth, OID 1.3.6.1.5.5.7.3.1, más IP Security IKE Intermediate, OID 1.3.6.1.5.5.8.2.2³². Hay que enseñar a tu autoridad de certificación a emitir un OID del que la mayoría de las herramientas no ha oído hablar nunca, o la conexión falla con un error de política y ningún mensaje útil.
• Hace falta un segundo valor de registro antes de que el cliente ofrezca criptografía decente. strongSwan documenta añadir NegotiateDH2048_AES256 bajo Rasman\Parameters para conseguir AES-256-CBC y un grupo de 2048 bits³³. Léelo al revés, que es como importa: sin tocar el registro, la propuesta por defecto es más débil que eso.
• El renovado de claves iniciado por el servidor lo rechazan los clientes detrás de NAT, y el apaño documentado es desactivar la renovación en la pasarela y dejar que la inicie el cliente³³.
• Extensiones estándar de IKEv2 sencillamente no están — sin redirección IKE, sin rondas de autenticación múltiples³³.

Nada de eso es un fallo de Linux. Cada punto es un proyecto de código abierto escribiendo lo que tiene que hacer para acomodar la lectura que un fabricante hace de una norma que ese mismo fabricante ayudó a escribir.

Ese es el patrón, y tiene treinta años. PPTP era el protocolo de Microsoft, puesto por escrito como Informational y nunca normalizado³⁰. MS-CHAPv2 y MPPE eran la autenticación y el cifrado de Microsoft, y los dos se rompieron en público¹⁶. SSTP es un túnel de Microsoft que nadie más termina. DirectAccess era IPsec, y era Windows en los dos extremos por diseño — y ya está obsoleto y en retirada, con los clientes empujados hacia Always On VPN³⁴. Ninguno de ellos fue jamás un protocolo en el que el resto pudiéramos encontrarnos a mitad de camino. Era un protocolo al que uno se sumaba, y si no ejecutabas el sistema operativo correcto en ambos extremos te tocaban el apaño de registro, el OID raro y la página de soluciones.

Así que lo digo claro, al fin y al cabo es mi blog. El Fisher-Price OS (Windows) nunca ha sido un par de verdad dentro de una pila de protocolos abierta, porque nunca fue para eso. Esconde la máquina a la persona que la usa, y además como objetivo de diseño, y una pila que no puedes ver es una pila que no puedes hacer interoperar. Si es el único sistema operativo que has administrado, las secciones de arriba sobre leer contadores del núcleo y escuchar el cable habrán sonado a otro idioma, y eso es la brecha — no una preferencia, una brecha.

Nada de esto tiene por qué costarle nada al lector. Cada diagnóstico de esta entrada se ejecuta desde cualquier Unix de la red, apuntado a lo que esté roto, y le da exactamente igual lo que haya al otro lado. Y si ese sistema operativo es el único que tienes, la parte de diagnóstico de más abajo trae también sus propias herramientas — la captura, los dos cmdlets y los códigos de error con lo que cada uno dice de verdad. Un túnel roto hay que arreglarlo el lunes igualmente. El sustituto que defiendo al final tiene entonces un solo cliente, que se comporta igual en cada plataforma incluida esa — por primera vez en treinta años eso es cierto de una VPN.

El expediente de obsolescencia se lee como una esquela

Deja los apaños a un lado y lee sin más lo que los organismos de normalización le han hecho a esta familia con los años. No es opinión. Son niveles de exigencia, en RFC publicados.

La penúltima fila es la que le pondría delante a cualquiera que me diga que IPsec está bien y que el problema es la red. IPv6 obligaba a IPsec en origen — era el argumento de seguridad, escrito en los requisitos de nodo. En 2011 el IETF cambió de idea: «Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture a SHOULD for all IPv6 nodes.»³⁶

Hasta la familia de direcciones que le habría devuelto a IPsec todo lo que el NAT le quitó dejó de exigirlo hace quince años. Eso no es la red fallándole a IPsec. Son las personas que diseñaron la red decidiendo que no se había ganado el mandato.

La complejidad se señaló en 1999, por escrito

Nada de esto es sabiduría a toro pasado, y eso es lo que hace que merezca escribirse.

En 1999 se encargó a Niels Ferguson y Bruce Schneier evaluar IPsec. Su informe es corto, claro y merece leerse entero. Abre con «IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result.»³⁷ Y nombra la causa: «Our main criticism of IPsec is its complexity. IPsec contains too many options and too much flexibility; there are often several ways of doing the same or similar things. This is a typical committee effect.»³⁷

E hizo tres recomendaciones que hoy se leen como una lista de cosas que pasaron igualmente, veinte años tarde y por las malas:

• Eliminar el modo transporte. «We therefore recommend that transport mode be eliminated.»³⁷ El modo transporte es el que usa L2TP/IPsec, y el modo al que el NAT más daño hace.
• Eliminar AH. «We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality.»³⁷ Lo eliminó el NAT en su lugar, por una razón peor.
• No permitir nunca cifrado sin autenticación. Avisaban de que los administradores «will be quite likely to configure ESP for only encryption, believing that it provides security» — con toda probabilidad configurarían ESP solo con cifrado, creyendo que eso da seguridad³⁷.

Ocho años después ese último punto dejó de ser un aviso. Degabriele y Paterson publicaron ataques que «break any RFC-compliant implementation of IPsec making use of encryption-only ESP» — rompen cualquier implementación conforme que use ESP solo con cifrado, a partir únicamente del texto cifrado, y que no exigen más que escuchar el tráfico e inyectar paquetes³⁵. La predicción llevaba ocho años en el registro público y la norma seguía permitiendo esa configuración.

El veredicto de aquel informe de 1999 es la frase a la que vuelvo una y otra vez: «We have found serious security weaknesses in all major components of IPsec. As always in security, there is no prize for getting 90% right; you have to get everything right.»³⁷

Dos datos más, y lo dejo.

Logjam, 2015. El equipo que hay detrás escaneó una muestra del 1 % de IPv4 en busca de IKE y encontró que el 86,1 % de los servidores IKEv1 y el 91,0 % de los IKEv2 admitían el grupo Oakley 2 de 1024 bits, y que el 66,1 % de los servidores IKEv1 perfilados lo preferían. Su conclusión: un cálculo previo contra un segundo grupo de 1024 bits «would allow decryption of traffic to 66% of IPsec VPNs», y los documentos de inteligencia publicados sobre explotación de VPN son «consistent with having achieved such a break»³⁸. La agilidad criptográfica, de la que IPsec tiene la mayor cantidad, es lo que permitió que casi todo el mundo se quedara quince años en el mismo grupo débil.

CVE-2016-1287. Un desbordamiento de búfer en el código IKEv1 e IKEv2 de los Cisco ASA, alcanzable enviando paquetes UDP manipulados, con ejecución remota de código antes de la autenticación³⁹. Piensa dónde está esa caja. Es el equipo que expusiste a propósito a todo internet, ejecutando el protocolo con más opciones del parque, con un reensamblador de fragmentos delante del analizador, y guardando las llaves de todo lo que hay detrás. La complejidad de la que avisaban Ferguson y Schneier no es una abstracción. Es superficie de ataque, en la única máquina que no puedes poner detrás de nada.

Diagnosticarlo mientras sigas explotándolo

No puedes apagar todo esto esta tarde, así que aquí tienes cómo trabajarlo. Este es el método, en el orden que menos cuesta, con lo que significa de verdad cada resultado.

Mira primero el cable, no la consola

Las dos consolas te dirán lo que creen. El cable te dice lo que pasó. Una captura en la frontera, treinta segundos, responde a la vez a las tres primeras preguntas:

tcpdump -ni eth0 'udp port 500 or udp port 4500 or ip proto 50 or ip6 proto 50'

• Nada en absoluto saliente — el problema está por delante de IPsec: encaminamiento, política o un cortafuegos del host. Deja de buscar en la criptografía.
• Solo saliente, nada de vuelta — tus paquetes salen y sus respuestas no llegan. Filtrado en tránsito, un par muerto, o el extremo remoto rechazando en silencio.
• UDP 500 en ambos sentidos pero el 4500 no aparece nunca — la traversía de NAT no se negoció. O un extremo la tiene desactivada o falló la detección.
• Protocolo 50 en el cable mientras un extremo está detrás de NAT — la negociación decidió que no había traductor cuando sí lo hay. Eso no se arregla solo.

Leer el fallo del intercambio de claves

IKEv2 te dice por qué rechazó, y los nombres de las notificaciones son lo bastante concretos como para diagnosticar solo con ellos. Ayuda tener antes delante la forma del intercambio entero, porque cada notificación de abajo pertenece a un peldaño concreto de él.

La guía de fase 2 de Juniper dice lo mismo del más común de ellos: «no proposal chosen» significa que el equipo «did not accept any of the IKE Phase 2 proposals that the peer sent», y el arreglo es una propuesta mutuamente aceptable y no un reinicio repetido⁴⁰.

En strongSwan, el estado de todo en una orden:

swanctl --list-sas                 # what is established, and what it negotiated
swanctl --log                      # the negotiation as it happens

En Cisco, show crypto ikev2 sa y show crypto ipsec sa, con debug crypto ikev2 cuando no levanta⁴¹. En Junos, show security ike security-associations y show security ipsec security-associations, con la negociación en show log kmd-logs⁴².

¿Se negoció realmente la traversía de NAT?

Esta es la comprobación que la gente se salta, y explica buena parte de los «desde la oficina va y desde casa no».

Cada extremo manda resúmenes de las direcciones y puertos que cree en juego. Si el resumen que el extremo remoto calcula a partir del paquete recibido no cuadra con el que mandaste, hay un traductor entre medias, y ambos extremos pasan a UDP 4500. Si la detección falla — un lado tiene la traversía desactivada, o algo en medio estropea el intercambio — ambos extremos siguen con ESP desnudo, que no sobrevivirá al traductor.

Así que: ve el puerto 4500 en la captura, en ambos sentidos, o no hay traversía ninguna. No te fíes de la palabra de la consola.

Comprueba después que el keepalive esté corriendo de verdad y que su intervalo sea menor que el plazo con que tu operador caduca las asociaciones. El valor por defecto son veinte segundos⁶; el suelo de la norma para operadores de NAT son dos minutos⁹; lo que hace tu operador concreto, no lo ves. Si el túnel se muere tras un rato inactivo y revive con el tráfico, es esto todas las veces.

Los contadores del núcleo que casi nadie lee

En Linux la capa de transformación lleva un desglose completo de errores, y es la forma más rápida de convertir «no funciona» en una causa concreta. Los contadores los documenta el propio núcleo⁴³.

cat /proc/net/xfrm_stat        # error counters, by cause
ip -s xfrm state               # per-SA packet and byte counters
ip xfrm policy                 # what should be protected, and in which direction

Se lee mejor como camino que como lista. El paquete pasa por cinco etapas, y cada una tiene su propio contador:

Mira cuál se mueve mientras ocurre la avería:

XfrmInTmplMismatch y XfrmInNoPols son los dos que conviene reconocer de vista, porque ambos significan que la criptografía está bien y la política no, que es lo contrario de donde todo el mundo mira primero.

Dice «levantado» y no se mueve nada

Ambos extremos establecidos, sin tráfico. Lee los contadores por asociación en los dos sentidos:

ip -s xfrm state

• Bytes salientes subiendo, entrantes planos — estás cifrando y enviando, y no vuelve nada. O tu ESP no llega a ellos o el suyo no llega a ti. Pídele al extremo remoto su contador saliente; si también sube, los paquetes mueren en tránsito y la siguiente pregunta es dónde, y esa es una pregunta de TTL y no de criptografía.
• Los dos planos — no se le está ofreciendo nada al túnel. Encaminamiento o política, no IPsec. En modo basado en ruta, comprueba que la ruta apunte de verdad a la interfaz del túnel; en modo basado en política, comprueba los selectores.
• Los dos subiendo, aplicaciones aún rotas — no es el túnel. Ve a mirar qué hay al otro lado.

El consejo de Juniper para este caso sigue el mismo instinto en su lenguaje: si solo sube el contador de paquetes salientes de la sesión, confirma con el par si el tráfico se está recibiendo siquiera⁴⁴.

Lo pequeño funciona, lo grande se cuelga

La MTU. Siempre es la MTU. La prueba lleva diez segundos:

ping -M do -s 1400 10.0.0.1      # inside the tunnel, do-not-fragment set
ping -M do -s 1300 10.0.0.1      # step down until it succeeds

Donde empieza a pasar te dice el tamaño realmente utilizable. Haz luego que TCP lo averigüe por sí mismo, fijando el tamaño de segmento anunciado al camino en vez de confiar en que cada error ICMP sobreviva al viaje:

nft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu

Y arregla también la causa de fondo, que casi siempre es una regla ICMP demasiado amplia en alguna frontera. Descarta el eco si quieres. He defendido en otro sitio que se lo merece. Pero conserva Fragmentation Needed y Packet Too Big. Son el mecanismo, no una cortesía.

Se cae a reloj

Cronometra las caídas. El intervalo nombra la causa él solo.

• Un periodo fijo que coincide con una vida útil configurada — renovación de claves. La asociación expira y la negociación de reemplazo falla o entra en carrera. Comprueba las vidas útiles de ambos extremos; valores distintos son normales y no pasa nada, pero una vida dura en un extremo más corta que la blanda del otro produce exactamente esto.
• Tras un rato sin tráfico, de vuelta al primer uso — caducó una asociación de NAT. Intervalo del keepalive, o ausencia de él.
• La detección de par muerto lo tira mientras el enlace está bien — las sondas se pierden en lugar de que el par esté muerto, a menudo porque las sondas son el único tráfico y la asociación ya se ha ido.

El segundo usuario echa al primero

Dos pares llegan al concentrador desde una dirección y se autentican con la misma identidad. La pasarela elige entre conservar la asociación antigua y sustituirla, y un valor por defecto muy extendido es sustituir. Así que gana la segunda conexión y la primera muere en silencio.

Dale a cada par una identidad verdaderamente única en vez de una dirección o un nombre compartido, y configura la pasarela para que conserve varias asociaciones desde una misma dirección en lugar de suponer una por par. Y pruébalo de la única forma que cuenta: dos clientes, una dirección, a la vez. Si tu prueba de aceptación nunca ha tenido dos usuarios detrás de un NAT, no has probado justo el caso en el que está la mayoría de tus usuarios.

Los mismos fallos, en el Fisher-Price OS (Windows)

Cada comprobación de arriba se ejecuta desde una máquina Unix, y si tienes una en esa red úsala, porque te dirá la verdad antes y le da igual lo que corra al otro lado. Pero mucha gente que lee esto tiene un cliente que no conecta, un sistema operativo que le esconde la máquina a propósito, y nada más donde mirar. Así que aquí va el mismo método otra vez, en el mismo orden, con las herramientas que ese sistema trae de verdad.

Mira el cable. No hay tcpdump, pero hay una captura. Lánzala elevada, reproduce el fallo, párala:

netsh wfp capture start cab=on file=ipsec
netsh wfp capture stop

Eso escribe un .cab. Dentro está el rastro de lo que la plataforma de filtrado y el intercambio de claves hicieron realmente mientras fallaba, y eso es más de lo que ninguna de las dos consolas admite. Para verlo en directo en lugar de archivado, la misma familia de comandos escribe en consola con file=-: netsh wfp show state «Displays the current state of WFP and IPsec», y netsh wfp show ikeevents «Displays recent Internet Key Exchange (IKE) epoch events matching the specified parameters», filtrado a un solo par⁴⁵.

netsh wfp show state file=-
netsh wfp show ikeevents remoteaddr=203.0.113.5 file=-

show ikeevents es aquí lo más parecido al registro de intercambio que cualquier otra pila escribe sin que se lo pidan. Conviene saber que existe. Si no, la interfaz te entrega un número de tres cifras y nada más, y acabas diagnosticando un intercambio de claves a ciegas.

Lee las asociaciones, y lee las dos. Los equivalentes de ip -s xfrm state y swanctl --list-sas son dos cmdlets, y la separación entre ambos es todo el diagnóstico:

Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

El modo principal es el intercambio de claves. El modo rápido lleva los paquetes. Microsoft dice la relación con claridad: «There is only one main mode SA between a pair of computers, but there can be many quick mode SAs»⁴⁶. Así que modo principal presente con modo rápido vacío es el mismo fallo que una IKE_SA levantada sin CHILD_SA debajo, y significa lo mismo: los dos extremos se pusieron de acuerdo en cómo hablar y luego no en qué proteger. Mira los selectores de tráfico, no los algoritmos.

Lee los registros, en los dos sitios donde se esconden. Los fallos de conexión caen en el registro de Aplicación bajo el origen RasClient, y la nota de Microsoft sobre cómo leerlos es la parte útil: «All error messages return the error code at the end of the message»⁴⁷. Ese número es el diagnóstico, y la sección siguiente dice qué significan los números. Las decisiones de directiva y de filtrado caen en otro sitio completamente distinto, bajo Registros de aplicaciones y servicios, en los canales de Firewall de Windows con seguridad avanzada. Dos registros, dos equipos, un fallo.

Recógelo como es debido cuando tengas que escalar. El paquete soportado es TSS — TSS.ps1 -Scenario NET_VPN en el cliente, TSS.ps1 -Scenario NET_RAS en el servidor, arrancado antes de reproducir el fallo y parado después⁴⁸. Apréndelo antes de que alguien te lo pida.

Cuando se queda en Conectando y acaba expirando

Este es el fallo que llena los tickets, y la palabra del error es mentira. Empieza por nombrar el código. El código es preciso aunque el mensaje no sirva de nada.

Todos salen de la propia lista de errores de Microsoft⁴⁹. Ahora vuelve a leer el 809. Se llama ERROR_VPN_TIMEOUT, y la causa documentada es un puerto bloqueado. El cliente no expira porque el otro extremo sea lento. Expira porque el otro extremo está mudo, y el silencio es el único modo de fallo que sabe informar un protocolo sin puertos y sin negociación visible.

Ojo con la palabra blocked, eso sí, porque carga más de lo que aguanta. Tres cosas distintas la llevan puesta, y solo una de ellas es una regla de denegación.

Nadie envió nunca un 4500. La traversía de NAT no se negoció, así que el cliente siguió hablando ESP, y ESP no le da nada que reescribir a un traductor. El comportamiento por defecto de esa plataforma ya basta como explicación: sin el valor de registro no forma ninguna asociación NAT-T con un servidor detrás de un traductor³¹. Así que el 4500 no está bloqueado. No se ha intentado nunca.

El ayudante que antes tapaba esto está apagado. Los cortafuegos y los routers domésticos llevan ayudantes por protocolo — el IPsec passthrough en equipo de consumo, y toda la familia de pasarelas de nivel de aplicación detrás — que leen un protocolo que el NAT no sabe tratar y abren el camino de vuelta para él. En Linux la forma automática de todo eso se apagó por defecto en el núcleo 4.7 «for security reasons», y desde entonces la recomendación es enganchar un ayudante a propósito con una regla o no hacerlo en absoluto; entre los ayudantes cubiertos está el de PPTP⁵⁰.

Y apagarlos fue lo correcto. Un ayudante es un trozo de tu cortafuegos que analiza una carga útil y luego abre un agujero según lo que ha leído. NAT Slipstreaming es la factura de eso: un navegador que visita una página, tráfico moldeado para que el ayudante SIP o H.323 del router lo lea como una llamada, y un agujero abierto a través del NAT — en la versión de 2021, hacia cualquier dirección interna, no solo hacia la máquina que cargó la página⁵¹. Apagar los ayudantes cierra eso. También deja tu IPsec parado. Las dos cosas son ciertas a la vez, y la segunda no es un argumento para deshacer la primera.

Que es otra vez esta entrada en pequeño. El protocolo solo funcionaba porque unas cajas en medio leían tráfico que no era suyo y abrían agujeros en su nombre, y el sector se ha pasado la última década decidiendo, con toda la razón, dejar de hacer eso.

Así que trabaja las causas en este orden, lo más barato primero.

Una: no vuelve nada. Captura en el cliente, o pregúntale a la pasarela. Si UDP 500 sale y no vuelve nada, es filtrado o alcanzabilidad, y ningún temporizador lo arregla. Si el 500 va y viene y el 4500 no aparece nunca, la traversía de NAT no se negoció. Y si cualquiera de los dos extremos está detrás de un traductor, vuelves al valor de registro de más arriba en esta entrada: AssumeUDPEncapsulationContextOnSendRule, 1 o 2, en las dos máquinas, y luego reiniciar³¹. Sin él, el cliente se niega por diseño y lo notifica como expiración.

Dos: la respuesta es demasiado grande para llegar. Esta se lleva tardes enteras. La autenticación por certificado hace grande el segundo intercambio, porque lleva una cadena, y un intercambio grande se fragmenta. Los fragmentos los tiran las mismas cajas intermedias que todo lo demás de esta entrada, el cliente retransmite al mismo agujero, y entonces se rinde y dice expiración. La señal es un diagnóstico por sí sola: una clave precompartida conecta y un certificado no. Eso no es un fallo de certificado. Es un fallo de tamaño, porque el intercambio con clave precompartida es lo bastante pequeño para caber. La fragmentación IKEv2 normalizada existe precisamente para esto²³, y strongSwan deja constancia de cuándo la tuvo esta plataforma: «IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server»³³. Cualquier cosa más antigua, o una pasarela con la fragmentación desactivada, y dependes de un camino que lleve un datagrama UDP fragmentado. Muchos no lo hacen.

Tres: conecta y luego se cae a reloj. Cronométralo. Si muere tras un periodo fijo de inactividad, eso es el 828 y es configuración, no un fallo — -IdleDisconnectSeconds en el servidor, con -SALifeTimeSeconds, -MMSALifeTimeSeconds y -SADataSizeForRenegotiationKilobytes como los otros tres relojes capaces de terminar una sesión⁵². El último la termina por volumen en lugar de por tiempo, y por eso una sesión puede morir puntualmente durante una copia grande de ficheros y nunca durante un día entero de correo. Y si muere al renovar claves con el cliente detrás de NAT, ese es el fallo de interoperabilidad documentado más arriba: el cliente rechaza una renovación iniciada por el servidor con el error de Microsoft 13863, y la respuesta del lado de la pasarela es dejar de iniciarla y que la inicie el cliente³³.

Cuatro: no es el túnel en absoluto. El 930 es RADIUS. El 812 es un método de autenticación que el servidor no aceptó⁴⁷. El 13801 y el 13806 son certificados — uso extendido de clave equivocado, caducado, falta la raíz, o un nombre de servidor que no coincide con el sujeto del certificado⁴⁷. La negociación del túnel estaba bien en los cuatro casos, y si te pasas la tarde con los algoritmos no encontrarás ninguno.

Esto es lo que hay que llevarse de esa tabla. Seis códigos de error, cinco de ellos con la palabra timeout en el nombre, y ni uno solo es una expiración de verdad. Son un puerto bloqueado, un fragmento perdido, una decisión de directiva y un servidor RADIUS, todos llevando la misma palabra, porque la capa que informa del fallo no ve lo bastante de lo que pasó como para decir algo más útil. Alargar el temporizador no arregla ninguno, y alargar el temporizador es justo a lo que te invita la interfaz.

Qué usar en su lugar

No voy a fingir que el sustituto sea exótico. Está en el núcleo y lleva años estándolo.

WireGuard es un puerto UDP, una clave por par, ninguna negociación de cifrados y ninguna agilidad de protocolo. La postura de su autor al respecto es deliberada y está dicha: «It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.»⁵³ Esa sola decisión borra de golpe NO_PROPOSAL_CHOSEN, INVALID_KE_PAYLOAD, los ataques de degradación y el hallazgo de Logjam, porque no hay nada que negociar ni nada que degradar.

También es honesto con el precio, y yo también: sin agilidad, el día que cae una primitiva actualizas la flota entera en lugar de cambiar una línea de configuración. Es un coste operativo real y es el correcto a pagar.

El resto encaja casi punto por punto con la lista de arriba. Tener un puerto UDP significa que NAT y CGNAT lo tratan como a cualquier otro flujo, y que ECMP y la agregación de enlaces le aplican el hash como a cualquier otro flujo. La itinerancia viene de serie en vez de atornillada — un paquete autenticado desde una dirección nueva mueve el extremo del par, así que un teléfono que pasa del wifi al móvil no renegocia nada. A un paquete no autenticado no le responde nada, así que un escáner encuentra un puerto cerrado donde IPsec le ofrecería un concentrador con el que hablar. Y cabe en menos de 4.000 líneas de código⁵³, frente a una pila que necesita un documento entero para enumerar sus dieciséis incompatibilidades con una sola caja intermedia.

En rendimiento, sencillamente midió más rápido que las dos configuraciones IPsec con las que se comparó: 1.011 Mbit/s frente a 881 y 825, con menos latencia⁵³. Yo no retiraría un protocolo por una prueba de rendimiento. Lo menciono porque el último argumento que le queda a IPsec suele ser el rendimiento, y tampoco es cierto.

Para llevar a una persona hasta una aplicación — en lugar de una red hasta otra red — la respuesta no es un túnel en absoluto. Identidad en la puerta, la aplicación publicada a través de ella, nada encaminado. Eso lo he montado con Proxmox y Cloudflare Access en VDI Zero Trust sin la factura de la nube, y lo relevante aquí es que quien necesita tres aplicaciones internas no necesita una ruta a todo tu parque.

Y digamos en voz alta la parte callada sobre el hardware. Sí, hay tarjetas de red y ASIC con descarga de ESP, y ese es un argumento real para IPsec en equipos concretos a velocidades concretas. Es un argumento sobre silicio que alguien ya te vendió, no sobre que el protocolo sea correcto. Como tal caduca, y rápido. PPTP sobrevivió exactamente igual, exactamente mientras existió la casilla.

Retirarlo como es debido

Retirar algo es un plan con fechas, no un sentimiento. Este es el que yo firmaría.

Para los nuevos despliegues de IPsec ahora. No «preferir alternativas». Parar. Cada túnel nuevo es un túnel que alguien tendrá que migrar más adelante, y los que se construyen hoy seguirán funcionando en 2035 si nadie dice que no esta semana.

Haz primero el acceso remoto, porque ahí es donde más fuerte cae cada avería de esta entrada: el CGNAT, la dirección compartida, los keepalives, el segundo usuario en la misma casa, el agujero negro de MTU en la red de un hotel cualquiera. Es además lo más fácil de mover, porque los equipos están gestionados y el cambio es un cliente.

Después el sitio a sitio por internet público, los mismos problemas con menos extremos y una ventana de mantenimiento.

Deja para el final los túneles de los que no posees los dos extremos: un socio, un regulador, el servicio gestionado de un operador. Esos se mueven cuando se mueve el contrato, y cómo ponerlos en movimiento está en el punto siguiente.

Deja de comprar equipos cuyo único túnel es IPsec. Ponlo en el pliego. Una línea que pida un túnel moderno, basado en puertos y capaz de itinerancia, es una línea que un fabricante contesta o no contesta, y así es como acaba perdiendo el argumento del parque instalado. Ese argumento es el único que mantiene vivo todo esto, y solo se derrota comprando.

Escribe qué túneles quedan y por qué, y pon una fecha a cada uno. Un protocolo del que nadie se ha ocupado en diez años es como PPTP ha llegado a 2026. Un inventario con fechas es la diferencia entre retirar algo y limitarse a que no te guste.

Si lo sigues desplegando, ¿puedes llamarte profesional de TI?

Es una pregunta de verdad, y la voy a responder con honestidad, porque es hacia donde camina el resto de esta entrada.

Depende de si lo sabes. Y saber no te pasa sin más. Asegurarte de que lo sabes es el trabajo.

Si este año estás montando un acceso remoto IPsec nuevo y no sabes decir, sin mirar nada, por qué ESP no tiene puertos, qué le hace una línea residencial detrás de NAT de operador, por qué una red NAT64 no lo lleva en absoluto, o para qué sirve realmente ese byte cada veinte segundos — entonces no. En esto no, todavía no. No estás eligiendo un protocolo. Estás repitiendo una forma, porque la anterior era así y nadie en la sala preguntó por qué — tú incluido. El fallo no es la laguna. Lagunas tiene todo el mundo. El fallo es construir por encima de una que nunca fuiste a cerrar. Como tal, quien lo herede en 2035 se come una década de tickets que eran todos evitables el día que lo dibujaste.

Y le voy a poner el nombre que le toca, porque la versión educada lleva veinte años circulando y no ha cambiado nada. Quien despliega un protocolo que no sabe explicar no es un ingeniero. Es un seguidor. Lee fichas — la arquitectura de referencia del fabricante, la última petición de cambio, un diagrama que alguien dibujó en 2014 y que nadie ha vuelto a abrir — y las lee con auténtica convicción, y detrás de la actuación no hay comprensión ninguna. Desde fuera se parece exactamente a la competencia. Sigue pareciéndose exactamente a la competencia hasta el primer fallo que las fichas no cubren, y a partir de ese segundo es lo único que importa en la sala.

Las fichas son también la razón de que este protocolo siga aquí. Nadie se puso delante de una pizarra en 2026 a defender IPsec por sus méritos. Se volvió a desplegar porque estaba en la ficha, y la ficha la escribió un fabricante cuyo interés es que sigas comprando la caja que lo termina. Así es como algo sobrevive veinte años a su propia esquela: no por haber sido defendido, sino por no haber tenido que justificarse ni una sola vez ante alguien capaz de notar la diferencia.

Y esto se dice. En voz alta, en la sala, en el momento — no mascullado en el pasillo después. Quien pone la palabra profesional al lado de su nombre recibe con ella la invitación a que le pregunten, y preguntar no es de mala educación. Que te pregunten y tener respuesta es toda la diferencia entre la palabra y una tarjeta de visita.

Donde más pesa es cuando lo estás pagando. Una consultora, un MSP, la rama de servicios profesionales de un fabricante, el integrador del acuerdo marco: lo que compras es criterio, y el criterio es lo único que no puedes inspeccionar en la entrega. Así que inspecciónalo antes. Pregunta por qué este protocolo y no otro. Pregunta qué le pasa en una línea detrás de NAT de operador, en una red móvil solo IPv6, en un camino que descarta fragmentos en silencio. Pregunta cuáles de esos han vivido ellos mismos y qué hicieron entonces. Sabrás en menos de dos minutos si te están contando algo o leyéndotelo, y dos minutos son una prueba bastante más barata que cuatro años de tickets. Y si la respuesta son fichas y firmas igualmente, eso también es una decisión: acaba de pasar a ser tuya y no suya.

Si sabes decir todo eso y lo despliegas igualmente porque un regulador lo nombra por protocolo, porque el equipo del socio no termina otra cosa, o porque el sustituto está en el presupuesto del año que viene y esto tiene que funcionar en marzo — entonces sí, evidentemente, y estás haciendo bien tu trabajo. Las restricciones son reales, y yo he construido rodeando cosas peores. Lo que separa a los dos no es el protocolo del diagrama. Es si escribiste por qué, y si hay una fecha al lado.

La posición indefendible es la de en medio. Saber lo bastante para estar incómodo, y construirlo igual porque nadie te obligó a justificarlo. Eso no es ingeniería. Es costumbre, con un número de cambio encima — y es exactamente así como L2TP acabó en una ficha técnica impresa este año.

Así que hazte la pregunta antes de que cierre el concurso, no después. Profesional no es una palabra sobre qué protocolos conoces. Es una palabra sobre si puedes defender el que elegiste, en voz alta, ante alguien que conoce sus modos de fallo. Si puedes, despliega lo que exijan las restricciones y duerme tranquilo. Si no puedes, acabas de encontrar lo que toca leerse esta noche, y eso no es un insulto. Todo el mundo fue seguidor alguna vez, sin excepción, yo incluido. Lo que no se puede defender es elegir seguir siéndolo y llamar a eso una carrera.

Una buena idea también puede haber terminado

Quiero ser justo con IPsec, porque se lo merece.

Fue el instinto correcto. La seguridad va abajo en la pila, donde todo la hereda y ninguna aplicación tiene que merecer confianza para hacerla bien. Atar la asociación a la dirección no fue un error en 1995 — la dirección era la máquina, y construir sobre eso era lo correcto. Quienes lo escribieron eran gente seria con un problema real, y es el artículo de WireGuard, entre todos los documentos, el que mejor lo dice: la estratificación de IPsec es sólida, todo está en su sitio, hasta la perfección académica⁵³.

Y entonces se movió el suelo. No porque IPsec hiciera nada mal, sino porque este sector decidió que las direcciones eran un coste que gestionar en lugar de algo que recibe cada máquina, y construyó veinticinco años de traducción para esquivar la alternativa. A IPsec se le retiró el cimiento sin ruido y, en vez de admitirlo, calzamos por debajo. Encapsulación UDP. Luego keepalives. Luego encapsulación TCP para las redes que bloquean UDP. Luego otra cabecera UDP para que un router encuentre algo a lo que aplicar el hash. Cada arreglo razonable por separado; el montón que forman es un protocolo sostenido en pie por gente a la que pagan por sostenerlo en pie.

Esa es la parte que merece enfado, y en realidad no va de IPsec. Nuestro sector es muy bueno manteniendo cosas y muy malo terminándolas. El mantenimiento es facturable, presupuestado, con gente asignada y seguro. Retirar algo es una decisión que alguien tiene que firmar, con su nombre debajo, y sin recompensa inmediata. Así que PPTP vivió catorce años más allá de la prueba de que no valía nada, L2TP se sigue entregando en cajas que se venden este año, e IKEv1 siguió negociando túneles una década después de pasar a Historic. No porque nadie los defendiera. Sino porque nunca se obligó a nadie a matarlos.

No hay premio por acertar el 90 %. Ferguson y Schneier lo escribieron de IPsec en 1999, y lo que ha pasado desde entonces son treinta años en los que el sector se ha equivocado en el último 10 % de una forma nueva cada vez y ha llamado solución al parche.

Una buena idea también puede haber terminado. Saber cuándo dejar de mantener algo es una habilidad, y es aquella en la que este oficio es peor. Alguien tiene que ser quien diga que un protocolo ya ha tenido su vida, escriba la fecha y cargue con las consecuencias de haber sido quien lo dijo. Si no, en 2040 seguiremos mandando un paquete de un byte cada veinte segundos, para mantener caliente una tabla en una caja que no es nuestra, en una red que nos quitó las direcciones y nos las cobró.