Nothing But NAT - Part 1
Let’s say you have a SCADA Server 10.10.10.100 /24 in your main OT Network and you just commissioned a new OEM machine with multiple devices including PLC 192.168.1.10 /24.
You’d like your SCADA Server to be able to reach this OEM PLC but:
You can’t re-IP the OEM network for any number of reasons not limited to but including:
a. modifications may void warranty
b. significant effort to re-IP
You can’t deploy a router to directly interface to the OEM network for any number of reasons not limited to but including:
a. The OEM network IP Schema conflicts in your OT network schema in some way
b. This OEM network is one of several identical ones and you can’t integrate multiple of the same IP Schema
If you have several identical OEM machines, you don’t want to re-IP each machine AND deploy router(s) to directly interface to the OEM network because:
a. See 1a and 1b above
b. Maintaining 10 separate copies of the PLC program with the only change being IP address seems cumbersome. Need to make a PLC change a few months in, make it for machine 1, Save as for machine 2 - change IP, Save as for machine 3 - change IP…definitely more cumbersome with high machine counts.
Enter Network Address Translation or NAT. This is a feature found in many industrial routers or firewalls or perhaps in a dedicated NAT appliance (more on this later). A NAT device can leverage different techniques discussed further below to modify the IP header and allow two dissimilar networks to communicate through the modification of IP headers as needed to meet the application need.
Destination NAT (often seen as “1:1 NAT”)
If the OEM PLC has a default gateway (DG) configured equal to the NAT appliance inside interface IP, DNAT has you covered. All that is required is the allocation of a virtual or alias IP representing the OEM PLC as if it sits directly on the OT network and configuration of DNAT. Above we select 10.10.10.10 /24 (a free address in the OT network) as our virtual IP and define the mapping to the real IP (192.168.1.10) of the PLC. As the name implies, in Destination NAT the Destination IP in the IP header is modified by the NAT device per a configured NAT rule. Remember though, for this to work, the OEM PLC must have its DG properly configured, with its DG assignment matching the NAT appliance inside interface assignment. There are many reasons why this might not be the case or desired, and so often DNAT alone is insufficient.
Source NAT
So what if that OEM PLC does not have any DG configured, or has some DG configured for another IP and can’t be modified? Are we stuck? Source NAT can help us here. In most cases, modifying the Source IP in the header to the NAT device inside interface is sufficient as then traffic to the OEM PLC appears to be coming from something “local” (from the same network) and therefore it requires no DG to communicate back. Source NAT is simply modifying the Source IP in the IP header.
Note that unlike DNAT, SNAT is rarely applied alone (see Double NAT below); the one exception is in the case of dedicated secure remote access solutions. These solutions from Secomea, eWON, Tosibox, and many others often utilize SNAT (typically without the user configuring it, just baked into the solution) to facilitate remote access to devices even when those devices don’t have their DG pointing back to the remote access appliance.
Double NAT (DNAT + SNAT)
So this is the magic. If we combine DNAT and SNAT, sometimes referred to as a Double NAT, we can achieve connectivity from the SCADA Server in the OT network to the OEM PLC regardless of the PLC’s DG configuration.
Keep in mind a single NAT device can support multiple rules so you could create rules to facilitate communication to multiple devices in the OEM network above with just a single NAT device. Hopefully this overview gives you an idea of how NAT is a great tool to have in the tool belt. In future posts, we’ll discuss a few more variants, use cases, and after configuring countless NAT applications using many different existing appliances, why James Joy and I decided to build one.
***CLARIFICATION***
All discussions in this “Nothing But NAT” series is regarding traditional NAT which is performed across a routed/L3 network boundary. This qualification is only necessary because Cisco introduced the lesser known and utilized L2 (hardware) NAT in some of their IE_000 products (and by association in the Allen Bradley/Rockwell Stratix equivalents). I have some cautions against the use of L2 NAT in OT environments, but alas, this is a subject for another day.