Solving DNS Resolution Problems
This topic provides a way to check whether the DNS query you are making from your OpenVPN client device is making it through the VPN tunnel.
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. 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.
Tip
What's DNS? Refer to 1. What is DNS?
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.
Ensure you've configured the DNS settings for Access Server:
Sign in to the Admin Web UI.
Click 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).
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.
Note
In our documentation, we use example IPv4 addresses and subnets reserved for documentation, such as 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.
Ensure you replace them with valid IPv4 addresses and subnets for your network(s).
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:
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)1 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)2 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)3 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)4
The VPN client at 203.0.113.2 sent a DNS request to Access Server.
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 MAX 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.
This line shows a DNS result received.
This line shows the result relayed back to the VPN client.
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.
Sign in to the Admin Web UI.
Click Configuration > VPN Settings.
Enter a single domain or list of comma-separated domains for DNS Resolution Zones.
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.
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.
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.2541
DNS Effective Name Resolution Policy Table Settings2
Settings for .openvpn.net
----------------------------------------------------------------------------
Generic (DNS Servers) : 1.2.3.4The 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.
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:1 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.
Click Configuration > VPN Settings.
Enter a default suffix for Default Domain Suffix.
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 the 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
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: 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)1
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)1
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 no firewall is 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.
Check if the built-in Windows firewall is blocking queries from a subnet outside the local network on Windows Server platforms.
If you use private IP addresses for a DNS server, ensure that it doesn't belong to one of the VPN subnets.