I have successfully built a VPN connection between gcp and aws using the following guide(https://cloud.google.com/solutions/automated-network-deployment-multicloud).
I can currently ping the resources on the other cloud providers based on the private IP. However, I would like to use the dns resolution that resolves to private IP of the AWS resource DNS names. Can someone please help me with this?. Using DNS server policy may not be the best of options for me as it points to alternative name server only and not the gcp’s internal name servers anymore. So how can I use forwarding zones in gcp for DNS names such as database-test.c34fdgt1ascxz.us-west-1.rds.amazonaws.com so that it resolves to private IP. The above example is for database which I have not made public. Has someone done this already? Or does anyone have any idea on how to go about this. Any help is much appreciated, thank you so much.
It is possible.
If your goal is to configure outbound forwarding to AWS, then you should remove this policy you just need a Cloud DNS managed zone to accomplish this.
The DNS queries that are forwarded from GCP to AWS will come from the 35.199.192.0/19 address block.
The 35.199.192.0/19 traffic can be routed over a dynamic VPN tunnel dynamic (BGP), so you would just need to modify your AWS VPN gateway or router by adding a route that to reach 35.199.192.0/19.
It looks like a public address block, but Google uses this block only for forwarding, and does not announce it on the public Internet.
And finally, AWS needs to be configured so that responses to DNS queries from 35.199.192.0/19 are routed back to GCP using the VPN tunnel configured between AWS and GCP.
In other words, this traffic needs to go through the VPN tunnel.
To debug it you can use stackdriver logging and also by checking network captures on both endpoints.
Check this documentation guides: Creating Forward zones1 and DNS forwarding2.
You can't resolve AWS private IP addresses by submitting the AWS public endpoint to GCP's DNS. That just wont work.
AWS uses a service called Route53 resolver that will forward requests that can't be resolved internally to an external DNS server that you specify. We use this in our env's to resolve on-prem corp IP's that are not part of Route53. I have not tried this, but it's possible you can use that to point to GCP DNS.
Related
What options are available to allow on prem client make requests to VPC Endpoint (interface created for private RestAPI) ?
Do I absolutely need to use Corporate DNS?
If I use corporate DNS, my concern is that all existing requests going to S3 by on prem will suddenly get routed and wont work as expected?
Assuming here that I have also direct connect and transit gateway.
Is a VPC Endpoint even necessary?
Any insight is appreciated.
I'm making the assumption at this point that a VPC Endpoint is the solution for allowing on prem client to make request since it needs some VIP or url to make the request to. How else would I create a private RestAPI without a VPC endpoint?
I am assuming you are asking about Private API Gateway.
In this case VPC Endpoint is mandatory, as it is private.
When you create VPC Endpoint, it will generate some specific DNS names for this endpoint, you can use them to reach your API Gateway.
As you have Direct Connect, your best solution is to use Route53 Resolver.
In this solution your on-premise DNS will forward all resolution names that ends with amazonaws.com to Route53 Resolver.
Please, do not confuse name resolution with network connectivity, resolving names via Direct Connect doesn't mean all services request will flow via Direct Connect.
There is a good whitepapper about this solution:
https://d1.awsstatic.com/whitepapers/hybrid-cloud-dns-options-for-vpc.pdf
I have a GCP VPC and it is connected to on-prem using Public Cloud Interconnect.
Traffic flow between onprem and the VPC is ok. All routes and firewalls are configured correctly.
Now I would like to have the company DNS servers available for VMs in my VPC.
My 3 DNS servers are
10.17.121.30 dns-01.net.company.corp
10.17.122.10 dns-02.net.company.corp
10.17.122.170 dns-03.net.company.corp
Now I have done the below config in Cloud DNS in GCP.
The DNS name is company.corp
The "In use by" is referring my VPC.
The IPs 10.17.121.30, 10.17.122.10 and 10.17.122.170 are on-prem and are accessible from the VPC over port 53.
But after having done all the above, if I try to connect to any on-prem machine using its name, I get
telnet: could not resolve example-server.corp.sap/443: No address associated with hostname
The above request is being made from a VM inside the VPC.
Which leads me to believe that my DNS servers might not be correctly configured. What have I missed here ?
If you are intending to have your VMs able to resolve hostnames within your on-premises network, then you will need to make use of DNS forwarding. You would need to configure your private zone as a forwarding zone. Once this is done you can use your forwarding zone to query on-premises servers.
I have an instance running on premise and its IP address is changed regularly. My other services are running on AWS and they are using IP to connect to the premise's services. I have to update the IP address saved on AWS services whenever the IP is changed on premise network. I have a thought about using DNS but it is still a need to update A record.
I am looking for a way to do some auto-detect instead of manual updating. I wonder whether I can use load balancer to do the check. I know there will be a range of IP addresses on premise network. Can load balancer do a health check on these IP within the range? So my AWS service can send request to the load balancer. Is there any side-effect on this approach?
You need to use hostname instead of IP address as you mentoned the IP addresses keeps changing. AWS VPC can use a DNS forwarder like Unbound, which can forward the requests to your on premise DNS server when VPC resolution is unable to resolve the hostnames. This appraoch is quite effective as you send only those DN resolution to on-premise DNS that are missed by AWS VPC DNS.
Unbound allows resolution of requests originating from AWS by
forwarding them to your on-premises environment—and vice versa. For
the purposes of this post, I will focus on a basic installation of
Amazon Linux with the configuration necessary to direct traffic to
on-premises environments or to the Amazon VPC–provided DNS, as
appropriate. Review the Unbound documentation for details and other
configuration options.
Further reading : How to setup DNS resolution from AWS to on premise servers
Setup
I've got the below configured in a single AWS account. If it helps, the Client is Kibana and the Service is ElasticSearch.
What I'm trying to do
Route traffic from the "Client" EC2 instances to an Internal Application Load Balancer using a Route53 Alias Record in a Private Hosted Zone.
I've followed AWS's documentation, and as I understand it, I should just be able to create the alias record in the Private Hosted zone... and the good new is, I can
The Hosted Zone name is internal.my_company.com
The Alias name is service.internal.my_company.com
Problem
If I open a Session Manager terminal on one of the Clients and run the following:
curl <internal_load_balancer_dns>:9200
I get a response from the Service as expected
However, if I run
curl service.internal.my_company.com:9200
I get the following response
curl: (6) Could not resolve host: service.internal.my_company.com
I've googled around, but can't find anything recent relating to this. Have I missed something in letting Route53 know how to reach the Internal Load Balancer?
Let me know if you need more information about the setup.
Thanks
Is the VPC hosting your private subnets associated with the private hosted zone? (Probably so, since you have to pick a VPC when creating the zone.)
For the VPC, did you enable DnsHostnames and DnsSupport?
VPC --> Actions
I have an AWS instance, and I want to visit the REST API hosted on another AWS instance on another VPC. Is the only way to access the API through public IP of the server? Or is there any other mechanism for inter-AWS traffic?
Note, the API server is a third party service, I have no control whatever to it, only know that is hosted on AWS.
Yes, because the API is hosted in another VPC, you can access that only as follows
Using the public IP
Using the elastic IP (if that exist)
Using the internet facing load balancer (if the EC2 is behind a load balancer)
In addition to the answer of #Arafat Nalkhande, I would like to add that there's another option as well called VPC Peering which does helps you achieve this:
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them privately. Instances in either VPC can communicate with each other as if they are within the same network
You can also use VPNs, but that would be an overkill.
Edit: As mentioned in the comments, I had misread the question and the solution isn't applicable in the given case.