¿Cómo conectar varios PLC con la misma IP mediante NAT y VPN en un router industrial?

Cuando un fabricante entrega varias máquinas con la misma plantilla de direcciones para PLC y HMI, cada máquina necesita una identidad única y visible desde el centro. Esa identidad puede obtenerse mediante renumeración, traducción estática de direcciones o NAT dentro de la VPN, pero siempre debe existir un camino bidireccional inequívoco. De lo contrario, al concentrar todos los equipos en un mismo SCADA a través de routers industriales y VPN, la dirección repetida 192.168.1.10 no basta para saber qué PLC es el destino. El síntoma típico es engañoso: «la VPN está conectada, pero no se llega al PLC» o, peor aún, «se ha accedido a la máquina equivocada».

Puntos clave

El conflicto aparece cuando redes de máquina que funcionaban como dominios de direcciones aislados pasan a compartir un entorno enrutable. Antes de elegir una solución, documente el ID del sitio, la función de cada equipo, la dirección original, la dirección visible desde el centro, el prefijo de origen del centro, los flujos permitidos y su responsable. Después compare la posibilidad de renumerar con el NAT 1:1 estático, el mapeo estático de puertos y el NAT sobre VPN, teniendo en cuenta el control del OEM sobre las direcciones, la compatibilidad del SCADA con puertos distintos, el comportamiento real del protocolo, las funciones del router y el coste de reversión. Una VPN protege y transporta el tráfico, pero no convierte por sí sola direcciones privadas repetidas en destinos únicos. La arquitectura solo queda validada cuando se comprueban la ruta de retorno en ambos sentidos, la vinculación entre túnel y dirección, la recuperación tras fallos, la trazabilidad de los registros y una reversión coordinada.

---

Confirme primero que el conflicto es de direccionamiento, no de la VPN ni del PLC

Las direcciones privadas de RFC 1918 pueden repetirse en dominios aislados. Dos máquinas sin interconexión pueden utilizar 192.168.1.0/24 sin ningún conflicto. El problema empieza cuando ambas redes entran en el mismo dominio enrutable: si no se resuelve antes el solapamiento, el router central no puede escoger la máquina correcta utilizando únicamente la dirección de destino.

El concepto de address realm de RFC 2663 ayuda a precisar el diagnóstico. Una misma dirección puede identificar hosts diferentes en dominios distintos, pero la comunicación entre dominios exige una frontera explícita de traducción o enrutamiento. En este artículo, los túneles IPsec entre sitios aportan transporte y protección. Si el concentrador VPN recibe 192.168.1.0/24 desde dos túneles y ni las políticas, ni los selectores, ni la traducción distinguen esos contextos, la ambigüedad de encaminamiento permanece.

Durante el diagnóstico, revise la tabla de rutas central, las políticas VPN y las direcciones de origen y destino observadas en los paquetes. Si dos túneles anuncian 192.168.1.0/24, o si el SCADA configura la misma IP como destino para dos máquinas, el conflicto ya es estructural. Volver a crear el túnel, cambiar la SIM o aumentar el tiempo de espera del PLC no generará un destino único.

Cree un inventario que fije la identidad y la responsabilidad de cada traducción

No basta con anotar «el PLC es 192.168.1.10». Para cada objeto mapeado, registre como mínimo el ID del sitio, el número de serie de la máquina, la función del equipo, la interfaz local, la IP y máscara originales, la IP visible desde el centro, el prefijo de origen central, la dirección de origen que verá el equipo de campo, los protocolos y puertos autorizados, el sentido del acceso, el dispositivo que realiza la traducción, el nombre de la regla, la tabla de rutas o VRF, el peer VPN, la versión del cambio, el responsable y el valor de reversión. El inventario de activos y la tabla de puntos del SCADA deben vincular el sitio, la dirección original, el alias central y la versión de la regla; el equipo de campo debe poder reconstruir toda la ruta antes y después del NAT.

Supongamos que los PLC de las máquinas A y B utilizan ambos 192.168.1.10/24. En la documentación podemos asignar 192.0.2.10 como alias central de la máquina A y 198.51.100.10 como alias de la máquina B, vinculando cada uno a su propia regla y túnel. 192.0.2.0/24 y 198.51.100.0/24 son bloques reservados por RFC 5737 exclusivamente para documentación. No deben desplegarse tal cual: el proyecto real necesita direcciones aprobadas por la organización, únicas en el dominio de enrutamiento central y sin solapamiento con las redes existentes del cliente.

Sitio	Máquina/equipo	Dirección original en campo	Dirección visible desde el centro	Regla y túnel
SITE-A	MACHINE-A / PLC	192.168.1.10/24	192.0.2.10	SITE-A-PLC-01 / VPN-A
SITE-B	MACHINE-B / PLC	192.168.1.10/24	198.51.100.10	SITE-B-PLC-01 / VPN-B

Este diagrama conceptual solo representa los alias de sitio y la ruta de retorno bidireccional cuando la dirección de origen central no se solapa. Cada sitio debe quedar aislado mediante su propio router, interfaz de túnel o contexto VRF/de política, y tanto la ida como la vuelta deben atravesar el mismo contexto NAT e IPsec. No se muestran las direcciones exteriores de la VPN, los selectores concretos, el orden de procesamiento propio del fabricante ni el Twice NAT necesario cuando también se solapa el origen central.

La tabla es deliberadamente mínima. En un proyecto real hay que distinguir entre un mapeo estático de un solo host, una lista de traducciones por dispositivo y una traducción de prefijo completo. El netmap de una subred, los dominios de enrutamiento separados y sus límites de capacidad son funciones específicas de cada fabricante; no pueden inferirse de una ficha que solo diga «compatible con NAT». También deben reservarse espacio de direcciones, máscaras, direcciones especiales y un proceso para incorporar HMI, variadores u otros equipos en el futuro.

Que el destino sea único tampoco garantiza una ruta de retorno válida. El análisis de RFC 5684 sobre redes privadas solapadas y VPN muestra que el solapamiento entre el centro y el sitio puede afectar tanto a la conectividad como a la identidad del host. Por ejemplo, si el SCADA central usa 192.168.1.20, el PLC de SITE-A interpretará el destino de su respuesta como un host de su propia subred y tratará de resolverlo mediante ARP, en vez de enviar el paquete a la puerta de enlace. Traducir únicamente 192.0.2.10 a 192.168.1.10 no basta en ese caso. Hay que renumerar, separar los dominios de direcciones o, tras validar el equipo y su firmware, aplicar DNAT y SNAT de forma conjunta mediante Twice NAT.

Escenario	Par de direcciones iniciado desde el centro	Después del router de SITE-A	Condición para la ruta de retorno
El origen central no se solapa	203.0.113.20 → 192.0.2.10	203.0.113.20 → 192.168.1.10	El PLC responde por su puerta de enlace y la misma sesión deshace la traducción
El origen central también pertenece a 192.168.1.0/24	192.168.1.20 → 192.0.2.10	203.0.113.20 → 192.168.1.10	Un DNAT + SNAT validado deshace ambas traducciones en el retorno

Los bloques 192.0.2.0/24, 198.51.100.0/24 y 203.0.113.0/24 de la tabla son direcciones de documentación de RFC 5737. Sustitúyalos en producción por rangos aprobados y no solapados, y documente un trazado de paquetes auditable con origen y destino, protocolo y puerto, valores previos y posteriores al NAT, dominio de rutas, túnel y camino inverso.

La organización también debe decidir quién controla la unicidad. Si cada sitio escoge por su cuenta sus alias centrales, el conflicto solo se desplazará de las máquinas al centro. Un único plan de direccionamiento debe asignar los rangos visibles y hacer que las reglas de los routers, el concentrador VPN, la tabla de puntos del SCADA y el registro de cambios utilicen el mismo ID de sitio.

Compare la renumeración, la traducción estática y el NAT sobre VPN

Renumeración. Es la opción más directa cuando el OEM controla las direcciones de PLC y HMI, las configuraciones de protocolo y su mantenimiento durante todo el ciclo de vida. Cada máquina recibe desde el principio una subred de sitio única; el centro utiliza enrutamiento normal, los paquetes conservan direcciones extremo a extremo y las capturas son más fáciles de interpretar. El coste está en cambiar referencias estáticas dentro del PLC, HMI, variadores, software de ingeniería, recetas y equipos de terceros. En máquinas ya instaladas, la parada y las pruebas de regresión pueden resultar más costosas que añadir NAT.

Traducción estática 1:1. Es una forma de configurar el Basic NAT descrito en RFC 3022: solo se traduce la dirección IP y cada dispositivo recibe un alias central fijo. Basic NAT también puede utilizar asociaciones dinámicas desde un pool, por lo que no es sinónimo directo de NAT 1:1 estático. Esta opción es adecuada cuando no se puede modificar la plantilla de la máquina, pero el centro necesita tratar cada PLC como un host independiente. Antes de adoptarla, valide reglas estáticas en ambos sentidos, ARP y rutas, granularidad y capacidad del pool, orden de traducción y camino de retorno.

Mapeo estático de puertos. Traduce la dirección y el puerto de transporte y puede considerarse una configuración estática de entrada basada en NAPT. Si el SCADA inicia la conexión, hace falta una asociación fija y única de «protocolo + IP externa + puerto externo → IP interna + puerto interno»; un NAPT dinámico de salida no crea automáticamente ese camino entrante. Si el protocolo utiliza descubrimiento por difusión o multidifusión, negocia conexiones secundarias dinámicas o transporta direcciones dentro de la carga útil, verifique el flujo completo con la documentación del fabricante del PLC y del protocolo. Que el puerto principal responda no demuestra compatibilidad. Los requisitos de RFC 4787 para el mapeo UDP también recuerdan que la traducción de puertos depende de reglas de mapeo, filtrado y temporizadores; no se comporta como un cable estático sin estado.

NAT sobre VPN. No es un quinto mecanismo de direccionamiento: integra NAT, enrutamiento y política de túnel en un único diseño que debe verificarse como conjunto. Las referencias a selector, SA y ESP de este artículo se aplican a túneles IPsec entre sitios; para otras VPN hay que revisar su propio modelo de rutas y políticas. La arquitectura de RFC 4301 utiliza políticas y selectores para decidir qué tráfico protege el gateway IPsec, mientras que el modo túnel ESP de RFC 4303 encapsula los paquetes. Si ambos sitios siguen presentando 192.168.1.0/24 al entrar en la política central, el cifrado no elimina la ambigüedad. RFC 3715 describe además problemas de selectores, políticas solapadas y renegociación al combinar NAT e IPsec. Por ello, el diseño debe indicar si la traducción ocurre antes o después del túnel y si los selectores utilizan las direcciones originales o las traducidas.

Opción	Cuándo encaja mejor	Coste principal	Verificación imprescindible
Renumeración	El OEM controla todas las referencias estáticas y las pruebas de regresión	Cambios en equipos y proyectos, posiblemente con parada	Referencias, rutas, descubrimiento y reversión
NAT 1:1 estático	La plantilla de máquina no puede cambiar y el centro necesita una IP única	Gestión del pool y de reglas estáticas bidireccionales	Granularidad, orden de traducción, retorno e IP dentro de la carga útil
Mapeo estático de puertos	Hay pocos servicios y el SCADA admite puertos diferentes	Inventario de puertos y mayor complejidad de estado	Regla estática entrante, conexiones secundarias, temporizadores UDP y registros
NAT sobre VPN	Varios sitios convergen en un concentrador controlado	Acoplamiento de NAT, rutas y política de túnel	Cinco tuplas antes/después, selectores, dominio de rutas y recuperación bidireccional

Fije el enrutamiento, el control de acceso y los registros en el límite industrial

En la topología descrita, un router industrial que haya demostrado las funciones necesarias con el firmware objetivo puede actuar como frontera de traducción, ya que observa las direcciones originales de la máquina, las direcciones del lado ascendente o VPN, el control de acceso y el estado del enlace. La selección y las pruebas de laboratorio deben confirmar el mapeo estático, el enrutamiento por políticas o los dominios independientes, el orden de traducción, la ruta de retorno, los registros de coincidencia, los límites de capacidad y la restauración de configuración. La frase «admite NAT y VPN» no demuestra por sí sola que un equipo gestione subredes solapadas.

Las reglas de firewall deben vincular la identidad autenticada del peer con una política estable de túnel o SA, la interfaz o VRF, el prefijo original autorizado, el alias central asignado, el sentido y el conjunto mínimo de servicios. El SPI cambia cuando se reconstruye o renegocia una SA; sirve para correlacionar eventos en tiempo de ejecución, no como clave permanente de una regla. Según el procesamiento de entrada definido por RFC 4301, un paquete descifrado que no coincida con los selectores de su SA debe descartarse y generar un evento auditable. Ningún túnel debe poder declarar direcciones asignadas a otro sitio.

Los registros deben permitir seguir una conexión central hasta el sitio, la identidad del peer, el túnel, las direcciones antes y después de la traducción, el protocolo, el puerto y la regla aplicada. Un estado «VPN connected» sin selectores, coincidencias de reglas ni evidencia de NAT no demuestra que el ingeniero esté comunicándose con la máquina correcta. Las modificaciones de configuración también necesitan versión y valores de reversión para evitar que los cambios improvisados separen la tabla de puntos del SCADA de las reglas desplegadas.

Demuestre con el SCADA y pruebas de campo que no existe cruce entre sitios

Siga una secuencia de aceptación repetible:

1. Compruebe de forma estática que cada identidad enrutable resuelve a un solo sitio o dispositivo: para NAT 1:1, revise el alias; para mapeo de puertos, la combinación «protocolo + alias + puerto externo»; para dominios separados, «VRF/túnel + prefijo original». Verifique también que las cinco tuplas antes y después del NAT, los selectores VPN y el inventario coinciden; que la puerta de enlace predeterminada del PLC/HMI —o una ruta de retorno explícita— conduce a la misma frontera que aplica el NAT inverso; que el SCADA no reutiliza endpoints, y que las reglas incluyen el ID del sitio.

2. Conecte solo la máquina A y lea un valor seguro y claramente identificable. Confirme mediante un técnico en campo o un registro independiente que la solicitud llegó a A. Desconecte A, conecte B y repita la prueba.

3. Mantenga A y B en línea al mismo tiempo. Siguiendo la matriz de flujos permitidos, pruebe tanto conexiones iniciadas desde el centro como comunicaciones iniciadas en campo; contraste la ruta de retorno, los registros de traducción y el sondeo simultáneo. No limite la prueba a ping: cubra los protocolos TCP/UDP reales y, si existen, valide por separado descubrimiento, callbacks y conexiones secundarias.

4. Ejecute pruebas negativas: envíe una dirección válida por el túnel equivocado, suplante la dirección de otro sitio e intente acceder a un puerto no autorizado. Los tres flujos deben rechazarse, y los registros deben correlacionar sitio, túnel, selector y regla.

5. Simule la caída de un solo sitio y valide la reconexión TCP, la recuperación de UDP tras superar el tiempo de inactividad configurado y la comunicación bidireccional después de un rekey de IPsec. Cuando A esté fuera de servicio, las solicitudes dirigidas a A deben fallar o agotar el tiempo de espera; nunca deben llegar a B.

6. Reinicie el router o el concentrador VPN y ejecute una reversión coordinada solo en laboratorio o durante una ventana de mantenimiento aprobada, con el proceso en estado seguro. El objeto de reversión debe ser un paquete known-good verificado y vinculado a una versión, que incluya NAT, rutas, túneles, control de acceso y tabla de puntos del SCADA. Ante un fallo, el sistema debe cerrarse de forma segura y repetir toda la batería de pruebas contra el cruce de sitios.

Si el protocolo permite operaciones de escritura, empiece en un entorno aislado o en una ventana aprobada y utilice objetos seguros que no alteren el estado del proceso. La aceptación en producción debe comenzar con lecturas. NIST SP 800-82 Rev. 3 y la guía de CISA Configuring and Managing Remote Access for Industrial Control Systems subrayan la necesidad de acceso controlado, supervisión y respeto por las restricciones operativas.

Seleccione una solución mantenible y reversible para el modelo y firmware concretos

Las páginas actuales de los modelos Wavetel WR143 y WR255 enumeran categorías como NAT, VPN, rutas estáticas o por políticas, firewall y administración mediante SNMP/RMS. Esa información sirve para crear una lista inicial, pero no confirma públicamente NAT 1:1 estático, netmap de prefijo completo, VRF o múltiples tablas de rutas, traducción antes o después de la VPN, capacidad de mapeo, registros de coincidencia ni reversión con un solo paso.

Si está evaluando el portafolio de routers celulares industriales de Wavetel, entregue al proveedor el ejemplo de direcciones repetidas, el plan de origen y destino central, los protocolos PLC reales, la topología VPN y el número de sitios concurrentes. Solicite una demostración sobre el firmware objetivo utilizando el mismo trazado de paquetes y la misma lista de aceptación. La decisión final debe basarse en que cada traducción pueda observarse, auditarse y revertirse como parte de un conjunto coherente.

Preguntas frecuentes

¿Por qué dos subredes de máquina 192.168.1.0/24 no pueden enrutarse directamente por la misma VPN?

Porque el centro recibe el mismo prefijo de destino desde dos contextos y la IP por sí sola no indica si debe escoger la máquina A o la B. La VPN transporta y protege el tráfico, pero sigue haciendo falta un objeto de ruta único, dominios de direcciones separados o una traducción explícita.

¿Cuándo conviene renumerar en lugar de utilizar NAT?

La renumeración suele ser más fácil de comprender a largo plazo cuando el OEM controla todas las direcciones, referencias estáticas y pruebas. Si una máquina instalada no puede detenerse, contiene equipos de terceros que no admiten cambios o debe conservar una plantilla idéntica, puede evaluarse NAT, asumiendo la gestión adicional de traducciones, registros y reversión.

¿En qué se diferencian el NAT 1:1 estático y el mapeo de puertos?

El NAT 1:1 asigna a cada equipo una IP traducida fija y permite que el centro continúe usando los puertos normales del servicio. El mapeo estático de puertos permite que varios equipos compartan una dirección, diferenciándolos por puerto. Este último exige que la aplicación central acepte endpoints no estándar y que se mantenga una asociación única de protocolo, dirección y puerto externo.

¿Debe el SCADA guardar la dirección original del PLC o la dirección traducida?

Los parámetros de conexión del centro suelen utilizar el alias visible desde el centro. El inventario, la tabla de puntos y el registro de cambios deben conservar juntos el ID del sitio, la dirección original, el alias central, el prefijo de origen central, la dirección que verá el PLC y la versión de la regla. Guardar solo una dirección impide explicar la ruta de retorno y debilita el diagnóstico y la auditoría.

¿Puede una VLAN resolver por sí sola que varios PLC utilicen la misma IP?

Una VLAN separa dominios de difusión de capa 2, pero no crea automáticamente destinos de capa 3 diferentes para el SCADA. Para acceder simultáneamente a PLC con la misma IP siguen siendo necesarios alias centrales únicos, dominios de enrutamiento aislados o una traducción explícita y validada.

¿Cómo se comprueba que el mapeo nunca conduce a la máquina equivocada?

Valide primero cada sitio por separado y después todos los sitios en línea, utilizando el protocolo real para comprobar ambos sentidos, el retorno y los registros. Añada pruebas negativas con el túnel equivocado, suplantación de direcciones y puertos no autorizados, y compruebe en una ventana controlada la caída, el rekey, el reinicio y la reversión coordinada. Si la máquina A no está disponible, ninguna solicitud dirigida a A puede terminar en B.