Kassinipedia

Troubleshooting IPsec PA a Meraki

Se lee en 6 min

Troubleshooting IPsec PA a Meraki

Contenido complementario

Este tema no está en las notas de mis cursos; está armado con la documentación oficial de Meraki y de Palo Alto (consultadas en octubre de 2026). Los mensajes de log del MX vienen de una traducción del artículo oficial y pueden variar. 🔎 Verificar = compruébalo en tu equipo.

Pendiente: validar en el lab

Este contenido no salió de mis clases. Probar estos comandos y pasos en el laboratorio antes de usarlos en un trabajo real, y corregir lo que difiera en mi versión.

Resumen

Esta nota junta en un solo procedimiento los dos lados de un túnel Palo Alto ↔ Meraki. Como el Dashboard de Meraki no tiene CLI, la forma de diagnosticar es leer en paralelo el ikemgr.log del PA y el Event log del MX, y comparar. La tabla de correlación relaciona cada mensaje de un lado con su causa y con lo que verás en el otro. Se apoya en Troubleshooting IPsec (lado PA) y Troubleshooting VPN Meraki (lado MX).

Requisitos previos

Procedimiento

graph TD
    A["Paso 1: ¿IKE SA?<br/>show vpn ike-sa + VPN status"] -->|No| B["Paso 3: Fase 1"]
    A -->|Sí| C["¿IPsec SA con encap y decap?"]
    C -->|No| D["Paso 4: Fase 2"]
    C -->|Sí, solo encap| E["Paso 5: tráfico (retorno)"]
    C -->|Sí, ambos| F["Paso 5: tráfico (políticas, NAT, MTU)"]

Paso 1: Estado en ambos lados

show vpn ike-sa gateway GW-to-Meraki
show vpn ipsec-sa tunnel Tunnel-to-Meraki
show vpn flow
show vpn gateway
show vpn tunnel
show running tunnel flow info

Según la documentación de Palo Alto: show vpn ike-sa (SAs de fase 1), show vpn ipsec-sa (fase 2), show vpn flow (contadores IPsec), show vpn gateway (gateways y su configuración), show vpn tunnel (túneles auto-key) y show running tunnel flow info (estadísticas básicas de todos los túneles). En el Dashboard: VPN status.

Paso 2: Provocar la negociación y leer los logs

  1. Genera tráfico interesante desde un host detrás del MX (ping a una IP de la subred remota).
  2. En el PA: test vpn ike-sa gateway GW-to-Meraki.
  3. Activa el log con debug ike global on y léelo con less mp-log ikemgr.log (en PAN-OS 11.2 o superior el archivo es ikemgr-ng.log). En paralelo, lee el Event log del MX filtrando por All IPsec VPN. Al terminar, debug ike global off.

Paso 3: Fase 1, checklist

  • ¿Misma versión IKE en ambos lados?
  • ¿PSK igual (cuidado con espacios y caracteres especiales)?
  • ¿Propuestas F1 iguales (cifrado, hash, DH)?
  • ¿IDs correctos? IKEv1: el MX usa su IP; IKEv2: Local ID del MX = Peer Identification del PA.
  • ¿UDP 500/4500 permitido, y NAT-T activado si hay NAT?
  • ¿IP del peer correcta? Con el MX tras NAT, la IP de uplink puede ser privada.

Paso 4: Fase 2, checklist

  • ¿Política F2 igual y PFS igual?
  • IKEv1: ¿cada par de subredes tiene su Proxy ID y su espejo en Meraki (Private subnets y VPN mode Enabled)?
  • IKEv2 policy-based: ¿el PA acepta el selector agregado? 🔎 Verificar.
  • Lifetimes por tiempo en ambos.

Paso 5: Tráfico, checklist

  • Ruta a la subred remota por tunnel.X en el PA y ruta de retorno en el otro lado.
  • Security Policy y NAT exemption (ver Packet Flow y Sessions).
  • Zona de la Tunnel Interface correcta.
  • El tráfico interesante debe venir de un cliente detrás del MX, no del propio MX (sobre todo en Passthrough/Concentrator; 🔎 Verificar).
  • Spoke de Auto VPN → PA con túnel policy-based: no funciona por diseño (ver Auto VPN).
  • BGP: TCP 179 y rutas anunciadas.

Paso 6: Capturas

PA:

debug ike pcap on
# provoca la negociación
debug ike pcap off
view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap

MX: Packet capture en el uplink, filtro UDP 500/4500.

Paso 7: Reiniciar el túnel limpiamente

clear vpn ike-sa gateway GW-to-Meraki
clear vpn ipsec-sa tunnel Tunnel-to-Meraki

La documentación de Palo Alto describe estos clear como el borrado de las SAs IKEv1 y no aclara su efecto sobre un gateway IKEv2. Para IKEv2 documenta el Restart desde la GUI (Network → IPSec Tunnels, pantalla Tunnel Info, o el gateway en IKE Gateways): reinicia también las SAs IPsec hijas y es disruptivo para las sesiones existentes. Tras cualquier clear, comprueba con show vpn ike-sa que desapareció y genera tráfico de nuevo. En Meraki, el reinicio ocurre al cambiar la configuración; evita guardar cambios innecesarios.

Tabla de correlación

Lo que ves en el MXLo que suele ver el PACausaSolución
no-proposal-chosen received (F1)No encuentra propuesta aceptableCifrado, hash o DH de F1 distintosIgualar perfiles
phase1 negotiation failed due to time upNada en el log; el MX es quien intentaEl PA no responde: IP, UDP 500/4500, política de entradaVerificar IP, reglas ike, ping, captura
exchange Aggressive not allowed(si el PA lo envía)El MX solo acepta mainPoner Exchange Mode main en el PA
invalid flag 0x08Versión IKE inesperadaIKEv1/IKEv2 distintoIgualar versión
no-proposal-chosen received (F2)Propuesta F2 inesperadaPolítica F2 / PFS distintosIgualar perfil IPsec
failed to pre-process ph2 packet / failed to get sainfoProxy ID mismatch / selectoresSubredes distintas (máscara)Corregir Proxy IDs y subredes
(túnel sube y cae)Se renegocia periódicamenteLifetimes F2 distintosIgualar a mano
Verde, sin tráficoencap sube, decap en 0 (o al revés)Ruta de retorno, NAT, políticaVer Paso 5
Solo una subred funcionaUn solo Proxy ID o selectorFalta Proxy ID o IKEv2 limitadoProxy IDs completos, IKEv1 o route-based

Verificación

Comando o lugarQué debes verSi no lo ves
Ping en ambos sentidos entre cada par de subredesTodos respondenPaso 4 o 5
show vpn ipsec-sa tunnel Tunnel-to-Merakiencap y decap incrementandoPaso 5
VPN status y Event log del MXVerde y sin erroresTabla de correlación
Si hay BGP: show routing protocol bgp summaryVecino Established y rutas en ambos ladosBGP sobre IPsec PA a Meraki

Errores comunes

”Ping funciona pero la aplicación no”

”Funcionó ayer y hoy no”

  • Causa: algo cambió: alguien guardó cambios de VPN en Meraki (reinicia túneles), o cambió la IP pública del MX (failover de uplink).
  • Revisa: el Event log del MX y el historial de commits del PA.
  • Solución: corrige el cambio o actualiza la IP del peer.

”El PA dice Phase 2 bien y Meraki dice rojo”

  • Causa: el Dashboard puede tardar unos segundos en actualizarse.
  • Solución: fuerza tráfico y refresca; si persiste, compara las SAs reales con el log del MX.

Cambié la PSK y no sube

  • Causa: la PSK no coincide en los dos lados o el túnel no se reinició.
  • Solución: cámbiala en ambos lados casi a la vez y reinicia el túnel (Runbook 13 de Runbooks).

Solo falla un sitio de muchos

  • Causa: diferencia en la configuración de ese peer.
  • Solución: compáralo con uno que funciona: Availability, subredes, IDs.

Fuentes

Retroenlaces