A partner created several VPCs for us using publicly routable IP ranges as their internal CIDRs. This is causing problems with VPNs and routing because those ranges can overlap with destinations on the public internet or with networks on the other side of a connection. Changing the VPC ranges is expected to take months, and the VPCs already contain live EC2 instances, databases, and load balancers. In the meantime, what is the most cost-effective way to translate or route traffic around these conflicting address ranges?
4 Answers
For a temporary solution, you can deploy a Linux NAT instance with multiple network interfaces and use iptables to translate traffic between the conflicting ranges. This can work well when the required protocols and ports are limited, but it adds a potential bottleneck and single point of failure unless you build a redundant pair. Make sure the VPC route tables send the affected traffic through the NAT instance and that return traffic follows the same path.
First confirm whether the partner actually owns or controls those public ranges. Using address space assigned to your organization can be intentional for avoiding overlap in business-to-business VPNs. If they used public ranges they do not control, or ranges that overlap with networks your users need to reach, that is a serious design problem. In either case, document the conflicting routes before choosing a translation scheme.
Be careful about treating this as a permanent routing problem. The primary CIDR block on a VPC cannot simply be removed, so routes for that range will always be considered local inside the VPC. The clean solution is to create replacement VPCs with private, non-overlapping CIDRs and gradually move the workloads using migration or redeployment strategies that fit your downtime limits.
Check the route tables carefully. If a VPC uses a range that matches a public destination or a remote VPN network, AWS will prefer the VPC's local route for that range, so traffic may never leave the VPC as expected. NAT can mask the conflict for selected flows, but it will not remove the local route or solve every protocol and routing-direction issue.
That is the key limitation: NAT may help specific applications, but it cannot make the VPC stop owning its primary CIDR. Long term, the workloads need to move to correctly addressed VPCs.
A staged migration is probably safer than trying to NAT every service indefinitely, especially for databases and services that need bidirectional connectivity.