Using NAT to Solve Overlapping Network Addresses Issues in AWS

5 min readApr 27, 2019

In cloud networking, the IP address overlap problem occurs frequently. Here are some common reasons.

Your AWS VPCs are not planned, everyone starts with the default 10.0.0.0/16 and grow organically.
You SaaS service in the cloud need to connect to your customers and partners for secure data transfer or secure access and you have no control over their network CIDR range.
Your organization acquires a new company, their network CIDRs overlap with yours.

Network Address Translation (NAT) is a common technique to connect two networks with overlapping CIDRs. Often times, the connectivity between these two networks need to be encrypted with IPSec.

Things get more complex if one side of the network cannot do any NAT function. For example, you cannot require your partner or customer to perform NAT function on their end. Sometimes, your partner or customer network can only connect to a public IP address to avoid internal network packet looping problem.

This blog provides an example on how to use advanced NAT function applying to only one side of the network and connect two overlapping CIDR networks. If you learn this example, you will be able to tackle overlapping network address problems of all sorts.

For simplicity, we use two identical AW VPCs, VPC-1 represents your network and VPC-2 represents your on-prem, partner or customer network, as shown below.

VPC-1 CIDR =  10.17.0.0/20, instance-1 in VPC-1 has an IP address 10.17.4.179.
VPC-2 CIDR = 10.17.0.0/20, instance-2 in VPC-2 has an IP address 10.17.7.81.

The Solution

The solution is to build a IPSEC tunnel between VPC-1 and VPC-2 and apply both source NAT (SNAT) and destination NAT (DNAT) on VPC-1 gateway (I will explain the gateway in the next section, for now assumes it is a router). The packet flow is demonstrated as below:

instance-1 sends a packet to instance-2 with virtual destination IP address, say it is 172.16.0.43. From instance-1’s point of view, the destination instance is 172.16.0.43.
When the packet arrives at the VPC-1 gateway, the gateway does DNAT on the packet to translate the virtual destination IP address to 10.17.7.81 which is the instance-2 IP address.
The gateway at VPC-1 then translates the packet source IP address (10.17.4.179) to a virtual source IP address, say it is 192.168.0.43.
The packet then arrives at VPC-2 with destination IP address 10.17.7.81 and source IP address 192.168.0.43. From instance-2’s point of view, instance-1’s address is 192.168.0.43.
When instance-2 sends a packet to instance-1, the destination is 192.168.0.43.
When the packet arrives at the VPC-1 gateway over the IPSEC tunnel, VPC-1 gateway translates its destination IP address from 192.168.0.43 to 10.17.4.179.
The VPC-1 gateway then translates the source IP address of the packet from 10.17.7.81 to 172.16.0.43.

The Configuration Steps

I am going to use a solution from Aviatrix Systems. Aviatrix provides a Metered AMI on AWS Marketplace. Follow the Startup Guide to subscribe and launch with a Cloudformation script. After you launch the Controller and go through on boarding, follow the steps below to configure.

Step 1: Follow the Site2Cloud workflow to launch gateways

(You can follow the gateway launch instructions in this. Leave optional parameters unchecked.)

For the above example, we also launch a gateway in the VPC-2 to emulate an on-prem environment.

Step 2: Create a Site2Cloud tunnel

Go to Aviatrix Controller Console -> Site2Cloud.

Click “+Add New”. Fill the form and click OK. Select “Unmapped” for Connection Type field.

2.1 On the VPC-1 gateway side

On the VPC-1 gateway side, the Local Subnet field should be 192.168.0.43/32, and the Remote Subnet field should be 10.17.7.81/32, as shown below.

2.2 On the VPC-2 gateway side

On the VPC-2 gateway side, the Local Subnet field should be 10.17.7.81/32, and the Remote Subnet field should be 192.168.0.43/32, as shown below.

Wait for the tunnel to come up.

Normally you’ll need to download configuration, but in this example since both ends of the network are VPCs, you can simply configure each site2cloud tunnel. Make sure the Pre-shared Keys are the same for both ends. In this case, I used “Aviatrix101#” as our pre-shared key.

Step 3: Configure DNAT on VPC-1 Gateway

This step is to configure the gateway to translate the destination IP address 172.16.0.43 to the real private IP address 10.17.7.81, before routing happens.

At the main navigation bar, click Gateway. Highlight the gateway, in this case, the VPC-1 gateway, click Edit.

Scroll down to Destination NAT. Follow the instructions here to configure, as shown below.

Step 4: Configure SNAT on VPC-1 Gateway

This step is to translate the packet source IP address after routing happens. In this example, the address is translated from 10.17.7.81 to 172.16.0.43 for packets going from on-prem (VPC-2) to VPC-1, and 10.17.4.179 to 192.168.4.43 for packets going from VPC-1 to on-prem (VPC-2).

For the same VPC-1 gateway, configure SNAT as shown below. Notice we entered “Dst CIDR” as qualifier to reduce the scope of the rule as a good practice. And the reason that the address is 10.17.7.81/32 is that the destination has already been translated after the DNAT rule before routing happens.

Step 5. Test Connectivity

From instance-1, you should be able to ping instance-2 by “ping 172.16.0.43”. From instance-2, you should be able to ping instance-1 by “ping 192.168.0.43”. Make sure you have instance Security Groups inbound rules configured properly.

Done.

Epilogue

Since the publishing of this blog, we have developed new techniques that significantly simplifies the solution in solving the overlapping network address issues. Specifically you can do bi-directional network address to network address translation without individually specifying IP addresses, thus allowing for deployment at scale. To learn more, refer to Sub-10 Seconds Failover Time in Overlapping Networks.