Unable to resolve Azure private endpoint to private IP over Azure VPN

Question

Unable to resolve Azure private endpoint to private IP over Azure VPN

Jeff Morris 25

TL;DR: Azure VPN clients working from home still resolve Azure File Storage Private Endpoint to the public IP instead of private.

All users including technical staff work from home using their work computers and home ISP.

Azure VPN is utilized to grant access to Azure resources.

We have configured an Azure File Storage account with file shares to server as network folder shares for the company. The file share has public network access disabled. A private endpoint has been created attached to the general servers VNET with a private IP in that subnet range to allow access to the file shares from the Azure network.

We do have a Private DNS zone automatically created with the private endpoint, and we added the A record to it for the storage account there as it only made an SOA record automatically and no other records were generated at the time of creation.

We added a forward lookup zone for "privatelink.file.core.windows.net" to our DNS servers (running as VMs inside of Azure) with an A record to the file storage account.

We are using ADDS/RBAC roles to allow resource access, not the storage keys and that portion seems to be functioning as desired to limit access to resources as intended.

Servers are resolving the

chrischin 915 Reputation points Microsoft Employee

2025-03-28T02:10:28.4233333+00:00

In order for your Private DNS zone to work for the DNS queries sent from your P2S VPN clients, the queries must eventually make it to Azure DNS.

If you are not using any other DNS solution inside Azure, double check that the VNET that your P2S clients connect to (it houses the GatewaySubnet), looks like the screenshot below.

If you are using your own DNS, make sure it eventually does conditional forwarding to Azure DNS.Once we are sure that the P2S VPN client DNS queries make it to Azure-provided DNS, we need to make sure this VNET is linked to the Private DNS zone that resolves the Azure File FQDN to the private IP address. Go to the Private DNS zone and then the Virtual Network Links blade. Ensure your VNET shows up in the list, if not, add it.
Go back and test from a P2S VPN client.

If you suspect a misconfiguration somewhere, where the users might be using their ISP's DNS, you can try a nslookup on a P2S VPN client to see what it is. The one you want to see is 168.63.129.16 (Azure DNS).
Jeff Morris 25 Reputation points

2025-03-28T14:45:40.61+00:00

We are using 2 custom DNS servers inside of Azure for DNS, not Azure-provided. I created a Forward Lookup Zone for privatelink.file.core.windows.net with a static A record to the Storage Account in Azure, which works just fine and the internal servers resolve to the private IP. P2S VPN connections still resolve the public IP using the ISP DNS.

CONFIG 1: Works for internal servers across multiple peered VNETs, but not for VPN clients.

NOTE: I also only had the 'vpnlink' and 'internal-link' from the Virtual Network Links screenshot below when it was working for all servers across different peered VNETs. I added the external-link during testing with the Conditional Forwarder as the servers stopped resolving the internal IP.

CONFIG 2: I also tried making it a conditional forwarder instead prior to this, but that didn't work as even the internal servers will resolve the public IP of the storage account.

Servers are in the yellow VNETs, VPN traffic and hub are the green VNET.

CONFIG 2 Server response: Points to internal DNS server but resolves public IP. When this was ran in CONFIG 1, this resolved the private IP and mapped network shares worked normally.

CONFIG 1 OR CONFIG 2 P2S VPN client response:
Jeff Morris 25 Reputation points

2025-03-28T15:57:53.39+00:00

Thanks, we have no on-prem anything. All users are at their individual homes using Azure VPN to connect to resources. All server infrastructure is located within Azure.

The VPN Gateway is in the 'Connectivity' subscription

The Storage Account is in 'Prod' Subscription

The Private Endpoint is in the 'Prod' Subscription / prod-internal-westus3-vnet/AppSubnet

The 2 custom domain controllers are in the 'Identity' subscription / shd-adds-westus3-vnet/ADDSSubnet

I updated the virtual links and the servers inside of Azure are resolving properly now. I forgot to add the identity link to connect the domain controllers. This is still using the Conditional Forwarder in custom DNS instead of the static A record in a forward lookup zone.

The VPN still resolves to public IPs.

Accepted answer

1 additional answer

Your answer

chrischin 915 Reputation points Microsoft Employee

2025-03-28T02:10:28.4233333+00:00

In order for your Private DNS zone to work for the DNS queries sent from your P2S VPN clients, the queries must eventually make it to Azure DNS.

If you are not using any other DNS solution inside Azure, double check that the VNET that your P2S clients connect to (it houses the GatewaySubnet), looks like the screenshot below.

If you are using your own DNS, make sure it eventually does conditional forwarding to Azure DNS.Once we are sure that the P2S VPN client DNS queries make it to Azure-provided DNS, we need to make sure this VNET is linked to the Private DNS zone that resolves the Azure File FQDN to the private IP address. Go to the Private DNS zone and then the Virtual Network Links blade. Ensure your VNET shows up in the list, if not, add it.
Go back and test from a P2S VPN client.

If you suspect a misconfiguration somewhere, where the users might be using their ISP's DNS, you can try a nslookup on a P2S VPN client to see what it is. The one you want to see is 168.63.129.16 (Azure DNS).
Jeff Morris 25 Reputation points

2025-03-28T14:45:40.61+00:00

We are using 2 custom DNS servers inside of Azure for DNS, not Azure-provided. I created a Forward Lookup Zone for privatelink.file.core.windows.net with a static A record to the Storage Account in Azure, which works just fine and the internal servers resolve to the private IP. P2S VPN connections still resolve the public IP using the ISP DNS.

CONFIG 1: Works for internal servers across multiple peered VNETs, but not for VPN clients.

NOTE: I also only had the 'vpnlink' and 'internal-link' from the Virtual Network Links screenshot below when it was working for all servers across different peered VNETs. I added the external-link during testing with the Conditional Forwarder as the servers stopped resolving the internal IP.

CONFIG 2: I also tried making it a conditional forwarder instead prior to this, but that didn't work as even the internal servers will resolve the public IP of the storage account.

Servers are in the yellow VNETs, VPN traffic and hub are the green VNET.

CONFIG 2 Server response: Points to internal DNS server but resolves public IP. When this was ran in CONFIG 1, this resolved the private IP and mapped network shares worked normally.

CONFIG 1 OR CONFIG 2 P2S VPN client response:
Jeff Morris 25 Reputation points

2025-03-28T15:57:53.39+00:00

Thanks, we have no on-prem anything. All users are at their individual homes using Azure VPN to connect to resources. All server infrastructure is located within Azure.

The VPN Gateway is in the 'Connectivity' subscription

The Storage Account is in 'Prod' Subscription

The Private Endpoint is in the 'Prod' Subscription / prod-internal-westus3-vnet/AppSubnet

The 2 custom domain controllers are in the 'Identity' subscription / shd-adds-westus3-vnet/ADDSSubnet

I updated the virtual links and the servers inside of Azure are resolving properly now. I forgot to add the identity link to connect the domain controllers. This is still using the Conditional Forwarder in custom DNS instead of the static A record in a forward lookup zone.

The VPN still resolves to public IPs.

Answer 1

chrischin 915 Microsoft Employee

Hi Jeff,

Your CONFIG1 has some drawbacks, and I am confident we can get something similar to CONFIG2 to work.

I see you are using the DNS role on Windows Server. Instead of doing it the way you have in the screen shot above (CONFIG1), do it this way instead:

Go to DNS Manager
Right-click on your server name and go to Properties
Go to the Forwarders tab
Click Edit and add Azure's DNS to it: 168.63.129.16

Finally, remove the Azure Files domain from your Forward Lookup Zone.

What this is doing is telling your DNS that anytime it receives a DNS query that it doesn't know how to resolve (not in any of your Foward Lookup Zone), send it off to Azure DNS to figure it out.

This way, you are not having your DNS server resolving Azure FQDNs which is hard to manage and may not be the behavior you want as you continue to add more resources to your environment. With CONFIG1, what would happen if you added a second Azure File share with its own private endpoint that has a different private IP than this one?

This will also cover you for future private endpoints on other Azure services.

Which VNET in your screenshot is the pair of DNS Servers residing in?

Do you have both of their IP address set in each of the VNET's?

Like this for me but use your own DNS Server IP addresses:

User's image

As for your P2S VPN clients, you will need to push a modified azurevpnconfig_xxx.xml file with this content:

User's image

Where x.x.x.x, and y.y.y.y would be your pair of DNS servers (https://learn.microsoft.com/en-us/azure/vpn-gateway/azure-vpn-client-optional-configurations).

To recap, after making these modifications, whenever a server or P2S VPN client needs to resolve your Azure File share FQDN (xyz.file.core.windows.net), the behavior will be consistent and be handled by your pair of DNS servers. Your DNS servers (once you remove the forward lookup zones from CONFIG1), will realize it doesn't know the answer for file.core.windows.net (nor should it), and forward to 168.63.129.16. If the VNET that your pair of DNS Servers are sitting in (shd-adds-westus3-vnet?), has a vnet link to the Private DNS Zone for your private endpoint, it will return the private endpoint IP.

Jeff Morris 25 Reputation points

2025-03-28T17:20:52.6166667+00:00

I am currently using the Conditional Forwarding in DNS. Forward lookup zone is already gone. The Azure IP is already in the DNS 'Forwarders' section as you describe, and that appears to be working perfectly with the internal servers.

All vnets have the 2 correct DNS IPs in the custom setting.

RDP checks from the DC's in the identity subscription, the file server in the prod-internal vnet, the web server in the prod-external network all resolve to the private IP as intended.

From the DC:

I checked the Azure VPN config and both DC IP's are in the XML (auto-generated, these weren't manually added):

Azure VPN client is still resolving to the public IP.

I ran Get-DnsClientNrptPolicy and I see the 2 intended DNS servers in the 'NameServers' section.
chrischin 915 Reputation points Microsoft Employee

2025-03-28T17:50:48.3733333+00:00
From a P2S VPN client, after successfully connecting to the hub VNET using VPN, could you run

ipconfig /all ipconfig /flushdns nslookup pminas1sa.file.core.windows.net nslookup pminas1sa.file.core.windows.net 10.100.2.4 ping pminas1sa.file.core.windows.net

And report back the results please.
Jeff Morris 25 Reputation points

2025-03-28T18:05:58.42+00:00
PS C:\WINDOWS\system32> ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : CT166F3

Primary Dns Suffix . . . . . . . : insidepmi.com

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : insidepmi.com

Ethernet adapter Ethernet 5:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Realtek USB GbE Family Controller #3

Physical Address. . . . . . . . . : 00-E0-4C-68-02-E9

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Ethernet adapter PdaNet Broadband Connection:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : PdaNet Broadband Adapter

Physical Address. . . . . . . . . : 02-50-F2-25-02-20

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wi-Fi 2:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel(R) Wi-Fi 7 BE200 320MHz #2

Physical Address. . . . . . . . . : DC-97-BA-01-D1-79

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wi-Fi 5:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel(R) Wi-Fi 7 BE200 320MHz #5

Physical Address. . . . . . . . . : DE-97-BA-01-D1-78

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wi-Fi:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel(R) Wi-Fi 7 BE200 320MHz

Physical Address. . . . . . . . . : DC-97-BA-01-D1-78

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::8d86:6c53:cf3a:c4cc%7(Preferred)

IPv4 Address. . . . . . . . . . . : 192.168.50.80(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Lease Obtained. . . . . . . . . . : Wednesday, March 26, 2025 7:03:00 AM

Lease Expires . . . . . . . . . . : Saturday, March 29, 2025 6:39:10 AM

Default Gateway . . . . . . . . . : 192.168.50.1

DHCP Server . . . . . . . . . . . : 192.168.50.1

DHCPv6 IAID . . . . . . . . . . . : 98342842

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2E-E9-2C-FF-00-E0-4C-68-02-E9

DNS Servers . . . . . . . . . . . : 192.168.50.1

NetBIOS over Tcpip. . . . . . . . : Enabled

PPP adapter Pragmatic Azure VPN:

Connection-specific DNS Suffix . : insidepmi.com

Description . . . . . . . . . . . : Pragmatic Azure VPN

Physical Address. . . . . . . . . :

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

IPv4 Address. . . . . . . . . . . : 10.100.50.4(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.255

Default Gateway . . . . . . . . . :

NetBIOS over Tcpip. . . . . . . . : Enabled

Connection-specific DNS Suffix Search List :

insidepmi.com ```Ethernet adapter Bluetooth Network Connection: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network) Physical Address. . . . . . . . . : DC-97-BA-01-D1-7C DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes PS C:\WINDOWS\system32>
Jeff Morris 25 Reputation points

2025-03-28T18:10:10.82+00:00
chrischin 915 Reputation points Microsoft Employee

2025-03-28T19:42:25.8033333+00:00
Can you add this to your azurevpnconfig_xxx.xml:

<azvpnprofile> <clientconfig> <dnssuffixes> <dnssuffix>file.core.windows.net</dnssuffix> </dnssuffixes> </clientconfig> </azvpnprofile>

Test it, and report back please.

The goal is to get your ipconfig /all to look similar to this for the PPP adapter Pragmatic Azure VPN entry:
Jeff Morris 25 Reputation points

2025-03-28T20:50:27.2866667+00:00

Same result. I tried as above as well a 'core.windows.net' and same output as above.

I did note in the articles this reference. We are using Entra ID for authentication, and I did verify the dns servers are not listed in the ipconfig output as expected.

"When using Microsoft Entra ID authentication, the Azure VPN Client utilizes DNS Name Resolution Policy Table (NRPT) entries, which means DNS servers aren't listed under the output of ipconfig /all. To confirm your in-use DNS settings, consult Get-DnsClientNrptPolicy in PowerShell."
chrischin 915 Reputation points Microsoft Employee

2025-03-28T21:17:38.29+00:00

Can you provide a fresh screenshot of ipconfig /all after your changes? I just want to make sure we see the dnssuffixes that you added. If we don't see it, it may not be aware of your changes and might need to:
Jeff Morris 25 Reputation points

2025-03-28T22:40:57.3066667+00:00

It's working now, it just needed the period before 'core.windows.net' to work properly. I noticed it when I was merging entries into the new XML file. File share is mapped and working as intended. Thank you SO much for the assistance! This was driving me nuts all week.

Answer 2

Hello Jeff Morris

Thank you for your response.

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, you need to configure a conditional forwarder in the on-prem DNS server machine to point to the private DNS resolver. Additionally, you need to configure the private DNS resolver inside Azure.

kindly check the below 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 “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Share via

Unable to resolve Azure private endpoint to private IP over Azure VPN

1 additional answer

Your answer