Kassinipedia

Troubleshooting IPsec

Se lee en 8 min

Troubleshooting IPsec

Contenido complementario

Este tema no está en las notas de tus cursos que tengo (la lección de Troubleshooting IPsec de PCNSE está pendiente de ver); está completado con conocimiento general de PAN-OS. Compáralo con lo que veas en la lección y corrígelo si difiere.

Resumen

Un túnel IPsec falla en uno de tres puntos, y saber en cuál es la mitad del trabajo. Fase 1 (IKE): los dos extremos no logran autenticarse ni acordar un canal seguro (IP o PSK incorrecta, propuestas incompatibles, certificados, identificadores, puertos bloqueados). Fase 2 (IPsec): la Fase 1 sube pero no se acuerdan las claves de datos (perfil de cifrado distinto, PFS, Proxy IDs que no coinciden). Tráfico: el túnel está arriba pero los usuarios no se alcanzan (ruta, política, NAT, zona de la Tunnel Interface). La GUI lo resume con dos indicadores: IKE Phase 1 y Tunnel Info en Network > IPSec Tunnels.
Esta nota da un procedimiento para localizar la fase que falla, los comandos que muestran el estado de las SA y la razón del fallo (el log ikemgr.log es la fuente más útil), y las causas típicas con su solución. Se apoya en IPsec Fundamentals, Site-to-Site VPN Estático, Site-to-Site VPN con Certificados e IPsec PA a Cisco.

Requisitos previos

  • Acceso a ambos extremos (o al menos a un extremo y al administrador del otro) para comparar parámetros
  • Haber leído IPsec Fundamentals (qué debe coincidir en cada fase)
  • Conocer las IP de los peers, el método de autenticación, versiones de IKE y los Proxy IDs o redes protegidas
  • Acceso CLI para ver el log de IKE (ver CLI y Config Management)
  • Conectividad IP básica entre los peers (comprobada con ping)
  • El Troubleshooting Toolkit como referencia de capturas y contadores

Procedimiento

graph TD
    A["Network > IPSec Tunnels:<br/>¿Phase 1 verde?"] -- No --> F1["Fase 1: peer, PSK/certificado,<br/>propuestas, puertos UDP 500/4500"]
    A -- Sí --> B["¿Tunnel Info verde?"]
    B -- No --> F2["Fase 2: perfil IPsec, PFS,<br/>Proxy IDs"]
    B -- Sí --> C["¿Pasa tráfico?<br/>show vpn flow: encap/decap"]
    C -- No --> F3["Rutas, Security Policy,<br/>NAT exemption, zona del túnel"]
    C -- Sí --> OK["Funciona: revisa estabilidad<br/>(lifetimes, DPD)"]

Paso 1: Estado general

  1. Network > IPSec Tunnels: mira Status (IKE Phase 1 y Tunnel Info).
  2. Por CLI:
show vpn ike-sa
show vpn ike-sa gateway GW-PA16
show vpn ipsec-sa
show vpn ipsec-sa tunnel Tunnel-to-PA16
show vpn flow
show vpn flow name Tunnel-to-PA16

Qué indican:

ResultadoSignificado
No hay IKE SAFalla la Fase 1
Hay IKE SA pero no IPsec SAFalla la Fase 2
Hay ambas SA, encap sube y decap no (o al revés)El tráfico se envía pero no vuelve (o no sale): revisa el otro extremo, rutas o políticas
Ambas subenEl túnel pasa tráfico

Paso 2: Provocar la negociación y leer el log

test vpn ike-sa gateway GW-PA16
test vpn ipsec-sa tunnel Tunnel-to-PA16
less mp-log ikemgr.log
tail follow yes mp-log ikemgr.log

El log ikemgr.log es la fuente más útil: indica qué propuesta recibió, qué rechazó y por qué. También sirve Monitor > Logs > System con el filtro ( subtype eq vpn ). Si un comando no coincide con tu versión, usa Tab o ?.

Mensajes y su significado típico:

Mensaje en el logCausa probable
IKE phase-1 negotiation is failed. Couldn't find configuration for IKE phase-1 request for peer IP ...El peer te contacta con una IP o ID que no coincide con tu IKE Gateway (IP del peer, Local/Peer ID, interfaz)
no suitable proposal found / no proposal chosenLas propuestas de cifrado/hash/DH no coinciden entre los dos
pre-shared key mismatch o authentication failedLa PSK difiere, o el certificado no es válido
Received notify type INVALID_ID_INFORMATION / Proxy ID mismatchLos Proxy IDs o redes protegidas no son espejo
Phase 1 timeout / sin respuestaEl peer no recibe o no responde: UDP 500/4500 bloqueado, IP incorrecta o peer apagado
IPsec-SA ... negotiation is failedFase 2: perfil IPsec, PFS o Proxy ID
IKEv2: NO_PROPOSAL_CHOSENLas propuestas no coinciden
IKEv2: AUTHENTICATION_FAILEDPSK, certificado o ID incorrectos
IKEv2: TS_UNACCEPTABLELos Proxy IDs (traffic selectors) no coinciden

Paso 3: Fase 1 (IKE) — checklist

  1. Alcanzabilidad: ping source <IP-local> host <IP-peer> (puede estar bloqueado el ICMP y aun así funcionar IKE).
  2. Security Policy: ¿se permite ike (UDP 500) y ipsec-esp-udp (UDP 4500) hacia y desde el firewall? Mira Monitor > Logs > Traffic filtrando por el peer.
  3. IKE Gateway: Interface y Local IP correctas, Peer IP correcta, misma versión de IKE (v1 o v2) en ambos lados.
  4. Autenticación: PSK idéntica (vuelve a escribirla en ambos), o certificados válidos, de confianza y con los IDs correctos (ver Site-to-Site VPN con Certificados).
  5. IKE Crypto Profile: cifrado, hash, DH iguales.
  6. Identificadores: Local/Peer Identification coherentes, sobre todo con NAT o IP dinámica.
  7. NAT-T: si hay NAT en el camino, activa NAT Traversal en ambos.
  8. Passive Mode: si un extremo es solo respondedor, el otro debe iniciar.

Paso 4: Fase 2 (IPsec) — checklist

  1. IPsec Crypto Profile: protocolo ESP, cifrado, hash iguales.
  2. PFS: si un lado tiene grupo DH y el otro no-pfs, falla; igualarlos.
  3. Proxy IDs: en espejo exacto con las redes del peer (o la ACL de un Cisco; ver IPsec PA a Cisco).
  4. Lifetimes: no deben fallar la renegociación; alinéalos.
  5. Tunnel Interface asociada al túnel y en el Virtual Router.

Paso 5: Tráfico — checklist

  1. Ruta: la red remota apunta a tunnel.X (show routing route destination <IP-remota>).
  2. Security Policy: zona de origen (inside) a zona del túnel (vpn) y viceversa; mira Monitor > Logs > Traffic.
  3. NAT exemption: el tráfico VPN no debe traducirse (regla No NAT arriba) (ver Source NAT).
  4. Zona de la Tunnel Interface: en la zona correcta, con User-ID si la necesitas.
  5. Ambos sentidos: show vpn flow con encap y decap subiendo.
  6. Tunnel Monitor: si está habilitado, comprueba que el destino responde; si falla, el túnel se marca caído y la ruta se retira aunque las SA estén arriba.
  7. MTU: si el ping pequeño pasa pero las conexiones grandes se cuelgan, ajusta el MSS/MTU (por ejemplo con el MTU de la Tunnel Interface más bajo) y revisa la fragmentación.

Paso 6: Capturas

  1. Packet capture con filtro Protocol 17 (UDP) y Port 500 (y otro filtro con 4500) en la interfaz outside para ver si el peer envía y recibe IKE (ver Troubleshooting Toolkit).
  2. Para el tráfico de datos, captura en la Tunnel Interface (etapas receive, firewall, transmit).

Paso 7: Reiniciar el túnel limpiamente

clear vpn ike-sa gateway GW-PA16
clear vpn ipsec-sa tunnel Tunnel-to-PA16
test vpn ike-sa gateway GW-PA16
test vpn ipsec-sa tunnel Tunnel-to-PA16

Después de cambiar parámetros, limpia las SA para que se negocien de nuevo con los valores nuevos.

Verificación

Comando o lugarQué debes verSi no lo ves
Network > IPSec TunnelsAmbos indicadores en verdeMira qué fase falla y aplica el checklist
show vpn ike-saUna IKE SA para el peer correctoSi no hay, lee ikemgr.log
show vpn ipsec-saIPsec SA con SPI, bytes y lifetimeSi no hay, falla la Fase 2
show vpn flowencap y decap aumentandoSi solo sube uno, falta ruta o regla en el otro extremo
ping source <IP-tunnel> host <IP-tunnel-peer>RespuestasSi falla con el túnel arriba, revisa rutas y política
Monitor > Logs > Traffic: zona vpnSesiones de ida y vuelta permitidasSi no hay, no entra al túnel o lo bloquea una regla
Monitor > Logs > System (subtype eq vpn)Eventos del establecimientoÚtil para ver el motivo exacto

Errores comunes

Phase 1 no sube y el log dice que no encuentra configuración para el peer

  • Causa: el peer llega con una IP/ID que no coincide con tu IKE Gateway, o el IKE Gateway usa otra interfaz.
  • Solución: corrige Peer IP, Local Address, y los identificadores; confirma que la interfaz es la que recibe el tráfico.

No hay propuesta aceptable

  • Causa: los perfiles de cifrado de Fase 1 o Fase 2 no coinciden.
  • Solución: iguala cifrado, hash y DH en ambos lados, y la versión de IKE.

Fase 1 y 2 suben pero no hay ping entre redes

  • Causa: ruta, política o NAT.
  • Solución: aplica el checklist de tráfico (ruta, Security Policy en ambos sentidos, NAT exemption).

El túnel funciona y a los minutos cae

  • Causa: renegociación fallida por lifetimes o PFS distintos, o DPD que detecta pérdida.
  • Solución: alinea lifetimes y PFS, y estabiliza el enlace.

Funciona en un sentido

  • Causa: ruta de retorno o regla de seguridad faltante en el otro firewall, o NAT que modifica el origen.
  • Solución: revisa ambos extremos con show vpn flow y los logs de tráfico.

Las conexiones pequeñas funcionan y las grandes se cuelgan

  • Causa: MTU/MSS: el encapsulado agrega cabeceras y los paquetes grandes se fragmentan o se descartan.
  • Solución: reduce el MTU de la Tunnel Interface o ajusta el MSS (Adjust TCP MSS en la interfaz).

Con certificados, falla solo después de un tiempo

  • Causa: certificado vencido, o CRL/OCSP inaccesible.
  • Solución: renueva el certificado y asegura el acceso a la validación de revocación.

Cambié la configuración y sigue igual

  • Causa: las SA anteriores siguen activas con los valores antiguos.
  • Solución: limpia las SA (clear vpn ike-sa ..., clear vpn ipsec-sa ...) y vuelve a iniciar.

Vista Gráfica

Retroenlaces