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/24para el lado Palo Alto y172.20.50.0/24para 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 real | Se ve en el túnel como |
|---|---|
LAN Palo Alto 10.10.0.0/24 | 172.20.10.0/24 |
LAN Meraki 10.10.0.0/24 | 172.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ámetro | Palo Alto | Meraki |
|---|---|---|
| Red que se anuncia por el túnel | Proxy 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 alcanza | Ruta 172.20.50.0/24 → tunnel.X | Private subnets / rutas con 172.20.10.0/24 |
| Reglas de firewall | Direcciones 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
- 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/24elige VPN on with translation y la subred traducida172.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.
- En el peer, Private subnets =
172.20.10.0/24. - Verifica que las subredes anunciadas al peer son las traducidas.
2. Palo Alto
- NAT estático bidireccional: Source NAT de
insideavpn(origen10.10.0.0/24, destino172.20.50.0/24) hacia172.20.10.0/24, con la traducción inversa para el tráfico entrante (ver Source NAT y Destination NAT). - Proxy IDs (si el túnel es policy-based): local
172.20.10.0/24, remoto172.20.50.0/24. La documentación de Palo Alto indica que, con NAT, el Proxy ID debe llevar la red posterior al NAT. - Ruta:
172.20.50.0/24haciatunnel.X, Next Hop None. - Security Policy (direcciones previas al NAT, zonas posteriores):
- Saliente
inside→vpn: origen10.10.0.0/24, destino172.20.50.0/24. - Entrante
vpn→inside: origen172.20.50.0/24, destino172.20.10.0/24(la dirección traducida que usa el otro lado, antes del NAT de destino).
- Saliente
Verificación
| Comando o lugar | Qué debes ver | Si no lo ves |
|---|---|---|
show vpn ipsec-sa | SA activa con encap/decap creciendo | Proxy IDs con direcciones previas al NAT |
Ping desde un host 10.10.0.10 (PA) a 172.20.50.10 | Responde el host 10.10.0.10 del lado Meraki | Revisa NAT y rutas de ambos lados |
| VPN status del MX | La subred traducida, no la original | Revisa VPN on with translation |
show session all filter destination 172.20.50.10 | La sesión con el NAT esperado | Revisa 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.