Skip to content
the VPN-DNS-server doesnt seem to be used, can not resolve internal host names
Got a problem with Viscosity or need help? Ask here!
- Posts: 9
- Joined: Tue Jan 15, 2019 8:48 pm
Hello!
We have an OpenVPN server that works fine with viscosity for basically all of our 100 employees (Mac and Windows alike).
One user can not resolve local hostnames though. The Viscosity agent (v1.9 [1556]) seems to have gotten the correct DNS server IP.
The OS version is macOS 10.14.6.
I have done tcpdumps at our router and DNS server and see that no traffic from that users vpn-IP is sent to the DNS server.
The IP of our DNS server is 82.x.y.222.
Do you have any ideas about what could be causing this, or how i can troubleshoot more?
Attaching some screenshots and pastes...
$ scutil --dns | grep ‘nameserver\[[0-9]*\]’
nameserver[0] : 192.168.10.1
nameserver[1] : fd04:6d23:65d3::1
nameserver[0] : 82.x.y.222
nameserver[0] : 192.168.10.1
nameserver[1] : fd04:6d23:65d3::1
nameserver[0] : 82.x.y.222
We have an OpenVPN server that works fine with viscosity for basically all of our 100 employees (Mac and Windows alike).
One user can not resolve local hostnames though. The Viscosity agent (v1.9 [1556]) seems to have gotten the correct DNS server IP.
The OS version is macOS 10.14.6.
I have done tcpdumps at our router and DNS server and see that no traffic from that users vpn-IP is sent to the DNS server.
The IP of our DNS server is 82.x.y.222.
Do you have any ideas about what could be causing this, or how i can troubleshoot more?
Attaching some screenshots and pastes...
$ scutil --dns | grep ‘nameserver\[[0-9]*\]’
nameserver[0] : 192.168.10.1
nameserver[1] : fd04:6d23:65d3::1
nameserver[0] : 82.x.y.222
nameserver[0] : 192.168.10.1
nameserver[1] : fd04:6d23:65d3::1
nameserver[0] : 82.x.y.222
Attachments
networking.png (127.48 KiB) Viewed 6755 times
details.png (44.78 KiB) Viewed 6755 times
- Posts: 9
- Joined: Tue Jan 15, 2019 8:48 pm
Maybe its "DNS over HTTPS" that has started showing up in macOS... hmm.
Hi AlexanderK,
Could you please post the following items. This should give us a better idea of the configuration:
1. A complete copy of the output from running "scutil --dns" (without the grep).
2. A complete copy of the OpenVPN log with the log verbosity level raised. You can raise the log verbosity by editing the connection in Viscosity, clicking on the Advanced tab, and then adding the command “verb 5” (without the quotation marks) on a new line in the Advanced commands area:
https://www.sparklabs.com/support/kb/ar ... n-commands
Please feel free to censor any sensitive details before posting. Alternatively you can email these to our support email address.
Regards,
James
Could you please post the following items. This should give us a better idea of the configuration:
1. A complete copy of the output from running "scutil --dns" (without the grep).
2. A complete copy of the OpenVPN log with the log verbosity level raised. You can raise the log verbosity by editing the connection in Viscosity, clicking on the Advanced tab, and then adding the command “verb 5” (without the quotation marks) on a new line in the Advanced commands area:
https://www.sparklabs.com/support/kb/ar ... n-commands
Please feel free to censor any sensitive details before posting. Alternatively you can email these to our support email address.
Regards,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
- Posts: 9
- Joined: Tue Jan 15, 2019 8:48 pm
Thanks! U got mail:)
Thanks for sending along those details.
I can confirm it looks like your DNS settings are correct. As it is a Split DNS setup, the VPN DNS server should be getting used for any mxx.txxxxx.xx subdomains, while the user's normal DNS server will be getting used for all other lookups.
You should be able to confirm it is working correctly using the dscacheutil command as listed here:
https://www.sparklabs.com/support/kb/ar ... omain-name
Don't use any legacy tools when testing, namely nslookup, host, or dig, as these don't use macOS's resolver system:
https://www.sparklabs.com/support/kb/ar ... unix-users
Now you mentioned that the user is using DoH in Chrome. By default Chrome's DoH support should work just fine with a Split DNS setup: its default mode is to use DoH if the local system DNS server supports DoH, and make normal DNS requests if it doesn't [1]. So in this case, if the user sets their local DNS server to be one that supports DoH (e.g. Cloudflare or Google's DNS Servers) Chrome should make normal queries for mxx.txxxxx.xx subdomains, but DoH queries for everything else.
However, it sounds like the user isn't using Chrome's default DoH behaviour, but has manually turned on DoH for all lookups. This means Chrome will ignore the OS's Split DNS setup and servers and only use the DoH server it has configured for DNS lookups. I'm afraid there is no way around this, at least with Chrome. The user should be advised to change their DoH configuration, or use a different web browser.
[1] https://blog.chromium.org/2019/09/exper ... r-dns.html
Cheers,
James
I can confirm it looks like your DNS settings are correct. As it is a Split DNS setup, the VPN DNS server should be getting used for any mxx.txxxxx.xx subdomains, while the user's normal DNS server will be getting used for all other lookups.
You should be able to confirm it is working correctly using the dscacheutil command as listed here:
https://www.sparklabs.com/support/kb/ar ... omain-name
Don't use any legacy tools when testing, namely nslookup, host, or dig, as these don't use macOS's resolver system:
https://www.sparklabs.com/support/kb/ar ... unix-users
Now you mentioned that the user is using DoH in Chrome. By default Chrome's DoH support should work just fine with a Split DNS setup: its default mode is to use DoH if the local system DNS server supports DoH, and make normal DNS requests if it doesn't [1]. So in this case, if the user sets their local DNS server to be one that supports DoH (e.g. Cloudflare or Google's DNS Servers) Chrome should make normal queries for mxx.txxxxx.xx subdomains, but DoH queries for everything else.
However, it sounds like the user isn't using Chrome's default DoH behaviour, but has manually turned on DoH for all lookups. This means Chrome will ignore the OS's Split DNS setup and servers and only use the DoH server it has configured for DNS lookups. I'm afraid there is no way around this, at least with Chrome. The user should be advised to change their DoH configuration, or use a different web browser.
[1] https://blog.chromium.org/2019/09/exper ... r-dns.html
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
5 posts
Page 1 of 1