When multiple identical VPC CIDRs compete for an AWS Transit Gateway!
We recently had to integrate with one of our service providers in my organization. Both entities operate on AWS, and the service provider exclusively supports Transit Gateway integration.
Throughout the integration process, we faced an issue with VPC CIDR overlap. We were not able to attach our VPC to their transit gateway due to a VPC CIDR overlap.
What is IP overlapping?
IP overlap occurs when two or more networks use the same ranges of IP addresses.
- PROBLEM
SERVICE Bshould be able to access SERVICE Avia the transit gateway. However account B’s CIDR could not attach, as the transit gateway already has an equivalent CIDR attachment.
Q: Does AWS Transit Gateway support overlapping VPC CIDRs?
Amazon Transit Gateway doesn’t support routing between Amazon VPCs with overlapping CIDRs. If you attach a new Amazon VPC that has a CIDR which overlaps with an already attached Amazon VPC, Amazon Transit Gateway will not propagate the new Amazon VPC route into the Amazon Transit Gateway route table. (Source)
2. PROPOSALS
- Creating a new VPC with a different CIDR and attaching it to the transit gateway would easily resolve this issue. However, in reality, network migration can be a hassle. Therefore, we chose to decline this option.
- Create a new VPC with a different CIDR
10.2.0.0/26, attach it to the transit gateway and enable VPC peering between10.1.0.0/26and10.2.0.0/26. Add a route10.0.0.0/8 -> TRANSIT GATEWAYin10.2.0.0/26.
The VPC peering option didn’t work as VPC peering doesn’t support transit networks. :(
So, What should be done, when multiple identical VPC CIDRs compete for an AWS Transit Gateway?
There may be several solutions to rectify it. Here I’ll share the solution that we implemented and worked for us.
3. SOLUTION
We need a non-conflicting VPC CIDR, such as 10.2.0.0/26, that can be attached to the transit gateway. Traffic from 10.1.0.0/26 to 10.0.0.0/8` should be routed or NATed via10.2.0.0/26.
- AWS VPC secondary CIDR
In AWS, a secondary CIDR block can be associated with a Virtual Private Cloud (VPC) to expand the address range of the VPC. AWS can have up to four secondary CIDR blocks associated with it. Each secondary CIDR block must be unique and non-overlapping with the VPC’s primary CIDR block as well as any other secondary CIDR blocks associated with the VPC.
When you associate a secondary CIDR block with a VPC in AWS, the associated route is automatically added to the main route table of the VPC. Therefore, you don’t need to manually add a route for the secondary CIDR block in this case. This entry tells the VPC that it can reach the 10.2.0.0/26 and 10.1.0.0/26subnets locally.
It allows us to route traffic from 10.1.0.0/26 to 10.2.0.0/26 effortlessly and same time we can attach 10.2.0.0/26 to the transit gateway.
What’s next? we need a NAT gateway in secondary CIDR to NAT and forward the traffic to the destination.
- Private NAT Gateway
Private NAT gateway uses a unique private IP address to perform network address translation for the overlapping source IP address, and a unique destination IP address that load balances the destination overlapping IP address. You can route traffic from your private NAT gateway to other VPCs or on-premises network using Transit Gateway or virtual private gateway (Source).
We cooked our recipe using these two ingredients. As shown in the diagram traffic of 10.0.0.0/8from 10.1.0.0/26 will be routed to the NAT gateway running on 10.2.0.0/26 . From there, it’ll be NATed and routed to the transit gateway.
In conclusion, this setup efficiently manages the flow of traffic, ensuring a smooth and secure network operation.
HAPPY NETWORKING!