How to Connect Multiple PLCs with the Same IP Using NAT and VPN

When several machines are delivered with the same PLC or HMI address template, each machine needs a unique identity that the central network can route. Renumbering, static address translation, or NAT inside a VPN design can provide that identity, but only if the forward and return paths remain unambiguous. Otherwise, a VPN can be connected while the PLC is unreachable—or, worse, the SCADA system reaches the wrong site.

Key Takeaways

Repeated machine subnets become a problem only when their address realms are joined. Start with a site ID, device role, original address, center-visible address, central source prefix, permitted flows, and owner for every mapping. Then choose between renumbering, static 1:1 address mapping, static port mapping, and NAT over VPN according to OEM control, protocol behavior, router capability, and rollback cost. A VPN protects and transports packets; it does not make duplicate private addresses unique. Every design must prove the return path, tunnel-to-address binding, failover behavior, logging, and coordinated rollback before it can be trusted not to cross-connect sites.

---

Prove the Conflict Comes from Duplicate Addresses, Not the VPN or PLC

RFC 1918 private addresses may be reused in isolated address realms. Two disconnected machines can both use 192.168.1.0/24 without conflict. The ambiguity appears when those realms enter one routed environment and the center has no unique route or translation object for each machine.

The address-realm terminology in RFC 2663 helps separate the issues: one address can identify different hosts in different realms, but communication between realms needs an explicit routing or translation boundary. The IPsec site tunnels discussed here provide transport and protection only. If a central VPN hub receives the same remote prefix from two tunnels without a policy, selector, or translation that distinguishes them, routing remains ambiguous.

Check the central routing table, VPN policy, and the actual source and destination addresses before changing PLC timeouts or rebuilding a tunnel. If both tunnels advertise 192.168.1.0/24, or if SCADA is configured with the same destination for both machines, the structural conflict is already visible. Replacing the SIM or reconnecting the VPN cannot create a unique target.

Build an Address Register That Fixes Machine Identity and Translation Ownership

“The PLC is 192.168.1.10” is not a sufficient address record. Each mapping should include the site ID, machine serial number, device role, field interface, original IP and mask, center-visible IP, central source prefix, source address seen by the field device, allowed protocol and port, access direction, translation device, rule name, routing table or VRF, VPN peer, change version, owner, and rollback value. The asset register and SCADA tag database should bind the site ID, original address, mapped address, and rule version together.

Suppose Machine A and Machine B both contain a PLC at 192.168.1.10/24. Documentation can assign 192.0.2.10 to Machine A and 198.51.100.10 to Machine B, with each alias bound to its own rule and tunnel. The 192.0.2.0/24 and 198.51.100.0/24 ranges are RFC 5737 documentation addresses. They must never be copied into a real deployment; use organization-approved addresses that are unique in the central routing domain.

Site	Machine/device	Original field address	Center-visible address	Rule and tunnel
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

This conceptual diagram shows site aliases and return paths only when the central source does not overlap the machine subnet. Each site must be isolated by its own router, tunnel interface, or VRF/policy context, and both directions must traverse the same NAT and IPsec context. VPN outer endpoints, exact selectors, vendor processing order, and Twice NAT for an overlapping central source are not shown.

This is a minimum example. A production register must distinguish host-by-host mappings from full-prefix mappings and reserve capacity for HMIs, drives, and future devices. Prefix netmap, separate routing domains, and their scale limits are vendor-specific capabilities; they cannot be inferred from a generic “NAT supported” statement.

A unique destination alias is still not enough when the central source overlaps the machine subnet. RFC 5684 describes the reachability and identity failures that overlapping private networks can create. If the SCADA source is 192.168.1.20, the SITE-A PLC may treat it as an on-link host and ARP for it instead of using its default gateway. In that case, translating only 192.0.2.10 to 192.168.1.10 is insufficient. The design must renumber, isolate the address realms, or—after validation on the target device and firmware—apply both DNAT and SNAT (Twice NAT).

Scenario	Address pair sent by the center	Pair after SITE-A routing/NAT	Return-path condition
Central source does not overlap	203.0.113.20 → 192.0.2.10	203.0.113.20 → 192.168.1.10	PLC returns through its default gateway and the same session is reverse-translated
Central source is also in 192.168.1.0/24	192.168.1.20 → 192.0.2.10	203.0.113.20 → 192.168.1.10	Validated DNAT and SNAT are both reversed on return

All three example blocks—192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24—are reserved for documentation by RFC 5737. Replace them in a real project and record the source, destination, protocol, port, pre- and post-translation values, routing domain, tunnel, and reverse path in an auditable packet walk.

The address plan also needs one owner. If every site chooses its own central alias, duplicates will simply move from the machine side to the center. A central address authority should allocate mapped ranges, and the router rules, VPN hub, SCADA tags, and change records should all reference the same site ID.

Compare Renumbering, Static Address Mapping, and NAT over VPN

Renumbering is the clearest option when the OEM controls every PLC/HMI address, static reference, engineering file, and regression test. Each machine receives a globally unique site subnet from the start, so the center uses ordinary routing and packet captures retain end-to-end addresses. The cost is changing PLCs, HMIs, drives, recipes, engineering tools, and third-party devices. For installed equipment, the outage and regression effort can exceed the cost of adding a controlled NAT boundary.

Static 1:1 address mapping is one configuration of Basic NAT as described by RFC 3022: it changes IP addresses and gives one device a fixed center-visible alias. Basic NAT may also use dynamic address pools, so Basic NAT and static 1:1 NAT are not synonyms. Static 1:1 mapping is useful when the machine template cannot change but the center must address each PLC as a separate host. Verify the bidirectional rule, ARP and routing behavior, mapping granularity, translation order, and return path before deployment.

Static port mapping translates the address and transport-layer port and can be implemented as a static inbound use of NAPT. When SCADA initiates the connection, the design needs a fixed and unique protocol + external IP + external port → internal IP + internal port rule. Ordinary dynamic outbound NAPT does not create that inbound path. Protocols that rely on broadcast or multicast discovery, negotiate additional connections, or carry addresses inside the payload require protocol-specific testing. RFC 4787 also shows that UDP NAT behavior depends on mapping, filtering, and timers; port translation is not a stateless patch cable.

NAT over VPN is not a separate address mechanism. It is a design in which translation, routing, and tunnel policy are validated together. This article's selector, SA, and ESP discussion applies to IPsec site tunnels; other VPNs must be checked against their own routing and policy model. RFC 4301 uses policy and selectors to identify protected traffic, while ESP tunnel mode provides encapsulation. Encryption does not remove ambiguity if two sites still enter the central policy as 192.168.1.0/24. RFC 3715 further shows that combining NAT and IPsec affects selectors, overlapping security policies, and renegotiation. Document whether translation occurs before or after tunneling and whether selectors use original or translated addresses.

Option	Best fit	Main cost	Acceptance focus
Renumbering	OEM controls all static references and regression testing	Device and project changes, possibly an outage	Every reference, route, discovery function, and rollback
Static 1:1 mapping	Machine template cannot change and the center needs a unique IP	Address-pool and bidirectional-rule management	Mapping granularity, translation order, return path, payload-embedded IPs
Static port mapping	Few services and the central application accepts different ports	More complex port inventory and state	Static inbound rules, secondary connections, UDP timers, readable logs
NAT over VPN	Many sites converge through a controlled hub	Coupled NAT, routing, and tunnel policy	Pre/post-translation tuple, selector, routing domain, bidirectional recovery

Bind Routing, Access Control, and Logs at the Industrial Router Boundary

In this topology, an industrial router can be the translation boundary only if the required functions are verified on the target model and firmware. It sees the original machine-side address, the upstream or VPN-side address, access policy, and link state. Procurement and laboratory testing still need to confirm static mappings, policy routing or isolated routing domains, translation order, return behavior, rule-hit logging, capacity, configuration backup, and rollback. “Supports NAT and VPN” alone does not prove that a router can handle overlapping subnets.

Firewall policy should bind the authenticated peer identity, a stable tunnel or SA policy, an interface or VRF, the permitted original prefix, the assigned alias, direction, and minimum service set. An SPI changes when an SA is rebuilt or rekeyed; use it for runtime logs and event correlation, not as a long-lived rule key. Under the inbound processing model in RFC 4301, a decrypted packet that does not match the SA selectors should be rejected and logged. A tunnel for one site must not be allowed to claim another site's address.

For general public reachability, VPN credentials, and remote-access controls, see Wavetel's guide to remote PLC and HMI access through an industrial cellular router. The present design focuses only on duplicate-address isolation and preventing cross-site access.

One central connection should be traceable through the site, peer identity, tunnel, original address, translated address, protocol and port, and rule name. A “VPN connected” message without selector, rule-hit, and translation records cannot prove that an engineer reached the intended machine. Configuration changes also need a version and rollback value so the router and SCADA database do not drift apart.

Prove with SCADA and Field Tests That Traffic Cannot Cross Sites

Run acceptance tests in a repeatable sequence:

1. Check that every routable identity resolves to one site or device. For 1:1 NAT, check the alias; for port mapping, check protocol + alias + external port; for isolated routing, check VRF/tunnel + original prefix. Confirm that pre/post-translation tuples, VPN selectors, and the mapping register agree. Verify that the PLC/HMI default gateway or explicit return route points to the same boundary that performs reverse NAT.

2. Connect only Machine A and read a safe, identifiable, read-only value. Have field personnel or independent logs prove that the request reached A. Disconnect A, connect B, and repeat.

3. Put A and B online together. Test center-initiated and field-originated flows according to the permitted-flow matrix, checking return routes, NAT logs, and concurrent polling. Do not rely on ping; test the real TCP/UDP protocol and list discovery, callbacks, or secondary connections separately.

4. Run negative tests: send a valid address through the wrong tunnel, spoof another site's source address, and access an unauthorized port. All three must be rejected, with logs that identify the site, tunnel, selector, and rule.

5. Break one site link and verify TCP reconnection, UDP recovery after the configured idle period, and bidirectional communication after IPsec rekey. If Machine A is offline, a request for A must fail or time out; it must never fall through to Machine B.

6. Restart the router or VPN hub and test a coordinated rollback only in a laboratory or approved maintenance window with the process in a safe state. The known-good bundle must include NAT, routes, tunnels, access rules, and SCADA tags. A failure should fail closed and trigger the full anti-cross-site test again.

If the protocol allows writes, begin in an isolated environment or an approved maintenance window with an object that cannot alter the production state. Production acceptance should start read-only. NIST SP 800-82 Rev. 3 and CISA's Configuring and Managing Remote Access for Industrial Control Systems both support controlled access, monitoring, and operational constraints for OT environments.

Select a Maintainable, Reversible Router Design

Wavetel's WR143 and WR255 product pages list feature categories including NAT, VPN, static and policy routing, firewall, and SNMP/RMS. The WRTOS and RMS pages provide operating-system and centralized-management context. These pages support a candidate list; they do not publicly confirm static 1:1 mapping, full-prefix netmap, VRF or multiple routing tables, translation order around VPN processing, mapping capacity, rule-hit logs, or one-click rollback.

When evaluating Wavetel's industrial cellular router portfolio, give the supplier the duplicate-address example, central source and destination plan, actual PLC protocol, VPN topology, and concurrent site count. Ask for a demonstration on the target firmware using the same packet walk and acceptance checklist. Choose a design only when every mapping can be observed, audited, and rolled back as one controlled bundle.

FAQ

Why can't two machine networks using 192.168.1.0/24 route directly through one VPN?

The center sees the same destination prefix for both machines and cannot select A or B by IP address alone. A VPN can protect the traffic, but it still needs a unique routing object, an isolated routing domain, or explicit translation for each site.

When should I renumber instead of using NAT?

Renumber when the OEM controls every device address, static reference, and test process and wants long-term end-to-end address transparency. Evaluate NAT when installed equipment cannot be stopped, third-party devices cannot be changed, or the machine template must remain identical—but accept the additional mapping, logging, and rollback work.

What is the difference between static 1:1 mapping and port mapping?

Static 1:1 mapping gives one device a fixed translated IP while preserving its normal service ports. Static port mapping lets several devices share an address by assigning different external ports. The latter requires the central application to accept nonstandard ports and needs a unique, stateful protocol/port mapping inventory.

Should central SCADA store the original PLC address or the translated address?

The connection configuration normally uses the center-visible address. The asset and tag records should bind the site ID, original address, center-visible address, central source prefix, source address seen by the field device, and rule version. Storing only one address makes the return path and audit trail difficult to reconstruct.

Can VLANs alone solve duplicate PLC addresses?

VLANs isolate Layer 2 broadcast domains but do not automatically give central SCADA different Layer 3 destinations. Simultaneous routed access still requires unique center-visible addresses, isolated routing domains, or validated explicit translation.

How do I prove the mapping cannot reach the wrong machine?

Bring up each site separately, then run both together and check the real protocol, return path, and rule logs. Add negative tests for the wrong tunnel, a spoofed site source, and unauthorized ports, followed by controlled disconnect, rekey, restart, and rollback tests. A request for Machine A must never reach Machine B when A is offline.