Nothing But NAT - Part 3
What if I have several overlapping machines/cells/islands of the same IPs?
After getting to know the NAT basics a common question that comes up is “What do I do if I have several machines/cells/areas that all have the same IP range?”
The traditional answer to this question is that you need a NAT appliance for each, like shown below:
That’s because NAT appliances are by their nature routers and a single router traditionally can’t have multiple interfaces or routing table entries that overlap as that would create a conflict. It wouldn’t be able to differentiate one 192.168.1.X island from another.
This traditional answer is often met with a mix of confusion, surprise, or sometimes downright shock as sometimes that quantity of cells/machines/areas isn’t just two but its twelve, thirty six or even two hundred! The commercial prospect of having to purchase dozens of NAT appliances and the technical and maintenance prospect of taking on dozens of individual appliances is often a project-killer.
So, what can we do if a customer has a project with multiple overlapping IP cells and doesn’t want to purchase/maintain dozens of NAT Appliances?
ENTER THE NGFW (Next Generation Firewall)! NGFWs like Fortinet’s FortiGate range of firewalls have tons of virtualization capabilities. We can virtualize interfaces (VLANs and subinterfaces), routing tables (VRF - virtual routing and forwarding), and practically entire firewalls (VDOMs, ADOMs, etc.).
Below we drew up an example of seven overlapping cells with every cell PLC addressed identically 192.168.10.80 /24. Whereas this normally would require one NAT appliance per cell, we can perform NAT for these seven cells using a SINGLE FortiGate.
How many overlapping cells could I support on a single appliance?
A key note about the drawing, I show the first three cells connecting directly to the FortiGate. This could be a connection directly to the PLC or more likely a connection to the existing cell switch (not shown). Still though, this might seem to imply the limitation of “how many cells” could be connected coming down to the number of interfaces on the FortiGate. NOT TRUE :) I show for cells 4 through 7 that we can leverage a managed switch, VLANs, VLAN trunking, and subinterfaces to connect multiple overlapping cells to one interface on the FortiGate thereby demonstrating that the limiting factor here is NOT physical interface quantity.
Here’s a picture in fact from the field where we deployed this solution for a major automotive manufacturer to address NAT for nine overlapping cells and notice everything comes into a 24 port FortiSwitch on the bottom and only two cables actually are required to the FortiGate above.
So if physical interfaces aren’t our bottleneck here what then, IS the limit? We originally benched a solution using VDOMs on FortiGate which were limited on models we regularly use to 10 but then we solved it using VRF and as you can see in the doc screenshot below these have a MUCH higher ceiling. Naturally we’d want to size the FortiGate accordingly but it’s pretty cool to see how high the ceiling can be!
In the traditional solution, if a NAT appliance fails you only lose comms to one machine. In this solution, if the NAT appliance fails you lose ALL the cells at once. This is dumb.
I agree with this observation about a single appliance. BUT, it’s worth noting for applications where the NAT communication is critical you could deploy High Availability pairs or even Cluster NGFWs eliminating the single point of failure. With the right cell counts the cost savings of a pair of NGFWs over individual NATs can still be substantial and you have hardware redundancy covered.
This seems cool, but technically complex. I changed my mind and would rather stick to individual appliances.
I agree; this solution is not a one-size-fits-all and overlapping NAT configuration using VRF is not simple.
First, I typically only bring up this solution when the situation presented to me is more static in nature. We help configure and test and for the most part there aren’t a lot of changes expected after deployment. Second, we regularly have to supply SOP docs for even basic NAT appliances given the UIs can often be confusing. At the point you’re reviewing SOP docs to make changes we certainly can provide similar for the setups described above. Ultimately the proof is in the pudding and we have customers running both solutions successfully. More options to discuss are better than less and it’s up to the customer to decide which is best for them after some pros/cons discussion.