Cómo verificar un túnel IPsec en FortiGate por CLI (FortiOS 7.4.4)
Cuando un túnel IPsec no levanta o se cae intermitentemente, la GUI del FortiGate no te dice mucho. Muestra un ícono rojo o verde, y eso es todo. La causa raíz está en la CLI.
Este post cubre el flujo completo de diagnóstico para un túnel IPsec con FortiOS 7.4.4, usando como referencia un FortiGate 60F conectado a un Cisco ASA 5516-X. Túnel vpn-hq-asa, subnets local 10.20.0.0/24 y remota 10.10.0.0/24, peer remoto en 198.51.100.10.
Los comandos están ordenados tal como los usaría en producción: de más rápido a más invasivo.
1. Verificar el estado de Phase 1 (IKE Gateway)
El primer comando que corro siempre:
diagnose vpn ike gateway list name vpn-hq-asa
Lo que te muestra:
- Versión IKE negociada (IKEv1 o IKEv2)
- Role:
initiatororesponder local-idyremote-id- La proposal de cifrado aceptada (ej.
aes256-sha256-modp2048) - Lifetime negociado
- STATE: este es el campo que más importa
Si ves STATE: established → Phase 1 OK, sigue al siguiente paso.
Si ves STATE: connecting o STATE: connect → Phase 1 está fallando. No avances a Phase 2 todavía; el problema está aquí.
2. Verificar el estado de Phase 2 (Child SAs / Tunnel)
diagnose vpn tunnel list name vpn-hq-asa
Este comando muestra las child SAs activas para el túnel. Lo relevante:
- Selectores (proxy IDs): subnet local y subnet remota que se están negociando
bytes_encryptedybytes_decrypted: contadores de tráfico real- DH group y lifetime restante
replay_window
Phase 2 está funcionando cuando los contadores de bytes incrementan con tráfico real. Si los counters están en cero o no aparece ninguna SA, hay un problema de selectores o Phase 1 aún no establecida.
3. Debug IKE en tiempo real
Cuando los dos comandos anteriores no son suficientes y necesitas ver exactamente qué está fallando en la negociación:
diagnose vpn ike log filter name vpn-hq-asa
diagnose debug application ike -1
diagnose debug enable
Esto vuelca cada paquete IKE procesado para ese túnel: proposals enviadas, proposals rechazadas, errores de autenticación, timeouts. Con esto puedes ver exactamente en qué paso falla la negociación.
CRÍTICO: Siempre apaga el debug cuando termines. Dejarlo activo consume CPU de forma innecesaria, especialmente con
-1(verbosity máximo).
diagnose debug disable
diagnose debug reset
No lo olvides. En equipos con varios túneles activos o carga de tráfico, el debug IKE con verbosity -1 puede impactar el forwarding.
4. Sniffer de paquetes ESP/IKE
Para confirmar que los paquetes realmente salen del FortiGate y que el peer remoto responde:
diagnose sniffer packet any 'host 198.51.100.10 and (esp or udp port 500 or udp port 4500)' 4
Este sniffer captura tráfico ESP (protocolo 50), IKE en UDP/500 y NAT-T en UDP/4500. Si ves paquetes saliendo pero ninguna respuesta del peer, el problema está del lado del ASA o en el camino de red entre ambos. Si no ves ni siquiera paquetes saliendo, hay un problema de routing o policy en el FortiGate antes del túnel.
Ctrl+C para detener la captura.
5. Verificar la tabla de routing
get router info routing-table all | grep vpn-hq-asa
Confirma que la ruta estática hacia 10.10.0.0/24 existe y está activa apuntando a la interfaz del túnel. Si esta ruta no aparece o apunta a otra interfaz, el tráfico no llegará al túnel aunque Phase 1 y Phase 2 estén establecidas.
6. Simular un lookup de firewall policy
diagnose firewall iprope lookup 10.20.0.5 5000 10.10.0.5 80 6 internal
Este comando simula un lookup de política para un flujo específico: origen 10.20.0.5:5000, destino 10.10.0.5:80, protocolo TCP (6), desde la interfaz internal. Te muestra qué política matchea ese tráfico.
Si el tráfico de LAN hacia el remoto está matcheando una política incorrecta (por ejemplo, una regla de acceso a internet que lo envía por la ruta default), el túnel puede estar establecido pero el tráfico nunca lo atraviesa.
Validación final con tráfico real
Una vez que tienes Phase 1 y Phase 2 establecidas, el test definitivo:
- Genera tráfico desde la LAN local hacia el remoto:
execute ping-options source 10.20.0.5
execute ping 10.10.0.5
- Vuelve a ejecutar:
diagnose vpn tunnel list name vpn-hq-asa
Observa los contadores:
-
bytes_encryptedsube,bytes_decryptedse queda en cero → el tráfico sale del FortiGate correctamente, pero no regresa. El problema está en el lado del ASA: o no está devolviendo tráfico, o el routing de retorno en el ASA apunta a otro lugar. -
Ambos contadores incrementan → el túnel está funcional para este flujo. El tráfico entra y sale correctamente.
Troubleshooting: Errores comunes y cómo resolverlos
Error: “no SA proposal chosen”
Aparece en el debug IKE cuando Phase 1 o Phase 2 no tienen overlap de proposals entre los dos lados. El FortiGate propone un conjunto de algoritmos (cifrado, hash, DH group) y el ASA no tiene ninguno en común.
Fix: Compara las proposals activas en ambos lados.
En FortiGate:
diagnose vpn ike gateway list name vpn-hq-asa
Busca la línea proposal en el output.
En el ASA:
show crypto ikev2 sa
show crypto ikev2 policy
Ambos lados deben tener al menos un conjunto idéntico de encryption + prf/hash + dh-group. Un solo bit de diferencia (ej. FortiGate con sha256 y ASA con sha1 solamente) rompe la negociación.
Error: “selector traffic mismatch”
Phase 1 establece pero Phase 2 falla. Significa que los quick mode selectors (proxy IDs) declarados en cada lado no coinciden.
Fix: En el FortiGate, el selector se define en la Phase 2 config (local subnet + remote subnet). En el ASA, está en la crypto map access-list. Verifica que ambas subnets sean idénticas: 10.20.0.0/24 no es lo mismo que 10.20.0.0/255.255.255.0 en cómo lo interpreta cada plataforma, aunque en la mayoría de casos coinciden. Más común es encontrar /24 vs /25, o que alguien añadió un host en la ACL del ASA en lugar de una subnet.
Error: “DPD timeout”
Phase 1 estaba establecida pero los DPD probes (Dead Peer Detection) no reciben respuesta y el túnel se cae.
Fix: Revisa primero el modo DPD configurado en el FortiGate:
config vpn ipsec phase1-interface
edit vpn-hq-asa
show | grep dpd
next
end
set dpd on-demand envía probes solo cuando hay tráfico pendiente. set dpd on-idle envía probes cuando el túnel está inactivo. Si el ASA no responde a los DPD probes, puede ser un problema de MTU (los probes se fragmentan y se pierden) o que NAT-T no está habilitado en ambos lados cuando el peer está detrás de NAT. Confirma que set nattraversal enable esté configurado en la Phase 1 si hay NAT en el camino.
Phase 1 OK pero Phase 2 nunca llega a active
Casi siempre es un problema de selectores. Usa:
diagnose vpn tunnel list name vpn-hq-asa
Revisa qué selectores están activos. Si no aparece ninguna SA en el output, Phase 2 no ha negociado nada. Activa el debug IKE (paso 3) y busca el mensaje de error específico en la negociación de Phase 2.
Tráfico no pasa aunque el túnel está “verde”
Ejecuta el lookup de policy (paso 6) para confirmar que el tráfico LAN → remoto matchea la política correcta. También verifica la tabla de routing (paso 5). Un túnel establecido pero con routing o policy incorrectos no mueve ni un byte.
FAQ
¿Qué hago si Phase 1 establece pero Phase 2 nunca llega a active?
Casi siempre es un mismatch de selectores. Ejecuta diagnose vpn tunnel list name vpn-hq-asa para ver qué SAs están activas y qué selectores está intentando negociar el FortiGate. Compara esos selectores contra la crypto map access-list del ASA. Deben ser idénticos: misma subnet local, misma subnet remota, mismo prefijo. Si sigues sin ver la causa, activa el debug IKE (paso 3) y busca el mensaje de error en la fase de negociación de Phase 2.
¿Cómo apago el debug IKE para no consumir CPU innecesario?
Siempre con estos dos comandos en ese orden:
diagnose debug disable
diagnose debug reset
diagnose debug disable para el output pero deja los filtros activos. diagnose debug reset limpia los filtros. Si solo corres disable sin reset, los filtros permanecen y pueden interferir con futuros debugs. No dejes el debug IKE con verbosity -1 corriendo en producción; consume CPU especialmente bajo carga de tráfico o con muchos túneles activos.
¿Por qué veo “no SA proposal chosen” en los logs?
Significa que el FortiGate y el peer remoto no tienen ningún conjunto de algoritmos en común para negociar la SA. Revisa las proposals configuradas en la Phase 1 y Phase 2 del FortiGate contra las del ASA. Cada parámetro debe coincidir exacto: algoritmo de cifrado (ej. AES-256), algoritmo de hash/PRF (ej. SHA-256), y DH group (ej. group 14 / modp2048). Un solo parámetro que no coincida en ninguna proposal produce este error.
¿Cómo confirmo que el tráfico realmente está pasando por el túnel y no por la ruta default?
Dos formas. Primera, verifica la tabla de routing:
get router info routing-table all | grep 10.10.0.0
Confirma que la ruta hacia el remote subnet apunta a la interfaz del túnel, no a la WAN. Segunda, ejecuta el lookup de policy:
diagnose firewall iprope lookup 10.20.0.5 5000 10.10.0.5 80 6 internal
Si el tráfico matchea una política que apunta a internet en lugar del túnel, el tráfico va por la ruta default aunque el túnel esté activo. Y como validación final, genera tráfico y confirma que bytes_encrypted y bytes_decrypted incrementan en diagnose vpn tunnel list.
¿Cuál es la diferencia entre diagnose vpn ike gateway list y diagnose vpn tunnel list?
diagnose vpn ike gateway list muestra el estado de Phase 1: el IKE SA entre los dos peers. Te dice si los dos extremos se han autenticado mutuamente y han acordado los parámetros de cifrado para el canal de control IKE.
diagnose vpn tunnel list muestra el estado de Phase 2: las child SAs que llevan el tráfico real. Aquí están los selectores (proxy IDs), los contadores de bytes encriptados/desencriptados, y el estado de cada SA de tráfico.
Puedes tener Phase 1 establecida sin Phase 2. No puedes tener Phase 2 sin Phase 1. Siempre verifica en ese orden.
Conclusión
El flujo de diagnóstico para un túnel IPsec en FortiGate CLI siempre sigue el mismo orden: Phase 1 → Phase 2 → tráfico real. diagnose vpn ike gateway list para el estado del canal de control, diagnose vpn tunnel list para las SAs de datos y contadores de tráfico, debug IKE solo cuando necesitas ver la negociación en detalle, y siempre apaga el debug cuando termines.
Los tres errores más frecuentes en túneles FortiGate ↔ ASA son: proposal mismatch, selector mismatch, y DPD issues relacionados con NAT-T o MTU. Con los comandos de este post puedes identificar cuál es el problema en menos de cinco minutos.
Si estás configurando este túnel desde cero en lugar de diagnosticarlo, revisa también el post sobre configuración de túnel IPsec site-to-site FortiGate con Cisco ASA (EN), que cubre la configuración completa de ambos lados — Phase 1, Phase 2, ACL del crypto-map, y los modos de falla más comunes. La ruta curada del trabajo FortiGate completo está en la Guía de campo FortiGate.