NAT sobre VPN con subredes solapadas (PA y Meraki)

Contenido complementario

Este tema no está en las notas de mis cursos; está armado con la documentación oficial de Palo Alto y de Meraki (consultadas en octubre de 2026). Direcciones 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

Es común que dos sitios usen la misma red (por ejemplo 10.10.0.0/24), sobre todo después de una adquisición. Un túnel no puede enrutar hacia una red que también es local, así que hay que traducir las redes a rangos únicos. La regla de Palo Alto es que ambos extremos traduzcan (o uno renumere) y que los Proxy IDs usen las direcciones posteriores al NAT. En Meraki, la traducción de subredes VPN está disponible desde MX 26.1.2; la documentación indica que a los peers IPsec no-Meraki se anuncian las subredes traducidas, pero conviene probarlo. Esta nota arma el diseño y lista las trampas.

Requisitos previos

  • Haber leído Source NAT, Destination NAT, Packet Flow y Sessions y Non-Meraki VPN Peers (IPsec)
  • Un rango libre para las redes traducidas (ejemplo: 172.20.10.0/24 para el lado Palo Alto y 172.20.50.0/24 para el lado Meraki)
  • Firmware del MX ≥ 26.1.2 para la traducción hacia peers no-Meraki
  • Aceptar que las aplicaciones que incrustan IP en el payload pueden fallar con NAT

Conceptos clave

El problema

graph LR
    A["LAN PA<br/>10.10.0.0/24"] --- PA["Palo Alto"]
    PA == "IPsec" === MX["Meraki MX"]
    MX --- B["LAN Meraki<br/>10.10.0.0/24"]

El PA ve la red remota como 10.10.0.0/24, que es también la suya: el tráfico “remoto” se queda en local. Lo mismo le pasa al MX.

Diseño con traducción en ambos lados

Red realSe ve en el túnel como
LAN Palo Alto 10.10.0.0/24172.20.10.0/24
LAN Meraki 10.10.0.0/24172.20.50.0/24
graph LR
    A["10.10.0.0/24<br/>(real)"] --- PA["Palo Alto<br/>traduce a 172.20.10.0/24"]
    PA == "IPsec" === MX["MX<br/>traduce a 172.20.50.0/24"]
    MX --- B["10.10.0.0/24<br/>(real)"]

Qué debe coincidir

ParámetroPalo AltoMeraki
Red que se anuncia por el túnelProxy IDs / rutas con la red traducida (172.20.10.0/24)Traducción por subred local; al peer se anuncia la subred traducida
Red remota que se alcanzaRuta 172.20.50.0/24 → tunnel.XPrivate subnets / rutas con 172.20.10.0/24
Reglas de firewallDirecciones previas al NAT y zonas posteriores (ver Packet Flow y Sessions)En el MX que traduce, la subred sin traducir; en los MX remotos, la traducida

Configuración (Ejemplo)

1. Meraki

  1. En Security & SD-WAN → Configure → Site-to-site VPN pon VPN subnet translation = Enabled; aparece la columna VPN subnet en las redes locales. Para 10.10.0.0/24 elige VPN on with translation y la subred traducida 172.20.50.0/24 (1:1, mismo tamaño). Hazlo en cada red que permita VPN con esa subred duplicada.
    • También existe 1:M (a un /32 o una subred menor; es con estado y descarta el tráfico entrante no solicitado) y, desde Wired 26.1.2, varias subredes locales hacia el mismo destino traducido (M:M).
    • Con BGP, evita 1:M/M:M en la VLAN de mayor número: puede afectar al tráfico generado por el MX. La solución documentada es una VLAN pequeña ficticia (por ejemplo /30) con un ID mayor y habilitada para VPN.
    • El artículo describe sobre todo Auto VPN; para peers IPsec no-Meraki indica que se anuncian las subredes traducidas. 🔎 Verificar con un peer de prueba.
  2. En el peer, Private subnets = 172.20.10.0/24.
  3. Verifica que las subredes anunciadas al peer son las traducidas.

2. Palo Alto

  1. NAT estático bidireccional: Source NAT de inside a vpn (origen 10.10.0.0/24, destino 172.20.50.0/24) hacia 172.20.10.0/24, con la traducción inversa para el tráfico entrante (ver Source NAT y Destination NAT).
  2. Proxy IDs (si el túnel es policy-based): local 172.20.10.0/24, remoto 172.20.50.0/24. La documentación de Palo Alto indica que, con NAT, el Proxy ID debe llevar la red posterior al NAT.
  3. Ruta: 172.20.50.0/24 hacia tunnel.X, Next Hop None.
  4. Security Policy (direcciones previas al NAT, zonas posteriores):
    • Saliente inside → vpn: origen 10.10.0.0/24, destino 172.20.50.0/24.
    • Entrante vpn → inside: origen 172.20.50.0/24, destino 172.20.10.0/24 (la dirección traducida que usa el otro lado, antes del NAT de destino).

Verificación

Comando o lugarQué debes verSi no lo ves
show vpn ipsec-saSA activa con encap/decap creciendoProxy IDs con direcciones previas al NAT
Ping desde un host 10.10.0.10 (PA) a 172.20.50.10Responde el host 10.10.0.10 del lado MerakiRevisa NAT y rutas de ambos lados
VPN status del MXLa subred traducida, no la originalRevisa VPN on with translation
show session all filter destination 172.20.50.10La sesión con el NAT esperadoRevisa la regla de NAT y su orden

Errores comunes

Solo traduje un lado

  • Causa: el otro extremo sigue viendo una red que es también local.
  • Solución: la documentación de Palo Alto es explícita: ambos extremos deben traducir (o uno cambia de subred).

El Proxy ID usa las IP originales

  • Causa: los Proxy IDs se escribieron con las direcciones previas al NAT.
  • Solución: usa las direcciones posteriores al NAT; si no, la Fase 2 falla.

Las reglas de seguridad no se aplican

  • Causa: la regla usa las direcciones o zonas equivocadas.
  • Solución: direcciones previas al NAT, zonas posteriores al NAT.

Funciona por IP pero fallan algunas aplicaciones

  • Causa: protocolos que llevan IP dentro del payload (algunos de voz, bases de datos antiguas) se rompen con NAT.
  • Solución: usa un ALG si existe o renumera.

Configuré todo por API y el Dashboard ya no me deja editar

  • Causa: la API de peers no valida solapamientos.
  • Solución: corrige el solapamiento a mano y usa el Dashboard para cambios con subredes.

Mi MX es anterior a 26.1.2

  • Causa: la traducción hacia peers no-Meraki no está documentada en versiones anteriores.
  • Solución: asume que no existe; traduce con un equipo externo o renumera.

Fuentes