Let say I have two VPC's (VPC-A with 10.50.0.0/16 and VPC-B with 10.50.0.0/16) in AWS with same conflicting/overlapping CIDR ranges in my AWS account. I already have the two VPC's fully functional with 100 plus instances running in either of the VPC's. I am now in great need for the two vpc's to communicate which has the same CIDR ranges. Is there a possible solution that can make the two VPC's communicate to each other. Can this be achieved by establishing a VPN tunnel (though I have same CIDR range). Any suggestions/solutions on this would be highly helpful. Thanks in advance.
Connecting two AWS VPC Regions of the same CIDR range
amazon-vpcamazon-web-servicescidrvpn
Related Solutions
I found the issue. It was quite non-intuitive.
When the Active Directory is created, AWS automatically creates an associated security group.
The SG was called "d-9462#####_controllers" and had the description "AWS created security group for d-9462##### directory controllers". (d-9462##### being the ID for the directory)
What makes it counter-intuitive is that this SG is not displayed anywhere (as far as I can tell) within the Directory Services console. You would have to know that it existed, and know to search for it within the VPC security groups.
By default this SG grants access only to the VPC in which the Directory resides.
To fix the issue you need to explicitly grant access to whatever other VPC's you need.
Regarding question 1.
Assuming you are referring to the ability to connect via an IPSec based VPN to securely connect to resources that are located outside AWS. The answer is yes. However, the native AWS implementation of this does have some restrictions. The first is that it is not possible to specify any aspects of the phase 1 or phase 2 configuration settings. Instead AWS provide you with the ability to download pre-configured settings for a range of manufacturers, but also provide some good generic examples too.
Some good resources are:
AWS Managed VPN Connections - provides details on the AWS VPN Gateway service
Your Customer Gateway - provides information on the settings required on the device outside of AWS
Regarding question 2.
This is true, if the tunnel drops for some reason, the AWS side cannot initiate it (this is a VERY annoying limitation if you ask me). However there are ways around it. Some devices support sending keep alive packets to keep the tunnel up. For example Cisco ASA's can make use of IP SLA feature to send SLA messages accorss the tunnel to keep it up. Extract from the sample ASA configuration:
In order to keep the tunnel in an active or always up state, the ASA needs to send traffic to the subnet defined in acl-amzn. SLA monitoring can be configured to send pings to a destination in the subnet and will keep the tunnel active. This traffic needs to be sent to a target that will return a response. This can be manually tested by sending a ping to the target from the ASA sourced from the outside interface. A possible destination for the ping is an instance within the VPC. For redundancy multiple SLA monitors can be configured to several instances to protect against a single point of failure.
Or you can simply arrange for a system on one side to periodically send a ping - via a cron job or scheduled task.
Another option however is to deploy your own IPSec gateway into AWS - either running on the instance itself, or on another instance, you then can update the route table on your subnet to route to the off AWS subnets via this instance. This allows you more control on the IPSec settings and behaviour - but is arguably more complex to manage compared to the native AWS service.
Best Answer
There is no way to do this without introducing a very large amount of complexity, resource contention, and instability into the environment.
You'll just need to buckle down and renumber one of the VPCs.