PLC NAT: Translation Maps Addresses, Not Physical Links

After you build a routed path and configure translation in both directions, PLC B can address the camera through a mapped IP. NAT alone cannot join two disconnected cabinets, and it does not replace the camera-control protocol. Start with connectivity; address translation comes after that.

Read the symptom from PLC B

The fault will look simple at PLC B: the translated camera address does not answer, or the connection opens but cannot complete. Work backward from that symptom. Check the network path first.

Do not begin by changing the IP addresses of the two 1769-L36ERMS controllers. That wastes time when the cabinets have no route between them. Prove that a router, gateway, tunnel, or other network link can carry traffic from one cabinet to the other.

Understand what NAT actually changes

NAT rewrites packet addresses as traffic crosses a router or gateway. It does not assign physical connectivity and does not create a cable, radio path, routed plant network, or Internet tunnel.

• Destination NAT changes the destination address on traffic sent toward the camera. PLC B connects to a mapped address, and the gateway forwards that traffic to the camera's real address.
• Source NAT changes the source address seen by the camera. This can force the camera's reply back through the translating gateway.
• 1:1 NAT reserves one mapped address for one real address. A bidirectional implementation normally combines the required source and destination translations.
• Double-sided NAT translates addresses at both network boundaries. Use it when each cabinet must retain its existing address plan or when the two sides contain overlapping subnets.

The mapped address does not have to be genuinely public. Engineers often call the outside NAT address “public,” but it may simply be another private address on the network between the gateways. Determine whether the intermediate network is an isolated plant network or the public Internet before selecting the architecture.

NAT also does not perform camera control. PLC B still needs an application connection that the camera understands. Avoiding PLC-to-PLC messaging removes PLC A from the control path; it does not remove the need for messages between PLC B and the camera.

Choose the connection before the translation

If the cabinets are truly disconnected, add a communication path. There are three practical cases:

• Routed plant network: Route the subnets directly when the address ranges are unique and both devices can use valid gateways. NAT may be unnecessary.
• Connected networks with address conflicts: Use 1:1 NAT or double-sided NAT to present unique mapped addresses on each side.
• Public Internet between cabinets: Terminate a VPN at gateways serving the two local networks. Carry the PLC-to-camera traffic inside the tunnel, then apply routing or NAT as required by the address plans.

Do not expose the camera or controller directly through unrestricted port forwarding over the public Internet. A port mapping is only a forwarding rule; it provides neither network isolation nor a trusted path. Use a VPN or an equivalent managed secure gateway and restrict traffic to the required endpoints and services.

Routing is the cleaner choice when both subnet plans are unique and controllable. Select NAT when renumbering is impractical, an address overlap must be hidden, or a boundary requires a stable mapped address.

Configure the end-to-end path

1. Record the current settings. Read the IP address, subnet mask, and default gateway from PLC B, the camera, and each boundary device. Identify any overlapping address ranges before changing the network.
2. Establish the carrier path. Connect the cabinet networks through the approved routed network or gateway pair. If the path crosses the public Internet, bring up the VPN before creating camera rules.
3. Select a mapped camera address. Choose an address that is valid and unique from PLC B's side of the network. Do not reuse an address already assigned to a physical device.
4. Create destination translation. Map the address used by PLC B to the camera's real address. Restrict forwarding to traffic required by the camera-control connection.
5. Create the return path. Add source translation when the camera lacks a route back to PLC B's subnet, or add an explicit route through the gateway when the network design permits it. A request without a valid return path still fails.
6. Handle the second boundary. If both cabinets use translating gateways, configure complementary rules so the forward and reply packets cross both devices consistently.
7. Configure PLC B. Point its camera connection at the mapped camera address, not the camera's inaccessible local address. Configure the application service required to control the camera.
8. Apply filtering. Permit only the two required endpoints and required services. Block unsolicited access from other networks.

Keep PLC A out of the transaction if it has no control role. Its presence on the camera's local network does not make it a router, NAT device, or automatic relay for PLC B.

Verify both packet directions

Test one layer at a time. A successful test at one layer does not prove the next layer.

1. Confirm that both network gateways are online and that the inter-cabinet route or tunnel is active.
2. From PLC B's side, test the mapped camera address using a diagnostic method permitted by the devices and firewall. A failed ping alone is not conclusive because a device may reject diagnostic traffic.
3. Inspect the NAT translation or session table while initiating a connection. Confirm that the mapped destination changes to the camera's real address.
4. Inspect the camera-side gateway. Confirm that the request exits toward the camera and that a reply returns.
5. Verify the reverse translation. PLC B must receive the reply from the address it originally targeted.
6. Open the actual camera-control connection from PLC B and exercise a harmless read or status operation before issuing control commands.
7. Interrupt and restore the network path. Confirm that the session reconnects according to the controller and camera configurations.

If requests reach the camera but replies disappear, stop changing destination NAT. Diagnose the camera's subnet mask, default gateway, source translation, and reverse route. That is a return-path fault.

Avoid the recurring NAT traps

• Using NAT as a substitute for connectivity: Two disconnected cabinets remain disconnected regardless of the mappings entered.
• Configuring destination NAT only: The camera may receive the request and send its reply toward the wrong gateway.
• Translating when routing would work: Extra address layers make packet captures, maintenance, and fault isolation harder.
• Ignoring overlapping subnets: A device treats a destination in its own subnet as local and may never send the packet to its gateway. Use unique mapped networks or double-sided translation.
• Changing controller programs before proving transport: Application edits cannot repair a missing route, inactive tunnel, or blocked firewall rule.
• Assuming reachability equals control: The camera must support the service PLC B uses, and every required connection must pass the firewall and translation rules.
• Publishing industrial devices to the Internet: Direct port exposure expands the attack surface. Put the traffic inside a controlled VPN and limit endpoint access.
• Documenting only real addresses: Record real addresses, mapped addresses, translation direction, routes, and rule ownership. Technicians need both views to troubleshoot the path.

FAQ