If you want to give a Network Architect sleepless nights, just give him overlapping IP addresses and mention 2-way NAT.
Overlapping IP addresses happen for multiple reasons:
- Mergers and acquisitions – forgiveable. Most likely someone has to readdress
- Accessing a third party resource – can happen, but it shouldn’t
- Poor planning – probably the most frequent reason. And it’s usually Daves fault
The Scenario
So, let’s take a hypothetical situation that you may face in today’s “build anything anywhere” world.
You have an organization using the 10.0.0.0/8 CIDR block for IP addressing. For historic reasons, the DC is using 2 x /16s for their production VLANs (10.0.0.0/16 and 10.1.0.0/16). It happens.
Enter the developers, who are busy working on a cloud-native application in AWS. They’ve been told to use a CIDR in the 10.0.0.0/8 block and, without understanding longest prefix matches and other nitty-gritty, have used 10.0.1.0/24 and 10.0.2.0/24.
All perfectly reasonable as long as these 2 worlds never have to speak.
The VPCs need to speak to each other
No problem. Our clever developers didn’t use overlapping IP addresses between the 2 VPCs, so we can simply deploy a transit VPC and with some help from Aviatrix get IP connectivity between the 2 VPCs.
Life is still good. Our VPCs can speak to each other and the on-premises world is segregated from any issues that may happen with the Cloud.
On Prem needs to talk to the Cloud
Should have seen this coming. The app is a success and needs to integrate with the company ERP solution on-premises.
No problem. Enter Aviatrix with Site2Cloud and we can simply and securely connect these 2 worlds.
Aviatrix has cleverly taken care of the IPSec tunneling and propagation of routing information.
But, there’s a problem with the routing:
- Servers in VLAN 200 can no longer reach certain servers in VLAN 100
- VLAN 100 can reach none of the machines in the cloud
- VLAN 200 can reach the cloud machines
The problem is clear: VLAN100 and the cloud VPC CIDRs are overlapping. Any connectivity between them will at best not work and at worst create unforeseen issues.
Mapped NAT
Enter the solution: we configure Mapped NAT on the S2C Aviatrix device. No other device configs need to be changed to make this work.
Let’s define some terms:
- Local Subnet: This is local to the Aviatrix S2C device, meaning the Cloud subnets to be NAT’d
- Remote Subnet: Again, remote to the Aviatrix S2C device, meaning the on-premises subnets to be NAT’d
- Real: The IP address as they are defined on the end hosts themselves
- Virtual: The IP address that the real IP will be NAT’d to
Anyone who has had to worry about “nat inside vs nat outside” and “inside local vs inside global” and which interface is “inside” and which is “outside” will appreciate the simplicity here.
So, the S2C gateway has taken care of 2 key things in order to make this work.
- It takes care of tracking the NAT state as it traverses the gateway
- It takes care of routing updates to ensure the Virtual addresses are reachable
Let’s look at how the traffic flows:
As you can see, each end device targets the virtual IP address of the other side. The S2C gateway manages the state and translation.
You’ll also notice that the host portion of the IP address maps to the virtual IP.
This of course implies that DNS is in on the game. But that’s a problem for Dave to solve.
