OpenVPN Support Forum

Hello,

with the lastest OpenVPN Connect 3.3.6 oder Community Edition 2.5.7 (Windows 10 x64) the pushed DHCP-OPTION DOMAIN seems not to work anymore as expected like in previous versions. Resolving hostnames without fqdn don't work.
Using OpenVPN Gui 2.5.6 it works, with 2.5.7 not.
Is this a bug or a bad feature?

regards
Markus

Hi Markus,

"Search" domains (see your Windows resolver documentation, it might be explained in PowerShell cmdlets) are an ugly kludge. The way they work, a stub resolver first asks for the non-qualified name, and on getting NXDOMAIN for that query, it then appends a dot and one of the specified search domains (in order specified probably, although that could vary according to the OS resolver implementation, and I can't speak for every OS ever created.)

Then the query is retried with this name, and this process repeats for every listed search domain until a positive answer is received.

Every DNS name is fully qualified and goes all the way back to the root zone, "." DNS nameservers only deal in fully qualified names. One exception to this I know of is dnsmasq(8), which has its own domain defined, and assumes that a non-qualified name queried is a name in that domain. So it works like a search domain but saves one of the steps of failed resolution.

Windows has a feature called Name Resolution Policy Table (NRPT) and this is implemented in OpenVPN Connect. But I am not sure if community openvpn(8) servers push this. (Our commercial products do.)

As for your question about 2.5.7, this is not the proper subforum for that. We don't have an actual forum dedicated to community client issues. But since most client issues are actually server issues, you can take such questions to the server forum (Administration or Configuration for community, or OpenVPN Access Server, or OpenVPN Cloud.)

If you do repost about your 2.5.7 question in one of the above, this post might help you get to a useful answer in an expeditious manner.

regards, rob0

openvpn_inc wrote: ↑

Tue Jul 19, 2022 2:04 pm

...Windows has a feature called Name Resolution Policy Table (NRPT) and this is implemented in OpenVPN Connect. But I am not sure if community openvpn(8) servers push this. (Our commercial products do.)

Thanks for your answer.
The server side of my OpenVPN implementations are Sophos XGS Firewalls.
They send DHCP-OPTION DOMAIN domainname.

For example here an cut of the logfile:
0 [route] [remote_host] [255.255.255.255] [net_gateway]
1 [route-gateway] [10.81.234.1]
2 [sndbuf] [0]
3 [rcvbuf] [0]
4 [ping] [45]
5 [ping-restart] [180]
6 [route] [192.168.44.0] [255.255.255.0]
7 [topology] [subnet]
8 [route] [remote_host] [255.255.255.255] [net_gateway]
9 [dhcp-option] [DNS] [192.168.44.1]
10 [dhcp-option] [DNS] [192.168.44.254]
11 [dhcp-option] [DOMAIN] [cubus.local]
....
Remote Address: 92.206.82.47
Tunnel Addresses:
10.81.234.4/24 -> 10.81.234.1
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv6: no
Add Routes:
192.168.44.0/24
Exclude Routes:
DNS Servers:
192.168.44.1
192.168.44.254
Search Domains:
cubus.local

If I now ping an fqdn, like server.cubus.local, the ip is resolved correctly. But as I ping only the hostname, server, no ip is resolved.
As I change OpenVPN Connect to the community version of OpenVPN Gui up to version 2.5.6 it works with same client configs.

When I put the option "dhcp-option ADAPTER_DOMAIN_SUFFIX Domainname" to the client config it also works with OpenVPN Connect. However, this requires a manual change to the config file of each user, who actually downloads it conveniently from the Sophos user portal.

regards
Markus