Ante Miličević

December 8, 2023

Azure Private Endpoints DNS resolution within an private network - Azure P2S VPN connection

Demystify Azure Private Endpoints and DNS resolution within a private network with this straightforward guide. Learn how to enhance network security and connectivity using Azure P2S VPN connections in a few simple steps.

Introduction

In this post we are going on details on how to make Private Endpoint DNS name resolution work properly over point to site (P2S) VPN connections using Azure Virtual Network VPN Gateway or Virtual WAN VPN Gateway. To setup a P2S Azure VPN with Azure AD SSO integration you can read here.

In this post we are going to cover:

Problem with Azure Private Endpoint P2S VPN DNS resolution
Problem with Azure P2S VPN DNS resolution - example
Solution 1 - Change hosts file on your local machine
Solution 2 - Use a DNS Forwarder
Solution 3 - Use Azure Private DNS Resolver - recommended

Problem with Azure Private Endpoint P2S VPN DNS resolution‍

In Azure, many DevOps engineers face a common issue: difficulties in resolving the DNS of a private endpoint while connected to a Point-to-Site (P2S) VPN. The problem stems from the fact that a private DNS zone doesn't work by default over an Azure P2S VPN connection. This means that it's not possible to find the correct address for a private resource when connected to a P2S VPN.

This becomes a big problem when using private endpoints to protect Azure resources because there's no easy way to figure out the correct address for the private endpoint when connected to a VPN.

It's important to know that this problem isn't limited to just P2S VPN connections. It also occurs when trying to find the address of a private resource from an on-premise network connected through ExpressRoute or a VPN S2S (Site-to-Site).

Thankfully, there are some solutions available to solve this problem. In this blog post, we'll discuss these solutions in simple terms. By understanding these options, you'll be able to overcome the challenge of DNS resolution when working with private endpoints and different types of VPN connections.

Problem with Azure P2S VPN DNS resolution - example

To give you a clearer understanding of the problem, let's consider a simplified scenario. Imagine there's a basic setup consisting of a public application that customers can access over the internet. This public app relies on a couple of private resources: another app service and a database.

Since it doesn't make sense for the database and the second app service to be accessible from anywhere on the internet, we decide to make them private using Azure Private Endpoints. When a private endpoint is created, Azure modifies the way name resolution works by adding a CNAME record that points to the specific fully qualified domain name (FQDN) of the private endpoint. You can read an explanation about private endpoint here.

By default, Azure also creates a private DNS zone with the <span id="test" class="kool-class" style="color: #E4474C; background-color: #E9E9E6; border-radius: 5px; padding: 5px;" fs-test-element="test">privatelink</span> subdomain and sets up a DNS A resource record for the private endpoint.

Here's the key point to understand: when you access the resource endpoint URL from outside the Virtual Network (VNet) where the private endpoint resides, it resolves to the public endpoint of the resource. However, when accessed from the VNet hosting the private endpoint, the resource endpoint URL resolves to the private endpoint's IP address.

While it may seem a bit complex at first, let me provide a quick example to help illustrate how private endpoints function in a simpler manner.

I have created a new App Service that is accessible to the public over the internet.

<pre class="codeWrap"><code>$ nslookup test-dns-resolver.azurewebsites.net
Server: ...
Address: ...
Non-authoritative answer:
Name: waws-prod-am2-439-397b.westeurope.cloudapp.azure.com
Address: 25.52.22.33
Aliases: test-dns-resolver.azurewebsites.netwaws-prod-am2-439.sip.azurewebsites.windows.net
</code></pre>

To enhance its security, I decided to make the app private by setting up a private endpoint. Azure facilitates this by modifying the public name resolution and adding a CNAME record that points to the dedicated fully qualified domain name (FQDN) of the private endpoint.

<pre class="codeWrap"><code>$ nslookup test-dns-resolver.azurewebsites.net
Server: ...
Address: ...
Non-authoritative answer:
Name: waws-prod-am2-439-397b.westeurope.cloudapp.azure.com
Address: 25.52.22.33
Aliases: test-dns-resolver.azurewebsites.net
test-dns-resolver.privatelink.azurewebsites.net
waws-prod-am2-439.sip.azurewebsites.windows.net
</code></pre>

When the private endpoint is created, a private DNS zone is automatically generated with a corresponding "privatelink" subdomain. This DNS zone includes an A-record that associates the private endpoint address with the private IP assigned to the resource. Additionally, the private DNS zone is linked to the virtual network (VNET).

<div class="table-wrap">
<div class="table-scroll">
<table>
<thead>
<th>Name</th>
<th>Type</th>
<th>Record Value</th>
</thead>
<tr>
<td>test-dns-resolver</td>
<td>A</td>
<td>10.0.1.5</td>
</tr>
<tr>
<td>test-dns-resolver.scm</td>
<td>(A)</td>
<td>10.0.1.5</td>
</tr>
</table>
</div>
</div>

Conversely, if the resolution is attempted from a client outside the VNET, it will return the public IP address. It's important to note that if the app is accessed from outside the VNET, an error will occur due to the private configuration.

Now, let's consider a situation where someone needs to access these private resources. To enable this, a Point-to-Site (P2S) VPN is implemented. However, when connected to the VPN and attempting to access private resources that utilize a private endpoint, an error occurs.

<pre class="codeWrap"><code>$ curl -I test-dns-resolver.azurewebsites.net
HTTP/1.1 403 Ip Forbidden
</code></pre>

This issue arises because private DNS zone resolution does not function properly when connected via an Azure P2S VPN connection. Instead of using the private endpoint's private IP, it attempts to connect using the public endpoint.

A similar problem occurs when attempting to access a private Azure resource from an on-premises network connected to Azure via Express Route or VPN.

To address this challenge, several solutions are available, which I will discuss in the following sections.

Solution 1 - Change hosts file on your local machine

The hosts file serves as a means to override the DNS system, allowing you to redirect a browser or other local applications to a specific IP address.

If you need to access a private resource, modifying the hosts file on your machine is the simplest solution. By pointing the private resource to the private IP of the private endpoint, you can override the DNS resolution for the private services.

Here's an example of how to modify the hosts file:

<pre class="codeWrap"><code>10.0.2.4 app-private-api-test-dns-resolver-dev.azurewebsites.net
10.0.2.4 app-private-api-test-dns-resolver-dev.scm.azurewebsites.net
10.0.5.5 cosmos-test-dns-resolver-dev.mongo.cosmos.azure.com
10.0.5.6 cosmos-test-dns-resolver-dev-westeurope.mongo.cosmos.azure.com
</code></pre>

With this configuration, the mentioned services will resolve to the private endpoint's private IP instead of the public endpoint.

While this solution works, it is highly inefficient. In the provided example, we only have two private resources—a Cosmos database and an App Service. However, in real projects with numerous resources and multiple environments (e.g., development, staging, production), managing the hosts file becomes burdensome as it accumulates hundreds of private IPs.

Moreover, each time a new private resource is created on Azure, the hosts file must be updated, and everyone using the VPN must be informed to update their own hosts files accordingly.

While this solution may suffice for small projects with a limited number of users accessing resources via VPN, it is not a viable approach in larger, more complex scenarios.

Solution 2 - Use a DNS Forwarder

Another solution for P2S VPN clients to resolve Private Endpoint entries hosted on Azure Private DNS Zones is by using a DNS Forwarder.

The primary purpose of a DNS Forwarder is to redirect DNS queries to Azure DNS.

Once you have deployed a DNS forwarder or proxy in Azure, you can configure the DNS server at the VNET level or directly in the client XML profile.

With the setup in place, you will be able to successfully resolve Private Endpoint entries from your VPN P2S clients.

The DNS forwarder or proxy can be hosted on a virtual machine or a container service like ACI or AKS.

Configuring a DNS forwarder is relatively straightforward, as you only need to forward queries to the Azure DNS IP: 168.63.129.16.

Here's an example of a containerized Bind DNS Server that can be deployed on ACI or AKS:

[GitHub Repository - az-dns-forwarder] (https://github.com/whiteducksoftware/az-dns-forwarder)

If you examine the Bind Server configuration, you'll notice that it simply forwards queries to Azure DNS:

<pre class="codeWrap"><code>options {
recursion yes;
allow-query { any; }; # do not expose externally
forwarders {
168.63.129.16;
};
forward only;
dnssec-validation no; # needed for private dns zones
auth-nxdomain no; # conform to RFC1035
listen-on { any; };
};
</code></pre>

Using a DNS Forwarder is the recommended solution for resolving private DNS zones, and it works well.

For more detailed documentation on this topic, you can refer to:

Azure Private Endpoint DNS Configuration Scenarios

However, there are some inconveniences with this approach. The DNS forwarder or proxy becomes an additional piece of software that requires proper setup and maintenance. Maintenance becomes more challenging if you use a virtual machine instead of a containerized approach because you need to manage the underlying OS updates.

Furthermore, setting the DNS forwarder as the main DNS server for the VNET implies a need for high availability deployment.

In conclusion, using a DNS forwarder to resolve a private DNS zone when connected to a VPN works well, but there is now a better solution available.

Solution 3 - Use Azure Private DNS Resolver - recommended

The Azure DNS Private Resolver resource eliminates the need for an additional DNS Forwarder to resolve private DNS zones.

Let's revisit the previous example where a public app was utilizing several private resources. After deploying an Azure Private DNS Resolver, the diagram will appear as follows:

The notable addition is the deployment of a DNS Resolver Inbound endpoint.

The inbound endpoint allows name resolution from on-premises or other private locations through an IP address within your private virtual network address space.

To enable the inbound endpoint, you need to allocate a subnet within the VNet where it will be provisioned. This subnet can only be delegated to "Microsoft.Network/dnsResolvers" and cannot be utilized by other services.

DNS queries received by the inbound endpoint will be routed to Azure DNS. This enables name resolution for Private DNS Zones, including VMs using auto registration or Private Link-enabled services.

It is crucial to configure the DNS Resolver Inbound endpoint as the DNS Server in the VNet. Failure to do so will result in the inability to resolve any private resources.

When creating a Private DNS Resolver, there is also the option of outbound endpoints. These outbound endpoints facilitate conditional forwarding of name resolution from Azure to on-premises, other cloud providers, or external DNS servers.

In this scenario, there is no need for an outbound endpoint; only the inbound endpoint is required.

The setup process is relatively straightforward. Provision an Azure DNS Private Resolver along with an inbound endpoint, and then configure the inbound endpoint as the DNS Server in your VNet.

You can configure inbound endpoint as the DNS server in 2 ways:

<ol>
<li style="white-space: pre-line;">Specify DNS Server for the Virtual Network
Go to your virtual network → “DNS servers” → “Custom”
<img src="https://cdn.prod.website-files.com/64d4f32bbf4bcd247875f1b1/6539818125f1ac20ca3138c3_azure-private-endpoints-dns-3.png" alt="azure private endpoints dns 3">
</li>
<li style="white-space: pre-line;">Specify DNS Server inside VPN Client Profile
Download VPN Client profile to your computer and add DNS settings.
Modify your XML file with following logic: </li>
<pre class="codeWrap"><code> ...
<usernamepass i:nil="true" />
</clientauth>
<clientconfig>
<dnsservers>
<dnsserver>10.225.2.4</dnsserver> #IP address of Inbound endpoint
</dnsservers>
</clientconfig>
<name>aks-vnet-29738558%</name>
...</code</pre>
</ol>

Once this is done, you will be able to resolve private DNS zones when connected to a P2S VPN.

Overall, the Azure DNS Private Resolver and inbound endpoint simplify the process of resolving private DNS zones, eliminating the need for additional components or configurations.