How to make VPN connections to different networks which have the same CIDR?

Question

So,

I have an app running in a VPC, with (currently) a VPN connection to the development location. The app is accessible at, let's say, 10.0.2.25 (IP of the internal ELB, accessible only via VPN). The VPN-capable router I have (aka. client gateway) has no BGP capabilities.

The CIDR of the network I'm on (client network is 192.168.1.0/24) and on the VPC there is a Virtual Private Gateway (vgwA) and a corresponding routing rule (Destination 192.168.1.0/24; Target wgwA).

I can access the app without any problem (all ACL/Security Groups are properly configured).

My question is what happens when I want to create another VPN connection to a different site, but whose network has the same CIDR block (192.168.1.0/24) or a CIDR block that might overlap (or include) it (e.g. 192.168.1.0/16)? Is this successful - and will the users on the client networks be able to access the app?

Basically, what do I need to be capable to make VPN connections to different networks which have the same (or partially common) CIDR? BGP-capable customer gateway? Different virtual gateways on the same VPC? (I don't think that AWS allows that - and it doesn't really make sense) Routing rules based on the external IP of the customer gateway? (e.g. Destination: 87.44.75.124 Target: vgwA; - doesn't really make sense)

Answer 1

The "right" solution is to change the CIDR block of your VPC to prevent such an overlap. Since this is not a simple task, as currently, you need to start copies of your instances in the newly created VPC, you can consider using the following hack:

Define your VPN device as a Dynamic NAT, that will translate a non-overlapping IP address to the real private IP of your VPC, while providing a local DNS for the servers in the VPC with the above set of non-overlapping IPs.

To be more specific you will have the following components on the client network, assuming that you have some sort of VPN device there:

• VPC-facing router has an IP address route for say 192.168.3.0/24 pointing to VPC
• Customer implements an internal DNS server that implements DNS A records of the type: customer-A-record.customerdomain.com -> 192.168.3.x
• Users on premise (home network) access VPC resources using DNS names (NOT IP addresses); so when an internal network user is trying to SSH or HTTP into a VPC host, they do so against the DNS name (NOT the IP address): customer-A-record.customerdomain.com
• Internal DNS server resolves the DNS name to an 192.168.3.x/24 IP address
• Internal router/layer-3 switch routing tables have a routing table entry for 192.168.3.x/24 pointing to the VPC customer gateway (which is the VPN gateway on the client network terminating the VPN connection to VPC)
• The Customer VPN gateway receives a packet going to 192.168.3.x/24; it has a static destination NAT DNAT entry to translate 192.168.3.x-> 192.168.0.x
• The Customer VPN gateway ensures that the source IP is translated as well to ensure that there is a non-overlapping return IP address, so besides DNAT it all does source NAT SNAT: 192.168.0.x->192.168.3.x (may be a different source IP subnet – it’s more efficient to use the same for both SNAT & DNAT)
• The customer VPN gateway now forwards a packet on it’s IPSec tunnel/interface which has (Source-IP, Destination-IP)=(192.168.3.x,192.168.0.x) which poses on conflicts on the destination network (VPC)
• The VPC hosts receives a non-conflicting packet, does what it’s supposed to do with it and sends a response packet of the form (Source-IP, Destination-IP)=(192.168.0.x,192.168.3.x) across the VPN tunnel to client network
• The Customer VPN gateway on client network does both DNAT/SNAT and ends up with another non-conflicting response of the form (Source-IP, Destination-IP)=(192.168.3.x,192.168.0.x), which it then forwards to its local (home) network on 192.168.0.0/24.