Non-Meraki VPN Peers (IPsec)

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

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 Non-Meraki VPN peer es un túnel IPsec desde un MX hacia un equipo que no es Meraki (Palo Alto, Cisco, Fortinet, nubes públicas…). Se define a nivel de organización y se ofrece a las redes con Availability. Las decisiones importantes son tres: IKEv1 o IKEv2, policy-based o route-based, y estático o BGP, porque cambian cuántas SAs se negocian y qué debe coincidir en el otro lado. El túnel concreto con Palo Alto está en IPsec PA a Meraki (IKEv1 y proxy IDs) e IPsec PA a Meraki (IKEv2 y route-based). Teoría en 01 - IPsec and IKE (Phases, SAs and Selectors) y 02 - Policy-based vs Route-based VPN.

Requisitos previos

• Haber leído IPsec Fundamentals y Meraki Fundamentos y Dashboard
• IP pública (o FQDN) del peer, alcanzable por UDP 500 y 4500
• Preshared key (la VPN no-Meraki no usa certificados)
• Subredes a proteger en cada lado, sin solaparse
• Fase 1 en modo main (el MX no acepta aggressive mode), con lifetimes por tiempo (no por volumen de datos) y modo túnel

Conceptos clave

Firmware: qué necesita qué

Función	Firmware mínimo
IKEv2	MX 15.12
DH grupo 14	MX 15.12
DH grupos 15 y 21	MX 19.2
Peer por FQDN (requiere IKEv2)	MX 18.1
Peer por IPv6	MX 18.2
Túneles primario y secundario	MX 19.1.4
Route-based dinámico (eBGP)	MX 19.1.4
Route-based estático	MX 26.2.x
IKEv2 policy-based	MX 15 hasta 26.1; Meraki lo está retirando desde 26.2, salvo que el peer lo pida explícitamente

Dirección de Meraki

El camino de futuro es IKEv2 route-based. Si estás diseñando algo nuevo, parte de ahí; el policy-based queda para equipos viejos que lo exigen.

Campos del peer

Campo	Qué es
Name	Nombre del peer
IKE version	IKEv1 o IKEv2
IPsec policies	Presets Default, AWS, Azure, o Custom
Public IP / Hostname	IP o FQDN del peer (FQDN requiere IKEv2 y MX ≥ 18.1)
Local ID	Solo IKEv2. Si lo dejas vacío, el MX usa la IP de su uplink, no necesariamente su IP pública
Remote ID	Identificador del peer (IP, FQDN o User FQDN); necesario si el peer está detrás de NAT
Private subnets	Subredes remotas detrás del peer (CIDR; 0.0.0.0/0 = ruta por defecto hacia el peer)
Preshared secret	PSK
Availability	Todas las redes o solo las de ciertas tags
Routing	Estático o Dinámico (BGP)

Parámetros de la política Custom

	Fase 1	Fase 2
Cifrado	AES-128/192/256, 3DES	AES-128/192/256, 3DES
Hash	MD5, SHA1, SHA256	MD5, SHA1, SHA256
DH / PFS	Grupos 1, 2, 5, 14, 15, 21	PFS off o grupos 1, 2, 5, 14, 15, 21
Lifetime	Segundos	Segundos

Defaults débiles

El artículo oficial de troubleshooting de Meraki (traducción japonesa) documenta la política Default: Fase 1 con 3DES, SHA1, DH 2 y lifetime de 28 800 s; Fase 2 con 3DES o AES, MD5 o SHA1, PFS desactivado y lifetime de 28 800 s. Para un túnel moderno usa Custom con AES-256, SHA256 y DH 14 y evita DES/3DES (Meraki los está retirando de la fase 2). Meraki no ofrece los grupos 19 ni 20; Palo Alto sí, pero con un MX solo puedes usar los que ambos tengan en común.

FIPS 140

Si el entorno exige FIPS, IKEv2 es obligatorio y SHA1/MD5 no son válidos (SHA256 sí).

IKEv1 vs IKEv2 (policy-based): cuántas SAs

	IKEv1	IKEv2
Traffic selector	Un par de subredes por SA	Un par agregado con todas las subredes locales y remotas
SAs con m subredes en Meraki y n en el peer	T = 2 × m × n	2
Ejemplo m=2, n=2	8 SAs	2 SAs

graph LR
    subgraph Meraki
    M1["10.1.0.0/24"]
    M2["10.1.1.0/24"]
    end
    subgraph Peer
    P1["192.168.1.0/24"]
    P2["192.168.2.0/24"]
    end
    M1 --- P1
    M1 --- P2
    M2 --- P1
    M2 --- P2

El problema de IKEv2 agregado

Algunos equipos (la documentación de Meraki cita Cisco ASA) aplican en IKEv2 el límite de IKEv1: solo aceptan un par de subredes por SA, y el resto del tráfico se descarta. Si te pasa, vuelve a IKEv1 o pasa a route-based. 🔎 Verificar cómo se comporta tu versión de PAN-OS con el selector agregado de Meraki.

Policy-based vs route-based

	Policy-based	Route-based
Qué decide el tráfico	Traffic selectors (subredes configuradas)	La tabla de rutas (estáticas o BGP) con interfaces de túnel virtuales (VTI)
Cambiar subredes	Hay que tocar ambos lados	Solo rutas
Auto VPN → peer	No funciona (el tráfico que viene de Auto VPN no se enruta por el túnel)	Sí
Firmware	Cualquiera (IKEv1) o IKEv2 hasta 26.1	Dinámico: ≥ 19.1.4. Estático: ≥ 26.2

Selectores 0.0.0.0/0

En route-based los selectores son 0.0.0.0/0 ↔ 0.0.0.0/0, pero eso no manda todo por el túnel: lo que entra lo deciden las rutas. Si el peer es policy-based y no acepta selectores amplios, los health checks pueden fallar y Meraki marca las rutas como “malas”; en ese caso los selectores del peer deben cubrir todo el tráfico esperado.

Alta disponibilidad y failover

• Uplink: si el primario falla, el túnel se mueve al secundario. En el peer se configura como backup la IP pública del uplink secundario del MX.
• Los túneles corren solo por el uplink activo, salvo que configures Multi-Uplink IPsec VPN.
• Si anuncias 0.0.0.0/0 por el túnel y este cae, el tráfico no pasa solo al WAN; hay que usar health checks de la ruta.

Túneles primario y secundario: qué es y qué no es

Según la documentación oficial de Meraki, la función está diseñada para peers externos tipo SASE/SSE, no se soporta entre dos MX y no está soportada en peers con BGP sobre IPsec.

• Requiere MX ≥ 19.1.4 e IKEv2.
• Usa health checks de capa 7: solo uno por par de túneles y solo en túneles con ruta estática.
• Orden: primario si está arriba; si no, secundario; si ambos caen, tráfico directo a Internet (DIA) solo si lo activaste (desactivado por defecto). El failback es preemptivo: el tráfico vuelve al primario cuando se recupera.
• Los eventos se registran en la categoría Non-Meraki VPN Healthcheck.
• No es un diseño de alta disponibilidad para un Palo Alto con dos ISP: para eso el peer debe soportar la IP de backup (la IP pública del uplink secundario del MX).

Qué debe coincidir con el Palo Alto

Parámetro	Meraki	Palo Alto
IKE version	IKE version	IKE Gateway → Version
Cifrado / hash / DH (F1)	Phase 1 (Custom)	IKE Crypto Profile
Cifrado / hash / PFS (F2)	Phase 2 (Custom)	IPsec Crypto Profile
PSK	Preshared secret	Pre-shared Key
IP del peer	Public IP	Peer Address
Local ID del MX	Local ID (IKEv2) o IP de uplink	Peer Identification
Remote ID	Remote ID	Local Identification
Redes protegidas (policy-based)	Private subnets + subredes de la red	Proxy IDs
Lifetimes	Segundos (por tiempo, no por datos)	Iguálalos a mano. Los defaults difieren (PAN-OS: IKE 8 h, IPsec 1 h; Meraki: 28 800 s en ambas fases). En IKEv2 cada extremo aplica su propio lifetime (RFC 7296 §2.4 y §2.8); Meraki documenta que un lifetime de fase 2 distinto es causa de caídas periódicas

MTU y MSS

Dato	Valor (documentación oficial de Meraki)
Sobrecarga en IPsec no-Meraki	hasta 100 bytes
Sobrecarga en Auto VPN	hasta 69 bytes (VRF suma 8; SGT suma 8; con ambos, 12 en total sobre lo estándar)
MTU de WAN y LAN del MX	1500 por defecto; no soporta jumbo; PPPoE máximo 1492
Cambiar el MTU de VPN no-Meraki	Requiere contactar a soporte de Meraki y MX ≥ 19.1.12 (o ≥ 19.2.4 en esa rama)

MSS en peers no-Meraki

Los registros de cambios de firmware citados en la comunidad de Meraki incluyen la corrección de que el MX no aplicaba el TCP MSS clamping al tráfico por peers no-Meraki: una entrada en MX 19.1.11 (id MX-2492, que un usuario indica que luego se retiró de las notas) y otra en MX 19.2.2. No hay notas oficiales que lo confirmen; comprueba en las tuyas que tu versión las incluye. El PA sí ajusta el MSS en los túneles IPsec (ver MTU y MSS en túneles IPsec (PA y Meraki)).

Subredes solapadas

• El Dashboard valida que las subredes remotas de un peer no-Meraki no se solapen con rutas locales, estáticas o de Auto VPN; la API no hace esa validación y puede dejar la configuración bloqueada para editar desde el Dashboard (ver Troubleshooting VPN Meraki).
• Si dos sitios usan la misma subred existe VPN subnet translation (MX 26.1.2+). Detalle en NAT sobre VPN con subredes solapadas (PA y Meraki).

Detección de caída (DPD)

• IKEv1: depende de DPD (RFC 3706), que solo envía sondas cuando hay inactividad.
• IKEv2: la detección de vida es parte del protocolo (RFC 7296 §2.4). En la comunidad de Meraki se afirma que el MX solo envía DPD cuando no cruza tráfico; no hay documentación oficial de los tiempos. 🔎 Verificar en el log de tu túnel.
• No existe un idle timeout configurable en peers no-Meraki: el túnel se renueva por lifetime.
• Si necesitas detección rápida, usa BGP con timers adecuados o monitorea desde el PA (ver BGP sobre IPsec PA a Meraki).

Configuración (Ejemplo)

1. Crear el peer

Security & SD-WAN → Configure → Site-to-site VPN → Organization-wide settings → Non-Meraki VPN peers → Add a peer. 🔎 Verificar los nombres en tu versión.

1. Name, IKE version e IPsec policies (Custom con AES-256 / SHA256 / DH 14).
2. Public IP del peer y, con IKEv2, Local ID y Remote ID fijos.
3. Private subnets del peer y Preshared secret.
4. Availability: la red del MX o sus tags.
5. Routing: estático, o dinámico con BGP (ver BGP sobre IPsec en Meraki).
6. Guardar (puede reiniciar túneles).

2. Subredes locales

En la red del MX, Local networks: VPN mode = Enabled en las subredes que deben pasar por el túnel.

3. Iniciar y probar

Un túnel IPsec no sube hasta que hay tráfico “interesante”: haz ping a una IP de la subred remota desde un host detrás del MX. Genera ese tráfico desde un cliente detrás del equipo, no desde el propio MX (sobre todo en Passthrough/Concentrator; 🔎 Verificar).

4. Probar el MTU

1472 bytes de datos + 28 de cabeceras = 1500, con el bit DF activo:

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

Si responde “necesita fragmentación”, baja el tamaño hasta que funcione: ese valor + 28 es tu MTU útil.

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
Security & SD-WAN → Monitor → VPN Status (red) u Organization → Monitor → VPN Status	El peer con Status, Name, Public IP y Subnets en verde	Troubleshooting VPN Meraki
Network-wide → Monitor → Event log (All IPsec VPN)	Fase 1 y fase 2 establecidas	Revisa el mensaje en Troubleshooting VPN Meraki
show vpn ike-sa / show vpn ipsec-sa en el Palo Alto	IKE SA e IPsec SA activas	Troubleshooting IPsec PA a Meraki
Ping DF de 1472 bytes a través del túnel	Responde o indica el tamaño máximo	Ajusta MTU/MSS

Limitaciones de VPN status

Para peers no-Meraki el estado solo indica si el peer está alcanzable (no se recogen uso ni latencia), y la página no muestra peers cuando el MX principal conmuta al MX spare en HA.

Errores comunes

La fase 1 no sube

• Causa: PSK o política distintas, UDP 500/4500 bloqueado o IP incorrecta.
• Revisa: Event log y la configuración del otro extremo.
• Solución: iguala parámetros y abre los puertos.

Fase 1 arriba, fase 2 falla

• Causa: en policy-based, subredes distintas entre ambos lados (incluida la máscara).
• Solución: deja Private subnets y subredes locales en espejo con el otro lado.

Se cae periódicamente

• Causa: lifetimes de fase 2 distintos, o un peer que no acepta el selector agregado.
• Solución: iguala lifetimes; pasa a IKEv1 o a route-based.

Cambié algo y todos los túneles se reiniciaron

• Causa: los cambios de VPN reinician túneles.
• Solución: haz los cambios en ventana de mantenimiento.

Fuentes

• IPsec VPN Configuration Settings
• Policy and Route-based IPsec VPNs compared
• Primary and Secondary IPsec VPN Tunnels
• Troubleshooting MTU Issues
• VPN Status Page
• Using Site-to-site VPN Translation
• Troubleshooting Non-Meraki Site-to-site VPN Peers (traducción japonesa, defaults de la política)
• RFC 7296 (IKEv2) y RFC 3706 (DPD)