No DNS Suffix with DCO if connection initiated through openvpn-gui on windows

[2ps]

Describe the bug When connecting to openvpn community 2.6.3 from client version 2.6.3, the data channel offload interface does not pick up DOMAIN-SEARCH or search-domains suffixes in either the client file or pushed by the server

To Reproduce connect to the server using client 2.6.3 and the following configuration file on windows.

client
remote-cert-tls server
dev tun
proto udp
remote 123.123.123.123 1134
resolv-retry infinite
nobind
persist-key
persist-tun
verb 3
key-direction 1
cipher AES-256-GCM
auth-nocache
dhcp-option DOMAIN-SEARCH contoso.com
dhcp-option DOMAIN-SEARCH fabrikam.com
dhcp-option DNS 8.8.8.8
# tried dns search-domains contoso.com fabrikam.com here as well, too, no difference
pull
<ca></ca>
<key></key>
<cert></cert>

Expected behavior windows DCO adapter search suffix should be set properly with the specified domain search suffixes after successful connection

Version information (please complete the following information):

• OS: Windows 10 22H2
• OpenVPN version: 2.6.3 (client and server)

Additional context

Unknown adapter OpenVPN Data Channel Offload:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : OpenVPN Data Channel Offload
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : XXXXX
   IPv4 Address. . . . . . . . . . . : 172.16.1.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : XXXX
   DHCPv6 Client DUID. . . . . . . . : XXXX
   DNS Servers . . . . . . . . . . . : 8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Enabled

[2ps]

n.b., weirdly enough ADAPTER_DOMAIN_SUFFIX seems to work, but we can't set multiple domains using this dhcp option.

[lstipakov]

DOMAIN-SEARCH config option is translated into DHCP option 119, also known as Domain Search List. This requires DHCP support from adapter, which is implemented only by tap-windows6.

ADAPTER_DOMAIN_SUFFIX, which is an alias for DOMAIN config option, is translated into DHCP option 15, known as Domain Name. While this is done via DHCP when tap-windows6 is used, this can also be set via wmic command SetDNSDomain, which we use when DCO adapter is used.

As you've mentioned, with ADAPTER_DOMAIN_SUFFIX or DOMAIN you can set only one domain.

~~Unfortunately I am not aware of any other ways to set Domain Search List except DHCP, which DCO doesn't support. @selvanair do you have any thoughts on it?~~

Apparently one can do it with wmic nicconfig call SetDNSSuffixSearchOrder ("example.com","subdomain.example.com") which appears to work, albeit on global, not per-adapter level.

[lstipakov]

As @d12fk pointed out, using that WMI call (or setting value directly in registry HKLM\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SearchList makes those only search domains being used, which may make local resolution fail - i.e. if you have .local connection-specific suffix on your network adapter and then connect to VPN, you'll lose .local resolution.

[selvanair]

Apparently one can do it with wmic nicconfig call SetDNSSuffixSearchOrder ("example.com","subdomain.example.com") which appears to work, albeit on global, not per-adapter level.

Yes, that's why it was not included in my original patch using wmic. I'm a bit hazy on the details, but quoting from my commit message (commit 70882f3e4 for OpenVPN):

"DOMAIN-SEARCH is not handled here as wmic only supports setting the global search list which will over-ride all interface specific values. Editing the registry directly combined with a wmic command to reset the global SearchList is an option that could be considered in a separate patch."

I recall having experimented with this and there were some issues with editing the registry -- like the result not immediately effective unless a reset is done etc.

[selvanair]

As @d12fk pointed out, using that WMI call (or setting value directly in registry HKLM\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SearchList makes those only search domains being used, which may make local resolution fail - i.e. if you have .local connection-specific suffix on your network adapter and then connect to VPN, you'll lose .local resolution.

IIRC, its still possible to do this by editing the registry but one has to do a complicated dance for retaining the previous setting, correctly handling disconnect etc. And each time we've to follow up with a wmic reset call to make the changes effective. That seemed to work though MSDN tells us to reboot after editing this in the registry !

[d12fk]

Do we know what a wmic reset does behind the scenes? Maybe it's just a WIN32 API call.

[d12fk]

I'm interested in doing this right, because I need it for the --dns option implementation as well.

[selvanair]

I was writing from memory: the idea was to follow up with some dummy wmic call like SetDNSDomain which appeared to "reset" the configuration and make registry changes effective. No idea what API it uses internally.

[2ps]

@lstipakov -- I'd love to be a contributor, would it be architecturally advisable to try to implement dhcp support in the dco adapter or was dhcp support left off for any particular reason?

[lstipakov]

With tap-windows6 it works something like this:

• userspace process enables DHCP on adapter like this: netsh interface ipv4 set address name=$if_index source=dhcp
• userspace process prepares DHCP options and passes them to the driver via ioctl calls
• driver acts like DHCP server - listens for incoming UDP packets on port 67, checks if those are DHCP Discover or DHCP Request and replies with DHCP Offer and DHCP ACK, created from the options passed from userspace

I am a bit reluctant to add this to DCO - most of the network settings could be set from userspace via IPAPI / wmic. DOMAIN-SEARCH is one of few ones which currently cannot. DCO driver has been out there for several month and this is the first request for this feature, so I make a conclusion that demand for it is not that high. I think the driver should contain the most essential functionality, and search domains doesn't look like that for me.

@d12fk is working on userspace implementation - search domains could be set via wmic call or registry, but those will be global and replace all other domain resolutions, so this is not a trivial thing.

[2ps]

@lstipakov appreciate the insight here and certainly don't want to step on anyone's toes. Not to belabor this point, but at least from what I understand this issue is not the first mention or request for this:

• https://github.com/OpenVPN/openvpn/issues/306 (domain suffix when connecting in service mode)
• https://community.openvpn.net/openvpn/ticket/1209 (request for domain-search implementation to be full and consistent, please see the comment from Gert Döring earlier this year).

[Chatchonnamdi]

Ft

[savely-krasovsky]

@selvanair @lstipakov I cannot confirm that you need to call wmic reset after editing the registry, at least using Windows 11. In my case it works perfectly just by setting SearchList key. Yeah, nslookup doesn't work, but everything else (browser, curl, RDP, ssh) resolve domains without suffixes from the list. Probably nslookup just uses some low level API (as in most OSes).

I also don't see any wmic mention in Tailscale TUN interface implementation, they also just set SearchList: https://github.com/tailscale/tailscale/blob/92d3f64e95dc7b33fb19f03223d5ba4aa3331d8c/net/dns/manager_windows.go#L247-L253 Explanation: https://github.com/tailscale/tailscale/blob/92d3f64e95dc7b33fb19f03223d5ba4aa3331d8c/net/dns/manager_windows.go#L293-L297

[bahusafoo]

With tap-windows6 it works something like this:

• userspace process enables DHCP on adapter like this: netsh interface ipv4 set address name=$if_index source=dhcp
• userspace process prepares DHCP options and passes them to the driver via ioctl calls
• driver acts like DHCP server - listens for incoming UDP packets on port 67, checks if those are DHCP Discover or DHCP Request and replies with DHCP Offer and DHCP ACK, created from the options passed from userspace

I am a bit reluctant to add this to DCO - most of the network settings could be set from userspace via IPAPI / wmic. DOMAIN-SEARCH is one of few ones which currently cannot. DCO driver has been out there for several month and this is the first request for this feature, so I make a conclusion that demand for it is not that high. I think the driver should contain the most essential functionality, and search domains doesn't look like that for me.

@d12fk is working on userspace implementation - search domains could be set via wmic call or registry, but those will be global and replace all other domain resolutions, so this is not a trivial thing.

Running into issues in enterprise environments with DNS servers not properly pushing from OpenVPN server to clients (tried with 2.6.7-2.6.12). I notice if I disable the interface with the DCO driver and let OpenVPN simply use the "TAP-Windows Adapter V9", it connects up and pulls DNS servers just fine. I'm wondering if this is related or not. Either way, domain search lists absolutely are essential for the operation within the enterprise space.

Edit: For anyone who may find this later on, we actually discovered that KB2693643 breaks DCO if present. After uninstalling that from the affected systems, OpenVPN client connections to DCO enabled OpenVPN servers with DNS servers defined correctly pull their config and all is well.

[cron2]

Thanks for the info about KB2693643. This sounds nasty.

Googling finds that this breaks other VPN implementations too (namely Fortinet SSL VPN seems to get completely broken). I do wonder what Microsoft has been doing there... but it seems to be a an optional component (RSAT), so at least not a security-relevant KB...

[bahusafoo]

That KB used to be the way to install RSAT. Sonce Windows 10 1809, Microsoft has moved to enabling RSAT via powershell commands and/or the Feature on Demand ISO published seperately for each windows version. Those methods get messy in enterprise environments and there is some hoop jumping required to make things work with them, so alot of folks revert to installing that KB because it still appears to "work" and installs fast with less hoop jumping. The resulting RSAT features if using this KB in modern windows versions does not get updated as it's not properly detected/supported (IE, when LAPS featuers were added to RSAT directly and they added powershell support - you didn't get those CMDlets if you installed RSAT via the KB, only if you installed RSAT via Add-WindowsFeature or the FoD ISO).

TLDR lesson here: Don't do unsupported things in your enterprise environments and you won't run into rabbit hole issues down the road that take days of your time to pin down. Install RSAT properly to avoid issues with remote access VPN clients.

[d12fk]

With OpenVPN 2.7 this will work, at least when you push the DNS stuff with --dns instead of ´--dhcp-option`. Maybe also with the latter, it's worth a try.