IPsec (Internet Protocol Security) no es un único protocolo, sino una suite de mecanismos que protege comunicaciones en la capa IP. A diferencia de OpenVPN o WireGuard, que encapsulan su tráfico sobre UDP o TCP, IPsec se integra directamente en el funcionamiento de la red.

Esta arquitectura explica su doble realidad: está muy extendida en empresas, enlaces entre sedes y sistemas Apple, pero suele ser demasiado compleja para el uso cotidiano. Fue concebida para una Internet menos móvil y con menos traducción de direcciones. NAT, cambios frecuentes de red y múltiples implementaciones exponen hoy sus principales límites.

Arquitectura: modos y componentes

Modo transporte y modo túnel

El modo transporte cifra la carga útil, pero conserva visible el encabezado IP original. Las direcciones de origen y destino permanecen expuestas, por lo que se usa principalmente entre equipos dentro de entornos controlados.

El modo túnel encapsula el paquete IP completo dentro de uno nuevo. Oculta las direcciones internas y protege el contenido, a cambio de agregar encabezados y complicar la MTU. Es el modo habitual para VPN y conexiones entre sedes.

AH y ESP

Authentication Header (AH) verifica integridad, pero no cifra y es incompatible con la mayoría de escenarios NAT porque autentica campos que el router modifica. Su uso actual es muy limitado.

Encapsulating Security Payload (ESP) cifra, autentica y agrega protección contra repetición. Incluye un identificador de asociación, un número de secuencia y la información necesaria para validar cada paquete. ESP es el componente utilizado en los túneles IPsec modernos.

NAT-T

ESP usa el protocolo IP 50, no un puerto TCP o UDP. Muchos routers domésticos no pueden traducirlo correctamente. NAT Traversal resuelve el problema encapsulando ESP dentro de UDP 4500. Esto mejora la compatibilidad, pero agrega sobrecarga y depende de mensajes de mantenimiento para conservar el mapeo NAT.

Cuando una conexión falla, hay que distinguir si el origen está en IKE, ESP, NAT, el firewall o la MTU. Esa cadena hace que el diagnóstico sea más difícil que en protocolos diseñados desde el comienzo para atravesar NAT.

IKEv1 frente a IKEv2

IPsec no define por sí solo cómo intercambiar claves. Esa responsabilidad pertenece a IKE, que negocia algoritmos, autentica a las partes y crea asociaciones de seguridad.

IKEv1 requiere más mensajes, tiene modos heredados inseguros y no maneja bien la movilidad. El modo agresivo puede exponer información que facilita ataques de diccionario contra una clave compartida. Su presencia en una oferta actual es una señal de infraestructura atrasada.

IKEv2 reduce la negociación, mejora la autenticación y admite certificados, EAP, detección de pares inactivos y MOBIKE. Con MOBIKE puede actualizar una sesión cuando cambia la dirección IP sin reconstruir todo el túnel. Aun así, conserva la complejidad general de IPsec.

Criptografía: flexibilidad y riesgo de configuración

Una configuración moderna puede usar AES-256-GCM o ChaCha20-Poly1305, SHA-256 cuando se necesita una función separada de integridad, Diffie-Hellman grupo 14 como mínimo o Curve25519, y certificados X.509.

Estas opciones son sólidas. El problema es que IPsec también permite combinaciones heredadas: 3DES, SHA-1, grupos Diffie-Hellman débiles, claves compartidas previsibles o ausencia de secreto perfecto hacia adelante. La flexibilidad indispensable para interoperar con equipos antiguos también permite mantener configuraciones peligrosas.

El secreto perfecto hacia adelante depende de renovar las claves con un intercambio Diffie-Hellman nuevo. Si la política de renovación reutiliza material anterior, las sesiones quedan más expuestas. WireGuard evita gran parte de este problema al imponer una selección criptográfica moderna.

Rendimiento, MTU y estabilidad

Con aceleración AES-NI, IPsec puede alcanzar velocidades altas. El cifrado no suele ser el cuello de botella. Las dificultades aparecen en la encapsulación, la fragmentación y las redes inestables.

El modo túnel con NAT-T puede agregar aproximadamente entre 60 y 90 bytes por paquete, según la configuración. Si el paquete original ya se acerca a una MTU de 1500 bytes, el resultado puede fragmentarse. La pérdida de un solo fragmento obliga a reconstruir o retransmitir el paquete completo y aumenta la latencia.

Una solución habitual es reducir la MTU de la interfaz a 1400 o incluso 1280 y utilizar descubrimiento de MTU. Esa corrección exige conocimientos de red y no siempre está expuesta en una aplicación comercial.

En movilidad, IKEv2 con MOBIKE mejora mucho la continuidad, pero WireGuard suele retomar el tráfico con menos estado. La experiencia final depende de que el cliente, el servidor y la red admitan correctamente todos los componentes.

Por qué los servicios VPN todavía ofrecen IPsec

La razón principal es la compatibilidad. iOS, iPadOS, macOS y Windows incluyen IKEv2/IPsec y permiten distribuir perfiles sin instalar un cliente específico. Las empresas también conservan equipos Cisco, Juniper, Fortinet y otras plataformas con años de políticas, certificados y procedimientos alrededor de IPsec.

Para un entorno con MDM, una PKI interna o enlaces entre centros de datos, reemplazar toda esa infraestructura puede ser más costoso y riesgoso que mantenerla. IPsec persiste por interoperabilidad y requisitos de ecosistema, no porque sea siempre superior a un protocolo reciente.

Cuándo usar IPsec

IPsec sigue siendo razonable para:

  • enlaces permanentes entre oficinas o centros de datos;
  • entornos Apple administrados mediante MDM;
  • infraestructuras con certificados y firewalls ya preparados;
  • organizaciones que necesitan compatibilidad con equipos especializados.

Para una persona que solo necesita una VPN en su teléfono o computadora, WireGuard suele ofrecer una configuración más simple, mejor movilidad y una superficie de revisión menor. OpenVPN conserva ventajas cuando se requiere TCP 443 o compatibilidad con sistemas muy diversos.

Señales de alerta: IKEv1, claves compartidas débiles, ausencia de secreto perfecto hacia adelante, algoritmos heredados o documentación que no explica la renovación de claves.

Controversias y percepción después de Snowden

Las revelaciones de 2013 mostraron intentos de debilitar ciertos componentes criptográficos, incluido Dual_EC_DRBG, presente en algunas implementaciones. El problema histórico estaba relacionado con el generador aleatorio, no con ESP o IKE como conceptos. Las implementaciones modernas deben usar generadores y suites actuales como AES-GCM, ChaCha20-Poly1305 y SHA-256.

La desconfianza también nace de la complejidad. Una persona no especializada no puede comprobar fácilmente la combinación de algoritmos, la política de renovación o la calidad de una implementación específica. Windows, Apple, Android, strongSwan y Libreswan no comparten exactamente el mismo código; una auditoría de una pila no valida las demás.

Interoperabilidad y fragmentación de implementaciones

La etiqueta “IPsec” no identifica una única base de código. Windows, los sistemas Apple, Android, strongSwan, Libreswan y los dispositivos de red aplican el estándar mediante implementaciones diferentes. Pueden coincidir en los algoritmos principales y divergir en extensiones, tratamiento de fragmentos, almacenamiento de claves o mensajes de error. Una auditoría de una implementación no demuestra que todas las demás se comporten igual.

Esta diversidad complica el soporte. Una combinación aceptada por un firewall puede ser rechazada por otro; un equipo puede proponer primero una suite antigua; y una actualización de firmware puede cambiar la negociación. Las organizaciones reducen el riesgo documentando una lista corta de algoritmos, desactivando IKEv1, exigiendo certificados, registrando solo la información operativa necesaria y probando la renovación de claves.

Qué debe documentar un operador

  • versión de IKE y método de autenticación;
  • algoritmos de cifrado, integridad y grupos Diffie-Hellman;
  • frecuencia de renovación y uso de secreto perfecto hacia adelante;
  • soporte de MOBIKE y NAT-T;
  • política de registros y protección de las claves privadas;
  • MTU recomendada y procedimiento de diagnóstico.

La ausencia de estos datos no demuestra que el túnel sea inseguro, pero impide evaluar si la configuración moderna anunciada se aplica realmente.

Conclusión

IPsec puede ofrecer una seguridad alta cuando está configurado por un equipo competente. Sigue siendo coherente en empresas, enlaces entre redes y ecosistemas que dependen de su integración. Su flexibilidad e interoperabilidad son fortalezas profesionales y, al mismo tiempo, fuentes de errores para el gran público.

WireGuard suele ser mejor para velocidad, simplicidad y movilidad. OpenVPN es útil cuando se busca compatibilidad o TCP. IPsec se elige con frecuencia por una necesidad de infraestructura, no por ser el ganador universal.

Otros protocolos VPN

  • IKEv2: negociación y movilidad para IPsec.
  • L2TP: encapsulación heredada que depende de IPsec.
  • WireGuard: protocolo moderno y compacto.
  • OpenVPN: opción flexible y ampliamente compatible.
  • PPTP: protocolo obsoleto que debe evitarse.