Solving DNS Resolution Problems⁠

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. This helps you determine whether issues occur on the client or server side.

Access Server supports pushing instructions to VPN clients to use specific DNS servers. You can configure two DNS servers using the Admin Web UI. You can configure these from the command line for advanced configurations with more than two. Access Server also supports sending additional instructions for DNS resolution zones and default domain suffixes.

Testing DNS resolution from a client system⁠

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

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

Sign in to the Admin Web UI.
Select Configuration → VPN Settings.
Set Have clients use specific DNS Servers to Yes under DNS Settings.
Enter the Primary DNS Server.
Enter the Secondary DNS Server (optional).
Select Save Settings and Update Running Server.
- All OpenVPN clients' DNS requests go through Access Server to the specified DNS server.

For our example:

We installed OpenVPN Connect on Windows 11 and are connected to Access Server.
We set the primary DNS server to 8.8.8.8, the public Google DNS server.

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

To monitor activity from the server side:

Connect to the console and get root privileges.
Install tcpdump:
```
apt-get update
apt-get install tcpdump
```
After installation, run tcpdump with these parameters:
```
tcpdump -eni any port 53
```
(Optional) Filter by the VPN client IP address:
```
tcpdump -eni any port 53 and host 203.0.113.22
```

Create activity on the client side:

Open a command prompt on the VPN client device. (For example, run the cmd program on Windows to open the command prompt app.)
Enter this command to wipe the DNS resolver cache so it won't pull results from its local memory:
```
ipconfig /flushdns
```

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:

Return to your console or SSH session for Access Server.
If DNS resolution works correctly, you see results like this:
```
18:03:07.976553 In ethertype IPv4 (0x0800), length 76: 203.0.113.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.0.2.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.0.2.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 > 203.0.113.2.49531: 53268 1/0/0 A 216.58.211.100 (48)
```
1. The VPN client at 203.0.113.2 sent a DNS request to Access Server.
2. Access Server sent the request to the DNS server at 8.8.8.8, to find the A record (IP address for the DNS name www.google.com. The request went out through the network interface with the 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.
3. This line shows a DNS result received.
4. This line shows the result relayed back to the VPN client.

Split-DNS when using DNS resolution zones⁠

Access Server supports split DNS, which resolves only certain zones (domains) through a DNS server pushed by the VPN server and the rest through your existing local DNS servers.

Sign in to the Admin Web UI.
Select Configuration → VPN Settings.
Enter a single domain or list of comma-separated domains for DNS Resolution Zones.
Select 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.
- 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.
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.

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.0.2.254

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

The local DNS server handling most requests: Ethernet at 192.0.2.254.
The DNS server pushed by Access Server to resolve requests for the zone .openvpn.net: 1.2.3.4.

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

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 DNS server is assigned to the network adapter as the only top-level zone for DNS resolution. All DNS queries get redirected to the server at 1.2.3.4.

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.0.2.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.0.2.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:

Sign in to the Admin Web UI.
Select Configuration → VPN Settings.
Enter a default suffix for Default Domain Suffix.
Select Save Settings and Update Running Server.
- Windows clients will receive an instruction to resolve host names to FQDN names.

After configuring the default domain suffix, you can test it from one of your Windows clients. You can run a command from Command Prompt or PowerShell.

Command to see the default domain suffix using the 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

Additional troubleshooting⁠

Below are additional troubleshooting tips for DNS server issues.

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

A local DNS server in your network may only resolve local names or be 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: 203.0.113.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.0.2.133.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50)
18:07:10.082507 In ethertype IPv4 (0x0800), length 94: 203.0.113.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.0.2.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.0.2.133.54519: 50281 NXDomain 0/1/0 (123)
18:07:10.103641 Out ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 203.0.113.2.54519: 50281 NXDomain 0/1/0 (123)

The NXDomain output is like saying, "We can't find the answer to your question." We purposefully selected a name for our example that didn't exist, so we got this 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.0.2.133.60180 > 1.2.3.4.53: 16427+ AAAA? www.google.com. (32)
18:19:29.935479 In ethertype IPv4 (0x0800), length 76: 203.0.113.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:
1. Choose a DNS server that works.
2. Ensure no firewall is blocking traffic between the VPN client and the DNS server.
3. 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.
4. Check if the built-in Windows firewall is blocking queries from a subnet outside the local network on Windows Server platforms.
5. If you use private IP addresses for a DNS server, ensure that it doesn't belong to one of the VPN subnets.

Solving DNS Resolution Problems⁠

Testing DNS resolution from a client system⁠

Split-DNS when using DNS resolution zones⁠

Using default domain suffix⁠

Additional troubleshooting⁠

Was this information helpful?