Desconexiones IKEv2 en Windows: errores comunes y soluciones fiables

Cómo falla realmente IKEv2 en Windows (para que dejes de adivinar)

“Desconexión IKEv2” no es un solo problema. Es una familia de problemas que todos se ven como “VPN caída” a nivel de usuario.
Tu trabajo es separar: fallos de negociación (no puede levantar el túnel), fallos de vivacidad (túnel arriba, luego muere),
problemas de enrutamiento/MTU (túnel arriba, el tráfico muere) y fallos de credenciales/certificados (túnel arriba hasta que hay que renovarlo).

Las piezas móviles que importan en Windows

• RasClient: la capa cliente VPN de Windows. Los códigos de error suelen venir de aquí.
• IKEEXT: servicio IKE y AuthIP IPsec Keying Modules. Si esto está mal, nada bueno pasa.
• Política IPsec: propuestas (cifrado/integridad/grupo DH), tiempos de vida y qué selectores de tráfico están permitidos.
• Certificados: EKU, validación de cadena, alcance de CRL/OCSP y la identidad correcta (SAN vs CN).
• NAT-T: si estás detrás de NAT (casi siempre), probablemente uses UDP 4500. Bloquear eso es un clásico.
• Rekey + DPD: el mundo de “keepalive” donde los túneles mueren cuando un lado decide que el otro se fue.
• Cambios de perfil de red: el roaming de Windows de Wi‑Fi a LTE es una prueba de estrés para el túnel.

Lo que “desconexión” suele significar en la práctica

La mayoría de desconexiones reales en IKEv2 sobre Windows caen en unos pocos grupos:

1. UDP 500/4500 se bloquea o se manipula durante la sesión (Wi‑Fi de hotel, portales cautivos, cortafuegos “seguros”).
2. Mismatch de rekey (tiempos de vida, propuestas, PFS o mapeos NAT que expiran) que provoca caídas cada N minutos.
3. Fallas en la cadena/identidad del certificado que solo aparecen después de una rotación, un cambio de CA o una caída de CRL.
4. MTU/fragmentación donde IKE funciona, el túnel está “conectado”, pero el tráfico real se atasca o se reinicia.
5. Enrutamiento/DNS dividido donde el túnel permanece arriba, pero el usuario cree que está “caído” porque nada resuelve.

La solución no es “probar diferentes suites de cifrado hasta que funcione.” Así terminas con una VPN que conecta,
pero falla en cada cafetería con un NAT distinto. La vamos a tratar como cualquier otro incidente de producción:
obtener señal, reducir el radio, y aplicar la corrección mínima que resista.

Una cita para colgar en la pared: “La esperanza no es una estrategia.” — Vince Lombardi.
La gente de operaciones la adoptó porque es dolorosamente precisa.

Broma corta #1: Si tu túnel IKEv2 se cae cada 60 minutos, felicidades: tu VPN aprendió a tomar la hora del almuerzo.

Guion de diagnóstico rápido

Este es el plan de “necesito una dirección en cinco minutos”. Asume cliente Windows + algún servidor IKEv2 basado en estándares
(RRAS, strongSwan, Libreswan, Palo Alto, FortiGate, ASA, Azure VPN Gateway, etc.). Los nombres exactos cambian; los modos de falla no.

Primero: decide si es “no puede conectar” o “conecta y luego se cae”

• No puede conectar: enfócate en propuestas, certificados, puertos e identidad.
• Conecta y luego se cae: enfócate en DPD, mapeos NAT, rekey, roaming, MTU y middleboxes.

Segundo: extrae el único registro que dice la verdad

En Windows, la mejor primera parada es el registro operativo RasClient junto con los eventos IKEEXT.
Si solo miras el error del GUI, estás depurando con los ojos vendados.

Tercero: confirma la salud del camino UDP 500/4500

Muchas desconexiones “aleatorias” son solo la realidad del NAT‑T. Si UDP 4500 se bloquea o se remapea agresivamente,
el túnel parecerá bien hasta que de repente no lo esté. Valida desde la red cliente que te importa.

Cuarto: revisa el tiempo de rekey y los tiempos de vida

Las desconexiones en intervalos consistentes gritan “mismatch de lifetimes” o “rekey fallando.” Si es exactamente 30/60/120 minutos,
no discutas: mídelo y compáralo con tus tiempos de vida Phase 1 / Phase 2.

Quinto: prueba un camino de “paquetes grandes” para detectar problemas de MTU

El tráfico de control IKE es pequeño. Tu tráfico real de aplicaciones no lo es. Si los paquetes grandes se fragmentan o se pierden, los usuarios llamarán “VPN caída”.
No lo es. Es un problema de path MTU disfrazado.

Sexto: si solo ocurre al hacer roaming, deja de culpar la criptografía

El roaming es un cambio de estado: nueva IP, nuevo NAT, nuevo cortafuegos, nuevo DNS. IKEv2 puede manejar movilidad (MOBIKE) en algunas pilas,
pero el soporte en Windows depende del escenario y de las capacidades del servidor. Trata las fallas por roaming como una categoría separada.

Hechos interesantes y un poco de historia

Un poco de contexto te ayuda a predecir dónde están los dragones. Aquí hay detalles concretos que aparecen en la resolución de problemas real.

1. IKEv2 se estandarizó en 2005 (RFC 4306). Reemplazó la complejidad de IKEv1 con un modelo de intercambio más limpio.
2. NAT traversal (NAT‑T) es más antiguo que la mayoría de los runbooks VPN: el enfoque práctico de “IPsec a través de NAT” se popularizó a principios de los 2000 y se estandarizó (RFC 3947/3948).
3. La pila VPN de Windows es por capas: RasClient gestiona los perfiles de usuario mientras IKEEXT hace IKE/IPsec. Depurar solo RasClient es como arreglar almacenamiento mirando una letra de unidad en el GUI.
4. EAP vs autenticación por certificado cambia los modos de falla: EAP (como EAP‑MSCHAPv2) suele fallar por “credenciales”, la autenticación por certificado falla por cadena/identidad/CRL. Mismo síntoma, universos distintos.
5. UDP 4500 existe porque NAT rompe IPsec: ESP (protocolo IP 50) no se lleva bien con NAT, así que NAT‑T encapsula ESP en UDP.
6. Dead Peer Detection (DPD) es deliberadamente impaciente: está diseñado para limpiar estado rápidamente cuando los pares desaparecen. En redes inestables, esa “característica” se vuelve tu corte de servicio.
7. Los códigos de error de Windows suelen ser abstracciones: el error 809 y 812 pueden ocultar múltiples causas raíz; los eventos muestran los códigos reales de IPsec/IKE.
8. Las fallas de rekey frecuentemente son fallas de middlebox: la criptografía está bien, pero el mapeo NAT expiró, el cortafuegos envejeció el estado, o un DPI decidió que UDP 4500 es sospechoso hoy.
9. La fragmentación de IKEv2 existe, pero no es magia: si el camino descarta fragmentos o bloquea ICMP con demasiada agresividad, seguirás teniendo atascos.

Errores comunes, qué significan y qué hacer

Los errores de VPN en Windows son como las alertas de almacenamiento: el mensaje suele ser el comienzo de la historia, no el final.
Usa el error del GUI solo para clasificar el problema, luego salta a los logs y al comportamiento de paquetes.

Error 809: “The network connection between your computer and the VPN server could not be established”

Qué suele significar: Los paquetes IKE no obtuvieron una ruta de respuesta válida. Habitualmente UDP 500/4500 bloqueado, NAT‑T roto o servidor no escuchando.

Soluciones fiables:

• Confirma que UDP 500 y 4500 estén permitidos extremo a extremo (red cliente, cortafuegos local, cortafuegos perimetral, grupos de seguridad del servidor).
• Asegura que el servidor esté realmente vinculado/escuchando y no restringido por políticas (especialmente en RRAS/Windows Server).
• Revisa doble NAT o timeouts NAT agresivos; ajusta keepalive/DPD en el servidor cuando sea posible.
• Si usas autenticación por certificado: confirma que el cliente confíe en la cadena del certificado del servidor y que el servidor presente el certificado correcto.

Error 812: “The connection was prevented because of a policy configured on your RAS/VPN server”

Qué suele significar: la autenticación fue suficiente para negociar políticas y luego fue rechazada. A menudo es política NPS/RADIUS, membresía de grupo, mismatch EAP o restricciones de tipo de túnel.

Soluciones fiables:

• Valida la política del servidor para el usuario/grupo y el tipo de túnel IKEv2.
• Confirma que el método de autenticación (tipo EAP) coincida con la configuración del cliente.
• Revisa el mapeo de certificados si usas certificados de máquina/usuario y el servidor espera un EKU o patrón de sujeto específico.

Error 13801: “IKE authentication credentials are unacceptable”

Qué suele significar: mismatch de autenticación por certificado: identidad errónea, EKU incorrecto, falta de clave privada, cadena no confiable o problemas de CRL/OCSP. A veces también mismatch de PSK (si se usa).

Soluciones fiables:

• Verifica que el certificado del cliente tenga EKU de Client Authentication y una clave privada, y que el servidor confíe en la CA emisora.
• Verifica que el certificado del servidor tenga EKU de Server Authentication y que su identidad coincida con lo que el cliente espera (SAN es la realidad moderna).
• Asegura que los puntos de distribución de CRL sean accesibles desde el cliente al conectar (esto falla en diseños donde “se necesita la VPN para alcanzar la PKI”).

Error 0x800B0109 / “A certificate chain processed, but terminated in a root certificate which is not trusted”

Qué suele significar: el cliente no confía en la CA emisora/intermedia, o el servidor presentó una cadena incompleta.

Soluciones fiables:

• Despliega los certificados raíz e intermedios correctos en el almacén de confianza del cliente.
• Arregla el servidor para que presente los intermedios (configuración errónea común en appliances y algunas pilas Linux).

Desconexiones cada 30/60/120 minutos

Qué suele significar: mismatch de rekey o de lifetimes, o timeout de NAT/cortafuegos alineado con un límite de tiempo.

Soluciones fiables:

• Alinea los lifetimes de IKE SA y Child SA en ambos extremos (y márgenes de rekey).
• Habilita/revisa DPD y keepalives NAT; asegura que el mapeo NAT no expire durante la sesión.
• Investiga middleboxes que envejezcan el estado UDP demasiado agresivamente.

Conectado, pero “algunos sitios no funcionan” o “Teams se corta”

Qué suele significar: rutas de split tunneling, DNS o problemas de MTU. El túnel no está abajo; el tráfico está mal enroutado o en un agujero negro.

Soluciones fiables:

• Confirma que las rutas instaladas por el perfil VPN coinciden con lo que pretendes.
• Confirma que los servidores DNS y el sufijo de búsqueda son correctos, y que las reglas NRPT (si se usan) están bien.
• Prueba el path MTU y ajusta la MTU de la interfaz o clampa MSS en la pasarela VPN si está disponible.

Broma corta #2: La resolución de VPN es solo redes, pero con más certificados y menos amigos dispuestos a quedarse en la llamada.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas reales que uso cuando alguien dice “Windows IKEv2 se desconecta constantemente.” Cada una incluye un comando,
salida representativa, qué significa y qué decisión tomar después. Ejecutarás algunas en Windows y otras en el servidor VPN.
Los comandos se muestran en un formato de consola consistente; adapta nombres de host e interfaces a tu entorno.

Task 1: Confirm the VPN profile is actually IKEv2 and not something “helpful”

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -Name 'Corp-IKEv2' | Select-Object Name,TunnelType,AuthenticationMethod,SplitTunneling"
Name      TunnelType AuthenticationMethod SplitTunneling
----      ---------- -------------------- --------------
Corp-IKEv2 Ikev2      Eap                 True

Qué significa: Realmente estás usando IKEv2. La autenticación es EAP y está habilitado el split tunneling.

Decisión: Si TunnelType no es Ikev2, detente. Arregla el perfil primero. Si la autenticación es EAP, enfócate en NPS/RADIUS y la configuración EAP; si es Certificate, enfócate en PKI.

Task 2: Pull RasClient operational errors around the disconnect

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-RasClient/Operational' -MaxEvents 20 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Auto"
TimeCreated           Id  LevelDisplayName Message
-----------           --  ----------------  -------
12/27/2025 09:14:11  20227 Error            CoId={...}: The user SYSTEM dialed a connection named Corp-IKEv2 which has failed. The error code returned on failure is 809.
12/27/2025 09:14:10  20226 Information      CoId={...}: The user SYSTEM dialed a connection named Corp-IKEv2.

Qué significa: La “desconexión” del GUI está respaldada por un código de error RasClient y una marca temporal concretos.

Decisión: Usa la marca temporal para correlacionar con logs IKEEXT y logs del servidor. Error 809 te empuja hacia comprobaciones de ruta UDP/NAT‑T.

Task 3: Check IKEEXT events for negotiation or authentication failures

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-IKE/Operational' -MaxEvents 10 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Wrap"
TimeCreated           Id  LevelDisplayName Message
-----------           --  ----------------  -------
12/27/2025 09:14:11  4653 Error            IKE failed to find valid machine certificate. Error 0x800B0109

Qué significa: Esto no es “red.” Es confianza/chain de certificados.

Decisión: Deja de tocar reglas de firewall. Arregla la confianza de CA, los intermedios y la selección de certificado.

Task 4: Validate the client certificate exists and has a private key

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path Cert:\CurrentUser\My | Select-Object Subject,HasPrivateKey,NotAfter,EnhancedKeyUsageList | Format-List"
Subject            : CN=alice, OU=Corp, O=Example
HasPrivateKey      : True
NotAfter           : 06/01/2026 12:00:00
EnhancedKeyUsageList : {Client Authentication (1.3.6.1.5.5.7.3.2)}

Qué significa: El certificado está presente, usable y tiene el EKU correcto.

Decisión: Si HasPrivateKey es False o el EKU está mal/falta, vuelve a emitir o corrige la plantilla/política. Si parece bien, pasa a validar la cadena e identidad.

Task 5: Confirm the root/intermediate chain is trusted on the client

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object {$_.Subject -like '*Example Root CA*'} | Select-Object Subject,Thumbprint,NotAfter"
Subject                 Thumbprint                                NotAfter
-------                 ----------                                --------
CN=Example Root CA      9A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B  01/01/2035 00:00:00

Qué significa: La CA raíz está presente. Si hay intermedios, asegúrate de que también estén instalados (almacén Intermediate Certification Authorities).

Decisión: Si faltan, despliega vía GPO/MDM. Si están, verifica que el servidor envíe los intermedios correctamente.

Task 6: Check whether Windows is attempting NAT-T (UDP 4500) and not stuck on UDP 500

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPsecMainModeSA | Select-Object -First 5 LocalAddress,RemoteAddress,LocalPort,RemotePort,AuthMethod,EncryptionAlgorithm,IntegrityAlgorithm | Format-Table -Auto"
LocalAddress RemoteAddress LocalPort RemotePort AuthMethod EncryptionAlgorithm IntegrityAlgorithm
------------ ------------- --------- ---------- --------- ------------------- -----------------
10.50.12.34  203.0.113.10  4500      4500       EAP      AESGCM256           None

Qué significa: La IKE SA está en UDP 4500: NAT‑T en uso, normal en la mayoría de redes cliente.

Decisión: Si nunca ves UDP 4500, sospecha fallo de detección NAT o una política que fuerce solo UDP 500. También verifica que UDP 4500 esté permitido en cortafuegos locales y perimetrales.

Task 7: Verify the IPsec Child SAs are stable and not constantly rekeying

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPsecQuickModeSA | Select-Object -First 5 RemoteAddress,LocalSubnet,RemoteSubnet,KeyModule,EncryptionAlgorithm,IntegrityAlgorithm,SAIdleTime | Format-Table -Auto"
RemoteAddress LocalSubnet     RemoteSubnet      KeyModule EncryptionAlgorithm IntegrityAlgorithm SAIdleTime
------------- -----------     ------------      --------- ------------------- ----------------- ----------
203.0.113.10  10.50.12.34/32  10.0.0.0/8        IKEv2     AES256              SHA256            00:02:11

Qué significa: Quick Mode (Child SA) existe. Si los ves recrearse constantemente, estás ante bucles de rekey o problemas de selectores de tráfico.

Decisión: Bucles de rekey: alinea lifetimes/propuestas y revisa logs del servidor. Problemas de selectores: verifica qué subredes se envían/permiten en ambos extremos.

Task 8: Check interface MTU and test PMTU with “do not fragment” pings

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like '*Corp-IKEv2*'} | Select-Object InterfaceAlias,NlMtu,ConnectionState | Format-Table -Auto"
InterfaceAlias        NlMtu ConnectionState
--------------        ----- ---------------
Corp-IKEv2            1400  Connected

cr0x@server:~$ powershell -NoProfile -Command "ping 10.0.10.10 -f -l 1360"
Pinging 10.0.10.10 with 1360 bytes of data:
Reply from 10.0.10.10: bytes=1360 time=21ms TTL=62

Qué significa: La MTU es 1400 y una carga de 1360 bytes funciona sin fragmentación. Si esto falla, tienes un problema de fragmentación/PMTU.

Decisión: Si los pings DF grandes fallan, reduce la MTU de la interfaz VPN (o clampa MSS en la pasarela). Si solo fallan ciertos destinos, sospecha un cortafuegos intermedio que descarta fragmentos o ICMP.

Task 9: Confirm DNS servers and suffix behavior during the VPN session

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto"
InterfaceAlias        ServerAddresses
--------------        ---------------
Ethernet              {192.168.1.1}
Corp-IKEv2            {10.0.0.53, 10.0.0.54}

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName internal-app.corp.example -Server 10.0.0.53 | Select-Object Name,IPAddress"
Name                     IPAddress
----                     ---------
internal-app.corp.example 10.0.20.15

Qué significa: La interfaz VPN tiene servidores DNS corporativos y la resolución funciona cuando consultas directamente a ellos.

Decisión: Si la resolución falla solo a través del resolvedor por defecto pero funciona al apuntar al DNS corporativo, debes arreglar sufijos DNS/NRPT o métricas para que Windows use el DNS correcto para nombres corporativos.

Task 10: Check routing and whether split-tunnel routes are present and preferred

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -like '*Corp-IKEv2*'} | Sort-Object DestinationPrefix | Select-Object DestinationPrefix,NextHop,RouteMetric | Format-Table -Auto"
DestinationPrefix NextHop      RouteMetric
---------------- --------      -----------
10.0.0.0/8        0.0.0.0      5
172.16.0.0/12     0.0.0.0      5
192.168.0.0/16    0.0.0.0      5

Qué significa: Existen rutas de split-tunnel enlazadas a la interfaz VPN.

Decisión: Si faltan rutas, el problema es la configuración del perfil o la política/push del servidor. Si las métricas son mayores que las rutas locales, Windows podría preferir la ruta equivocada; ajusta métricas con cuidado.

Task 11: Packet capture on Windows to confirm UDP 500/4500 behavior during a drop

cr0x@server:~$ powershell -NoProfile -Command "netsh trace start capture=yes report=yes scenario=VPNClient maxsize=512 filemode=circular tracefile=C:\Temp\ikev2.etl"
Trace configuration:
-------------------------------------------------------------------
Status:             Running
Trace File:         C:\Temp\ikev2.etl
Max Size:           512 MB
File Mode:          Circular

cr0x@server:~$ powershell -NoProfile -Command "netsh trace stop"
Merging traces ... done
Generating report ... done
Trace file and report:
C:\Temp\ikev2.etl
C:\Temp\ikev2.cab

Qué significa: Capturaste el escenario VPNClient. Esto suele ser suficiente para ver si los paquetes dejan de salir, dejan de regresar o reciben errores ICMP.

Decisión: Si UDP 4500 sale pero la entrada se detiene en el momento de la desconexión, sospecha bloqueo ascendente/expiración NAT. Si la salida se detiene, sospecha cortafuegos/driver/servicio local.

Task 12: Validate Windows services that must be alive (RasMan, IKEEXT)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service RasMan,IKEEXT | Format-Table Name,Status,StartType -Auto"
Name   Status Running StartType
----   ------ ------- ---------
RasMan Running         Manual
IKEEXT Running         Manual

Qué significa: Los servicios requeridos están en ejecución. Si se reinician o fallan, obtendrás desconexiones “aleatorias” que no son de red.

Decisión: Si alguno está detenido o inestable, revisa eventos del sistema, actualizaciones de drivers e interferencia de software de seguridad. Arregla eso antes de tocar ajustes de IPsec.

Task 13: On a Linux VPN server, verify it’s listening and see IKE handshakes

cr0x@server:~$ sudo ss -lunp | egrep ':(500|4500)\s'
UNCONN 0      0            0.0.0.0:500        0.0.0.0:*    users:(("charon",pid=1123,fd=12))
UNCONN 0      0            0.0.0.0:4500       0.0.0.0:*    users:(("charon",pid=1123,fd=13))

Qué significa: charon de strongSwan está vinculado a UDP 500/4500. Si no están abiertos, los clientes fallarán con síntomas tipo 809.

Decisión: Si no escucha, arregla el demonio/servicio, la sintaxis de configuración o la interfaz de enlace. Si escucha, pasa a firewall y logs de propuestas/certificados.

Task 14: On the server, confirm firewall allows UDP 500/4500

cr0x@server:~$ sudo nft list ruleset | egrep -n 'udp dport (500|4500)'
42: udp dport 500 accept
43: udp dport 4500 accept

Qué significa: El firewall del servidor permite IKE/NAT‑T.

Decisión: Si falta, añade reglas. Si están presentes, sospecha firewalls ascendente o grupos de seguridad. Si solo un puerto está abierto, abre ambos.

Task 15: On strongSwan, inspect live SAs and rekey timing

cr0x@server:~$ sudo swanctl --list-sas
ikev2-corp: #12, ESTABLISHED, IKEv2, 3b1c2d3e4f...
  local  'vpn.corp.example' @ 203.0.113.10[4500]
  remote 'alice' @ 198.51.100.27[52344]
  AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, rekeying in 41 minutes
  child: corp-net, #25, INSTALLED, TUNNEL, ESP:AES_GCM_16_256, rekeying in 9 minutes

Qué significa: Los temporizadores de rekey son visibles. Si las desconexiones coinciden con momentos de “rekeying in …”, has encontrado el disparador.

Decisión: Si el rekey falla, alinea lifetimes/propuestas, revisa fragmentación/MTU e inspecciona el comportamiento NAT. Si el rekey funciona pero el túnel cae al hacer roaming, enfócate en ajuste de MOBIKE/DPD.

Task 16: Watch live logs during a reconnect storm (server side)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" -f
Dec 27 09:14:11 vpn charon[1123]: 12[IKE] peer supports MOBIKE
Dec 27 09:14:41 vpn charon[1123]: 12[IKE] sending DPD request
Dec 27 09:14:46 vpn charon[1123]: 12[IKE] DPD response received
Dec 27 09:15:12 vpn charon[1123]: 12[IKE] retransmit 1 of request with message ID 7
Dec 27 09:15:27 vpn charon[1123]: 12[IKE] giving up after 5 retransmits
Dec 27 09:15:27 vpn charon[1123]: 12[IKE] deleting IKE_SA ikev2-corp[12] between 203.0.113.10[ vpn.corp.example ]...198.51.100.27[ alice ]

Qué significa: DPD empezó a funcionar, luego hubo retransmisiones y finalmente la SA fue eliminada. Eso es rotura clásica de ruta o NAT.

Decisión: Investiga timeout de NAT, cambios de red del cliente o filtrado de UDP 4500. Ajusta DPD/keepalive para que no sean tan precipitados y valida el comportamiento de roaming.

Tres mini-historias del mundo corporativo

Incidente 1: La suposición equivocada (“Es IKEv2, así que maneja roaming automáticamente”)

Una empresa mediana desplegó IKEv2 para reemplazar SSTP para el personal remoto. El grupo piloto lo adoró. Luego el despliegue llegó al equipo de ventas,
la encarnación humana de “siempre moviéndose”. El patrón de quejas fue consistente: conectar en la Wi‑Fi de casa, ir a una reunión, cambiar al hotspot del teléfono,
y la VPN moría silenciosamente. Los usuarios lo llamaban “desconexiones aleatorias” porque la falla no ocurría de inmediato. Ocurría cinco minutos después,
justo cuando el mapeo NAT expiraba y DPD decidía que el par había desaparecido.

El equipo de red asumió que IKEv2 significaba MOBIKE y roaming sin fricciones. Esa suposición es comprensible—y lo suficientemente equivocada en situaciones del mundo real
como para hacer daño. Windows IKEv2 más la configuración de la pasarela elegida no se comportaban como un cliente VPN móvil. El túnel subía bien, pero tras el cambio de IP,
el servidor seguía enviando al tuple antiguo hasta que la SA moría. Entonces Windows intentaba restablecer, a veces con éxito, a veces atrapado detrás de un portal cautivo.

La solución no fue una nueva suite criptográfica. Añadieron dos cambios operativos: (1) intervalos DPD más cortos y sensatos con un poco de gracia, y (2) orientación explícita
en el perfil Always On VPN para forzar reconexión al cambiar de red. También actualizaron los scripts de helpdesk: “Si acabas de cambiar de red, desconecta/reconecta una vez”
pasó a ser un procedimiento deliberado en vez de magia popular. La estabilidad mejoró porque el sistema fue diseñado para roaming, no para depender de la suerte.

La lección real: trata el roaming como un caso de prueba de primera clase. Ejecuta una prueba controlada: conecta, cambia redes, mantiene el tráfico, observa si las SA sobreviven.
Si falla, tienes un problema de diseño, no un “problema del usuario”.

Incidente 2: La optimización que salió mal (“Reduciremos lifetimes para mejorar la seguridad”)

Otra organización decidió “endurecer” su VPN reduciendo agresivamente los lifetimes de IPsec. Lifetimes más cortos pueden estar bien.
Pero lo llevaron demasiado lejos y de forma asimétrica: el equipo de pasarela cambió los lifetimes de Child SA, el perfil Windows quedó por defecto,
y nadie validó el comportamiento de rekey bajo carga.

Lo que pasó después fue predecible. Los rekeys aumentaron. La CPU subió en la pasarela, pero no lo suficiente como para alertar.
Luego apareció el problema real: los usuarios se desconectaban a intervalos regulares durante la jornada laboral. No todos a la vez—suficientes para crear una cola de soporte constante.
El helpdesk culpó al Wi‑Fi. El equipo de Wi‑Fi culpó a la VPN. El equipo VPN culpó a “Windows siendo Windows”.

Las capturas mostraron el intercambio de rekey iniciándose y luego un lado no aceptando la propuesta. A veces funcionaba, a veces no, dependiendo de qué instancia de SA
golpeara el mismatch primero. Además, cuanto más frecuentemente rekeyes, más dependes de que el camino sea estable, del estado UDP fresco y de que la fragmentación funcione.
En otras palabras: convertiste un sistema robusto en uno que requiere condiciones perfectas.

La solución fue aburrida y efectiva: alinear lifetimes, establecer márgenes de rekey razonables y mantener suites cripto modernas sin ser exóticas.
Restauraron lifetimes de Child SA más largos y usaron un calendario de rekey que no sometiera al plano de control. La seguridad no empeoró de forma significativa;
la fiabilidad mejoró dramáticamente. En producción, controles de seguridad que hacen que los usuarios eviten la VPN no son controles de seguridad. Son pensamiento deseoso.

Incidente 3: La práctica aburrida que salvó el día (rotación de certificados con disciplina)

Una gran empresa rotó CAs emisoras y certificados de servidor como parte de una modernización de PKI. Esto suele ser cuando las VPN mueren.
Los certificados no son difíciles; los ecosistemas de certificados son difíciles. Las CRL se mueven. Los intermedios cambian. Clientes legacy entran en pánico.
Alguien siempre olvida un intermedio en algún sitio.

Este equipo hizo una cosa poco sexy: mantuvieron un anillo canario de perfiles VPN y clientes fijados a una pasarela de prueba.
El anillo canario validó la confianza de cadena, EKU y el emparejamiento de identidad una semana antes del cambio general.
También tenían un rollback escrito: “restaurar certificado de servidor anterior + paquete de intermedios”, con ventana de tiempo y responsabilidad clara.

El día del corte, el anillo canario detectó una ruptura: los clientes en la Wi‑Fi de invitados no podían llegar a los nuevos puntos de distribución CRL.
Sin acceso a CRL, Windows se negó a confiar en el certificado presentado, y el error parecía una falla genérica de autenticación IKE.
El canario les salvó de desplegar un certificado que requería la VPN para validar el certificado necesario para usar la VPN. Sí, es tan circular como suena.

La solución fue igualmente aburrida: publicar CRL en una ubicación accesible desde cualquier parte (o ajustar la estrategia de comprobación de revocación con cuidado).
La rotación continuó con una cadena estable. Los usuarios no lo notaron, que es el mayor elogio que puede recibir operaciones.

Errores comunes: síntoma → causa raíz → solución

Esta sección es intencionalmente directa. La mayoría de los incidentes “Windows IKEv2 desconexión” se repiten porque los equipos siguen pisando las mismas rastras.
Aquí los comunes, ligados a síntomas observables.

1) Síntoma: Error 809 en algunas redes pero no en otras

Causa raíz: UDP 4500 bloqueado o moldeado; portal cautivo; filtrado Wi‑Fi “seguro”; o timeout NAT/upstream envejeciendo el estado UDP rápidamente.

Solución: Asegura que UDP 500/4500 pasen. Si no puedes controlar la red, aumenta keepalives/tolerancia DPD y proporciona una alternativa (a veces SSTP es un respaldo pragmático).

2) Síntoma: Conecta bien, luego se cae a intervalos consistentes

Causa raíz: mismatch de lifetime o rekey fallando; expiración de mapeo NAT; DPD muy agresivo; picos de CPU en la pasarela durante tormentas de rekey.

Solución: Alinea lifetimes y propuestas; ajusta DPD/keepalive; verifica capacidad de la pasarela; evita lifetimes excesivamente cortos salvo que tengas evidencia operativa.

3) Síntoma: Error 13801 tras cambios de certificados

Causa raíz: EKU incorrecto, clave privada ausente, cadena no confiable, mismatch de identidad (SAN) o chequeo de revocación fallando.

Solución: Valida EKUs, cadena e identidad en ambos extremos. Asegura que los intermedios se presenten. Asegura que CRL/OCSP sea alcanzable sin la VPN.

4) Síntoma: “Conectado” pero sitios internos agotan; pings pequeños funcionan, descargas fallan

Causa raíz: agujero MTU, fragmentación bloqueada, MSS demasiado alto o PMTU roto por ICMP bloqueado.

Solución: Reduce MTU en la interfaz VPN; clampa MSS en la pasarela; permite ICMP necesario (al menos fragmentation‑needed) cuando sea factible.

5) Síntoma: Solo algunas subredes alcanzables, otras muertas

Causa raíz: rutas split tunnel faltantes/incorrectas; selectores de tráfico no incluyen subredes necesarias; espacio IP solapado con redes domésticas.

Solución: Arregla rutas/TS empujadas; evita espacios RFC1918 solapados; si el solapamiento es inevitable, usa NAT en la VPN o rediseña el direccionamiento.

6) Síntoma: Desconexiones que correlacionan con suspensión/hibernación o cierre de tapa

Causa raíz: ahorro de energía de NIC, suspensión del sistema rompiendo el estado UDP, o cliente VPN que no reanuda correctamente.

Solución: Ajusta opciones de energía para dispositivos corporativos; asegura que Always On VPN dispare reconexión; considera deshabilitar gestión agresiva de energía del NIC vía políticas.

7) Síntoma: Funciona por cable, falla por Wi‑Fi

Causa raíz: la red Wi‑Fi bloquea UDP 4500, tiene peculiaridades de aislamiento de clientes, o la pila de seguridad del endpoint filtra diferente por interfaz.

Solución: Valida con captura de paquetes; revisa perfiles de firewall local (Público vs Privado); ajusta políticas de endpoint para UDP 500/4500.

8) Síntoma: El servidor muestra retransmisiones, el cliente muestra “autenticación fallida”

Causa raíz: mensajes perdidos a mitad de intercambio; fragmentación de mensajes IKE; MTU o drops por middlebox; a veces cadenas de certificados grandes inflan mensajes IKE.

Solución: Reduce el tamaño de la cadena de certificados; asegura soporte de fragmentación IKE en el servidor; arregla MTU; deja de bloquear fragmentos/ICMP a ciegas.

9) Síntoma: Después de habilitar “crypto más fuerte”, algunos clientes caen

Causa raíz: mismatch de propuestas; builds antiguos de Windows o ciertos appliances no soportan las suites elegidas como piensas.

Solución: Usa una base moderna y conservadora (AES‑GCM, PRF SHA2, DH group 14/19+ según convenga) y valida con un anillo de prueba antes del despliegue.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar un despliegue IKEv2 en Windows inestable

1. Recopila marcas temporales y síntomas. Obtén la hora exacta de la desconexión, tipo de red (Wi‑Fi doméstica, LTE, oficina) y si es periódico.
2. Extrae primero RasClient + logs IKE. Si el log apunta a cert/auth, quédate ahí. Si apunta a 809/transporte, ve a comprobaciones de ruta.
3. Verifica que los servicios (RasMan/IKEEXT) no estén inestables. Si lo están, arregla la estabilidad del endpoint antes de ajustar la red.
4. Confirma la accesibilidad de UDP 500/4500. Desde las redes afectadas. No asumas que porque funciona en la oficina funcionará en un hotel.
5. Comprueba si NAT‑T se usa realmente. Si los clientes están detrás de NAT (lo están), quieres UDP 4500 funcionando de forma fiable.
6. Alinea propuestas y lifetimes. Haz que ambos extremos estén de acuerdo. Rekey lo suficiente para ser seguro, no tanto como para provocar un DDoS del plano de control.
7. Prueba MTU temprano. Pings DF grandes y flujos reales. Arregla agujeros negros antes de discutir sobre enrutamiento.
8. Valida DNS y rutas. Confirma que nombres corporativos resuelven vía DNS corporativo y que las subredes intencionadas pasan por la VPN.
9. Pruebas de roaming. Cambia redes mientras ejecutas un ping/SSH/RDP continuo y observa el comportamiento. Si falla, decide si soportar roaming o documentar limitaciones.
10. Introduce canarios. Perfiles pilotos y cambios de certificado con un anillo pequeño antes del despliegue amplio.
11. Documenta la realidad de “redes conocidas malas”. Algunas redes bloquearán UDP 4500. Planea una estrategia de respaldo o acepta las limitaciones explícitamente.
12. Automatiza la recolección de logs para soporte. Un script de una línea que exporte RasClient e IKE ahorra horas por ticket.

Lista operativa: antes de cambiar algo en la pasarela

• ¿Tienes un cliente de prueba y una pasarela canaria?
• ¿Conoces los lifetimes y propuestas IKE/Child en ambos extremos?
• ¿Has validado la alcanzabilidad CRL/OCSP desde fuera de la VPN?
• ¿Tienes capturas de paquetes de un caso que falla?
• ¿Puedes revertir rápido (snapshot/export de configuración)?

Lista operativa: después de aplicar una corrección

• Prueba conectar, desconectar, reconectar.
• Prueba tráfico sostenido (10–30 minutos) y observa comportamiento de rekey.
• Prueba transferencias grandes y pings DF.
• Prueba roaming (Wi‑Fi ↔ LTE) si afirmas soportarlo.
• Verifica que el helpdesk tenga los nuevos pasos de “qué recopilar”.

Preguntas frecuentes

1) ¿Por qué se desconecta más IKEv2 en Windows en hoteles o Wi‑Fi de invitados?

Esas redes suelen bloquear o expirar agresivamente flujos UDP, especialmente UDP 4500. IPsec NAT‑T parece “tráfico UDP desconocido” para algunos equipos.
Los portales cautivos también causan cambios de ruta silenciosos que rompen mapeos NAT existentes. Confirma con logs y una traza.

2) ¿Es el error 809 siempre un problema de firewall?

Generalmente es un problema de conectividad, pero “conectividad” incluye comportamiento NAT, filtrado ascendente e incluso filtrado de seguridad del endpoint.
Trata 809 como “IKE no estableció una ruta funcional”, luego verifica UDP 500/4500 y el estado de escucha del servidor.

3) ¿Cuál es la forma más rápida de saber si son certificados?

Revisa Microsoft-Windows-IKE/Operational para errores de cadena y credenciales (como 0x800B0109) alrededor del tiempo de falla.
Si aparecen, deja de tocar puertos y valida EKUs, confianza de cadena y alcanzabilidad de revocación.

4) ¿Por qué se cae exactamente cada hora?

Eso casi siempre es comportamiento de rekey/lifetime o timeouts de estado que se alinean con un temporizador. Alinea los lifetimes de IKE SA y Child SA,
y revisa si los mapeos NAT expiran en tiempos similares. Los logs del servidor mostrando intentos de rekey son valiosos.

5) ¿Deberíamos reducir los lifetimes de IPsec para “más seguridad”?

No a ciegas. Lifetimes muy cortos aumentan la frecuencia de rekey y la sensibilidad a pérdida de paquetes, fragmentación y middleboxes.
Escoge una base sensata, valida rekey bajo carga y solo aprieta si tienes un modelo de amenaza real y capacidad operativa.

6) Conectado pero nombres DNS internos no resuelven—¿por qué el túnel parece bien?

Porque “conectado” solo significa que el plano de control está arriba. Si los servidores DNS no se aplican, el sufijo de búsqueda es incorrecto,
o las métricas/enrutamiento prefieren otra interfaz, tienes un túnel funcional que es prácticamente inútil. Verifica DNS por interfaz y tablas de enrutamiento.

7) ¿Los problemas de MTU realmente parecen desconexiones?

Sí. Las aplicaciones agotan, las sesiones se reinician, las llamadas de voz se degradan y los usuarios dicen “VPN caída” porque es el único control que conocen.
Prueba con pings DF y transferencias reales. Arregla MTU/MSS/ICMP y “arreglarás desconexiones” que no eran desconexiones.

8) ¿El software de seguridad en endpoints puede causar caídas IKEv2?

Absolutamente. Firewalls host, “inspección de red” y drivers que interfieren con VPN pueden descartar o retrasar UDP 4500,
bloquear tráfico de validación de certificados o reiniciar servicios. Si ves flaps de servicio o solo ciertas máquinas afectadas, investiga la pila del endpoint.

9) ¿El split tunneling es más propenso a causar inestabilidad?

Es más probable que cause confusión de “conectado pero no funciona”: rutas faltantes, métricas erróneas, ambigüedad de DNS y IP solapadas.
La estabilidad del túnel en sí suele estar bien, pero la experiencia de usuario puede empeorar si rutas/DNS no están bien diseñadas.

Conclusión: próximos pasos que perduran

Las desconexiones IKEv2 en Windows dejan de ser misteriosas cuando las tratas como cualquier otro incidente de producción:
clasifica la falla (bring‑up vs liveness vs tráfico), extrae los logs correctos y valida los fundamentos aburridos
(UDP 500/4500, lifetimes/rekey, certificados, MTU, enrutamiento, DNS).

Próximos pasos prácticos:

• Construye un paquete de soporte de dos comandos: exporta eventos RasClient + IKE operativos alrededor de la ventana de falla.
• Ejecuta una prueba centrada en rekey: mantén un túnel activo durante al menos dos ciclos de rekey mientras envías tráfico real.
• Ejecuta un plan de pruebas MTU y establece una estrategia MTU/MSS conocida y válida para tu flota.
• Adopta un anillo canario para perfiles VPN y cambios de certificados. Es aburrido. Funciona.
• Decide, explícitamente, si soportas roaming y redes hostiles—y documenta el comportamiento esperado.

El objetivo no es una VPN que conecta en tu laboratorio. Es una VPN que permanece conectada en el mundo real, donde los NAT expiran,
las Wi‑Fi engañan y los certificados caducan en el peor momento posible.