full and consistent support of dhcp-option DOMAIN and DOMAIN-SEARCH

[gvde]

It would be good if there was a consistent use of the dhcp-option to set the domain name suffix for the connection as well as the domain search list. Currently, it's a mix of using DOMAIN only, using it as connection suffix if it's a single one or using it as search list if there are multiple. Some clients use DOMAIN-SEARCH for search list. However, that's not even in the official documentation. It's really not easy to set this up properly for all kinds of clients if it's not clear from the configuration/server side to start with.

The connection suffix and the search list are two separate things, two separate dhcp options and should be handled separately.

In my opinion, DOMAIN should be the connection suffix as it is described in the documentation, the equivalent of DHCP option 15 Domain Name.

The dns domain search list, i.e. the equivalent of DHCP option 119 Domain Search should be a separate configuration option, e.g. DOMAIN-SEARCH as it is already used by some.

On client side, this should obviously be handled the same way it would be handled if options were not pushed by openvpn but instead the client would actually use DHCP with a DHCP server delivering exactly those two options as described.

[Selva Nair]

I do not think there is any inconsistency in the way --dhcp-option DOMAIN foo is handled within OpenVPN. On OS-es where dhcp-option is internally handled (e.g., Windows) its passed on as option 15. On other systems its in the environment as foreign_option_{n} set to dhcp-option DOMAIN foo.

Possibly scripts like update-resolv-conf handles it differently depending on foo is a single word or multiple words and may need fixing. Contributed scripts like pull-resolv-conf/xxx may also be doing this. But OpenVPN core doesn't make any such distinction. Though, technically, option 15 should be a single word (domain).

As for DOMAIN_SEARCH (option 119), we don't currently support it. AFAIK, until a recent update to Windows 10, this option wasn't correctly handled on Windows which is is relevant as Windows is one of the main platforms where we can internally process dhcp options.

That said, we could add DOMAIN-SEARCH as a new dhcp-option. Users will have to take care to specify DOMAIN (option 15) as a single suffix as systems/scripts may continue to interpret it differently based on single or multiple words.

[Gert Döring]

Interesting coincidence. I got the question about "can OpenVPN set the searchlist on Windows?" just a few weeks ago by a local user/admin...

Adding DOMAIN-SEARCH (or however we call it) is not overly hard - it needs clear documentation on the interpretation somewhere, a bit of windows hacking to get the necessary new data type into the DHCP "set up server response" code (it's DNS label compressed...), and update pull-resolv-conf/client.up.

Then, talk to Tunnelblick and the Connect guys :-)

It won't likely happen in the 2.4 scope as it's a new feature and not a bugfix - setting milestone to 2.5

[Gert Döring]

commit 78359a0478da64e18d49b13ea2e09def2b89f4a6
Author: Jan Just Keijser <jan.just.keijser@…>
Date: Tue Jul 14 11:39:10 2020 +0200

Added support for DHCP option 119 (dns search suffix list) for Windows.

As of Windows 10 1809 Windows finally supports this so it makes sense
to add support to OpenVPN as well.

Multiple options can be specified at the same time, with one search
domain per line (in the config, or pushed from server):

dhcp-option DOMAIN-SEARCH my.company.domain
dhcp-option DOMAIN-SEARCH some.example.domain

so, this is how the options to-be-pushed from the server need to look like. It works with 2.5.0 on Windows, and as far as I understand, it works with Tunnelblick on MAC.

On Linux, it needs to be handled by --up scripts talking to the system resolver - I have not investigated which distribution does this in what way.

OpenVPN Connect / 3.x, I have no idea. But I'll ask Lev...

[stipa]

This is implemented as well in OpenVPN Connect / OpenVPN3, but in a bit different way.

• dhcp-option DOMAIN my.company.domain means "split-DNS" - DNS traffic to that domain goes to DNS server provided by VPN

• dhcp-option ADAPTER_DOMAIN_SUFFIX mydomain.com means auto-completion - ping test would mean ping test.mydomain.com

[Gert Döring]

So ADAPTER_DOMAIN_SUFFIX (who came up with that strange name?) seems to be sort of the same thing as DOMAIN-SEARCH in 2.x...

So for a "full and consitent support" we'd need to teach 3.x to accept DOMAIN-SEARCH.

Also, we might want to look at what distributions ship wrt DOMAIN/DOMAIN-SEARCH and get them to update their scripts accordingly.

And our wintun support might need to be extended? I think JJK's patch only adds this to the DHCP replies, not to "non-DHCP" DNS config.

[Gert Döring]

Unlikely to be done in time for 2.5.0 - tentatively setting milestone to 2.5.1. Who knows :-)

[Selva Nair]

Currently we don't set any of the "dhcp-options" other than DNS via the service. DOMAIN is also ignored if dhcp is not possible.

It may be possible to set the DOMAIN, but I have not been able to find a way to set the adapter specific "domain suffix search list". Even the Windows dhcp client learned to do it only recently. Before that an option was to "edit the registry and reboot" but that applied only to a global search list, not an interface specific one. Now, at least on Windows 10, we can set this without a reboot but not per adapter.

How does openvpn3/connect handle this when not using dhcp?

[tct]

For ref: #1331

[stipa]

How does openvpn3/connect handle this when not using dhcp?

We add search domain to the registry, see ​https://github.com/OpenVPN/openvpn3/blob/master/openvpn/tun/win/tunutil.hpp#L1001

Cannot we use the same approach in openvpn2 for non-DHCP case?

[Selva Nair]

The code linked above sets only the Domain (option 15) not the search list (option 119). DOMAIN can be set by command line (works on Windows 10) which I think is more robust/reliable.

If you are using the registry edit for search list as well, have you tested that it really works? Displaying the parameters using "ipconfig /all" is not enough. One has to test name resolution -- not all related components get updated by a registry edit. Original Microsoft recommendation was to write the registry and then reboot(!).

In my tests the registry change to search list does not affect name resolution -- e.g., manually add (or remove) a domain, flush dns and see whether ping with hostname only starts to work (or stops working). nslookup doesn't seem to care about the search list so one has to use something like ping that will use the dns client service.

[rimbalza]

I would like to highlight the fact that in 2.5b4 tun and wintun drivers behave differently when connected to the same server: ​https://forums.openvpn.net/viewtopic.php?f=23&t=30990
While tun sets the connection suffix, wintun does not, so any short link will not work if using wintun. So current behavior is a breaking change to existing setups.

[Gert Döring]

Replying to rimbalza:

So current behavior is a breaking change to existing setups.

Let me highlight the fact that for an existing setup, the client will keep using the tuntap adapter, and not use wintun. So nothing breaks.

Only if you change the config over to wintun, you get the new stuff - and, with everything new, bits and pieces might be missing or not be implemented yet.

So we're not scrambling in pre-release panic to fix this.

[stipa]

I have tested the behavior on openvpn3.

Server config:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option ADAPTER_DOMAIN_SUFFIX vpntest.lev"

After connection, when client does

ping server

tcpdump on a server shows me

10.8.0.2.58599 > 10.8.0.1.domain: [udp sum ok] 60378+ A? server.vpntest.lev. (36)

[Selva Nair]

Replying to stipa:
DOMAIN works, the question was about DOAMIN-SEARCH (DhcpDomainSearchList? or SearchList? entry in registry). Also, testing by directly editing the registry is different from running OpenVPN3 as it may be doing other things that reset the DNS service (like register dns).

Manually editing the DhcpDomainSerachList? or SearchList? key in registry alone doesn't actually change the searchlist in DNS queries in my tests.

[Selva Nair]

Replying to stipa:

This is implemented as well in OpenVPN Connect / OpenVPN3, but in a bit different way.

• dhcp-option DOMAIN my.company.domain means "split-DNS" - DNS traffic to that domain goes to DNS server provided by VPN

• dhcp-option ADAPTER_DOMAIN_SUFFIX mydomain.com means auto-completion - ping test would mean ping test.mydomain.com

Just for completeness, and to avoid confusion: the above mentioned ADAPTER_DOMAIN_SUFFIX is equivalent to DOMAIN in openvpn2 which is not the same as DOMAIN-SEARCH discussed here.

[Selva Nair]

I did some tests on setting per interface domain search list:

Changing this in the registry does work "eventually" with a variable delay -- up to 5 minutes on my Win10 machine. However, following it up with a netsh or wmic command that changes some DNS parameter causes it to take immediate effect. So, editing the registry with the search-list before the call to do the domain setting may be a workable approach.

That would require a small change though: the domain must always set or cleared if none specified. Currently we leave the domain setting on the interface untouched if no --dhcp-option DOMAIN is specified.

[opoplawski]

This would be really nice to get consistent. From my notes it seems like Tunnelblick does use DOMAIN-SEARCH to set the DNS search list.

[sergio]

However, that's not even in the official documentation.

It is in the official documentation now:

​https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/vpn-network-options.rst

DOMAIN name

Set Connection-specific DNS Suffix to name.

DOMAIN-SEARCH name

Add name to the domain search list. Repeat this option to add more entries. Up to 10 domains are supported.

but client.up still ignores DOMAIN-SEARCH and uses multiple DOMAIN.

I believe the documentation must updated or client.up must fixed.

[Gert Döring]

Replying to sergio:

but client.up still ignores DOMAIN-SEARCH and uses multiple DOMAIN.

I believe the documentation must updated or client.up must fixed.

The documentation has DOMAIN-SEARCH now, and also clarifies that on everything that is not Windows, implementation of the functionality happens outside of OpenVPN. So I'd argue "the documentation is correct".

The user-contributed script contrib/pull-resolv-conf/client.up could be enhanced to support it, indeed. So, patches welcome, if you want to see this implemented.

[Gert Döring]

So, where are we with this? This ticket mixes Windows, MacOS and Linux all together, where the framework is vastly different - on Windows, OpenVPN does the config, on MacOS, Tunnelblick cares, and on Linux, distribution-provided scripts have to do the DNS config.

So I would reduce the scope of the ticket to "Windows, with the 3 different driver backents".

Have we ever solved DOMAIN-SEARCH for wintun (and windco)? If yes, I'd close this ticket.