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.
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 would like to understand what is required to achieve a network-level isolation but re-use (some) resources.
My working setup involves a VPC connected to a Virtual Private Gateway and a Client VPN Endpoint using mutual authentication (i.e. openVPN certificates).
If I want to spin up a new VPC instance for another complete different set of users, how can I achieve network isolation so that IAM users from one VPC cannot access anything in the other VPCs while requiring the use of VPN?
My primary problem with the current approach are the costs of having dedicated Client VPN endpoint associations for one VPC instance.
Docs suggested a possibility might be adding Transit Gateway, or associating multiple VPCs with the Virtual Private Gateway.
What would be a good approach?
Is there an alternative to AWS's security groups in the Google Cloud Platform?
Following is the situation which I have:
A Basic Node.js server running in Cloud Run as a docker image.
A Postgres SQL database at GCP.
A Redis instance at GCP.
What I want to do is make a 'security group' sort of so that my Postgres SQL DB and Redis instance can only be accessed from my Node.js server and nowhere else. I don't want them to be publically accessible via an IP.
What we do in AWS is, that only services part of a security group can access each other.
I'm not very sure but I guess in GCP I need to make use of Firewall rules (not sure at all).
If I'm correct could someone please guide me as to how to go about this? And if I'm wrong could someone suggest the correct method?
GCP has firewall rules for its VPC that work similar to AWS Security Groups. More details can be found here. You can place your PostgreSQL database, Redis instance and Node.js server inside GCP VPC.
Make Node.js server available to the public via DNS.
Set default-allow-internal rule, so that only the services present in VPC can access each other (halting public access of DB and Redis)
As an alternative approach, you may also keep all three servers public and only allow Node.js IP address to access DB and Redis servers, but the above solution is recommended.
Security groups inside AWS are instance-attached firewall-like components. So for example, you can have a SG on an instance level, similar to configuring IP-tables on regular Linux.
On the other hand, Google Firewall rules are more on a Network level. I guess, for the level of "granularity", I'd say that Security Groups can be replaced to instance-level granularity, so then your alternatives are to use one of the following:
firewalld
nftables
iptables
The thing is that in AWS you can also attach security groups to subnets. So SG's when attached to subnets, are also kind of similar to google firewalls, still, security groups provide a bit more granularity since you can have different security groups per subnet, while in GCP you need to have a firewall per Network. At this level, protection should come from firewalls in subnets.
Thanks #amsh for the solution to the problem. But there were a few more things that were required to be done so I guess it'll be better if I list them out here if anyone needs in the future:
Create a VPC network and add a subnet for a particular region (Eg: us-central1).
Create a VPC connector from the Serverless VPC Access section for the created VPC network in the same region.
In Cloud Run add the created VPC connector in the Connection section.
Create the PostgreSQL and Redis instance in the same region as that of the created VPC network.
In the Private IP section of these instances, select the created VPC network. This will create a Private IP for the respective instances in the region of the created VPC network.
Use this Private IP in the Node.js server to connect to the instance and it'll be good to go.
Common Problems you might face:
Error while creating the VPC Connector: Ensure the IP range of the VPC connector and the VPC network do not overlap.
Different regions: Ensure all instances are in the same region of the VPC network, else they won't connect via the Private IP.
Avoid changing the firewall rules: The firewall rules must not be changed unless you need them to perform differently than they normally do.
Instances in different regions: If the instances are spread across different regions, use VPC network peering to establish a connection between them.
I need to set up a connection between VPCs. My plan was VPC peering but customer asks for Private Link as they heard it is the secure way. But I am mostly concerned with performance overhead with the private link. What I understood (maybe wrong); in the Private Link architecture there is an extra NLB. Does not this introduce a latency because of extra network hop?
VPC peering and Private Link serve two different purposes.
VPC peering enables you to connect two VPC in a same way you would connect to local networks together, and remote networks using VPN. VPC peering allows network traffic from one VPC to the second VPC. For example, you can SSH from an instance in VPC A into an instance in VPC B.
Private Link is used to expose individual services of yours in VPC A to VPC B. But this does not allow for free flow of network traffic from VPC A to VPC B. For example, let's say you've developed very cool application for image segmentation. The application and all its databases and other resources that it requires are in VPC A. Now a friend comes and he/she would like to use your application. But the friend is in VPC B. Since your application is private, not exposed to the internet, a way for your friend to use the app would be to expose it through Private Link. For this you create NLB in-front of your application, and your friend will get network interface in his VPC B through which he can access your private application in VPC A.
Based on this and your question, there is no clear answer as the two options are used for different purposes. I would suggest to clarify exactly what are your or your customer requirements.
But generally, both will be equally fast. AWS docs write about VPC peering the following:
AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck.
Other examples from AWS docs is here:
Example: Services Using AWS PrivateLink and VPC Peering
Edit: Based on #Michael comment.
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.