I created a VPC1 and created a linux instance in the same VPC and then created a Transit Gateway and attached that VPC1 to that then created another VPC in another region and configured openswan in that and attached that VPN with TGW and configured a tunnel between the two region and I am able to do ssh and ping from both sides then I created new VPC and configured another linux instance and attached that VPC to the TGW but I am not able to ping or do ssh from openswan to that new linux instance , I did routing at TGW and subnet level but still I am facing issue
I have created two VPCs in two regions, my aws side VPC is in us-west-1 region and on-prem vpc is in London region, My us-west-1 vpc is in private network and one instance is running in that and I have configured Openswan VPN and established a vpn tunnel in us-west-1 and London region, I am able to ping from openswan to EC2 instance and vice-versa but if I want to access internet in EC2 instance that is in private network over the VPN tunnel then how to do that ?
Its quite difficult to judge issue based upon the error you have mentioned. There might be several possibility as one of the dependent module is missing or your configuration has not been done properly , due to which deamon is not getting started. Try to find out the configuration issue.
I am running into a corner case, where the TGW is not showing up in the route table. Do I need to create a TransitGatewayAttachement with the VPC first?
Default route just add the attachment , ideally of your configuration is good then you dont have to worry about adding the CIDR as thats automatic.. So add the attachment as static route..
In IPSEC Tunnel #1 you have the rightsubnet=10.0.0.0/8 right? Is this the vpc CIDR of the target vpc? my question here is the vpn is connected to a TGW right, but why we are giving the vpc CIDR of N-Virginia region as rightsubnet?
Correct. I have just taken a common wide range /8 due to multiple VPCs. Again range can be defined as per our requirement to make the communication based upon security best practices.
Is there a way to auto propagate the VPN routes to Frankfurt from the Transit Gateway down to the VPC? You are putting statics in at the vpc level to reach Frankfurt and I was curious why.
Auto propagate VPN routes from one region to different region is something not supported as per best of my memory if something is i would be happy to learn. Regards to the route i have used the CIDR range of frankfurt for communication within the VPC. Static IP is given to the instance as i dont have jump/bastion host setup to ssh into system. Let me know if that makes sense..
Hi, I'm trying to setup this using AWS cli: raw.githubusercontent.com/flunkedutopian/aws-trangw-vpn/master/aws-vpn.sh I'm able to bring the tunnels up, however I'm unable to ping or SSH to the AWS side from the DataCenter side. Could you have a look and tell me what I could be doing wrong... I'm of the belief that this would be something with regards to Security groups, however even a wide permissive setup for Security group is not helping. Please help
Its quite difficult to say at which step the process has failed. Have you checked the route back traffic as this needs to be there part of routing traffic from TGW to VPC and VPC to TGW , this is something i am not seeing in your route table . Also for ping enable iCMP traffic to check request.
@@Cloud4DevOps figured it out :) , that too before seeing this comment... you were right.. have updated the same: raw.githubusercontent.com/flunkedutopian/aws-trangw-vpn/master/aws-tgw-vpn.sh but thanks for lending an ear, very rare to find folks responding to queries, consider me subscribed for life
First of all, thanks for this amazing video. My vpn tunnel is up and running but I'm unable to ping any instance from my test site (openswan instance). At the other hand, other 3 instances which are connected thru TGW are pinging.
Hi Sunil, I was just wondering if you have discovered what is causing the ping block. i am having the same issue, i have follwoed the video step by step bu i cannot ping the instances from the vpn server.
You can use BgP routing as when you use a BGP device, you don't need to specify static routes to the Site-to-Site VPN connection because the device uses BGP to advertise its routes to the virtual private gateway. Hope that clears..
@@Cloud4DevOps I thought you have video for BGP, We have configured on our onpremise site, but IP Sec up and tunnel down. Doesnt know the issues. Is it because the onpremise side doesnt have BGP routing to our VPC?
@@imamariefrahman5038 No i have created video with Static routing.. If your router supports dynamic routing then you have to enter IP address and unique BGP ASN number to get this working..
Can you please share all the settings you did on the on premise side ec2 instance (after open swan installation), those two config files, and the entries, so that they can be copied and edited easily, thank you so much this was really helpful in learning and trying out.
@@Cloud4DevOps Still facing issue. Lemme explain you further. Have 2 VPC's in Mumbai - 10.1.0.0/16 and 10.2.0.0/16 with each having 1 public subnets only. And for my VPN i have N.Viginia region with VPC 100.0.0.0/16 with 1 public subnet. Have configred transit gw with 2 vpc and 1 vpn attachments in mumbai. between vpc's, the ping is fine. I have updated in mumbai RT's the VPN (NVirginia - 100.0.0.0/16 with VPN attachment. When it comes to VPN (N.Virgina) RT, I need to create routes for 10.1.0.0/16 and 10.2.0.0/16 in mumbai, I don't which interface I need to select.
@@rajur7461 TGW works like a cloud router , so within default RT of TGW update both Mumbai IPs and within the actual RT allow one iP from which you can ping the other. Due to transitive nature you will be able to get ping communication working both ways.
@@Cloud4DevOps ok thanks. But if I one more subnet that is private in N.Virginia (VPN), how to update it's RT to communicate with other side (Mumbai) with CIDR of 10.0.0.0/16 etc
@@rajur7461 So ideally if you have multiple cidr in one region and they are connected via TGW , update the ZRT with both CIDR range or use generic private range 10.0.0.0/8
