What is Azure Private DNS?

Azure Private DNS is a DNS service for Azure virtual networks. You can register a private DNS zone to Azure Private DNS and then link that zone with one or more virtual networks. If you enable DNS auto-registration for a virtual network, a new resource (e.g. virtual machines and VPN Gateways) will automatically add its IP address to Azure Private DNS. Resources in the linked virtual networks can use entries in Azure Private DNS to locate each other, instead of relying on IP addresses or the default Azure DNS domain. You can make Azure Private DNS and Azure VPN Gateway work together in several ways, some of which this article will describe.

The Azure VPN Gateway supports the OpenVPN protocol (except the “Basic SKU”). Unlike, for example, the commercial Access Server, the VPN Gateway does not have a built-in certificate authority (CA) tool for managing client certificates. And client certificates are essentially a requirement if you need to support clients other than Windows and Mac, such as Linux, iOS or Android. The use of easy-rsa-old as a CA for Azure VPN Gateway is documented quite well in this blog post, but this post is about using the newer easyrsa3 instead. Basic familiarity with easyrsa3 is assumed, so we just go through the steps you’d normally take.

OpenVPN is among the best VPN solutions, especially when you need a cross-platform (Windows, Mac, Linux, Android, iOS) solution that just works. It is best suited for point to site (P2S) or “road warrior” setups where users access internal resources using a VPN client when on the road.

When setting up OpenVPN server in Azure you have several options at your disposal:

1. Set up your own open source OpenVPN 2 server

Update: the problem described in this article seems to be resolved in Fedora 36 (NetworkManager 1.38.0-2.fc36). It is still present in Fedora 35 (NetworkManager 1.32.12-2.fc35).

The title of this blog post may seem familiar to some, as I solved this problem for OpenVPN earlier. I won’t repeat myself here, so please check the OpenVPN article to understand why this is happening.

Wireguard servers - unlike OpenVPN servers - are not able to push any settings such as DNS servers to their clients. However, Wireguard client itself is able to run PostUp commands to configure per-link DNS. The same approach can be used with OpenVPN “up” scripts as well, if you prefer having full control at the client-side. Here’s a Wireguard example:

Update: the problem described in this article seems to be resolved in Fedora 36 (NetworkManager 1.38.0-2.fc36). It is still present in Fedora 35 (NetworkManager 1.32.12-2.fc35).

Update: there a companion article about solving this problem for Wireguard in here.

In an the Manage Linux client DNS settings in OpenVPN and Wireguard article we described how to use the update-systemd-resolved script to update systemd-resolved per-link DNS servers automatically based on DNS servers pushed from an OpenVPN server. This is very convenient if you have to be connected to multiple remote locations each with their own DNS servers and zones.

OpenVPN and Wireguard are both used to provide secure, remote access to an organization’s internal services such as network shares (NFS and Samba), desktops and servers (SSH and RDP) or web services. Linux is generally a first-class citizen as far as clients are concerned but with one exception: accessing DNS through the VPN tunnel.

OpenVPN servers have the concept of pushing settings such as DNS servers to client. This happens by emulating a DHCP server. Windows OpenVPN clients for example are able to process this information automatically to update the (per-link) DNS server settings automatically. But Linux traditionally has not had this capability without support from “up” and “down” scripts. When one is using systemd-resolved the traditional ways such as using resolvconf or modifying /etc/resolv.conf directly no longer work or cause issues. Fortunately there is a good script, update-systemd-resolved, for automating the DNS server setup process for systemd-resolved. Basically it takes the list of DNS settings OpenVPN provides and converts them into dbus calls that modify the running systemd-resolved’s configuration.