Troubleshooting VPN Meraki

Contenido complementario

Este tema no está en las notas de mis cursos; está armado con la documentación oficial de Meraki (consultada en octubre de 2026). Los mensajes de log vienen de la versión japonesa del artículo oficial (no se encontró la inglesa); el texto exacto puede variar. 🔎 Verificar = compruébalo contra tu Dashboard.

Pendiente: validar en el lab

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

Resumen

Un túnel IPsec en Meraki falla igual que en cualquier otra marca: en fase 1, en fase 2 o en el tráfico. Lo diferente es que no tienes CLI: la evidencia está en el Event log, en VPN status y en las capturas de paquetes. Esta nota da el procedimiento y la tabla de mensajes. El otro extremo (Palo Alto) se diagnostica con Troubleshooting IPsec PA a Meraki.

Requisitos previos

• Acceso al Dashboard (lectura es suficiente para ver logs)
• Saber IKEv1/IKEv2, IPs, subredes y PSK acordadas con el otro extremo
• Acceso al otro extremo (o a su administrador)

Procedimiento

graph TD
    A["VPN status: ¿túnel verde?"] -->|No| B["Event log: ¿hay fase 1?"]
    A -->|Sí, sin tráfico| G["Rutas, firewall, NAT"]
    B -->|No hay respuesta| C["UDP 500/4500, IP, ping"]
    B -->|Fase 1 falla| D["Proposals, PSK, IKE version, IDs"]
    B -->|Fase 1 ok, fase 2 falla| E["Subredes, PFS, lifetime"]

Paso 1: Estado del túnel

VPN status: vista de red en Security & SD-WAN → Monitor → VPN Status, o de organización en Organization → Monitor → VPN Status. En los peers IPsec solo ves si están alcanzables (sin latencia ni uso).

Paso 2: Generar tráfico interesante

Ping a una IP de la subred remota desde un host detrás del MX: el túnel solo se inicia cuando hay tráfico que coincide con las subredes configuradas. Hazlo desde un cliente, no desde el propio MX (sobre todo en Passthrough/Concentrator; 🔎 Verificar).

Paso 3: Event log

Network-wide → Monitor → Event log, con estos filtros de tipo de evento:

Filtro	Qué muestra
All IPsec VPN	Negociación de VPN no-Meraki
All IPsec / Client VPN	Conectividad no-Meraki y Client VPN
Meraki VPN	Conectividad de Auto VPN
BGP	Notificaciones y sesiones BGP
Non-Meraki VPN Healthcheck	Health checks de túneles primario/secundario

Una negociación sana muestra: inicio de fase 1, ISAKMP SA establecida, inicio de fase 2, IPsec SA establecida.

Paso 4: Captura de paquetes

Si no hay nada en el log: captura de paquetes en la interfaz de Internet primaria del MX y descarga el .pcap para abrirlo en Wireshark; busca paquetes salientes sin respuesta. Una vez cifrado, el tráfico dentro del túnel no se ve en la WAN, así que la captura sirve para la negociación (UDP 500/4500), no para el contenido.

Paso 5: Descartar MTU

En IPsec no-Meraki hay hasta 100 bytes de sobrecarga. Prueba con el bit DF activo y 1472 bytes de datos (1500 menos 28 de cabeceras):

ping 192.168.50.10 -s 1472 -M do      # Linux
ping 192.168.50.10 -l 1472 -f         # Windows
ping 192.168.50.10 -s 1472 -D         # macOS

Baja el tamaño hasta que responda. Comprueba también que ningún equipo del camino bloquee los ICMP “Fragmentation Needed”. Más detalle en MTU y MSS en túneles IPsec (PA y Meraki).

Mensajes y qué significan

Mensaje	Causa más probable	Qué revisar
no-proposal-chosen received (fase 1)	Políticas de fase 1 distintas, PSK distinta, ISAKMP no habilitado en la interfaz del peer	Cifrado/hash/DH, PSK, alcance IP
no-proposal-chosen received (fase 2)	Políticas de fase 2 distintas	Lifetime por tiempo (no datos), modo túnel, PFS
failed to pre-process ph2 packet / failed to get sainfo	Subredes distintas entre ambos lados (a menudo la máscara)	Private subnets del peer vs. proxy ID/ACL del otro lado
invalid flag 0x08	Versión IKE distinta entre extremos	IKEv1/IKEv2 en ambos lados (si el otro extremo es un MX con firmware anterior a 15.12, usa IKEv1)
exchange Aggressive not allowed	El peer usa aggressive mode; el MX solo acepta main mode	Poner main mode en el peer
exchange Identity Protection not allowed	Fase 1 distinta en ambos lados, peer en aggressive mode o peer no configurado en el Dashboard	Comparar la fase 1 y capturar ISAKMP en el uplink primario
phase1 negotiation failed due to time up	El otro lado no responde	Ping, UDP 500/4500, captura
Túnel que cae cada cierto tiempo	Lifetime de fase 2 distinto (28 800 s por defecto en el MX; no admite lifetimes por volumen)	Igualar lifetimes

Causas por síntoma

Síntoma	Causa típica	Solución
Nunca hay fase 1	UDP 500/4500 bloqueado, IP incorrecta, peer detrás de NAT sin NAT-T	Abrir puertos; Remote ID/Local ID; NAT-T
Fase 1 sube, fase 2 no	Subredes, PFS o lifetimes distintos	Igualar parámetros
Túnel arriba, no pasa tráfico	Falta ruta o regla de firewall; NAT; selectores muy estrechos	Revisar rutas, reglas y NAT
Solo una de varias subredes funciona	Peer IKEv2 limitado a un par	IKEv1 o route-based
Un spoke Auto VPN no alcanza al peer	Túnel policy-based	Route-based + BGP
Sube solo si inicia el otro lado	No hay tráfico interesante desde detrás del MX (en Passthrough/Concentrator el propio MX no lo genera; 🔎 Verificar)	Tráfico interesante desde un cliente

Particularidades por proveedor

En Azure usa la supernet en Private subnets, no subredes sueltas. En Google Cloud VPN, firmware < 15.12 solo IKEv1 y sus gateways no contestan ICMP: el ping no sirve para probar.

Configuración (Ejemplo)

1. Revisión por API

Útil para varios sitios. Reemplaza ORG_ID y exporta tu clave en la variable de entorno MERAKI_API_KEY (no la pegues en comandos ni la guardes en archivos).

# Estado de VPN de toda la organización (Auto VPN y no-Meraki)
curl -s -H "Authorization: Bearer $MERAKI_API_KEY" \
  "https://api.meraki.com/api/v1/organizations/ORG_ID/appliance/vpn/statuses"
 
# Lista de peers no-Meraki
curl -s -H "Authorization: Bearer $MERAKI_API_KEY" \
  "https://api.meraki.com/api/v1/organizations/ORG_ID/appliance/vpn/thirdPartyVPNPeers"

Qué devuelve statuses: en thirdPartyVpnPeers los campos name, publicIp y reachability; en merakiVpnPeers, networkId, networkName, reachability y priority. Se puede filtrar con networkIds y paginar con perPage (3 a 300).

2. Modificar peers por API (con cuidado)

El endpoint de actualización es PUT /organizations/{organizationId}/appliance/vpn/thirdPartyVPNPeers. El cuerpo es un objeto con la lista peers, y cada peer exige name, privateSubnets y secret; ikeVersion vale "1" si no lo indicas.

Trata el PUT como un reemplazo completo

La página oficial de la API no dice explícitamente si la lista enviada reemplaza a la existente, pero la comunidad de Meraki reporta que sobrescribe lo enviado y que elimina y vuelve a establecer los túneles existentes, y el módulo de Ansible solo permite actualizar la lista completa. Asume que reemplaza: haz primero el GET, guarda una copia, modifica y vuelve a enviar todos los peers. Pruébalo antes en una organización de laboratorio.

Además, la API no valida el solapamiento de subredes como el Dashboard: la configuración resultante puede quedar bloqueada para editarla en el Dashboard hasta corregir el solapamiento a mano.

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
VPN Status	El peer en verde	Sigue el procedimiento desde el Paso 2
Event log (All IPsec VPN)	ISAKMP SA e IPsec SA establecidas	Busca el mensaje en la tabla
Ping entre cada par de subredes	Responde	Rutas, firewall o NAT
Ping DF con 1472 bytes	Responde o indica el tamaño máximo	Ajusta MTU/MSS
GET .../appliance/vpn/statuses	reachability correcta en cada peer	Revisa el peer que falla

Errores comunes

Miro el log y no veo nada

• Causa: filtraste el tipo de evento equivocado o el rango de tiempo es otro.
• Solución: usa All IPsec VPN, genera tráfico y refresca.

La página VPN status no muestra mi peer tras un failover HA

• Causa: limitación documentada: no muestra peers cuando el MX principal conmuta al MX spare.
• Solución: verifica en el Event log y desde el otro extremo.

”Funciona pero solo en una dirección”

• Causa: falta ruta de retorno en el otro lado o NAT sin excepción.
• Solución: revisa rutas y NAT exemption en ambos extremos.

El Dashboard dice “verde” pero el servicio no funciona

• Causa: el problema está en la capa de aplicación: MTU/MSS, firewall o NAT.
• Solución: sigue el Runbook 11 de Runbooks.

Fuentes

• VPN Status Page
• How to Use the Meraki Event Log
• Auto VPN Troubleshooting (captura de paquetes y pasos)
• Troubleshooting MTU Issues
• Primary and Secondary IPsec VPN Tunnels
• API: updateOrganizationApplianceVpnThirdPartyVPNPeers
• API: getOrganizationApplianceVpnStatuses
• Hilo de la comunidad sobre el PUT de peers
• Troubleshooting Non-Meraki Site-to-site VPN Peers (traducción japonesa)