search

OpenVPN / openvpn

OpenVPN is an open source VPN daemon
http://openvpn.net
Other
10.58k stars 2.96k forks source link

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

Open 2ps opened 1 year ago

2ps commented 1 year ago

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):

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 commented 1 year ago

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

lstipakov commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

d12fk commented 1 year ago

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

selvanair commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

With tap-windows6 it works something like this:

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 commented 1 year ago

@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:

Chatchonnamdi commented 1 year ago

Ft

savely-krasovsky commented 5 months ago

@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