Broken DNS resolver configuration after failed login

Viscosity Support (macOS)
1

Observed On:
Mac OS X Yosemite and El Capitan
Viscosity 1.6 and 1.6.1

Symptoms:
When connecting to a VPN using the correct credentials, DNS servers are set correctly. In case the login fails (e.g. typo in password) the login dialog is shown again (pre-filled user name field).

After entering the correct credentials, DNS settings are applied in the wrong order and the primary resolver is not marked as reachable. This results in all DNS lookups hanging indefinitely, with the exception of libresolv based tools like host, dig, and nslookup, which use the wrong name servers, but at least work.

When clicking “Cancel” instead and re-connecting to the VPN from scratch, DNS configuration works as expected. This happens with both Automatic and Full DNS modes.

How To Repeat:

  1. Connect to the VPN
  2. Check DNS configuration using scutil --dns.
  3. Try host sparklabs.com command (works)
  4. Try dscacheutil -q host -a name sparklabs.com (works)
  5. Log out.
  6. Attempt to connect using the correct username and an invalid password
  7. Wait for the login dialog to reappear (username is already set)
  8. Enter the correct password and connect
  9. Check DNS configuration using scutil --dns, compare to previous output
  10. Try host sparklabs.com command (works ok if the resolver is reachable)
  11. Try dscacheutil -q host -a name sparklabs.com (hangs)

Samples:

DNS configuration on a normal, working connection (authenticated successfully on first attempt):

$ netstat -rn | grep "/1"
0/1                172.30.2.1       UGSc            0        0   utun0
128.0/1            172.30.2.1       UGSc            1        0   utun0

$ scutil --dns
...

resolver #1
  search domain[0] : example.org
  nameserver[0] : 172.30.1.2
  nameserver[1] : 172.30.1.1
  if_index : 12 (utun0)
  flags    : Scoped, Request A records
  reach    : Reachable

resolver #2
  nameserver[0] : 8.8.8.8
  nameserver[1] : 8.8.4.4
  if_index : 4 (en0)
  flags    : Scoped, Request A records
  reach    : Reachable

$ cat /etc/resolv.conf |grep -v "#"
search example.org
nameserver 172.30.1.2
nameserver 172.30.1.1

$ host sparklabs.com
sparklabs.com has address 66.185.22.121
sparklabs.com mail is handled by 10 silicon.sparklabs.com.

$ dscacheutil -q host -a name www.sparklabs.com
name: www.sparklabs.com
ip_address: 104.25.84.32
ip_address: 104.25.85.32

DNS configuration on a broken connection (authenticated successfully on second attempt, like described above):

$ netstat -rn | grep "/1"
0/1                172.30.2.1       UGSc            0        0   utun0
128.0/1            172.30.2.1       UGSc            1        0   utun0

$ scutil --dns
...

resolver #1
  nameserver[0] : 8.8.8.8
  nameserver[1] : 8.8.4.4
  if_index : 4 (en0)
  flags    : Scoped, Request A records

resolver #2
  search domain[0] : example.org
  nameserver[0] : 172.30.1.2
  nameserver[1] : 172.30.1.1
  if_index : 12 (utun0)
  flags    : Scoped, Request A records
  reach    : Reachable

$ cat /etc/resolv.conf |grep -v "#"
nameserver 8.8.8.8
nameserver 8.8.4.4

$ host sparklabs.com
sparklabs.com has address 66.185.22.121
sparklabs.com mail is handled by 10 silicon.sparklabs.com.

$ dscacheutil -q host -a name www.sparklabs.com
   ***hangs***

Cheers,
Michael

2

Hi Michael,

Thanks for the report - much appreciated.

This should now be fixed in the latest beta version of Viscosity. Instructions for updating to beta versions can be found at:
https://www.sparklabs.com/forum/t/beta-latest-build-of-viscosity-for-mac/46/1

A workaround for the current 1.6.1 release is to manually set the desired DNS mode (under the Networking tab when editing your connection in Viscosity).

Cheers,
James

3

Hi James,

Thanks for your quick response.

I just tested and can confirm that the issue has been solved in 1.6.2b1.

Cheers,
Michael

4

I think I hit the same bug where /etc/resolv.conf is not updated after you connect to the VPN, while using Viscosity 1.6.7

Doing a cat on the file exposes only the old-dns server (before the VPN connection was established). Instead scmutil --dns reports all DNS servers.

I can confirm that due to this nslookup and probably dig too are broken as they fail to lookup all DNS servers. Side effects: kerberos and ldap discovery is also broken because they fail to discover their servers using DNS.

Does anyone knows a way to force MacOS (Sierra) to regenerate the resolv.conf file? I asked the question at http://apple.stackexchange.com/questions/264165/how-to-force-macos-to-regenerate-etc-resolv-conf-file but no answer yet.

5

Hi sbarnea,

macOS will set the resolv file to contain the primary DNS settings. If you want it to update to your VPN DNS servers you can make it do so by making sure your VPN connection is using Full DNS Mode (which will set the VPN DNS servers to be the primary servers). If your connection is using Split DNS mode the resolv file will not be updated by the OS.

For more information please see:
https://www.sparklabs.com/support/kb/article/configuring-dns-and-wins-settings/

Cheers,
James