Connecting PLC's on different subnet to Gateway

Francisco, it's easy with a multi-NAT router on each machine.

Let's say I have several identical machines. It can make life simple if every machine uses the same IP address for the PLC, etc. On the router you just set a 1 to 1 mapping of a unique WAN address to each LAN address. (You do need to configure the gateway setting on each LAN device if you want them to be able to reply to external requests - or use port masquerading on the LAN to make it look like external requests are coming from inside the LAN.)

In addition the router firewalls can be configured to only accept traffic from certain address ranges and can block traffic from other machines, if required.

If IT ever force a subnet change then it's just a matter of configuring the routers using a web browser. Otherwise it means getting out the software for each programmed device and reconfiguring them.

It's brilliant.

2 Likes

Exactly the point I am trying to make. Is in this moment when it makes sense and configure the network architecture to meet the Purdue/ISA 95 with cybersecurity in mind. I advise of creating an architecture diagram with all the firewalls, switches showing what ports are open and what app needs them.

Regarding your PLCs, are the IPs in your device network or on your plant network? because if you are connecting to the PLC through your device network you should consider changing it.
Work with the IT.

Is not a question of making my life easier, there are other considerations, Cyber security, remote access, firewall consideration, etc. The minute I see WAN I imagine remote access which means ports need to be open through the main firewall.
I don't know your network and your requirement, but I find it hard to believe that IT would allow access from different IP to go to different internal IPs be it PLC or servers. If you do, you are a lucky man.

Another possible option is adding an additional ethernet module to the control system allowing access from 2 subnets. Adding additional modules may or may not be possible I did not see the control system mentioned. Usually this route is more expensive but upfront cost is not everything, keep in mind who will be supporting these systems. Maintenance departments typically know how to troubleshoot PLC modules. IT departments do not.

If you explore adding a module I suggest thorough testing before making a decision. An example: Adding an ethernet card to a AB CLX system is basically the same as directly connecting to a CLX CPU. A Siemens ET200S CPU with an additional ethernet module has the limitation of only being able to use the OPCUA server from the ethernet connection on the CPU itself. ET200S can use IA Siemens driver on the additional module though. These are just examples, your system could be different.

Additionally, there is also the question of support. In our operation NAT routers are maintained by OT maintenance and controls. IT allows us to connect them, but OT networks are segmented, protected by firewalls, and access controlled. OT networks are not accessible from off site.

Finally, I second the use of Skorpian EIPR-E NAT. From a controls perspective they are easy to use and priced right. I have used many different OT focused NAT such as Ewon, 1783-NATR, Skorpian, and more. IT focused ones like Ubiquiti Edge Router X take more IT understanding to get going, but are more configurable. Skorpian is very easy to maintain and configure if you do not need to worry about IT networks down the line.

You are spot on with this! Yes each machine would need a NAT router unless you had a separate NIC at each machine that could be assigned its own unique IP address and could even put on a different VLAN but if none of these are possible its a NAT.

Keep in mind you even could use a simple device like a PI or similiar to transverse this that is running a Linux router distro if you follow what I'm saying.

You could also run a hypervisor with a trunk full of VLANs and have it run a docker container for each machine VLAN. Each container would be handed two virtual NICs, one for the facility side, one for the machine VLAN. That docker container would be set up with the NAT rules (in both directions, as needed). For truly identical machines, it could even be multiple copies of the same docker config, just with different VLAN assignments.

About as cheap as you can get, and probably more IT friendly (well, modern IT) than just about anything else.