Unable to Set DNS Servers with Mac Client

Got a problem with Viscosity or need help? Ask here!

sigsegv

Posts: 4
Joined: Fri Mar 06, 2020 9:33 am

Post by sigsegv » Fri Mar 06, 2020 10:13 am
Hello,

We have a working OpenVPN setup where clients connect to our server using a TAP config. They then get their IPv4 config info (IP, default route, and DNS servers) from the DHCP server on the subnet that they've just been connected to. The clients use SLAAC on the vtap interface to configure IPv6 (IP and default route). All traffic gets routed over the VPN.

This (usually) works okay enough, but we have been tasked to come up with a client-side config that will only direct our internal networks toward the VPN, allowing all other traffic to go out over normal (non-VPN) paths. I believe that I have the network routing parts set up and working correctly. Once connected, traffic that should go over the VPN, goes over the VPN. Traffic that shouldn't go over the VPN, doesn't.

Unfortunately, I cannot get DNS to work. Initially, I tried to get the config to work with DHCP-provided DNS, which is what the normal, I'll-take-ALL-your-traffic config does. Once the connection came up and was marked as connected, DNS queries failed. I could dig against the name servers and got responses, but using dscacheutil returned nothing. Checking the DNS server config with `scutil --dns` showed the original DNS server settings from before the VPN connection was established.

In an effort to get something working, I feel back to pinning the DNS servers in the VPN client config. I changed the DNS mode to "Full DNS" and put the IPv4 addresses of the two main recursive name servers that the clients should be using. Again, I connected, but things failed just as they had when I tried to get the DNS servers via DHCP. I returned to the config, checked the "Ignore DNS settings set by VPN server" option (even though the VPN server sends no DNS settings) and tried again, but to no avail.

I had one of my co-workers who uses Windows try this config on his laptop. It does work in Windows. (Additionally, the "DNS from DHCP" config didn't work for him and a split DNS config did work.)

There is a warning in the logs that kind of bothers me, but I see it every time I connect to the VPN server, even with the (working) config where all traffic is sent to the VPN.
Code: Select all
2020-03-05 16:45:04: Initialization Sequence Completed
2020-03-05 16:45:04: DNS mode set to Full
2020-03-05 16:45:04: State changed to Connected
2020-03-05 16:45:04: DNS change detected, restoring DNS settings
2020-03-05 16:45:08: DNS change detected, restoring DNS settings
2020-03-05 16:47:51: NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1557,1557] remote->local=[1557,1557]
2020-03-05 17:01:14: State changed to Disconnecting
Both the Mac and Windows clients are version 1.8.4.

Does _anyone_ have any ideas?

James

User avatar
Posts: 1980
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Fri Mar 06, 2020 8:36 pm
Hi sigsegv,
Once the connection came up and was marked as connected, DNS queries failed. I could dig against the name servers and got responses, but using dscacheutil returned nothing.
It sounds likely Split DNS was being used, and no domains were set. Split DNS will be used by default when split routing is being used (i.e. all traffic isn't routed into the VPN connection) and the DNS Mode is set to Automatic. I do recommend using Split DNS for your setup, but make sure that either the OpenVPN server is pushing out DNS domains, or that you've configured them in Viscosity. Please see the following links for more information:
https://www.sparklabs.com/support/kb/ar ... e-present/
https://www.sparklabs.com/support/kb/ar ... #dns-modes

Code: Select all
I returned to the config, checked the "Ignore DNS settings set by VPN server" option (even though the VPN server sends no DNS settings) and tried again, but to no avail. 
I recommend checking macOS's DNS configuration again and ensure that the DNS Servers are actually being set.
https://www.sparklabs.com/support/kb/ar ... being-used

Code: Select all
DNS change detected, restoring DNS settings
This indicates that the DNS server list does not match what Viscosity expects it to be for the VPN network interface. It could be that a DHCP server or IPv6 Auto-configuration has updated the DNS server list, and so Viscosity is applying the new settings. Or it could indicate something else on the machine is attempting to change the DNS settings (in which case, make sure any DNS proxy software is disabled, and no enterprise management software may be attempting to alter the DNS settings).

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

sigsegv

Posts: 4
Joined: Fri Mar 06, 2020 9:33 am

Post by sigsegv » Wed Mar 18, 2020 10:12 am
Sorry for the delay in responding, but I was redirected to some other, higher priority tasks. I'm back on this for the time being now.
It sounds likely Split DNS was being used, and no domains were set.
Yeah, that would make sense, but I verified that it's set to Full DNS.
Code: Select all
#viscosity dns full
I do have the DNS servers set there -- two IP addresses separated by a comma and both are reachable over the VPN via IP when the VPN is up -- but I didn't have a domain set, since I want all DNS queries to go to the listed DNS servers. I did, however, try adding our domain (let's say, example.com) in the Domains box, but that didn't help. All dscacheutil queries failed for internally-visible records under example.com, externally-visible records under example.com, and records not under example.com. The first resolver in the unscoped queries section was this
Code: Select all
resolver #1
  flags    : Request A records, Request AAAA records
  reach    : 0x00000000 (Not Reachable)
I tried changing the mode from Full DNS to Split DNS. The client still had the same IPs listed for Servers and our domain (example.com) in the Domains box. The `scutil --dns` output showed neither of the configured DNS server IPs listed, just the ones that were in there before the VPN came up. Doing a dscacheutil query for something not under example.com returned fine. Using dscacheutil to lookup something that's only visible internally, such as foo.example.com or bar.baz.example.com both fail too. Queries for externally available records under example.com -- www.example.com, for example -- did return successfully.

Will the DHCP sending DNS servers or the VPN server sending DNS servers via dhcp-option settings cause Viscosity to revert to the pre-VPN DNS settings, even if the servers presented are always the same two IPs that I have configured in the client?

Is there any other information that I can provide? Would it be better for me to open a support ticket so that I can provide more exact detail?

Thank you for your help.

James

User avatar
Posts: 1980
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Thu Mar 19, 2020 6:51 am
Hi sigsegv,

I think we'll need to see the complete output of the following to be able to let you know more:

1. The complete output from the command "scutil --dns" while connected to the VPN connection:
https://www.sparklabs.com/support/kb/ar ... being-used

2. A complete copy of the OpenVPN log with the log verbosity 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

The VPN connection can then be connected/reconnected and the OpenVPN log accessed:
https://www.sparklabs.com/support/kb/ar ... envpn-log/

3. The Raw Configuration Data for your connection. You can view the raw configuration data for your Viscosity connection by opening Viscosity’s Preferences window, holding down the Option/Alt key on your keyboard, right-clicking (or control-clicking on Mac) on your connection, and selecting “View Configuration Data”.

Please feel free to email us these details if you'd prefer not posting them in a public setting:
https://www.sparklabs.com/support/#contact

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

sigsegv

Posts: 4
Joined: Fri Mar 06, 2020 9:33 am

Post by sigsegv » Fri Mar 27, 2020 5:14 am
We took this to email. Turns out we were tweaking a macOS issue that James was able to work around in the 1.8.5b5 release.

Thank you, James.
5 posts Page 1 of 1