IPsec PA a Meraki (IKEv1 y proxy IDs)

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 de IP, nombres y subredes son de ejemplo. 🔎 Verificar = no confirmado en documentación.

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 IKEv1, un MX de Meraki es hacia afuera un equipo IPsec basado en políticas: protege pares de subredes concretas. Palo Alto es basado en rutas, así que para entenderse en la Fase 2 debes escribir Proxy IDs que coincidan con las subredes del MX. Con IKEv1 el MX negocia una SA por cada par de subredes (T = 2 × m × n), por lo que cada par necesita su Proxy ID. Esta nota arma ese túnel (la variante más compatible y la más fácil de depurar) y explica cómo crecer sin romperlo. Es el mismo problema de IPsec PA a Cisco, con el Dashboard de Meraki en lugar de una ACL. Para el diseño moderno (sin Proxy IDs) mira IPsec PA a Meraki (IKEv2 y route-based).

Requisitos previos

• Haber leído IPsec Fundamentals, Site-to-Site VPN Estático, IPsec PA a Cisco, Meraki Fundamentos y Dashboard y Non-Meraki VPN Peers (IPsec)
• IP pública del Palo Alto (ejemplo 23.1.2.15) y del MX (ejemplo 24.1.2.30), con UDP 500 y 4500 permitidos entre ambas
• Subredes sin solaparse: Palo Alto 10.10.0.0/24 y 10.10.1.0/24; Meraki 192.168.50.0/24 y 192.168.51.0/24 (ejemplo)
• PSK fuerte acordada (no la pongas en capturas ni en tickets)
• Acceso de administrador a la organización de Meraki

Topología

graph LR
    LANPA["LAN PA<br/>10.10.0.0/24<br/>10.10.1.0/24"] --- PA["Palo Alto PA-15<br/>(basado en rutas)<br/>Proxy IDs: m × n pares"]
    PA == "IPsec IKEv1" === MX["Meraki MX<br/>(basado en políticas)<br/>Private subnets del peer"]
    MX --- LANM["LAN Meraki<br/>192.168.50.0/24<br/>192.168.51.0/24"]

Qué debe coincidir

Parámetro	Palo Alto	Meraki (Dashboard)
Versión IKE	IKE Gateway → IKEv1 only mode	Peer → IKE version IKEv1
Modo de intercambio	main (el MX no acepta aggressive)	(fijo: main)
Cifrado / hash F1	IKE Crypto Profile: aes-256-cbc / sha256	Custom → Phase 1: AES-256 / SHA256
DH F1	group14	DH group 14
Cifrado / hash F2	IPsec Crypto Profile: ESP aes-256-cbc / sha256	Custom → Phase 2: AES-256 / SHA256
PFS	group14 o no-pfs	PFS group 14 u Off
Lifetimes	Iguálalos a mano. Defaults de PAN-OS: IKE 8 h, IPsec 1 h	Segundos (por tiempo, nunca por datos); 28 800 s por defecto en ambas fases
PSK	IKE Gateway → Pre-shared Key	Preshared secret
IP del peer	Peer Address = IP pública/uplink del MX	Public IP = IP pública del Palo Alto
Redes protegidas	Un Proxy ID por cada par (local × remoto)	Private subnets del peer = subredes del PA; subredes del MX = las que tengan VPN mode Enabled

Los pares se multiplican

Con IKEv1, 2 subredes en el MX y 2 en el Palo Alto son 4 Proxy IDs (8 SAs contando ambas direcciones). Con 5 × 5 serían 25 Proxy IDs. Además, la documentación de PAN-OS indica que cada Proxy ID cuenta como un túnel contra la capacidad IPsec del firewall; agrupar rangos en supernets reduce su número. Por eso este diseño no escala: pasa a BGP sobre IPsec PA a Meraki cuando crezca el número de subredes.

Proxy ID y subredes de Meraki deben ser espejo exacto

Si en el PA el Proxy ID dice Local 10.10.0.0/24, Remote 192.168.50.0/24, el MX debe tener 10.10.0.0/24 en Private subnets y 192.168.50.0/24 como subred local con VPN mode Enabled. Una diferencia de máscara es la causa más común de failed to get sainfo en el log del MX.

Configuración (Ejemplo)

1. Meraki: crear el peer

1. Security & SD-WAN → Configure → Site-to-site VPN → Organization-wide settings → Non-Meraki VPN peers → Add a peer. 🔎 Verificar la ruta en tu versión.
2. Name PA-15. IKE version IKEv1.
3. IPsec policies: Custom → Phase 1 AES-256 / SHA256 / DH 14; Phase 2 AES-256 / SHA256 / PFS 14 (u Off, igual que el PA); lifetimes iguales a los del PA.
4. Public IP: 23.1.2.15.
5. Private subnets: 10.10.0.0/24 y 10.10.1.0/24.
6. Preshared secret: la PSK acordada.
7. Availability: la red del MX (o las tags correspondientes).
8. En la red del MX, confirma que Local networks de 192.168.50.0/24 y 192.168.51.0/24 tienen VPN mode = Enabled.
9. Guardar. Recuerda: puede reiniciar túneles existentes.

2. Palo Alto: base

Sigue los pasos de Site-to-Site VPN Estático (zona vpn, Tunnel Interface, IKE Crypto Profile, IPsec Crypto Profile, IKE Gateway, IPsec Tunnel, ruta) con estos ajustes:

• IKE Crypto Profile IKE-MERAKI: DH group14, Encryption aes-256-cbc, Authentication sha256, Key Lifetime igual al del MX.
• IPsec Crypto Profile IPSEC-MERAKI: ESP, aes-256-cbc, sha256, DH Group group14 o no-pfs (igual que el MX), Lifetime igual al del MX.
• IKE Gateway GW-to-Meraki: Version IKEv1 only mode, Peer Address 24.1.2.30, Authentication Pre-Shared Key.
  • Advanced Options: Exchange Mode main, el IKE Crypto Profile acordado.
  • Identification: tipos disponibles IP address, FQDN, KEYID y User FQDN; si no pones valor, usa la IP local (Local) y la IP del peer (Peer). En Meraki el Local ID solo existe con IKEv2; con IKEv1 el MX se identifica con la IP de su uplink, que puede ser privada si está detrás de NAT. 🔎 Verificar con el log.
  • Si el MX está detrás de NAT: habilita NAT Traversal y ajusta Peer Identification a la IP de uplink del MX.
  • Dead Peer Detection (IKEv1): intervalo y reintentos configurables entre 2 y 100.
• Rutas: una por cada subred del MX, destino 192.168.50.0/24 y 192.168.51.0/24, interfaz tunnel.1, Next Hop None.

3. Palo Alto: Proxy IDs (uno por par)

Network > IPSec Tunnels > Tunnel-to-Meraki > pestaña Proxy IDs > Add (IPv4). Repite por cada combinación local × remota (protocolo any).

Para no teclear todas las combinaciones, genéralas con un script y pégalas en la CLI (sustituye los nombres y las subredes por las tuyas):

#!/usr/bin/env bash
# Genera los "set" de proxy-id para todas las combinaciones PA × Meraki
TUNNEL="Tunnel-to-Meraki"
PA_NETS=("10.10.0.0/24" "10.10.1.0/24")
MX_NETS=("192.168.50.0/24" "192.168.51.0/24")
i=1
for l in "${PA_NETS[@]}"; do
  for r in "${MX_NETS[@]}"; do
    echo "set network tunnel ipsec $TUNNEL auto-key proxy-id PID-$i local $l remote $r protocol any"
    i=$((i+1))
  done
done

Cada línea tiene la misma forma que en IPsec PA a Cisco:

set network tunnel ipsec Tunnel-to-Meraki auto-key proxy-id PID-1 local 10.10.0.0/24 remote 192.168.50.0/24 protocol any

Si un comando no coincide con tu versión, usa Tab o ?.

4. Palo Alto: NAT y políticas

• Regla de NAT no-nat-vpn (Source Translation None) de inside a vpn entre las subredes del PA y las del MX, arriba de la regla de Internet (ver Source NAT).
• Security Policy inside → vpn y vpn → inside para esas redes (ver Security Policy Fundamentals).
• En outside: aplicaciones ike e ipsec-esp-udp desde y hacia la IP del MX.
• Si el tráfico lleva NAT (por ejemplo, subredes solapadas), los Proxy IDs deben usar las direcciones posteriores al NAT (ver NAT sobre VPN con subredes solapadas (PA y Meraki)).
• El PA ajusta el MSS de TCP en túneles IPsec; si aun así hay problemas de tamaño, ver MTU y MSS en túneles IPsec (PA y Meraki).

5. Iniciar y probar

• Haz ping a una IP de la subred remota desde un host detrás del PA o del MX (el MX necesita tráfico interesante).
• Desde el PA: test vpn ike-sa gateway GW-to-Meraki y luego test vpn ipsec-sa tunnel Tunnel-to-Meraki.

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
show vpn ike-sa gateway GW-to-Meraki	La IKE SA establecida	Fase 1: ver Errores comunes
show vpn ipsec-sa tunnel Tunnel-to-Meraki	Una SA por cada Proxy ID	Proxy ID o subred faltante
show vpn flow name Tunnel-to-Meraki	encap y decap creciendo	Rutas, políticas o NAT (ver Troubleshooting IPsec)
VPN status e Event log del MX	Peer en verde; fase 1 y fase 2 establecidas	Troubleshooting VPN Meraki
Ping entre cada par de subredes	Todos responden	El par que falla indica el Proxy ID o la subred que falta

Errores comunes

La Fase 1 no sube

• Causa: PSK, política de F1 o versión IKE distintas, UDP 500/4500 bloqueado o Peer Identification mal.
• Revisa: Troubleshooting IPsec PA a Meraki.
• Solución: iguala los parámetros en ambos lados.

La Fase 1 sube pero la Fase 2 falla

• Causa: en el MX, failed to get sainfo indica subredes que no son espejo; no-proposal-chosen en F2 indica política F2 distinta. En el PA, mismatch de Proxy ID o de propuestas.
• Solución: corrige los Proxy IDs y las subredes del MX, o iguala el perfil IPsec.

Solo funciona un par de subredes

• Causa: falta el Proxy ID del resto de combinaciones, o falta la subred en Private subnets o VPN mode Enabled en el MX.
• Solución: completa todas las combinaciones.

El túnel cae a intervalos regulares

• Causa: lifetimes distintos (el MX usa por defecto 28 800 s) o lifetimes por volumen de datos.
• Solución: iguala los lifetimes por tiempo en ambos lados.

Hay NAT entre los dos extremos

• Causa: el MX se identifica con su IP de uplink privada.
• Solución: habilita NAT Traversal en el Gateway y ajusta Peer Identification. Con IKEv2 puedes fijar identificadores explícitos (IPsec PA a Meraki (IKEv2 y route-based)).

Crecí a 6 subredes y esto es inmanejable

• Causa: el número de Proxy IDs crece con m × n.
• Solución: cambia a BGP sobre IPsec PA a Meraki.

Fuentes

• Tips & Tricks: Why Use a VPN Proxy ID? (Palo Alto KB)
• Proxy ID for IPsec VPN (Palo Alto)
• Set Up an IKE Gateway (Palo Alto)
• Define IKE Crypto Profiles (Palo Alto)
• IPsec VPN Configuration Settings (Meraki)
• Policy and Route-based IPsec VPNs compared (Meraki)
• RFC 2409 (IKEv1)