Nothing But NAT - Part 2
What should my NAT appliance be able to do?
Given everything you just learned about NAT in Part 1, one question that may remain is “Are all NAT appliances equal? If a device says NAT on the datasheet, is that all I need to see to be confident it can tackle my application?” The answer to that is a…RESOUNDING NO :) Ultimately if I’m selecting one from scratch, the ideal appliance can accomplish:
1) Destination NAT
Bonus points if the appliance automatically adds the Alias IP assignment to the required interface based on the DNAT rule creation.
2) Source NAT+
One note here is that if an appliance supports Source NAT it likely by default Source NATs to the interface IP assigned to the appliance. In many applications this is sufficient but there are certain applications (like trying to do AB/Rockwell Produce/Consume implicit unicast messaging across the NAT boundary), where you’ll want the ability to Source NAT to ANY IP you designate. Some appliances offer ZERO Source NAT, some offer Source NAT to interface IP, and some can do this extra step. I’ll call this “extra” capability Source NAT+ and mention I always want this just. in. case.
3) Double NAT
4) Bi-directional capability
Interestingly there are some NAT appliances out there that basically can only perform a Public/External/WAN to Private/Internal/LAN Destination NAT and that’s it. You want to initiate something from the private side toward the public with no default gateway on one of those? You’re out of luck.
5) Qualification/Conditioning of NAT application
Believe it or not, there are cases where you need to apply a Double NAT (including Source NAT+) towards a PLC but only when the traffic is from a specific PLC on the public side; however if anyone else tries to talk to the same PLC you want a run-of-the-mill Double NAT. I say this because…I just had this happen :) In order to be able to accommodate this scenario you need the ability to “qualify” your NAT rules by providing match rules: perform X translation, but only when the traffic is from Y source IP, etc.
Easy peasy lemon squeezy, right?
Unfortunately, far from it. If you go survey the industrial NAT appliance/router/firewall market, you’ll find support for ALL of these capabilities is a complete mixed bag. Well actually what you’ll find is that it’s practically IMPOSSIBLE to identify much of this in vendor documentation, certainly not easily in a datasheet. Sometimes the vendor has a strong User Manual or Knowledge Base articles that might help you piece some of the above together but this is egregiously hit-and-miss.
What else do I need to know?
If you already have an existing appliance deployed but it seems like your application can’t be accomplished, there are sometimes more than one way to meet the end goal. Example if you’re missing Qualification but have the circumstance I mentioned earlier, you can maybe get away with creating two different Double NAT rules with different Alias IPs; have your PLC target the first rule IP and the other hosts target the second. Seem inefficient to tie up two IPs to reach the same target? Sure. But saves you the cost of another appliance.
My head hurts. I think I have a NAT application. What do I do now?
Stress no more - we got you fam. We’ve used almost every NAT appliance out there, and have a ton of them in our lab for demo or proof of use-case. Just ping us and we’ll get you through it!