How a Network Segment Accesses Intranet PLC and CNC Devices via NAT and Mapping IP
This page explains the mechanics behind reaching intranet PLC and CNC devices via NAT, and where that setup breaks down. It is written for controls engineers, integrators, and IT staff who have to connect a machine network to a plant network without redesigning either side. After reading it, you can judge whether NAT and mapping IP suits a given cell or whether you need a different access layer.
Why a network segment reaches intranet PLC and CNC devices via NAT
A CNC cell usually sits on its own subnet. The machine builder assigns addresses from a small pool, often 192.168.1.x or 10.10.10.x, and those addresses repeat from cell to cell. When plant IT tries to read data from those machines, the first problem is that two cells may use the same address for different controllers. NAT fixes that by giving each machine a second identity on the plant side.
Mapping IP works on the same idea but at a finer grain. Instead of translating every packet, the router keeps a table that says one outside address and port belongs to one inside device. A Siemens 828D on 192.168.1.10:102 becomes 172.20.5.10:4001 on the plant network. The plant side never sees the original address, so address collisions between cells stop mattering.
The segment that does the access is usually a managed switch or a small industrial router with two interfaces. One interface faces the machine subnet, the other faces the plant or DMZ. All traffic between them passes the mapping table. Nothing else crosses. That single rule is what keeps a misconfigured machine from flooding the plant network with broadcast traffic.
You get three practical benefits from this layout. Address reuse between cells is allowed. The plant side sees a stable target list it can document once. And you can drop or rewrite traffic at the boundary without touching the controller program.
- 1Address reuseEvery cell can keep its default subnet without renumbering.
- 2Stable plant-side targetsIT documents one IP per machine, not a moving DHCP lease.
- 3Boundary filteringYou decide which ports cross, and in which direction.
How NAT and mapping IP handle PLC and CNC traffic
Most PLC and CNC protocols are connection oriented and stateful. Siemens S7 uses TCP 102. FANUC FOCAS uses TCP 8193. Modbus TCP uses 502. EtherNet/IP uses 44818 for explicit messaging and UDP 2222 for implicit I/O. A mapping table must forward the TCP control connection and, where the protocol needs it, the UDP side channel. Forward only the TCP port and the machine may connect but never exchange cycle data.
Static one-to-one mapping is the safest form. One inside address maps to one outside address, all ports open. It is easy to reason about and easy to debug. The cost is address consumption and a wider exposure surface. If the plant side is a flat network, that exposure matters.
Port-level mapping saves addresses. You forward 102 to one controller, 8193 to another, and 502 to a third, all behind one outside address. This works until two devices need the same port. Two S7 controllers both want 102, and a single outside address cannot serve both without a different outside port. Clients that hard-code the port will fail. Some HMI and SCADA packages allow a custom port; many do not.
Timing is the quiet failure mode. NAT adds a translation step and, on small industrial routers, that step costs latency. A few milliseconds is fine for a data logger polling every second. It is not fine for a motion sync or a safety channel. Keep cyclic I/O on the machine subnet. Route only diagnostics, recipe transfer, and program upload across the boundary.
- 1Keep cyclic I/O localDo not stretch real-time traffic across a NAT hop.
- 2Check UDP needsEtherNet/IP implicit messaging needs UDP 2222 open.
- 3Watch hard-coded portsTwo devices on port 102 cannot share one outside IP.
Where mapping IP stops working
Protocols that embed IP addresses inside the payload are the classic problem. If a frame carries the sender address in the data field, NAT rewrites the header but not the payload. The receiver then replies to an address that does not exist on its side. Some industrial protocols have an application-layer gateway that fixes this. Others do not, and the connection stalls after the first handshake.
Broadcast and multicast discovery also break. A scan tool that finds devices by broadcast will only see devices inside its own segment. That is often desirable, but it surprises engineers who expect the full machine list to appear. If you need discovery across the boundary, you need a proxy or a gateway that answers on behalf of the devices, not plain NAT.
Address exhaustion is the third limit. One-to-one mapping needs one outside address per device. A shop with 40 machines and 3 controllers each needs 120 outside addresses. That is fine on a /24 and painful on a small DMZ range. Port mapping eases the pressure but brings back the shared-port conflict.
The last limit is operational. A mapping table is a document. If nobody updates it when a machine moves or a controller is swapped, the table becomes wrong and the fault looks like a network outage. Keep the table in version control and tie every entry to an asset tag.
- 1Payload-embedded addressesHeader NAT cannot fix an address inside the data field.
- 2Broadcast discoveryScans stop at the segment boundary by design.
- 3Table driftAn outdated mapping table mimics a hardware fault.
Choosing between one-to-one NAT and port mapping
Start with the protocol, not the address plan. If the machine speaks a clean TCP protocol with configurable ports, port mapping is enough. If it mixes TCP and UDP, or if the client software fixes the port number, one-to-one mapping removes a whole class of problems before they appear.
Then count devices. Under about 20 endpoints, one-to-one mapping is the low-risk option and the table stays readable. Above that, the address budget usually forces port mapping, and you should confirm every client can take a custom port before you commit.
Then check the traffic type. Polling, file transfer, and diagnostics tolerate a NAT hop. Cyclic I/O, motion sync, and safety traffic do not. If a control loop crosses the boundary, the design is wrong regardless of how the table is built.
Finally, decide who owns the table. If plant IT owns it and the controls team does not have read access, every change becomes a ticket. Give both teams visibility, and record the inside address, outside address, protocol, and port for each entry.
- 1Protocol firstConfigurable ports allow port mapping; fixed ports do not.
- 2Device countOne-to-one mapping is simpler below 20 endpoints.
- 3Traffic typeOnly non-real-time traffic should cross the boundary.
Mapping approach by situation
Pick the row that matches your cell, then confirm the port and protocol details before you build the table.
| Situation | Best mapping | Why |
|---|---|---|
| One S7 controller, plant needs read access | Port mapping, TCP 102 | One outside port is enough; no address waste |
| Two controllers both on port 102 | One-to-one NAT | Shared outside port cannot serve both |
| EtherNet/IP with implicit I/O | One-to-one NAT plus UDP 2222 | TCP-only mapping breaks cycle data |
| 40 machines, small DMZ range | Port mapping with custom ports | One-to-one needs 120+ outside addresses |
| Motion sync across cells | No NAT on the control path | Translation latency breaks the loop |
| Protocol embeds IP in payload | Application gateway, not NAT | Header rewrite does not fix the payload |
| Discovery scan across segments | Proxy or gateway | Broadcast does not cross the boundary |
The clear trade-off
If your cell has a handful of endpoints and the clients accept custom ports, use port mapping and save addresses. If ports are fixed, UDP is involved, or you want the simplest table to debug, use one-to-one NAT. Never route cyclic I/O or safety traffic across either.
Questions engineers ask next
Can two controllers share one outside IP if both use port 102?
Not with plain port mapping. The outside port is the only thing that separates them, and both devices answer on 102 internally.
One-to-one NAT gives each controller its own outside address, so both keep port 102 end to end. If addresses are tight, check whether the client supports a custom port before you plan the table.
Does NAT add enough latency to matter?
For polling and file transfer, the added latency is a few milliseconds and rarely matters. A data logger reading every second will not notice.
For cyclic I/O, motion sync, or safety functions, even small jitter matters. Keep those on the machine subnet and route only diagnostics and program transfer across the boundary.
Why does my scan tool only see some machines?
Discovery usually relies on broadcast or multicast, and those frames stop at the segment boundary. Devices on the far side are invisible to a plain scan.
If you need a full device list across segments, use a gateway or proxy that answers on behalf of the machines. Plain NAT and mapping IP do not forward broadcast.
What breaks when a protocol carries IP addresses inside the payload?
NAT rewrites the packet header, not the data field. The far device reads the old address from the payload and replies to an address it cannot reach.
The connection often completes the handshake and then stalls. You need an application-layer gateway that understands the protocol, not a header-only translation rule.
How do we keep the mapping table from going stale?
Treat it as a controlled document. Every entry should list the asset tag, inside address, outside address, protocol, and port.
Review it whenever a machine moves or a controller is replaced. An outdated entry usually looks like a network fault, which sends the wrong team to the wrong problem.
Is isolating each cell on its own subnet worth the effort?
Yes, in most plants. Per-cell subnets let every machine keep its default addressing and stop broadcast traffic from spreading.
The cost is one boundary device per cell and a mapping table to maintain. That is usually cheaper than renumbering every controller to fit a plant-wide address plan.
Send us the drawing and the network note
If your part design depends on a controller or cell layout, share the files and the interface list. We return a quotation and a free DFM analysis within 12 hours, and we machine from one prototype to 10,000+ part runs.
12-hour quote100% inspectionNDA on request
More from GreatLight
We publish setup notes, tooling trials and inspection data from the factory floor.
