When to NAT

[jonathan connParticipantKarma: 35Rank: Padawan]

So stemming off my other topic regarding the Stratix 5700, when is it appropriate to use NAT?

Background info:  I’m in the IT department and primarily manage the network as a whole (the Juniper backbone that runs through the whole plant).  The PLC guys work in the maintenance department and handle all the PLC stuff.  When I was hired in, the majority of PLC devices within a cabinet were connected to the network via unmanaged switches.  We still have a few of those, but a lot have been removed and replaced with Stratix switches.  Over the past couple of years, we’ve installed new plant equipment which use servo motors managed by PLC devices.  We were told that because of how chatty these devices we needed the Stratix 5700 specifically for the NAT feature to contain the traffic.  We had issues implementing this because of how our backbone network was setup regarding VLANs which has been taken care of.

Based on Fred’s video showing how to implement NAT on the 5700 and my experience testing it out over the last couple weeks, I’m not entirely convinced we need to worry about implementing NAT for traffic containment.  It seems the main benefit for NAT isn’t so much to contain traffic, but to allow PLC devices to have the same IP address to make setup and replacement easier (especially when paired with DHCP persistence).  When I describe how I setup and tested NAT, the PLC guys don’t seem to agree with that setup because they want to restrict who/what has access to those devices.

Thanks.

[PLCGuruKeymaster]

Hi Jonathan,

Traffic containment is definitely one advantage of using NAT configurations to isolate your “work-cell traffic”. The other advantage, as you mention, is IP address reusability. Virtually everything coming onto the production floor these days is an IP-based device, from PLCs, to HMIs, to “Smart” IO blocks, to Servo drives, and the list goes on and on which will quickly eat-up IP addresses on any subnet.

NAT provides a mechanism for controlled access, security, isolation and as you mention IP-address reusability. The latter becomes very useful specifically for dealing with outside OEMs and standards. Your controls engineers can now write a standard around the addressing convention for automation devices coming into your facility.

For example, you can standardize things like what address your PLCs, HMIs etc:

PLCs – 192.168.1.10 – .19

HMIs – 192.168.1.20 – .29

Drives – 192.168.1.30 – .39

You get the picture. This becomes very easy now from a maintainability stand-point and again it standardizes addressing schemes. There are of course a whole list of other advantages with going with managed switches in the work zone, remote management, traffic analysis, DHCP persistance, automatic DHCP assignment and all things I’m sure you’re very aware of.

This is a good thread and hopefully one that will get some good conversation going.

-Fred

[Jim ManleyModeratorKarma: 262Rank: Jedi]

Jonathan –

NATing is usually done when you have to hide the NAT’d network for addressing or security reasons.  NATing will also (usually) keep broadcast traffic from traversing the NAT device.

Prior to “retiring” and jumping into my dream job at the distillery, I was the chief IT architect for a major aerospace contractor.  One of the last projects I worked on was interconnecting a bunch of stand alone PLC networks and our business enterprise network.  Both sides of the “house” had multiple concerns about doing this.

From the IT side, the IT security guys were horrified by what they saw in the PLC networks (devices that hadn’t been patched in years, stuff running on OSs like Windows CE and Windows 98,  etc.) and had no desire to connect those networks to the business network without having some sort of control point (e.g., firewall) in between the networks and a plan for getting rid of the old, offensive systems/software.

The PCL guys, on the other hand, were terrified that connecting to the business network would reek havoc on the PLC systems by pushing out updates, flooding the networks with unneeded traffic, etc.   They also expressed the same concern about people being able to access the PLC network devices.

The PLC network device access is a valid concern.  A lot of the devices on a PLC network are implementing web based front ends that need to be secured.  I’ve found that the PLC drivers aren’t used to having to manage the security of their network because they’ve always been stand alone networks.  Reminds me of the 90’s when I first started integrating separate networks together.

This collision between Operational Technology (OT) networks (PLC networks) and Information Technology (IT) networks (business networks) has become a hot topic with the PLC and network vendors.  AB, in conjunction with Cisco, has been pushing this topic a lot lately.  Here’s a link to their converged network document.

You can address this concern with Access Control Lists on the devices doing the NATing, if they’re capable implementing ACLs.  My approach at the distillery involves using a port on one of my firewalls.  This approach allows me to maintain segregation between my PLC networks and the business network.  I can also use the firewall to implement rules that allow the devices on the PLC network to communicate with the appropriate business systems and vice-versa.

Jim

[Author]

Posts