Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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)

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

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|improve this answer
    
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 Jan 21 '13 at 11:55
    
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 Jan 21 '13 at 12:00
    
Or in the second case, the same CIDR blocks as in the previous comment, only that ClientNetworkB has 192.168.0.0/16 –  Bogdan Sorlea Jan 21 '13 at 12:01
    
Updated in the answer above –  Guy Jan 21 '13 at 17:14
    
it has become clearer now. Thank you [didn't have knowledge of the DNAT - but learning is a never-ending process] –  Bogdan Sorlea Jan 22 '13 at 12:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.