Dos oficinas en 192.168.0.0/24: conéctalas sin renumerar

octubre 15, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 4

¿Te fue útil?

Finalmente obtienes aprobación para conectar la Oficina A y la Oficina B. Luego descubres que ambas LAN usan 192.168.0.0/24, porque por supuesto así es. Todos piden “solo una VPN”, pero el enrutamiento no hace magia: cuando ambos lados reclaman las mismas direcciones, los paquetes no saben dónde está “192.168.0.50”.

Esta es la realidad cuando la red de oficina pequeña se encuentra con conectividad de verdad. La buena noticia: puedes conectarlas sin renumerar. La mala noticia: debes ser explícito sobre qué tipo de “sin renumerar” quieres decir, porque algunas soluciones son cinta aislante y otras son un soporte adecuado.

Qué falla realmente cuando las subredes se solapan

Si ambas oficinas usan 192.168.0.0/24, no tienes “un problema de enrutamiento”, tienes un problema de identidad. Las direcciones IP deben identificar endpoints. Cuando dos endpoints comparten la misma identidad, las cosas se complican rápido.

Por qué falla una VPN sitio-a-sitio simple

Los diseños clásicos de VPN sitio-a-sitio asumen esto: “El tráfico hacia la subred X entra en el túnel.” Con solapamiento, ambos sitios creen que son la subred X. Entonces:

Un host en la Oficina A envía a 192.168.0.50. Su SO decide “eso está en mi LAN local,” hace ARP por ella y nunca la enruta a la VPN.
Si fuerzas que vaya al túnel (enrutamiento por políticas, reglas de firewall), el extremo remoto recibe un paquete con una dirección fuente que también parece local, y las respuestas se enrutan mal.
Incluso si “de alguna forma” lo haces funcionar, todos los servicios que incrustan IPs en ACLs, logs o configuraciones se volverán ambiguos y dolorosos.

Broma #1: Las subredes superpuestas son como tener dos compañeros de trabajo llamados “Alex” en la misma rotación de guardia. Puedes hacerlo funcionar, pero tus alertas se convertirán en arte performativo.

Las tres colisiones que encontrarás

Colisión en la decisión de reenvío: los hosts tratan destinos de la misma subred como on-link. Hacen ARP, no enrutan.
Colisión en la ruta de retorno: las respuestas van al lugar equivocado porque la fuente/destino parecen locales en ambos extremos.
Colisión de estado: firewalls/tablas NAT no pueden distinguir de forma fiable flujos que comparten la misma semántica de 5-tupla entre sitios si no traduces algo.

La solución siempre implica hacer el tráfico inequívoco. Lo logras traduciendo direcciones, aislando tablas de enrutamiento, o subiendo la conectividad a una capa superior (overlay/proxy).

Hechos interesantes y contexto histórico

Un poco de perspectiva ayuda, porque este lío no es nuevo: es la consecuencia predecible de direcciones privadas y décadas de “simplemente enviarlo”. Aquí hay algunos datos concretos que explican por qué las subredes superpuestas son tan comunes:

RFC 1918 (1996) popularizó el espacio de direcciones privado (10/8, 172.16/12, 192.168/16), facilitando que todos seleccionen las mismas subredes de forma independiente.
192.168.0.0/24 se convirtió en “la LAN por defecto” principalmente porque routers de consumo tempranos la traían preconfigurada, y la inercia es poderosa.
NAT se trató originalmente como un parche pragmático para conservar IPv4; después se volvió un placebo de seguridad y una dependencia arquitectural.
IPsec se diseñó para seguridad red-a-red, pero no para colisiones de identidad; NAT traversal (NAT-T) resolvió otro problema (NAT en el camino), no las LAN superpuestas.
Appliances VPN tempranos solían usar túneles “basados en políticas” (dominios de cifrado). Ese modelo colapsa bajo solapamiento a menos que añadas traducción.
VRFs (virtual routing and forwarding) nacieron en tecnología de carriers para mantener rutas de clientes separadas en infraestructura compartida; hoy son la forma más limpia de mantener redes superpuestas distintas.
DNS de split-horizon existe desde antes de la nube y sigue siendo una herramienta práctica cuando la alcanzabilidad IP es confusa pero los nombres se pueden uniformar.
IPv6 debía acabar con esto. En cambio, muchas organizaciones ejecutan dual-stack parcialmente, mantienen LANs IPv4 privadas y aún así se solapan.

Árbol de decisión: qué deberías hacer (y qué te arrepentirás)

“Sin renumerar” puede significar varias cosas. Sé explícito antes de tocar un firewall:

Requisito estricto: los endpoints conservan sus IP actuales y aún así se comunican directamente por IP.
Requisito flexible: los endpoints mantienen sus IPs, pero pueden acceder a servicios remotos mediante nuevas IPs, nombres DNS o un proxy.
Requisito temporal: conservar IPs por ahora, conectar sedes y luego programar renumeración más adelante.

Mi orientación, con opinión:

Si necesitas alcance L3 amplio entre la mayoría de hosts en ambos lados: usa NAT entre sitios (también llamado traducción de red, NAT-on-a-stick, netmap) o VRFs si trabajas con routers serios.
Si solo unos pocos servicios deben ser accesibles (servidor de archivos, gateway RDP, app): usa proxies a nivel de aplicación o publica servicios detrás de un reverse proxy/bastión.
Si conectas usuarios/dispositivos, no redes: usa un overlay con su propio espacio de direcciones y modelo de identidad.
No estires L2 entre oficinas para “hacer una sola LAN.” A menos que tu trabajo incluya escribir postmortems por deporte.

Y una cita para mantener la honestidad. Aquí una idea parafraseada atribuida a menudo a Peter Drucker: “Si no puedes medirlo, no puedes mejorarlo.” En términos de redes: si no puedes observarlo, no puedes depurarlo.

Patrones de solución que funcionan en producción

Patrón 1: NAT / traducción de red (el ganador habitual)

Esta es la solución trabajadora. Mantienes ambas oficinas en 192.168.0.0/24, pero introduces una subred traducida para un lado (o ambos) cuando el tráfico cruza el enlace entre sedes.

Cómo se ve

LAN Oficina A: 192.168.0.0/24
LAN Oficina B: 192.168.0.0/24
Traducción para B vista desde A: 10.200.0.0/24 (ejemplo)

Cuando un host A quiere alcanzar un host B, apunta a 10.200.0.x. El dispositivo de borde traduce 10.200.0.x a 192.168.0.x a través del túnel, y también traduce la fuente para que el tráfico de retorno vuelva correctamente.

Dos variantes: traducción unidireccional vs bidireccional

Unidireccional (preferible cuando es posible): solo Oficina A necesita iniciar. A ve B como 10.200.0.0/24. B puede no necesitar saber que A existe.
Bidireccional: A ve B como 10.200.0.0/24 y B ve A como 10.201.0.0/24. Es más trabajo pero simétrico y más claro para ACLs.

Pros

Funciona con enrutamiento normal; sin cambios en endpoints si usas DNS y/o acceso por puerto.
Compatible con túneles basados en rutas IPsec, WireGuard, GRE, etc.
Radio de blast limitado: la traducción solo aplica entre sedes.

Contras

Algunas aplicaciones fallan si incrustan IPs en el payload (SIP, algunas licencias antiguas, ciertos casos de SMB).
Complejidad operativa: depurar NAT requiere disciplina y logging.
Equipos de seguridad a veces rechazan “ocultar” direcciones—aunque no es ocultación, es remapeo.

Qué evitar: SNAT ad-hoc “porque funciona.” Usa mapeo determinista y documentado (netmap o 1:1 cuando sea posible). NAT de sobrecarga por puertos aleatoria a través de un túnel es un futuro informe de incidentes.

Patrón 2: Proxies de aplicación (aburrido, efectivo, limitado)

Si el objetivo real es “los usuarios de la Oficina A necesitan la app de contabilidad en la Oficina B” y solo eso, no construyas una fusión de red. Publica la app correctamente.

Ejemplos:

Reverse proxy para apps HTTP(S) (Nginx/HAProxy) en una DMZ o red de servicios.
Gateway RDP / bastión para unos pocos servidores Windows.
Acceso a archivos mediante un servicio dedicado (SFTP/HTTPS) en lugar de SMB completo entre sedes.

Esto evita el solapamiento de subredes por completo: los clientes se conectan a una IP/nombre accesible, no a hosts internos aleatorios.

Patrón 3: Redes overlay (WireGuard, “Zero Trust”, malla)

Los overlays asignan su propio espacio de direcciones (a menudo 100.64.0.0/10 o un 10.x dedicado), y enrutan tráfico basado en identidad y política en vez de “¿está en mi LAN?”

Bueno cuando:

Necesitas conectividad dispositivo-a-dispositivo, no subred-a-subred.
No controlas claramente los routers de borde (CPE gestionado por ISP, firewalls de terceros, política).
Quieres despliegue gradual: añadir endpoints con el tiempo.

Pero: un overlay no resuelve automáticamente “quiero que cada impresora vea a cada portátil.” Resuelve “endpoints específicos pueden alcanzar endpoints específicos,” que suele ser lo que realmente se quiere cuando dejamos de pedir “una VPN”.

Patrón 4: VRFs y segmentación L3 (nivel empresarial)

Si tienes routers/switches que soportan VRFs (o instancias de firewall/VDOMs), puedes mantener ambas redes 192.168.0.0/24 separadas ubicándolas en tablas de enrutamiento distintas. Luego filtras rutas o haces NAT entre VRFs en puntos controlados.

Este es el modelo más limpio cuando integras muchas sedes con colisiones (ocurre en adquisiciones). También es el que más puede implementarse mal si tu equipo no ha gestionado VRFs en producción antes. La telemetría y observabilidad deben existir: rutas por VRF, políticas de firewall por VRF y diagramas claros.

Patrón 5: Bridging/estiramiento L2 (la sección “no lo hagas”)

Alguien propondrá “simplemente puentea las redes” para que sea una sola LAN. Eso significa extender dominios de broadcast (ARP, DHCP, multicast) a través de un enlace WAN. El problema del solapamiento no desaparece; se transforma en un problema de caos.

Broma #2: Estirar capa 2 entre oficinas es como enchufar tu centro de datos a una regleta de la tienda de la esquina. Técnicamente entrega electricidad.

Un WAN no es una LAN. Manténlo enrutado. Si debes usar L2 por un requisito legado de nicho, hazlo con contención explícita (EVPN/VXLAN, control de tormentas, DHCP guard) y un plan de reversión probado mientras estás bien cafeinado.

Guía de diagnóstico rápido

Cuando falla la conectividad entre subredes superpuestas, la gente pierde horas mirando el estado del túnel. No lo hagas. Tu cuello de botella suele ser una de tres cosas: (1) decisión de enrutamiento del host, (2) desajuste en la política de traducción, (3) ruta de retorno/estado de ACL. Aquí el orden que encuentra la verdad rápido.

1) Confirma qué intenta hacer el host (on-link vs enrutado)

Desde un cliente en la Oficina A, comprueba la ruta al IP (o nombre) objetivo que está usando.
Si cree que el destino es “link-local” (mismo /24), hará ARP y nunca llegará al gateway.

2) Confirma que el dispositivo de borde ve paquetes y aplica el NAT previsto

Revisa contadores de hit de firewall/NAT.
Usa captura de paquetes en interfaces internas y del túnel para demostrar la traducción.

3) Confirma que la ruta de retorno es simétrica

Busca respuestas saliendo por la interfaz equivocada.
Revisa entradas de conntrack/tabla de estado y NAT inverso.

4) Solo entonces sospecha del túnel o MTU

La mayoría de los casos “VPN está arriba pero nada funciona” son problemas de política/NAT/ruta, no de cripto.
Si ves conectividad parcial (ICMP funciona, TCP se atasca), entonces revisa MTU/MSS y fragmentación.

Tareas prácticas: comandos, salidas, decisiones (12+)

Las siguientes tareas asumen gateways/hosts basados en Linux para demostrar porque los comandos son explícitos e inspeccionables. Los mismos conceptos aplican a firewalls y routers, pero con una interfaz distinta.

Tarea 1: Identificar la subred local y el gateway en un cliente

cr0x@server:~$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.0.23/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever

Qué significa: el host está en 192.168.0.0/24. Cualquier destino 192.168.0.x parece “local” al kernel.

Decisión: si necesitas que este host alcance un host remoto también numerado 192.168.0.x, debes usar una IP de destino distinta (traducida/overlay/proxy). No intentes enrutar 192.168.0.0/24 al túnel desde este host; nunca elegirá la ruta.

Tarea 2: Probar que el host hará ARP en lugar de enrutar

cr0x@server:~$ ip route get 192.168.0.50
192.168.0.50 dev eth0 src 192.168.0.23 uid 1000
    cache

Qué significa: está on-link (dev eth0), no vía gateway.

Decisión: no uses 192.168.0.50 como la dirección “remota” desde esta LAN. Usa un prefijo traducido como 10.200.0.50 (con NAT en el borde), o un nombre DNS que resuelva a esa dirección traducida.

Tarea 3: Revisar la tabla ARP tras un ping fallido

cr0x@server:~$ ping -c 1 192.168.0.50
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.

--- 192.168.0.50 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
cr0x@server:~$ ip neigh show to 192.168.0.50
192.168.0.50 dev eth0 INCOMPLETE

Qué significa: el host hizo ARP en la LAN local, no obtuvo respuesta y nunca intentó el gateway VPN.

Decisión: cualquier “arreglo” que se centre en el túnel es prematuro. El endpoint no está enviando tráfico al túnel.

Tarea 4: Validar que el prefijo traducido es enrutable vía el gateway

cr0x@server:~$ ip route get 10.200.0.50
10.200.0.50 via 192.168.0.1 dev eth0 src 192.168.0.23 uid 1000
    cache

Qué significa: el tráfico a 10.200.0.0/24 irá al gateway (192.168.0.1), que puede entonces NAT/tunelizarlo.

Decisión: procede con NAT de borde y política de túnel para 10.200.0.0/24 como “remoto B.” Si esta ruta falta, añádela vía opción DHCP 121/rutas estáticas sin clase, o anúnciala mediante tu protocolo de enrutamiento interno.

Tarea 5: En el gateway, confirmar que el reenvío IP está habilitado

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Qué significa: el gateway enrutará paquetes entre interfaces.

Decisión: si esto es 0, nada más importa. Habilítalo y asegura que persista. Si es 1, sigue a rutas y reglas NAT.

Tarea 6: Verifica rutas en el gateway para la subred traducida y el túnel

cr0x@server:~$ ip route show
default via 203.0.113.1 dev wan0
10.200.0.0/24 dev wg0 scope link
192.168.0.0/24 dev lan0 scope link src 192.168.0.1

Qué significa: el gateway cree que 10.200.0.0/24 es alcanzable vía la interfaz de túnel (wg0).

Decisión: si 10.200.0.0/24 falta o apunta a otro sitio, arregla el enrutamiento primero. Las reglas NAT no rescatarán un enrutamiento malo.

Tarea 7: Verificar AllowedIPs de WireGuard (punto común de fallo)

cr0x@server:~$ wg show
interface: wg0
  public key: 6YcD...redacted...
  listening port: 51820

peer: p9nS...redacted...
  endpoint: 198.51.100.10:51820
  allowed ips: 10.200.0.0/24
  latest handshake: 41 seconds ago
  transfer: 120.33 KiB received, 98.11 KiB sent

Qué significa: el peer está arriba y el túnel aceptará/enrutará 10.200.0.0/24.

Decisión: si AllowedIPs no incluye tu prefijo traducido, el kernel descartará o enrutar mal el tráfico. Arregla AllowedIPs y vuelve a probar.

Tarea 8: Inspeccionar reglas NAT (nftables) y confirmar contadores

cr0x@server:~$ sudo nft list ruleset
table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "lan0" ip daddr 10.200.0.0/24 dnat to 192.168.0.0/24
  }
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wg0" ip saddr 192.168.0.0/24 snat to 10.201.0.1
  }
}

Qué significa: entrada desde LAN con destino a 10.200.0.0/24 se DNAT a 192.168.0.0/24. Salida al túnel se SNATea para que el lado remoto pueda devolver tráfico a una fuente única.

Decisión: si haces solo DNAT sin el SNAT correspondiente (o viceversa), las respuestas probablemente se perderán en la LAN equivocada. Usa traducción simétrica a menos que tengas un diseño asimétrico probado.

Tarea 9: Usar conntrack para confirmar estado y traducción

cr0x@server:~$ sudo conntrack -L | head
tcp      6 431999 ESTABLISHED src=192.168.0.23 dst=10.200.0.50 sport=51544 dport=445 src=192.168.0.50 dst=10.201.0.1 sport=445 dport=51544 [ASSURED] mark=0 use=1

Qué significa: conntrack muestra el flujo original (192.168.0.23 -> 10.200.0.50) y la tupla traducida hacia el extremo remoto (... dst=10.201.0.1 como fuente SNAT).

Decisión: si el estado nunca aparece, el tráfico no llega al gateway o está bloqueado por política antes del NAT. Si el estado aparece pero no hay tráfico de retorno, depura la ruta/NAT del lado remoto y la política del túnel.

Tarea 10: Captura de paquetes en interfaces LAN y túnel para demostrar NAT

cr0x@server:~$ sudo tcpdump -ni lan0 host 192.168.0.23 and host 10.200.0.50
IP 192.168.0.23.51544 > 10.200.0.50.445: Flags [S], seq 123456, win 64240, length 0
cr0x@server:~$ sudo tcpdump -ni wg0 host 192.168.0.50 and port 445
IP 10.201.0.1.51544 > 192.168.0.50.445: Flags [S], seq 123456, win 64240, length 0

Qué significa: ves el destino original en LAN (10.200.0.50) y el paquete post-NAT en el túnel (dst 192.168.0.50, src 10.201.0.1).

Decisión: si la captura en LAN muestra tráfico pero en el túnel no, NAT o enrutamiento está mal en el gateway. Si el túnel muestra salida pero no respuestas entrantes, el lado remoto no está devolviendo (política, enrutamiento o NAT asimétrico).

Tarea 11: Revisar filtro de ruta inversa (rp_filter) en gateways Linux

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.wg0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.wg0.rp_filter = 1

Qué significa: el filtrado estricto de ruta inversa puede descartar paquetes que llegan por una interfaz que no coincide con la ruta de retorno del kernel. NAT más túneles más múltiples interfaces es exactamente donde esto golpea.

Decisión: para gateways que hacen NAT sobre túneles, pon rp_filter en modo laxo (2) o desactívalo por interfaz, pero solo con entendimiento y política de firewall compensatoria. Si ves tráfico unidireccional misterioso, este es un sospechoso principal.

Tarea 12: Probar problemas de MTU/MSS (clásico “VPN está arriba pero TCP se queda”)

cr0x@server:~$ ping -M do -s 1380 -c 2 10.200.0.50
PING 10.200.0.50 (10.200.0.50) 1380(1408) bytes of data.
1388 bytes from 10.200.0.50: icmp_seq=1 ttl=63 time=22.1 ms
1388 bytes from 10.200.0.50: icmp_seq=2 ttl=63 time=21.7 ms

--- 10.200.0.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 21.7/21.9/22.1/0.2 ms

Qué significa: con DF activado, un payload de 1380 bytes funciona. Si esto falla mientras pings más pequeños tienen éxito, tienes un problema de MTU en el camino/túnel.

Decisión: ajusta MSS de TCP en el borde del túnel y/o reduce el MTU del túnel. No “arregles” desactivando PMTUD globalmente; así creas nuevos problemas.

Tarea 13: Verificar que las respuestas DNS coinciden con tu plan de traducción

cr0x@server:~$ dig +short fileserver.officeb.example
10.200.0.50

Qué significa: los clientes están apuntando a la dirección traducida, no a la ambigua dirección LAN real.

Decisión: si DNS devuelve 192.168.0.50 para un servicio remoto, los clientes harán ARP y fallarán. Arregla DNS (split-horizon o reenvío condicional) para que los nombres resuelvan a direcciones traducidas/overlay.

Tarea 14: Confirmar que la política de firewall no está descartando silenciosamente el tráfico traducido

cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "lan0" oifname "wg0" ip daddr 192.168.0.0/24 tcp dport { 22, 445, 3389 } accept
  }
}

Qué significa: la política por defecto es drop, y solo se permiten puertos específicos desde LAN hacia túnel hacia la LAN remota tras DNAT.

Decisión: si pretendías acceso amplio pero solo permitiste unos pocos puertos, verás fallos selectivos. Ajusta la política para que coincida con los requisitos. Y: mantenla ajustada. “Any-any entre sedes” es cómo el malware interno se vuelve un viajero frecuente.

Tres mini-historias corporativas

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana adquirió una más pequeña y necesitó “conectividad rápida” para sistemas financieros. Ambas oficinas estaban en 192.168.0.0/24, pero nadie lo notó porque el ticket decía “configurar VPN sitio-a-sitio, subredes estándar.” El equipo de red configuró un túnel IPsec basado en políticas con dominios de cifrado local y remoto ambos en 192.168.0.0/24. El túnel se levantó. El tablero quedó en verde. Todos se fueron a casa.

A la mañana siguiente, contabilidad no podía alcanzar nada. La primera suposición: “VPN caída.” No lo estaba. La segunda: “problema de DNS.” Tampoco. El problema real fue banal: los clientes en la Oficina A intentaban acceder a un servidor en la Oficina B por IP (192.168.0.40), y cada uno hacía ARP localmente. Helpdesk reportó “sin ruta al host” en máquinas Linux y “request timed out” en Windows. Ingenieros miraron SAs de IPsec y timers de rekey por dos horas.

El avance vino de una captura en un puerto de switch del cliente: solicitudes ARP por 192.168.0.40 repitiéndose como metrónomo. Sin participación del gateway. Sin tráfico VPN. El túnel era inocente.

Lo resolvieron desplegando NAT en el borde: Oficina B se volvió 10.200.0.0/24 vista desde Oficina A, y los nombres DNS para servicios de B resolvieron a esas IPs traducidas. El incidente terminó en silencio. El postmortem no fue “IPsec es difícil.” Fue “asumimos unicidad sin verificar.”

Mini-historia 2: La optimización que salió mal

Otra organización conectó dos sedes superpuestas con traducción y en su mayoría funcionó. Luego alguien intentó “optimizar latencia” añadiendo un segundo túnel sobre un ISP más barato y activando ECMP entre túneles. La meta fue balanceo de carga. La realidad fue conntrack y estado NAT rociado por dos caminos sin coordinación.

Algunos flujos llegaron por el túnel A, se NATearon, y las respuestas volvieron por el túnel B. Dependiendo del firewall, esas respuestas fueron o descartadas como estado inválido, o aceptadas y luego re-traducidas incorrectamente. Usuarios reportaron síntomas aleatorios: copias de archivos fallando al 37%, sesiones RDP congelándose, y apps web “cerrando sesión” a mitad de clic.

El equipo inicialmente culpó al ISP barato por pérdida de paquetes. Hubo algo de pérdida, sí. Pero el problema central fue el estado de traducción en dispositivos stateful sobre rutas asimétricas. Los túneles estaban sanos; la arquitectura no.

La solución no fue dramática: anclar flujos (routing por políticas o marcas de conexión) para que ambas direcciones de una conexión permanezcan en un túnel, o ejecutar activo/standby en lugar de ECMP para tráfico NAT stateful. “Optimización” se volvió “regresión de estabilidad” porque nadie preguntó si el sistema podía ser stateless. No podía.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía global tenía la costumbre: antes de cualquier cambio de conectividad inter-sede, producían una “Hoja de Identidad de Direcciones” de una página. Listaba cada subred relevante, rango de traducción, comportamiento DNS y quién lo poseía. Era aburrida. También previno un montón de outages.

Durante una mudanza de oficina, un contratista reconfiguró un router branch y accidentalmente cambió el pool DHCP de 192.168.1.0/24 a 192.168.0.0/24 porque “es lo que siempre usamos.” De la noche a la mañana impresoras y algunas estaciones tomaron leases nuevos. El diseño de traducción sitio-a-sitio ahora se solapó con la realidad local, y el primer reporte fue “servidor de archivos remoto caído.”

El ingeniero on-call sacó la Hoja de Identidad de Direcciones, vio que 192.168.0.0/24 estaba reservada para semánticas de traducción en esa región, y sospechó inmediatamente que la subred local había derivado. Un chequeo de logs DHCP lo confirmó. Revirtieron el scope DHCP, vaciaron unos leases, y el “corte VPN” se evaporó.

Sin heroísmos. Sin llamadas a vendor. Solo un documento aburrido y la disciplina para mantenerlo exacto. En operaciones, lo aburrido suele ser lo más sofisticado.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: “La VPN está arriba, pero no puedo hacer ping al 192.168.0.x remoto”

Causa raíz: el cliente trata 192.168.0.x como on-link y hace ARP local; el tráfico nunca entra al túnel.

Solución: no apuntes directamente a la subred remota solapada. Usa un prefijo traducido (p. ej. 10.200.0.0/24), una IP overlay o una dirección proxy. Ajusta DNS en consecuencia.

2) Síntoma: “Solo funciona en una dirección” (A puede alcanzar B, B no puede alcanzar A)

Causa raíz: traducción asimétrica o falta de emparejamiento SNAT/DNAT; el tráfico de retorno se enrutará localmente en el lado remoto.

Solución: implementa mapeo simétrico o asegúrate de que el lado remoto tenga una ruta de vuelta a la fuente traducida. Verifica entradas conntrack y capturas en ambos lados.

3) Síntoma: “Algunos puertos funcionan, SMB falla, RDP se reinicia”

Causa raíz: desajuste de política de firewall, módulos helper, o problemas MTU/MSS; a veces NAT hace hairpin inesperados.

Solución: confirma puertos permitidos en la política forward, prueba PMTUD con pings DF, ajusta MSS en el borde del túnel, y evita ALGs demasiado “inteligentes” salvo que los necesites.

4) Síntoma: “Funciona unos minutos, luego para hasta que reiniciemos el túnel”

Causa raíz: timeout de estado NAT, enrutamiento asimétrico, o ECMP sobre dispositivos stateful; a veces rekey cambia la ruta.

Solución: fuerza enrutamiento simétrico, aumenta timeouts relevantes si está justificado, y evita balanceo sin sincronización de estado.

5) Síntoma: “Solo unos pocos hosts pueden conectarse; otros no”

Causa raíz: solapamiento de nuevo a menor escala (rutas estáticas en algunos clientes, múltiples VLANs), IP duplicadas, o conflictos de scope DHCP.

Solución: inventario de direccionamiento. Verifica rutas de cliente y comportamiento ARP. Asegura scopes DHCP y confirma que los prefijos traducidos no se usan localmente.

6) Síntoma: “DNS resuelve, pero las conexiones van al equipo equivocado”

Causa raíz: split-horizon DNS mal configurado; el nombre interno resuelve a 192.168.0.x local en vez de a la IP traducida/overlay.

Solución: implementa reenvío condicional o views para que cada oficina reciba la respuesta correcta. Para servicios compartidos, prefiere nombres que resuelvan a direcciones inequívocas.

Listas de verificación / plan paso a paso

Plan paso a paso: conectar dos /24 superpuestos con NAT sobre un túnel

Elige prefijos de traducción que no existan en ningún otro sitio. No elijas otro “cute” por defecto como 192.168.1.0/24. Usa algo obviamente “virtual”, como 10.200.0.0/24 para Oficina B y 10.201.0.0/24 para Oficina A (vista desde B).
Decide si necesitas iniciación unidireccional o bidireccional. Si solo unos pocos servicios en B deben ser accedidos por A, la unidireccional puede bastar.
Elige el sustrato de conectividad: IPsec basado en rutas, WireGuard, GRE sobre IPsec, etc. Basado en rutas hace que NAT sea más fácil de razonar.
Añade rutas: en el gateway de Oficina A, enruta 10.200.0.0/24 al túnel. En el gateway de Oficina B, enruta 10.201.0.0/24 al túnel (si es bidireccional).
Implementa NAT determinista:
- DNAT 10.200.0.x a 192.168.0.x en el borde de Oficina B (o en el borde de A según diseño).
- SNATea fuentes a una fuente traducida que el lado remoto pueda devolver sin ambigüedad.
Actualiza DNS: haz que los servicios remotos resuelvan a IPs traducidas. Usa split-horizon si el mismo nombre debe resolver distinto por sitio.
Limita acceso con políticas de firewall: permite solo los puertos necesarios. Empieza restrictivo y amplía con intención.
Valida con capturas en tres puntos: LAN del cliente, lado LAN del gateway local, lado túnel del gateway.
Endurezce MTU/MSS antes de que los usuarios se quejen. Ajusta MSS en el borde del túnel si puedes.
Documenta el mapeo en un lugar que la gente realmente consulte (ticket + runbook). La traducción es una decisión de diseño, no un secreto.
Monitorización: añade chequeos de salud del túnel, contadores de reglas NAT y transacciones sintéticas (p. ej. TCP connect a la IP/puerto del servicio remoto).
Plan de reversión: prepárate para desactivar reglas NAT y rutas limpiamente. No improvises bajo presión.

Lista operativa: antes de declarar “listo”

Cada servicio entre sedes tiene un nombre que resuelve a una dirección inequívoca desde cada oficina.
Mapeos NAT son deterministas y documentados (qué rango traducido mapea a qué rango real).
El tráfico de retorno está probado con capturas; no se asume.
Políticas de firewall siguen el principio de menor privilegio, con reglas allow explícitas y drops logueados durante la puesta en marcha.
MTU/MSS probado con pings DF y una transferencia TCP real.
Puedes explicar el diseño a un ingeniero cansado a las 3 a.m. con un solo diagrama.

Preguntas frecuentes

1) ¿Puedo resolver subredes superpuestas solo con rutas estáticas?

No. Si un host cree que el destino está on-link (misma subred), hará ARP y nunca consultará tu ruta estática ingeniosa. Debes cambiar la identidad del destino (traducción/overlay/proxy) o cambiar la máscara del host (que es renumeración disfrazada).

2) ¿Y si cambio una oficina a /23 o /25 para “separarlas”?

Eso es renumeración parcial y casi siempre causa más daños colaterales de lo que la gente espera: scopes DHCP, ACLs, configuraciones de impresoras y suposiciones hardcodeadas. Puede ser un paso intermedio, pero no pretendas que sea indoloro.

3) ¿Es malo hacer NAT entre sitios?

Es un trade-off, no un pecado. Para redes superpuestas, NAT suele ser la vía menos arriesgada para conectividad sin tocar endpoints. Lo que es mala práctica es NAT inconsistente y sin documentar que convierte la depuración en arqueología.

4) ¿Qué rango traducido debo usar?

Elige algo poco probable de colisionar con redes existentes o futuras. Muchas organizaciones reservan un bloque como 10.200.0.0/16 para traducciones. Lo importante no es tanto la elección exacta sino que sea único en tu entorno y esté documentado.

5) ¿Funcionarán SMB/comparticiones de archivos a través de NAT?

Usualmente sí, si MTU/MSS está sano y firewalls stateful no lo están mangling. Pero SMB es sensible a latencia y pérdida, y ama conexiones largas. Prueba transferencias reales, no solo pings.

6) ¿Necesito traducir tanto fuente como destino?

En la mayoría de los casos de subred superpuesta, sí, al menos en la dirección que inicia la conexión. Solo DNAT a menudo falla porque el lado remoto enruta respuestas localmente (ya que la fuente parece de su propia LAN). Traducción simétrica hace la ruta de retorno inequívoca.

7) ¿Pueden overlays (como WireGuard) evitar NAT por completo?

A menudo sí. Si cada endpoint obtiene una IP overlay en un rango único, los endpoints hablan usando direcciones overlay, no las direcciones LAN solapadas. Pero si deseas “cada host de A alcance cada host de B por sus IPs existentes,” los overlays no cumplirán ese deseo sin traducción o proxies adicionales.

8) ¿Y si solo necesito acceso a un puñado de servidores en la otra oficina?

Usa un proxy o publica esos servicios detrás de una pequeña red de servicios con direccionamiento único. Tiene menos piezas móviles que una traducción de red completa y es más fácil de asegurar.

9) ¿Cómo manejan los VPNs en la nube CIDRs superpuestos (AWS/Azure)?

Generalmente no lo “manejan” automáticamente; requieren que uses NAT/traducción en el borde, o que asignes espacios de direcciones únicos por cada attachment de red. El solapamiento es un problema de topología, no una casilla de vendor.

10) ¿Cuál es la solución más limpia a largo plazo?

Renumerar a subredes únicas con un plan de direcciones real. NAT es un puente aceptable (a veces por años), pero el modelo de identidad más limpio a largo plazo es direccionamiento único más buen enrutamiento.

Conclusión: siguientes pasos que puedes ejecutar

Si conectas dos oficinas que ambas usan 192.168.0.0/24, no estás peleando con el cifrado. Estás peleando con la ambigüedad. Tu trabajo es hacer que los paquetes puedan responder a una pregunta: “¿A cuál 192.168.0.50 te refieres?”

Pasos prácticos:

Elige un prefijo traducido para una oficina (10.200.0.0/24 es un ejemplo válido) y resérvalo para que nadie lo use localmente luego.
Decide el modelo de acceso: alcance L3 completo (NAT/VRF) vs alcance por servicios (proxy) vs alcance por dispositivo (overlay).
Implementa conectividad basada en rutas (WireGuard o IPsec basado en rutas), luego añade NAT determinista con logging y contadores.
Arregla DNS para que las personas usen nombres y los nombres resuelvan a direcciones inequívocas desde cada sitio.
Ejecuta la guía de diagnóstico rápido una vez durante el despliegue a propósito, para poder hacerlo más rápido ante la inevitable sorpresa a las 2 a.m.

El resultado más profesional no es “lo hacemos funcionar.” Es “lo hacemos predecible, observable y fácil de explicar.” Así conectas redes superpuestas sin convertir la próxima guardia en una búsqueda del tesoro.