Troubleshooting DNS resolution problems

Upgrade to Latest Version

Introduction

This guide shows you how to test whether a DNS query from an OpenVPN client device successfully goes through the VPN tunnel to the target DNS server. Knowing this helps you determine if you encounter issues on the client or server ends.

Access Server supports pushing instructions to VPN clients to use specific DNS servers. You can configure two DNS servers using the Admin Web UI. For advanced configurations with more than two, you can configure these from the command line. This is a helpful feature if you run your own DNS server to resolve DNS names to private IP addresses. For example, you could provide a name, such as server1, to an end user for a Remote Desktop connection rather than connecting with the IP address. What's DNS? Refer to our commonly asked technical questions.

Access Server also supports sending additional instructions for DNS resolution zones and default domain suffixes.

Important: Operating systems handle DNS differently. Some try all DNS servers at once, accepting the first response. Not all operating systems support split DNS. This guide should help you with issues that arise from these differences.

Testing DNS resolution from a client system

This section shows how to test your DNS resolution from a device connected to Access Server.

Before you begin

Ensure you've configured the DNS settings for Access Server:

  1. Sign in to the Admin Web UI.
  2. Click Configuration > VPN Settings.
  3. Set Have clients use specific DNS servers to Yes under DNS Settings.
  4. Enter the Primary DNS Server.
  5. Enter the Secondary DNS Server (optional).
  6. Click Save Settings and Update Running Server.
    • All OpenVPN clients' DNS requests now go through Access Server to the specified DNS server.

For our example, we set the primary DNS server to 8.8.8.8, the public Google DNS server.

Note: We aren't using DNS resolution zones or the DNS default suffix setting in this scenario.

Ensure you've installed OpenVPN Connect on your chosen client system and are connected to Access Server.

For our example, we're using Windows 10 Professional connected to Access Server via OpenVPN Connect.

Monitor activity with tcpdump

Here, we use the tool tcpdump to monitor activity on port 53 TCP and UDP, the default port handling DNS queries. We flush the local DNS resolver cache on the client side and resolve several domains by pinging them.

Tip: We only have a few connected clients in our test situation. If you're testing on a production system with many connected clients, you can append a grep filter by IP address to filter the tcpdump queries so they return data specific to the VPN client's IP address.

To monitor activity from the server side:

  1. Open a console or SSH session to Access Server and obtain root privileges.
  2. Install tcpdump with these commands:
    apt-get update
    apt-get install tcpdump
  3. After installation, run tcpdump with these parameters:
    tcpdump -eni any port 53
  4. Filter by the VPN client IP address (optional):
    tcpdump -eni any port 53 and host 172.27.10.22

Create activity on the client side:

  1. Open a command prompt on the VPN client device. (For example, run the cmd program on Windows to open the command prompt app.)
  2. Enter this command to wipe the DNS resolver cache so it won't pull results from its local memory:
    ipconfig /flushdns
  3. Now create activity by resolving some domain names:
    ping www.google.com
    ping www.openvpn.net
    ping www.facebook.com
    • Each of these should yield results like this:
      Pinging www.google.com [216.58.212.228] with 32 bytes of data:
      Reply from 216.58.212.228: bytes=32 time=4ms TTL=56
      Reply from 216.58.212.228: bytes=32 time=3ms TTL=56
      Reply from 216.58.212.228: bytes=32 time=3ms TTL=56
      Reply from 216.58.212.228: bytes=32 time=3ms TTL=56
      Ping statistics for 216.58.212.228:
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
      Approximate round trip times in milli-seconds:
      Minimum = 3ms, Maximum = 4ms, Average = 3ms

View the client activity from the server:

  1. Return to your console or SSH session for Access Server.
  2. You should see results like this:
    18:03:07.976553 In ethertype IPv4 (0x0800), length 76: 172.27.232.2.49531 > 8.8.8.8.53: 53268+ A? www.google.com. (32)
    18:03:07.976579 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.49531 > 8.8.8.8.53: 53268+ A? www.google.com. (32)
    18:03:07.981162 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 > 192.168.47.133.49531: 53268 1/0/0 A 216.58.211.100 (48)
    18:03:07.981181 Out ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 > 172.27.232.2.49531: 53268 1/0/0 A 216.58.211.100 (48)

The above result from tcpdump shows these details:

  • The VPN client at 172.27.232.2 sent a DNS request.
  • Access Server sent the request to the DNS server at 8.8.8.8.
  • The request was to find the A record (IP address) for the DNS name www.google.com.
  • The first line shows that this request is coming to Access Server from the VPN client.
  • The second line shows the request leaving Access Server through the network interface with MAC address 00:0c:29:c7:60:e9, the Access Server network interface that goes to the internet since the 8.8.8.8 DNS server is on the internet.
  • The third line shows a DNS result received.
  • The fourth line shows the result relayed back to the VPN client.

In this case, DNS resolution is working.

Split-DNS when using DNS Resolution Zones

Access Server supports split DNS, which is the principle of resolving only certain zones (domains) through a DNS server pushed by the VPN server and the rest through your already present local DNS servers. 

You configure this in Access Server:

  1. Sign in to the Admin Web UI.
  2. Click Configuration > VPN Settings.
  3. Enter a single domain or list of comma-separated domains for DNS Resolution Zones.
  4. Click Save Settings and Update Running Server.
    • Clients will receive an instruction to resolve those domains through the DNS server pushed by Access Server and resolve the rest through the client's local DNS server.

Note: Not all OpenVPN clients support this, and there are some differences in behavior between versions of OpenVPN. You can achieve the best results with OpenVPN Connect v3.

When you use split DNS, you don't see the pushed DNS server in your ipconfig output. The DNS server isn't implemented at the network interface configuration level. Instead, it's implemented in the DNS system in a DNS resolution policy table.

Tip: To query this, you can use the scutil command-line utility on macOS or netsh on Windows. You can also use PowerShell on Windows, which we cover further down.

Split DNS example

Here, we give an example of how split DNS and normal DNS resolution look through the VPN tunnel.

Commands to see network configuration and DNS resolution policy on Windows:

ipconfig /all
netsh namespace show effectivepolicy

Commands to see network configuration and DNS resolution policy on macOS:

ifconfig
scutil -dns

Example output on Windows when split DNS is currently in use:

(OpenVPN) adapter Local Area Connection:
Description . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                    fec0:0:0:ffff::2%1
                                    fec0:0:0:ffff::3%1

Ethernet adapter Ethernet:
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
DNS Servers . . . . . . . . . . . : 192.168.47.254

DNS Effective Name Resolution Policy Table Settings
Settings for .openvpn.net
----------------------------------------------------------------------------
Generic (DNS Servers) : 1.2.3.4

The above output shows:

  • The local DNS server handling most requests: Ethernet at 192.168.47.254.
  • The DNS server pushed by Access Server to resolve requests for the zone .openvpn.net: 1.2.3.4.
  • Split DNS is in use in this example.

In this example, *.openvpn.net is resolved through the VPN DNS server. All others resolve through the local DNS server 192.168.47.254.

Note: The VPN interface gets three IPv6 self-assigned DNS server addresses. These aren't assigned by OpenVPN but by the operating system and shouldn't affect DNS resolution.

Example output on Windows when split DNS isn't used:

(OpenVPN) adapter Local Area Connection:
  Description . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect
  DNS Servers . . . . . . . . . . . : 1.2.3.4

DNS Effective Name Resolution Policy Table Settings
Settings for .
----------------------------------------------------------------------------
Generic (DNS Servers) : 1.2.3.4

The above output shows:

  • The DNS server is assigned to the network adapter as the only top-level zone for DNS resolution.
  • Split DNS isn't in use for this example.

In this example, all DNS queries get redirected to the server at 1.2.3.4.

Split DNS commands for PowerShell on Windows

You can run the following commands as an administrator in PowerShell.

Commands to see the network configuration and DNS resolution policy:

Get-NetIPConfiguration
Get-DnsClientServerAddress
Get-DnsClientNrptPolicy
Get-DnsClientNrptRule

Example output on Windows when split DNS is used:

PS C:\Users> Get-NetIPConfiguration

InterfaceAlias : Local Area Connection
InterfaceIndex : 4
InterfaceDescription : TAP-Windows Adapter V9 for OpenVPN Connect
DNSServer : fec0:0:0:ffff::1
fec0:0:0:ffff::2
fec0:0:0:ffff::3

InterfaceAlias : Ethernet
InterfaceIndex : 6
InterfaceDescription : Intel(R) 82574L Gigabit Network Connection
DNSServer : 192.168.47.254



PS C:\Users> Get-DnsClientServerAddress

InterfaceAlias            Interface Address ServerAddresses
                          Index     Family
--------------            --------- ------- ---------------
Local Area Connection             4 IPv6    {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
Ethernet                          6 IPv4    {192.168.47.254}


PS C:\Users> Get-DnsClientNrptPolicy

Namespace : .openvpn.net
QueryPolicy :
NameServers : {1.2.3.4}

Example output on Windows when split DNS isn't used:

PS C:\Users> Get-NetIPConfiguration

InterfaceAlias : Local Area Connection
InterfaceIndex : 4
InterfaceDescription : TAP-Windows Adapter V9 for OpenVPN Connect
DNSServer : 1.2.3.4


PS C:\Users> Get-DnsClientServerAddress

InterfaceAlias           Interface Address ServerAddresses
                         Index     Family
--------------           --------- ------- ---------------
Local Area Connection            4 IPv4    {1.2.3.4}

PS C:\Users> Get-DnsClientNrptPolicy
PS C:\Users> Get-DnsClientNrptRule
PS C:\Users>

Using default domain suffix

Access Server supports setting a default suffix so Windows clients can resolve host names to fully-qualified domain names (FQDN). This feature is helpful for a network using a Windows Domain or Active Directory server.

You configure this in Access Server:

  1. Sign in to the Admin Web UI.
  2. Click Configuration > VPN Settings.
  3. Enter a default suffix for Default Domain Suffix.
  4. Click Save Settings and Update Running Server.
    • Windows clients will receive an instruction to resolve host names to FQDN names.

After you configure the default domain suffix, you can test from one of your Windows clients. You can run a command from the command prompt or PowerShell.

Command to see the default domain suffix using command prompt:

ipconfig /all

Commands to see the default domain suffix using PowerShell:

Get-DnsClient
Get-DnsClientGlobalSetting

Example output when a default domain suffix is in use via command prompt:

PS C:\Users> ipconfig /all
Windows IP Configuration
DNS Suffix Search List: openvpn.net
Local Area Connection Adapter:
Connection-specific DNS Suffix. . : openvpn.net
Description . . . . . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect

Example output when a default domain suffix is in use via PowerShell:

PS C:\Users> Get-DnsClient


InterfaceAlias         Interface ConnectionSpecificSuffix ConnectionSpecificSuffix RegisterThisConn UseSuffixWhen
                           Index                          SearchList               ectionsAddress   Registering
--------------         --------- ------------------------ ------------------------ ---------------- -------------
Local Area Connection          4 openvpn.net              {}                       True             False

Troubleshooting

Below, we provide some tips for troubleshooting DNS server issues.

Ping request could not find domain (…). Please check the name and try again

You may encounter this if the client DNS server doesn't know the domain you are trying to resolve, can't be reached, or isn't correctly configured.

If the DNS server doesn't know the domain

It's possible that a local DNS server in your network can only resolve local names or is limited to a particular DNS zone.

Here's an example of an output showing a domain the DNS server can't resolve:

18:07:10.082330 In ethertype IPv4 (0x0800), length 94: 172.27.232.2.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50)
18:07:10.082356 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.168.47.133.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50)
18:07:10.082507 In ethertype IPv4 (0x0800), length 94: 172.27.232.2.57858 > 8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50)
18:07:10.082521 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.168.47.133.57858 > 8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50)
18:07:10.103610 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 192.168.47.133.54519: 50281 NXDomain 0/1/0 (123)
18:07:10.103641 Out ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 172.27.232.2.54519: 50281 NXDomain 0/1/0 (123)

In the output, NXDomain is like the output saying, "we can't find the answer to your question."

For our example, we purposefully selected a name that didn't exist to be sure we saw the error.

You could resolve the issue by configuring the DNS server to forward DNS queries to a public DNS server. That way, the DNS server can respond to both queries for local names and public names. Then, you can run tcpdump as described above.

If the DNS server can't be reached

If a query arrives at the VPN client, passes through Access Server, and out to the internet, but there's no reply, the DNS server is unreachable or not a DNS server.

Here's an example of an output showing that situation:

18:19:29.935439 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.60180 > 1.2.3.4.53: 16427+ AAAA? www.google.com. (32)
18:19:29.935479 In ethertype IPv4 (0x0800), length 76: 172.27.232.3.51334 > 1.2.3.4.53: 37513+ A? www.google.com. (32)

For our example, we used the IP address 1.2.3.4, which isn't a real DNS server. The query repeats a few times but ultimately fails.

To resolve this issue, you may need to do one of the following, depending on what's causing the unreachable server:

  • Choose a DNS server that works.
  • Ensure there isn't a firewall blocking traffic between the VPN client and the DNS server.
  • Check for missing routes (if you're using routing instead of NAT for Access Server) and implement static routes for direct VPN client communication or switch to NAT.
  • On Windows Server platforms, check if the built-in Windows firewall is blocking queries from a subnet outside the local network.
  • If you use private IP addresses for a DNS server, ensure that it doesn't belong to one of the VPN subnets.