Cannot connect to the Private Endpoint of an Azure Storage Account from AWS

Question

Cannot connect to the Private Endpoint of an Azure Storage Account from AWS

Alex Sanchez 25

I am using a Site to Site VPN between AWS and Azure, so all the traffic is private between them. The connection is successful and is showing UP in the AWS side and Connected on the Azure side. I also tested the connection between an EC2 instance and a VM using ping, telnet, and tcpping command by pointing to the private IP of each machine, and all of them are successful and show connection between them also through these ports. Also, I ensured that the traffic by these protocols is enabled using the security groups.

The problem starts when try to test the connection to an Azure Storage Account using a Private Endpoint. The service is not resolving the private endpoint when using the hostname instead of the private IP. I tested with curl -v and telnet command to the private IP of the storage account and shows connection. But if I try using the hostname in it does not work for resolving the private ip, for example, when using nslookup command with the hostname it shows the following:

Server:         192.168.0.2
Address:        192.168.0.2#53
Non-authoritative answer:
rclonedevsa.blob.core.windows.net       canonical name = rclonedevsa.privatelink.blob.core.windows.net.
rclonedevsa.privatelink.blob.core.windows.net   canonical name = blob.blz22prdstr07a.store.core.windows.net.
Name:   blob.blz22prdstr07a.store.core.windows.net
Address: 52.239.169.228

So, it's not resolving a private IP, instead is showing the public one, even when the host file is modified (for testing purposes):

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 
::1 localhost6 localhost6.localdomain6 
10.1.2.4 rclonedevsa.blob.core.windows.net

In the end, if I try to use a service which depends on this hostname, it will fail because of this like, for example, using Rclone.

Any guidance on this would be really helpful, thanks.

0 comments

Answer accepted by question author

TP 162.3K Volunteer Moderator

Hi Alex,

Are you using conditional forwarding on AWS side to send DNS requests over to Azure DNS Private Resolver on Azure side, or your own DNS server VM in VNet on Azure side?

The idea is, when the DNS lookup occurs from AWS side, the request is sent over to DNS server (or Azure DNS private resolver) in VNet in Azure, and this DNS server sends request to 168.63.129.16 which returns correct private IP for the private endpoint.

Please see article below (scroll a bit and click on diagram), and add a comment below if you have questions. If you think I'm understanding your configuration/needs incorrectly, please feel free to let me know in a comment and clarify.

What is Azure DNS Private Resolver?

https://learn.microsoft.com/en-us/azure/dns/dns-private-resolver-overview

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

Alex Sanchez 25 Reputation points

2025-04-09T19:35:51.04+00:00

Can you tell me more about this conditional forwarding? I am a little bit confused about it.
TP 162.3K Reputation points Volunteer Moderator

2025-04-09T21:39:21.9233333+00:00

Can you tell me more about this conditional forwarding? I am a little bit confused about it.

Sure. In this specific case, on your DNS server in AWS, you would create a conditional forwarder for domains that you want to want to forward requests over to Azure DNS Private Resolver.

For example, if you created forwarder for blob.core.windows.net it would send lookup requests for any hosts under blob.core.windows.net over to Azure DNS Private Resolver, which would in turn send to 168.63.129.16 on the Azure Virtual Network, and this would return correct private endpoint IP address.

NOTE: If you only have small number of VMs that need to resolve the private endpoint you could just use hosts file instead of setting up DNS private resolver, forwarding, etc.

In your question you mentioned hosts file. nslookup doesn't use hosts file, so it is normal that you were seeing public IP. Other applications will consider hosts file in their lookups, so it shouldn't be an issue.
Alex Sanchez 25 Reputation points

2025-04-09T22:15:33.7133333+00:00
Can you please share info about that behavior about the nslookup command? That would make me save a lot of time.

You mentioned:

Other applications will consider hosts file in their lookups, so it shouldn't be an issue. But, would not be a better practice to define this on a DNS service in the AWS side? Just asking

On the other hand, while setting up the DNS private resolver, I was trying to setting up in the subnet I am using but I am facing an issue regarding that it should not be used in the same subnet as the network interface card used for the private endpoint for the storage account. How can I solve this?
Alex Sanchez 25 Reputation points

2025-04-10T04:44:17.2133333+00:00

One additional question, should I use the FQDN or the privatelink one?
TP 162.3K Reputation points Volunteer Moderator

2025-04-10T05:25:55.8433333+00:00

Can you please share info about that behavior about the nslookup command? That would make me save a lot of time.

A: nslookup is diagnostic tool that allows you to send requests to DNS server. It provides lots of options to customize the requests for troubleshooting purposes such as which server to send to, type, show debug info, etc. It knows DNS protocol in regards to how to send requests over the network.

Contrast this with a regular application (e.g. web browser). In this case, it knows nothing about sending low-level dns protocol requests. When application needs to lookup a FQDN it calls standard API function of the operating system (e.g. gethostbyname, getaddrinfo). This API function considers the contents of the hosts file when responding to application.

You mentioned:

"Other applications will consider hosts file in their lookups, so it shouldn't be an issue."

But, would not be a better practice to define this on a DNS service in the AWS side? Just asking

A: Yes, it is better practice. I'm mentioning multiple approaches to give you potential options to fit your specific case. For example, say you only have one VM in AWS that needs to use the private endpoint, this isn't likely to change anytime soon, and maybe you have some budget constraints.

It may be simpler/quicker/cheaper to use hosts file as compared to setting up custom DNS server in AWS for conditional forwarding + Azure DNS Private Resolver in Azure.

Same reason I mentioned you could use your own DNS server in Azure instead of DNS Private Resolver -- it may have lower monthly cost.

There are pros/cons whichever way you choose. Azure DNS Private Resolver would be the standard approach that you would see in MS documentation.

One additional question, should I use the FQDN or the privatelink one?

A: Use the FQDN
Alex Sanchez 25 Reputation points

2025-04-10T13:46:00.9933333+00:00

Perfect, your solution worked. Finally I decided to use the conditional forwarding on the AWS side, in the future the computing components will migrate to a container tool (ECS, for example) so is a better option to decouple the DNS server from the machine itself

1 additional answer

Your answer

Alex Sanchez 25 Reputation points

2025-04-09T19:35:51.04+00:00

Can you tell me more about this conditional forwarding? I am a little bit confused about it.
TP 162.3K Reputation points Volunteer Moderator

2025-04-09T21:39:21.9233333+00:00

Can you tell me more about this conditional forwarding? I am a little bit confused about it.

Sure. In this specific case, on your DNS server in AWS, you would create a conditional forwarder for domains that you want to want to forward requests over to Azure DNS Private Resolver.

For example, if you created forwarder for blob.core.windows.net it would send lookup requests for any hosts under blob.core.windows.net over to Azure DNS Private Resolver, which would in turn send to 168.63.129.16 on the Azure Virtual Network, and this would return correct private endpoint IP address.

NOTE: If you only have small number of VMs that need to resolve the private endpoint you could just use hosts file instead of setting up DNS private resolver, forwarding, etc.

In your question you mentioned hosts file. nslookup doesn't use hosts file, so it is normal that you were seeing public IP. Other applications will consider hosts file in their lookups, so it shouldn't be an issue.
Alex Sanchez 25 Reputation points

2025-04-09T22:15:33.7133333+00:00

Can you please share info about that behavior about the nslookup command? That would make me save a lot of time.

You mentioned:

Other applications will consider hosts file in their lookups, so it shouldn't be an issue. But, would not be a better practice to define this on a DNS service in the AWS side? Just asking

On the other hand, while setting up the DNS private resolver, I was trying to setting up in the subnet I am using but I am facing an issue regarding that it should not be used in the same subnet as the network interface card used for the private endpoint for the storage account. How can I solve this?
Alex Sanchez 25 Reputation points

2025-04-10T04:44:17.2133333+00:00

One additional question, should I use the FQDN or the privatelink one?
TP 162.3K Reputation points Volunteer Moderator

2025-04-10T05:25:55.8433333+00:00

Can you please share info about that behavior about the nslookup command? That would make me save a lot of time.

A: nslookup is diagnostic tool that allows you to send requests to DNS server. It provides lots of options to customize the requests for troubleshooting purposes such as which server to send to, type, show debug info, etc. It knows DNS protocol in regards to how to send requests over the network.

Contrast this with a regular application (e.g. web browser). In this case, it knows nothing about sending low-level dns protocol requests. When application needs to lookup a FQDN it calls standard API function of the operating system (e.g. gethostbyname, getaddrinfo). This API function considers the contents of the hosts file when responding to application.

You mentioned:

"Other applications will consider hosts file in their lookups, so it shouldn't be an issue."

But, would not be a better practice to define this on a DNS service in the AWS side? Just asking

A: Yes, it is better practice. I'm mentioning multiple approaches to give you potential options to fit your specific case. For example, say you only have one VM in AWS that needs to use the private endpoint, this isn't likely to change anytime soon, and maybe you have some budget constraints.

It may be simpler/quicker/cheaper to use hosts file as compared to setting up custom DNS server in AWS for conditional forwarding + Azure DNS Private Resolver in Azure.

Same reason I mentioned you could use your own DNS server in Azure instead of DNS Private Resolver -- it may have lower monthly cost.

There are pros/cons whichever way you choose. Azure DNS Private Resolver would be the standard approach that you would see in MS documentation.

One additional question, should I use the FQDN or the privatelink one?

A: Use the FQDN
Alex Sanchez 25 Reputation points

2025-04-10T13:46:00.9933333+00:00

Perfect, your solution worked. Finally I decided to use the conditional forwarding on the AWS side, in the future the computing components will migrate to a container tool (ECS, for example) so is a better option to decouple the DNS server from the machine itself

Answer 1

Praveen Bandaru 11,800 Microsoft External Staff Moderator

Hello Alex Sanchez

I understand that you are facing a resolution issue when you are trying to connect AWS to azure storage account:

For further investigation, please provide the following information:

Also, let me know which DNS you are using in the private endpoint VNET - Azure provided or custom DNS.

If you are using custom DNS, you need to set a forwarder in the custom DNS server machine point to azure DNS IP (168.63.129.16.). And also, please confirm whether the custom DNS and private endpoint are in the same VNET or different VNETs, and check in the private DNS zone VNET's are linked properly.

If you are connecting from on-premises (AWS), you need to configure a conditional forwarder in the on-prem DNS server machine to point to the private DNS resolver inbound IP. Additionally, you need to configure the private DNS resolver inside Azure.

you are not ready to use a private DNS resolver, you need to configure a VM as a DNS server instead. Then, set up a conditional forwarder in the on-prem (AWS) DNS server machine to point to the VM's private IP.

Check the below public document for more understanding:

https://github.com/msrini-MSFT/Troubleshooting-Private-Link-DNS-Scenarios?tab=readme-ov-file#scenario-2---if-your-source-machine-is-deployed-on-premises-other-cloud

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to "Accept Answer " and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Alex Sanchez 25 Reputation points

2025-04-10T04:45:13.7566667+00:00

All of what I am using is Azure provided. I have not implemented anything custom
Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2025-04-10T07:29:23.07+00:00

Hello Alex Sanchez
Thank you for your response.

If you are using Azure-provided DNS in the Private Endpoint VNET, forwarder configuration on the Azure side is not required. You can simply link the Private Endpoint VNET to the private DNS zone and use the private DNS resolver.
Additionally, on your On-prem (AWS) DNS server machine, you need to configure a conditional forwarder pointing to the Azure private DNS resolver inbound IP.Check the document: https://github.com/msrini-MSFT/Troubleshooting-Private-Link-DNS-Scenarios?tab=readme-ov-file#scenario-2---if-your-source-machine-is-deployed-on-premises-other-cloud

Can you please share info about that behavior about the nslookup command? That would make me save a lot of time.

The nslookup command is a network utility that queries DNS servers for information about domain names and their associated IP addresses. It may show unexpected behaviours in different environments, such as variations in output or functionality across various operating systems.

Check the document for more understanding: nslookup

You mentioned: Other applications will consider hosts file in their lookups, so it shouldn't be an issue. But, would not be a better practice to define this on a DNS service in the AWS side? Just asking

This is another approach to forward DNS traffic to Azure, but this scenario is not recommended. You can use it for any workaround and testing purposes (best practices) only. If you make any modifications on the Azure side, this method will impact your production. The best approach is to use the Conditional Forwarder option.

you are not ready to use a private DNS resolver, you need to configure a VM as a DNS server instead. Then, set up a conditional forwarder in the on-prem (AWS) DNS server machine to point to the VM's private IP.

Additionally, as I mentioned in my previous response, if you are not ready to use a private DNS resolver, you can deploy a VM inside Azure and assign the DNS server role to it, which will reduce the cost.

One additional question, should I use the FQDN or the privatelink one?

Regarding your question, you can follow the below document to set public DNS zone forwarders.
https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns#storage

Once you complete all configurations, you can test nslookup from your source machine, and it will resolve privately.

Hope the above answer helps! Please let us know do you have any further queries.

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members