Open 2ps opened 1 year ago
n.b., weirdly enough ADAPTER_DOMAIN_SUFFIX
seems to work, but we can't set multiple domains using this dhcp option.
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.
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.
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.
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 !
Do we know what a wmic reset does behind the scenes? Maybe it's just a WIN32 API call.
I'm interested in doing this right, because I need it for the --dns option implementation as well.
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.
@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?
With tap-windows6 it works something like this:
netsh interface ipv4 set address name=$if_index source=dhcp
DHCP Discover
or DHCP Request
and replies with DHCP Offer
and DHCP ACK
, created from the options passed from userspaceI 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.
@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:
Ft
@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
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
orsearch-domains
suffixes in either the client file or pushed by the serverTo Reproduce connect to the server using client 2.6.3 and the following configuration file on windows.
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):
Additional context