A partner created several VPCs for us using publicly assigned IP ranges as their internal addressing. This is causing problems with VPNs and routing because those ranges can overlap with real destinations on the internet or with networks we need to reach. They are planning to correct the design, but migrating will take months because there are many VPCs with live EC2 instances, databases, and load balancers. In the meantime, what is the most cost-effective way to provide NAT or otherwise work around these conflicting address ranges?
4 Answers
For a temporary workaround, a Linux NAT instance with multiple network interfaces can work if the traffic patterns are limited and you only need specific ports and protocols. Configure iptables for the translations and route the affected subnets through it. Make sure you account for availability, return routes, source preservation, and the throughput limits of the instance; for production traffic, a redundant pair is safer than one server.
The cleanest long-term solution is to create new VPCs with RFC1918 private ranges and gradually migrate the workloads. A VPC's primary CIDR block cannot be removed, so the original range will continue to exist as a local route. Trying to permanently engineer around it is likely to create more problems than moving the infrastructure in stages.
Check the route tables before adding NAT. If a VPC uses a range that also contains an internet destination, AWS will prefer the VPC's local route, so traffic to that destination may never leave the VPC. NAT can translate traffic crossing a boundary, but it will not remove the VPC's built-in local route or fix every overlapping-network case. A proxy, transit intermediary, or staged workload migration may be required depending on which services need to communicate.
First confirm whether the partner actually owns or is authorized to use those public ranges. Using address space from your own organization for private connectivity can be valid, especially for dedicated business-to-business VPNs. If the ranges are merely public addresses that the partner does not control, that is a serious design issue and should be corrected rather than treated as a normal private network.
That is the migration plan, but we need an interim solution while the live systems are being moved.