How to solve overlapping IP addresses using the Aviatrix Cloud Network Platform

You have an awesome application running on AWS, and now your customers and partners want a private network connection to it. Great! Except for one problem: their site is using the same private IP address range as the one in your Amazon Virtual Private Cloud (Amazon VPC). This will prevent any communication until you resolve this situation using Network Address Translation (NAT). The old-fashioned way to solve this is with virtualized instances of traditional on-premises routers where NAT is complicated to configure, difficult to manage, troubleshoot, and scale. In this post, I will show how to implement a modern solution built for the cloud, provided by Aviatrix, and made available to you through AWS Marketplace.

Aviatrix is a premier AWS Partner providing a cloud-native networking and network security platform, giving you greater visibility and control over your network architecture in the cloud. Solving the overlapping IP address problem with NAT is one of the many capabilities of the Aviatrix platform. In this post, I will show how to use Aviatrix to connect your Amazon VPC to a remote network using the same overlapping IP address range assigned to your Amazon VPC.

Solution overview

The Aviatrix Cloud Network Platform consists of three main components. The Aviatrix Controller centrally manages a deployment of Aviatrix Gateways that forward packets in and out of your Amazon VPCs. And Aviatrix Co-Pilot provides visibility and troubleshooting tools for your Aviatrix-powered cloud network.

The following diagram illustrates the problem to be solved by following the steps in this guide. The network engineer in this diagram is trying to connect a remote network to an Amazon VPC network, both of which are using the same 10.1.0.0/16 IP address space.

To solve this problem, I will show how to deploy an Aviatrix Controller and Aviatrix Gateway in your AWS account. Then I’ll show how to connect the two networks together with IPsec VPN and assign Virtual Subnets for this connection that do not overlap.

Aviatrix can also be used to connect two Amazon VPCs that have overlapping IP addresses using a different approach not covered in this guide. Or you can use the method in this guide and think of the remote network as another Amazon VPC.

Solution walkthrough: How to solve overlapping IP addresses using the Aviatrix Cloud Network Platform

Step 1: Launch the Aviatrix Controller

1.1. Subscribe to the Aviatrix Secure Networking Platform Metered – CoPilot and 24×7 Support listing in AWS Marketplace.

1.2. Create a new VPC in your AWS account where you will launch your Aviatrix Controller. To do this, open the Amazon VPC console at https://console.aws.amazon.com/vpc/ and select Launch VPC Wizard. Choose the option VPC with a Single Public Subnet and then choose Select. Enter a name such as Aviatrix Controller for your new Amazon VPC and select Create VPC.

1.3. To get your Controller launched and associated with your AWS account, follow the steps 1.1 through 3.7 in the Aviatrix AWS Startup Guide. At step 2.5 in the Aviatrix AWS Startup Guide, be sure to select the Amazon VPC you created in step 1.2 here and choose its public subnet.

You can launch the Aviatrix Controller in any existing Amazon VPC that has a public subnet. I recommend creating a new Amazon VPC for your Aviatrix Controller and CoPilot, but it’s not a requirement.

Step 2: Deploy the Aviatrix Gateway

At this point, your Aviatrix Controller should be running in your AWS account and able to launch Aviatrix Gateways. Next, you use this controller to launch an Aviatrix Gateway in the Amazon VPC that will be connected to the remote network. I call this your Local Amazon VPC.

The Local Amazon VPC, where you launch the Aviatrix Gateway, must have a public subnet. This means that the Amazon VPC has an internet gateway attached to it and there is a subnet associated with a VPC routing table that contains a default route to the internet gateway. This is necessary because the Aviatrix Controller manages the Aviatrix Gateways over secure public internet connections. To launch an Aviatrix Gateway in your local Amazon VPC, do the following:

2.1. Access the Aviatrix Controller web UI by opening a browser window to https://AviatrixControllerEIP, where AviatrixControllerEIP can be found by going to the AWS EC2 console. Choose the Controller instance and locate its public IP address.

2.2. From the Aviatrix Controller web UI left-hand menu, select Gateway, then select Create New.

2.3. In the Cloud Type drop-down menu, select AWS. From the VPC ID drop-down menu, select your Amazon Local VPC. From the Public Subnet drop-down menu, select the public subnet of the Local VPC.

2.4. For Gateway Size, select the instance size for your gateway. The t3 instance family is fine for testing purposes. For production deployments, I recommend non-burstable instances, such as the c5 instance family.

2.5. Choose Create. After a few minutes, the Aviatrix Gateway will be launched in your Local Amazon VPC, and you’re ready to proceed.

Step 3: Connect to the remote site and define virtual subnets

You are now ready to establish a connection to the remote site. Upon defining this connection, you specify virtual subnets that do not overlap. The Local Amazon VPC and the remote site communicate with each other using the virtual subnets instead of the real ones.

The following diagram illustrates the final solution. The Local Amazon VPC is assigned the virtual subnet of 100.64.2.0/24, and the remote site is assigned 100.64.1.0/24. The Aviatrix Gateway connects to the remote site with IPsec VPN and performs NAT. Thus, it maps the virtual subnets to the real subnets as packets move through the gateway.

To establish a connection to the remote site, do the following:

3.1. Navigate to the Aviatrix Controller web UI. From the left-hand menu, choose Site2Cloud, then choose Setup, followed by Add New. This brings you to the Create New Connection page, where you enter the details of the IPsec VPN connection and the virtual subnets. For this blog post, I am focusing on the details needed to make the virtual subnets work. In the VPC ID/VNet Name drop-down menu, choose the Local Amazon VPC where you deployed the Aviatrix Gateway in step 2.

3.2. For Connection Type, choose Mapped. For Tunnel Type, select Route-based.

3.3. In the Primary Cloud Gateway menu, choose the Aviatrix Gateway you deployed in Step 2. Provide the IPSec VPN connection settings for the connection to the remote site. Just below the IPSec VPN settings, specify the virtual subnets to be used for the remote site and your Local Amazon VPC.

3.4. The Remote Subnet (Real) is the real IP network used at the remote site. In this field, you can enter the full 10.1.0.0/16 CIDR range, or you can specify a smaller subnet such as 10.1.1.0/24. As a best practice, use identical subnet mask lengths for the real and virtual subnet. In this example, I am showing /24 for both the real and virtual subnet.

3.5. The Remote Subnet (Virtual) is the IP network that your Local Amazon VPC uses to communicate with the remote site. Set this value to an IP network range that does not overlap with anything else in your network. Use the same subnet mask you used for the real subnet above. In this example, I am showing 100.64.1.0/24.

3.6. The Local Subnet (Real) is the IP range you are using in your Local Amazon VPC that overlaps with the remote sites real subnet. Set this to the real IP subnet of your Local VPC. In this example, my real local subnet is 10.1.1.0/24.

3.7. The Local Subnet (Virtual) is the IP range that the remote site uses to communicate with your Local Amazon VPC. The subnet mask length should be the same between the local real subnet and the local virtual subnet. However, it does not have to match the subnet mask you used for the remote subnets in steps 3.4 and 3.5. Choose Create.

Your Aviatrix Gateway now establishes an IPsec VPN connection to the remote site. As traffic from this connection flows through the gateway, the gateway maps the virtual subnets to the real subnets. It changes only the portion of the IP address covered by the subnet masks you specified in steps 3.4 through 3.7 above.

Step 4: Configure the remote site router

The Aviatrix Controller provides you with a configuration that can be applied to the remote site router. The configuration contains the proper settings to establish the IPsec VPN connection to your Aviatrix gateway. It also includes a route to the virtual subnet this remote site uses to communicate with your Local Amazon VPC.

4.1. From the Aviatrix Controller web UI left-hand menu, choose Site2Cloud, then Setup. Choose the connection you created in Step 3 and choose Edit.

4.2. Select the Vendor, Platform, and Software of the remote site device and choose Download Configuration. This downloads a text file containing a complete line-by-line configuration for the remote device to your computer.

4.3. Before applying this configuration to the remote device, open the configuration text file and read the instructions for settings that you must specify. For example, if the remote device is Cisco IOS, you must set the tunnel interface numbers that make this connection unique on that device.

4.4. Apply the configuration to the remote device and wait for the Tunnel Status of this connection to show as Up. It should only take a minute.

When the IPSec connection is Up, the remote site and your Local Amazon VPC can begin communicating using the virtual subnets you defined for this connection in steps 3.5 and 3.7.

Step 5: Testing the connection

Verify that everything is working by having an EC2 instance in the Local Amazon VPC ping something at the remote site using an IP address from the remote virtual subnet. Remember from Step 3.5 that we assigned 100.64.1.0/24 to the remote site. This means that your EC2 instance will send a ping to 100.64.1.X, and you replace the X with the real last octet of the device you are trying to ping.

For example, in the following diagram, the EC2 instance in the Local Amazon VPC wants to ping the host at the remote network with the real IP address of 10.1.1.17. To do so, the EC2 instance will send the ping to 100.64.1.17. When the Aviatrix Gateway receives the ping packets, it changes the 100.64.1. portion of the destination IP address to 10.1.1. and the final .17 octet remains unchanged. At the same time, the 10.1.1. portion of the EC2 instance source IP address is changed to 100.64.2. and the final .33 octect remains unchanged.

The host at the remote site receives the ping packet from the EC2 instance with a source IP address of 100.64.2.33. The host responds to the EC2 instance using the destination IP address of 100.64.2.33.

Step 6: Observe and troubleshoot the connection

You can now observe traffic flows and perform any troubleshooting using Aviatrix CoPilot.

6.1. To get your CoPilot instance up and running and associated to your Aviatrix Controller, subscribe to Aviatrix CoPilot in AWS Marketplace. Follow the steps outlined in the Aviatrix CoPilot deployment guide.

Aviatrix CoPilot draws a topology of your cloud network, including all of the Amazon VPCs, subnets, instances, Aviatrix Gateways, and the remote site you’ve connected. You can look at this topology map and see the status of your VPN connection to the remote site and the latency observed on the link.

6.2. Log into Aviatrix CoPilot. From the left side menu, navigate to Topology, then Network Graph, then Network. Look for the blue icon representing your Aviatrix Gateway. To get more details, select it twice.

The following screenshot of the topology map shows my Local Amazon VPC in the us-east-2 region, the EC2 instances in this VPC, the Aviarix Gateway in this VPC, the VPC subnet the Aviatrix Gateway is attached to, the IPSec VPN connection from the Aviatrix Gateway to the remote site, and the latency of 14.2ms measured on the VPN connection. If the connection were down, the blue line representing the IPSec VPN connection would become yellow and the latency would be reported as NO RESPONSE.

6.3. Select the red circle icon representing the Aviatrix Gateway. In the right sidebar, select the DIAG button. This brings up a diagnostic tool that enables you to see the traffic sessions the gateway is currently handling. It also shows other troubleshooting tools like ping, traceroute, and packet captures.

6.4. To observe the ICMP ping session you are using to test the connection and all of its details, in the diagnostic tool, select Active Sessions. In the search bar, enter icmp.

In addition to diagnostic tools, Aviatrix CoPilot can show you detailed information about network traffic traversing your Aviatrix-powered cloud network. Using Aviatrix CoPilot, you can identify top talkers on the network in real time or historically in one simple dashboard. You can also see if any known malicious IPs are talking on your network and block them automatically. Take some time to cruise around the CoPilot user interface to see what it can do, and read this AWS Partner Network blog post to learn more about all the benefits of using Aviatrix CoPilot with your AWS infrastructure.

Conclusion

In this post, I showed you how to get your Amazon VPC connected to a remote site that has overlapping IP addresses, how to test the connection, and how to access troubleshooting tools. Aviatrix makes this otherwise difficult task easy by giving you a modern solution designed for cloud networks. You can get started right now by subscribing to the Aviatrix Cloud Network Platform on the AWS Marketplace or schedule a live demo here to learn more.

About the author

Brad Hedlund is a Principal Solution Architect at Aviatrix with over 25 years of experience in the networking field. Prior to joining Aviatrix, Brad has held senior positions with AWS, VMware, and Cisco. In his career Brad has helped organizations optimize their network architectures and he has helped his industry peers learn about new networking technology through his many blog posts and instructional video content.

Josh Dean is a Senior Partner Solutions Architect at AWS. He works closely with networking partners to build solutions and capabilities to enable and simplify their migrations and operations in the cloud. Prior to AWS, Josh worked all the way up the stack, from data center engineering to application support, generally with a networking focus.

Hussein Khazaal is the networking category leader at AWS Marketplace with over 25 year of experience in the fields of telecommunications and networking. Prior to AWS, Hussein held leadership roles at Nokia, Alcatel-Lucent, and Ciena, including several start-ups, where he led large cross-functional teams and delivered multiple networking products and services to market.