I'm having an IPSec tunnel created between two AWS regions, using strongswan. When one region servers are restarted then strongswan wasn't able to ping to the private servers in the second region. It was working before. Is it a good idea to have an AWS resource (VPC peering) for the tunnel to create, so that I could solve this issue?
I think in general it's a better idea to use VPC peering instead of IPsec tunnels to connect multiple VPCs. VPC peering is managed by AWS and reduces your maintenance effort. You can only apply VPC peering between a few regions. See the blog post for more details.
See guide for further details: https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html
For connecting multiple regions with VPC peering see this blog post:
https://aws.amazon.com/blogs/aws/new-almost-inter-region-vpc-peering/
You might need to add (or switch) the parameter auto=start to your ipsec.conf for that tunnel connection.
If you use auto=add only on both sides, the tunnel connection establishement won't be started by any of the nodes.
Notice though that if you use auto=start on both sites, you might run into trouble if both sites try to establish the tunnel at the same time. This can happen if you restart StrongSwan simultaneously for example.
Related
I am trying to connect to an RDS Instance from my local machine through a VPC Peering connection. In my AWS Account I have two VPCs: VPC1 is connected to my local network via DirectConnect, VPC2 isn't. VPC2 contains all of my infrastructure and the idea is that if I want to connect to that infrastructure from my local machine I need to work through VPC1.
I have configured a route in the peering connection to forward IP based requests to VPC2 for a given address range. This doesn't really help me for RDS though because I don't know what the IP Address for RDS is, only the endpoint. I am guessing that there is some combination of DNS/Routing/Networking/Peering that will solve this problem but I haven't found any documentation that describes how to solve this issue.
Has anyone solved this issue before, or know of any documentation that describes what needs to be done?
Update:
The exact problem is that I can't connect to the RDS instance from my local machine. For example, if I use the RDS Endpoint as the server for my connection, the Sql Client I am using simply can't connect with a timeout error. My suspicion is that traffic is not being routed to VPC2 correctly but I don't know how to prove that.
As far as DNS goes, I am not sure how OnPrem is setup however I have 4 hosted zones in Route53 with a variety of URLs. Items that I setup in Route53 I am able to resolve by host name on my local.
Likewise, I am not sure how the network has been configured with DirectConnect (full VPN tunnel or otherwise).
As far as DNS and the network connections between AWS go though, that stuff works. I am able to resolve pieces of infrastructure in VPC1 fine I just (seemingly) can't get traffic to move across the Peering Connection in the way that I would expect.
I think the problem is that you think you can access vpc2 resources from on-prem just b/c you have direct connect to vpc1. What vpc-peering is giving you is access from vpc1 to vpc2 via private ip addresses. In your case you want vpc1 to act like a router to just transit your request from on-prem to vpc2. It does not work that way.
What are your options:
You could have a host vpc1 access vpc2 (like a bastion host) and you could ssh into that one first.
If possible, you can create a vpn connection from on-prem to vpc2.
And there are more complex solutions via transit gateway.
The doc here talks about vpc-peering limitations, it will basically explain that transitive connections like you want won't work: https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html
AWS scenario documentation to reach db mentions option 1 here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.Scenarios.html
Sorry for the Japanese material.
I think VPC1 and VPC2 cannot communicate even if you configure routing. So as long as communication is impossible, configuring DNS will not accomplish the goal, I guess.
AWS Solutions Architect ブログ: VPC Peeringの使いどころとTips等々
VPC Peering provides peering, not routing between multiple VPCs, so if you are peering 3 or more VPCs or connecting to locations outside of AWS via VPN or DirectConnect, even if you set the Routing Table appropriately for each, there will be no IP layer routing to networks more than 2 hops away. Even if you configure the Routing Table appropriately, there will be no IP layer routing to networks more than 2 hops away. Workarounds such as using proxies or stepping stones are required as before.
Translated with www.DeepL.com/Translator (free version)
Could PrivateLink help you achieve your goal?
AWS-40_AWS_Summit_Online_2020_NET01.pdf
Along the example on page 42:
local network --> Direct Connect --> VPC Endpoint (in VPC1) --> NLB (in VPC2) --> RDS (in VPC2)
I am trying to connect to a private server running on a windows machine from my AWS Lambda. The goal is to get some data from that server in the Lambda and work with it.
I've created a site-to-site VPN connection with that private server and the tunnels are up. I've put my lambda on the VPC that is connected to the site-to-site VPN. But still I can't connect to the server.
Can anyone please give me any resource or suggest the steps on how I should actually do it?
I've followed the following steps:
Created a VPC with a CIDR.
Created a private subnet from that VPC (let's say it's named subnet-1)
Added a site-to-site VPN, connected it to the private server and attached the VPC to the VPN connection.
Created a Lambda within the subnet-1.
Tried to ping the private server, but failed.
I'm not providing any code or any screenshot as this might make this question too long
Update: The issue is solved. I had a wrong configuration in the router table. After fixing that, it worked.
There are several things that can cause the connectivity to fail:
Are there NACLs that prevents the traffic from flowing outside of the subnet?
Is the lambda armed with a security group that allows passage towards the windows server?
Is the VPN fully working at the time of testing?
Are there any network firewalls on the on-premise network that prevents the traffic from the lambda to flow?
Do the CIDRs of the VPC collide with the CIDRs of the on-premise network?
I would usually assign compatible subnets between my VPC and on-premise site to make this work.
UPDATE: As per question's author, he faced router table related issue that prevents propagation of traffic between on-premise and AWS-based network.
These are the questions that I tend to ask when running into this problems but there could be other things that can cause your issue. Hope these checks help.
This is the first time I've tried to setup the AWS VPN attached to a transit gateway. I've tested using openswan and it worked like a charm. But the issue is now I am trying to set it up for our premise network which is behind a NAT device. I am trying to comprehend why the tunnel are still down and the network people from the onpremise side are not helping much (they said they've configured the customer gateway and that's it) .
Basically they have given me a CIDR range (/30) to where I need to NAT first all traffics before routing them to onprem and with that CIDR range I could not even create a subnet (invalid CIDR range for the subnet). I have also gotten the static routes which I've added to the transit gateway routes.
Is there a way to NAT traffic from a VPC to a specific network (AWS side in my case to 10.x.x.x/30) before sending the traffic over the tunnel to onpremise. I could not find a way to setup that up.
And also the onpremise network people are not helping much since they said they've setup everything on their side and waiting for me to bring the tunnel up. Is there something am I missing, in my previous AWS VPN setup, the initiator to bring the tunnel was always from the customer gateway side.
/palmer
In this case the vpn will be always initiate from the on premise side for completion.
you need to prepare a cgw and create a s2s vpn connection with those cgw and share the config information s2s with your on premise colleague .
Also for nat in vpc you can use the nat gateway for one way nat.
Could someone give a step-by-step procedure for connecting to elasticache.
I'm trying to connect to a redis elasticache node from inside my EC2 instance (sshed in). I'm getting Connection Timed Out errors each time, and I can't figure out what's wrong with how I've configured my AWS settings.
They are in different VPCs, but in my elasticache VPC, I have a custom TCP inbound rule at port 6379 to accept from anywhere. And the two VPCs share an Active Peer connection that I set up. What more am I intended to do?
EDIT:
I am trying to connect via the redis-cli command. I sshed in because I was originally trying to connect via the node-redis module since my EC2 instance hosts a node server. So officially my two attempts are 1. A scripted module and 2. The redis-cli command provided in the AWS documentation.
As far as I can tell, I have also set up the route tables correctly according to this: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html#route-tables-vpc-peering
You cannot connect to Elasticache from outside its VPC. It's a weird design decision on AWS' part, and although it's not documented well, it is documented here:
Amazon ElastiCache Nodes, deployed within a VPC, can never be accessed from the Internet or from EC2 Instances outside the VPC.
You can set your security groups to allow connections from everywhere, and it will look like it worked, but it won't matter or let you actually connect from outside the VPC (also a weird design decision).
In your Redis cluster properties you have a reference to the Security Group. Copy it.
In our EC2 instance you also have a Security Group. You should edit this Security Group and add the ID of the Redis Security Group as CIDR in the outbound connections + the port 6379.
This way the two Security Groups are linked and the connection can be established.
Two things we might forget when trying to connect to ElasticCache,
Configuring inbound TCP rule to allow incoming requests on port 6379
Adding EC2 security group in ElasticCache instance
Second one helped me.
Reference to (2) : https://www.youtube.com/watch?v=fxjsxtcgDoc&ab_channel=HendyIrawanSocialEnterprise
Here is step-by-step instructions for connection to Redis Elasticache cluster from EC2 inctance located in the same VPC as Elasticache:
Connect to a Elasticache Redis Cluster's Node
I am looking to find a way to communicate between 2 VPCs in AWS without the use of VPN connections to and from a certain company (outside AWS) - so that the traffic does not pass through the company's gateway. Or, simply said, access an EC2 instance in a VPC from another VPC (both in AWS) without leaving the Amazon Network (not going out on the internet, not even encrypted).
Basically what I want to do is to have a VPC acting as a "proxy" (let's call it PROX) and one acting as a "target" (called TARG). Now I want to connect a company through VPC to the PROX and inside the PROX route the requests to the TARG. Is this achievable? I would go for a traditional public-private single VPC, but I was asked to look into the previously described "architecture".
Use two Linux machines as VPN GW, each in each VPC.
Configure IPsec VPN between them.
That's all you need
This is not possible. You have to use a VPN connection between the two VPCs. You can directly connect them though relatively easily using the pair of IPSec gateways though. This is the recommended method of cross-connecting VPC's across regions.