IPsec PA a Meraki (IKEv2 y route-based)

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 valores son de ejemplo. 🔎 Verificar = no confirmado en documentación; es un laboratorio para probar, no una receta garantizada.

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

Con IKEv2 el MX manda un solo traffic selector agregado con todas sus subredes, y desde MX 19.1.4 (dinámico) y 26.2 (estático) puede funcionar route-based: qué tráfico entra al túnel lo deciden las rutas, no los Proxy IDs. Es el modelo que Meraki favorece (retira el IKEv2 policy-based desde 26.2) y el que casa con la forma de trabajar de Palo Alto. Esta nota explica tres variantes para que veas en tu laboratorio cuál funciona con tu firmware y tu PAN-OS, y qué identificadores fijar para evitar el problema típico del Local ID.

Requisitos previos

• Haber leído IPsec PA a Meraki (IKEv1 y proxy IDs) y Non-Meraki VPN Peers (IPsec)
• MX con IKEv2 (≥ 15.12). Para route-based dinámico, ≥ 19.1.4; para route-based estático, ≥ 26.2. Revisa el firmware antes de elegir variante
• Mismos datos de red que en la nota IKEv1
• Un laboratorio o una ventana de mantenimiento: el cambio de IKE version reinicia el túnel

Conceptos clave

Las tres variantes

Variante	Meraki	Palo Alto	Cuándo usarla
A. IKEv2 policy-based	IKEv2, Private subnets	Proxy IDs (ver el comportamiento documentado abajo)	Firmware antiguo sin route-based. Meraki lo retira desde 26.2
B. Route-based estático	IKEv2, MX ≥ 26.2	Tunnel Interface + rutas estáticas, sin Proxy IDs	Pocos sitios, sin BGP
C. Route-based dinámico (eBGP)	IKEv2, MX ≥ 19.1.4	Tunnel Interface con IP /30 + BGP	Lo recomendado: BGP sobre IPsec PA a Meraki

graph TD
    A["¿Qué firmware tiene el MX?"] -->|"< 19.1.4"| B["IKEv1 + proxy IDs"]
    A -->|"19.1.4 – 26.1"| C["Variante C: eBGP"]
    A -->|"≥ 26.2"| D["Variante B o C"]
    C --> E["¿Necesitas varias subredes<br/>o Auto VPN ↔ PA?"]
    E -->|Sí| C

Comportamiento documentado de PAN-OS con los selectores de IKEv2

Situación	Qué hace PAN-OS (documentado)
Sin Proxy ID (route-based)	Usa por defecto 0.0.0.0/0 ↔ 0.0.0.0/0, aplicación any. Con un peer policy-based en IKEv1 eso no coincide y falla; con IKEv2 hay narrowing
PA es respondedor y el peer propone selectores más específicos	Estrecha (narrowing) sus propios selectores al subconjunto común
PA es respondedor y tiene varios Proxy IDs	Responde con la primera entrada que coincide (ordenadas alfabéticamente por nombre completo del túnel) y solo instala la primera aunque el peer devuelva varias
PA es iniciador con varios Proxy IDs y ninguno coincide	Usa el último Proxy ID para negociar
Peer que no soporta narrowing (la documentación cita Cisco IOS 15.0)	Responde NO_PROPOSAL_CHOSEN y el túnel no sube
El estándar (RFC 7296 §2.9)	El respondedor puede estrechar pero no devolver un conjunto vacío; si nada es aceptable, TS_UNACCEPTABLE; si solo acepta un par, puede usar SINGLE_PAIR_REQUIRED

Consecuencia para la variante A

Si el PA es el respondedor y tiene varios Proxy IDs frente al selector agregado de Meraki, el comportamiento documentado indica que solo se instala la primera coincidencia: el síntoma sería “solo funciona una subred”. Sin Proxy IDs (route-based, variantes B y C) el PA estrecha a lo que ofrece el MX y no tiene ese problema. Confírmalo en el laboratorio (tabla de pruebas más abajo).

Qué debe coincidir

Parámetro	Palo Alto	Meraki
Versión	IKE Gateway → IKEv2 only mode	IKE version IKEv2
Cifrado / hash F1	IKE Crypto Profile	Custom → Phase 1
DH	group14 (PAN-OS lista también 19 y 20, que Meraki no ofrece)	DH 14 (15 y 21 requieren MX ≥ 19.2)
F2 / PFS	IPsec Crypto Profile	Custom → Phase 2
ID del MX	Peer Identification	Local ID (fíjalo; vacío = IP del uplink, no necesariamente la pública)
ID del PA	Local Identification	Remote ID
NAT-T	NAT Traversal activado si hay NAT	(automático)
Redes (variante A)	Proxy IDs	Private subnets
Redes (B y C)	Rutas / BGP, sin Proxy IDs	Rutas / BGP

Fija los IDs en ambos lados

En un hilo de la comunidad de Palo Alto (PA3250) el MX enviaba su IP WAN como ID y el PA debía esperarla (más NAT-T) para que el túnel subiera. Para no depender de eso, fija el Local ID en el MX (IP pública o FQDN/User FQDN), haz que Peer Identification del PA sea exactamente ese valor, y que el Remote ID del MX sea el Local Identification del PA. 🔎 Verificar en tu versión.

Configuración (Ejemplo)

1. Meraki

1. Peer con IKEv2, política Custom (AES-256 / SHA256 / DH 14, PFS 14 u Off).
2. Local ID = IP pública del MX (o User FQDN); Remote ID = lo que enviará el PA.
3. Variante A: Private subnets con las subredes del PA. Variante B (MX ≥ 26.2): peer route-based y rutas estáticas hacia el peer. 🔎 Verificar los nombres de campo en 26.2.
4. Variante C: Routing = Dynamic (BGP) (ver BGP sobre IPsec en Meraki).

2. Palo Alto

• IKE Gateway: Version IKEv2 only mode, Peer Address = IP del MX, PSK.
  • Local Identification / Peer Identification: tipo y valor acordados (PAN-OS admite FQDN, IP address, KEYID y User FQDN; sin valor usa las IP). Peer Identification = Local ID del MX; Local Identification = Remote ID del MX.
  • Liveness Check: comprobación de vida de IKEv2; el PA envía una petición informativa al peer cada 5 s por defecto. Si el iniciador no recibe respuesta tras 10 reintentos, borra la IKE SA y las CHILD SA y vuelve a empezar con un IKE_SA_INIT nuevo.
  • Passive Mode solo si quieres que el PA nunca inicie; en ese caso el MX debe iniciar siempre.
  • NAT Traversal si hay NAT entre ambos.
• Tunnel Interface con zona vpn.
• IPsec Tunnel: Tunnel Interface, IKE Gateway, IPsec Crypto Profile.
• Proxy IDs: variante A, los de la nota IKEv1 (pruébalos y registra qué pasa con el selector agregado); variantes B y C, ninguno. 🔎 Verificar el selector negociado en el log.
• Rutas estáticas (variante B) hacia las subredes del MX con Next Hop None e interfaz tunnel.X.

3. NAT y políticas

Idénticas a la nota IKEv1: no-NAT, Security Policy y reglas ike/ipsec-esp-udp.

4. Qué registrar en el laboratorio

Prueba	Resultado a anotar
Variante A, 2 × 2 subredes, PA con 4 Proxy IDs	¿Cuántas SAs aparecen en show vpn ipsec-sa? ¿Pasan los 4 pares?
Variante A, PA con 1 Proxy ID	¿Se descarta el resto del tráfico?
Variante B	¿El túnel sube sin Proxy IDs? ¿Qué selectores muestra el log?
Variante C	¿Establece BGP? (ver BGP sobre IPsec PA a Meraki)

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
show vpn ike-sa gateway GW-to-Meraki	IKE SA IKEv2 establecida	Versión o IDs: ver Errores comunes
show vpn ipsec-sa tunnel Tunnel-to-Meraki	Child SA activa	Selectores o propuestas F2
less mp-log ikemgr.log (ikemgr-ng.log en PAN-OS 11.2+)	El traffic selector negociado y los IDs de ambos lados	Activa debug ike global on y repite
VPN status e Event log del MX	Peer en verde	Troubleshooting VPN Meraki

Errores comunes

La Fase 1 sube con IKEv1 pero no con IKEv2

• Causa: versión distinta o IDs mal.
• Revisa: que ambos extremos usen IKEv2 (invalid flag en el log de Meraki suele indicar versión desigual).
• Solución: iguala versión e identificadores.

Funciona solo una subred

• Causa: el PA (respondedor con varios Proxy IDs) instala solo el primer par de selectores.
• Solución: usa route-based (sin Proxy IDs) o vuelve a IKEv1.

El túnel sube pero Meraki marca las rutas como malas

• Causa: un peer policy-based con selectores estrechos hace fallar los health checks de la ruta.
• Solución: amplía los selectores o pasa a route-based.

Cambié a route-based y se rompió Auto VPN

• Causa: los spokes necesitan que el peer anuncie las rutas.
• Solución: BGP, ver BGP sobre IPsec PA a Meraki.

Fuentes

• Configure IKEv2 Traffic Selectors (Palo Alto)
• Tips & Tricks: Why Use a VPN Proxy ID? (Palo Alto KB)
• Set Up an IKE Gateway (Palo Alto)
• RFC 7296 (IKEv2)
• Policy and Route-based IPsec VPNs compared (Meraki)
• IPsec VPN Configuration Settings (Meraki)
• Hilo Meraki–PA3250 (comunidad de Palo Alto)