Best Practice for Isolating PLCs and Manufacturing Equipment

When a new machine comes into our facility the PLCs and Variable Frequency drives typically come with their IP addresses in the 192.168.1.XX or 192.168.0.XX ranges. Our IT network is in the 10.0.192.0 - 10.0.207.255 range.

My first thought is to let the manufacturers keep using what they are used to *(192...)*using. Then we would isolate each machine network. One thought was to use a router at each machine and have the machine network hooked up to the LAN side and out IT network to the WAN. We could use port forwarding to access the PLCs from the IT network to capture manufacturing data or for purposes of modifying the ladder logic in the PLCs.

Is my approach acceptable? Is there a better method? I am extremely interested in what others are doing to accomplish the same thing.

bgreer5050 said:

When a new machine comes into our facility the PLCs and Variable Frequency drives typically come with their IP addresses in the 192.168.1.XX or 192.168.0.XX ranges. Our IT network is in the 10.0.192.0 - 10.0.207.255 range.

My first thought is to let the manufacturers keep using what they are used to *(192...)*using. Then we would isolate each machine network. One thought was to use a router at each machine and have the machine network hooked up to the LAN side and out IT network to the WAN. We could use port forwarding to access the PLCs from the IT network to capture manufacturing data or for purposes of modifying the ladder logic in the PLCs.

Is my approach acceptable? Is there a better method? I am extremely interested in what others are doing to accomplish the same thing.

Click to expand...

We leave the OEM equipment in the 192.168 range and use a local layer 2 switch to connect it to whichever of our PLCs is supervisory for the area. It costs us an ENBT or EN2T for each OEM system, but that's what we use for isolation.

We specify and have our purchasing department on board for buying Rockwell PLCs on OEM equipment so we can program the PLCs over our network on RSLinx. If data is required to pass on to other HMIs or our DCS we use messaging.

It is a pain to keep track of all of the data, and the various addresses that it has as it goes through the OEM HMI, OEM PLC, supervisory PLC, and DCS or Pi system. But once it is set up we can troubleshoot problems in communication or in the OEM system fairly well.

I'm not suggesting this as a 'Best practice' .. just what we are doing. We don't allow the OEM systems *ANY* access to our network. That's why they stay at the non-routable 192.168 address space. We have one OEM system - an HVAC system, where they installed a cell modem for their own remote troubleshooting. It goes into the micrologix 1500 on the serial port. Technically they could use that opening to hack our system, but they would need the correct versions of all of our software, and enough expertise to browse through ethernet cards on various ControlLogix backplanes. It's still a risk, but a small one.

Same as above....and EN card for the plant network on the 10.10.x.x and a second EN card for the local machine network on the 192.168.x.x network.

Follow Up

Could my issue be handled with a Stratix 5700 Managed Switch?

bgreer5050 said:

Could my issue be handled with a Stratix 5700 Managed Switch?

Click to expand...

Probably, but your networks are physically connected now. Do you want something on your low level machine network like a drive be able to potentially take down the rest of the facility? I had a customer recently that lost weeks of downtime because one technicians laptop had an app that kept trying to hit an internet server and flooded the plant network with packets that kept dropping off PLC ethernet cards. Physical isolation is the best policy, IMO.

We have 2 networks, one for manufacturing and one for management.
only certain ones in management can see the manufacturing side.
this keeps unwanted users from modifying plc programs, databases, and other key information.

you could specify to the oem what the ip addresses were to start with and save heartache.

regards,
james

How do you keep the networks separated?

So do you consider using 2 EN cards a physical separation?

Thanks

bgreer5050 said:

So do you consider using 2 EN cards a physical separation?

Thanks

Click to expand...

I do, because the networks aren't physically connected, except through the backplane. So you have three to four devices (2 ENBTs and the backplane and whatever management tool is routing the data...IE PLC) that would have to fail for one network to potentially affect the other. With a switch, it's just one.

I highly suggest looking into using a 9300-ENA NAT device. It basically has 2 network ports. You place on your the "public" (10.xxx) network and the other on the "local" 192.xxx network. You then construct a NAT tables in the 9300-ENA that translate an address on the public side to an address local side. The only thing you may have to change on your local 192 network is the gateway. The gateway on the local network must be set to the local ip address of the 9300-ENA.

One big advantage of NAT over using multiple network cards is A lot of PLCs such as the L1,L2,and L3 CompactLogix do not have multiple network cards available. NAT is also more cost effective.

setup 2 VLANS and an NAT...done I like 5700s for this but they are more expensive than an enbt by a long shot sooo there is also that to think about. I like the NAT more because I can access the ENTIRE machine from my desk not just the PLC, but all 27 servos 14 VFDs, PLCs, everything from my desk. If I ever have to get out of my chair for anything, that maintenance guy better have a damn good excuse for coming to get me

I second the suggestion of the 9300-ENA.

It solves a lot of problems and it relatively cheap. It will only pass date from the specific address that you map.

Slightly off-topic; I don't let vendors use 192.168.1.1 in any machine we buy for our plant. I've had several instances of some ethernet/IP device defaulting to it's unconfigured state (Stratix 6000 switches have done this to me) or someone plugs in an unconfigured device of some type and then it creates and IP conflict with the PLC or some other device that is supposed to be at .1

I am going to try the 9300-ENA device. What if I use a different subnet than the office network instead of a V-Lan? Would this be acceptable? Pros? Cons?

bgreer5050 said:

I am going to try the 9300-ENA device. What if I use a different subnet than the office network instead of a V-Lan? Would this be acceptable? Pros? Cons?

Click to expand...

Yes, this is exactly what it's made for, no cons.

For example, my machine networks are 192.168.1.xxx and I translate a few devices to 10.43.26.xxx or something like that.

I think there is also the 1783-NATR which might be a little less expensive. I haven't used it but my understanding is that it's the same as the 9300 but with a few less features (only up to 32 translations vs 128, etc).

B