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

7,130

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.
Share:
7,130

Related videos on Youtube

Bogdan Sorlea
Author by

Bogdan Sorlea

Updated on September 18, 2022

Comments

  • Bogdan Sorlea
    Bogdan Sorlea over 1 year

    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)

  • Bogdan Sorlea
    Bogdan Sorlea over 11 years
    Fortunately, I am doing this in a preliminary research phase - and therefore I can kill and create VPCs as much as I want (so for now I don't need to do all the instance copying). [see next comment...]
  • Bogdan Sorlea
    Bogdan Sorlea over 11 years
    Going back to the problem... I don't really understand your solution, so you might have to explain it better. I might have been ambiguous as well... There are two cases I need to find out how AWS VPC/VPN behaves about: One case consists of a VPC and one or more client networks having CIDR blocks which intersect - e.g. VPC has 192.168.0.0/16, ClientNetworkA has 192.168.1.0/24 and ClientNetworkB has 192.168.2.0/24 The other case consists of common parts of the CIDR block between the client networks - e.g. VPC has 10.0.0.0/16, ClientNetworkA has 192.168.1.0/24, ClientNetworkB has 192.168.1.0/24
  • Bogdan Sorlea
    Bogdan Sorlea over 11 years
    Or in the second case, the same CIDR blocks as in the previous comment, only that ClientNetworkB has 192.168.0.0/16
  • Guy
    Guy over 11 years
    Updated in the answer above
  • Bogdan Sorlea
    Bogdan Sorlea over 11 years
    it has become clearer now. Thank you [didn't have knowledge of the DNAT - but learning is a never-ending process]