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 70882f3 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:

• No DNS Suffix with DCO if connection initiated by OpenVPNService #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