Broken DNS resolver configuration after failed login

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

viscogrem

Posts: 12
Joined: Tue Feb 23, 2016 9:06 pm

Post by viscogrem » Tue Feb 23, 2016 10:08 pm
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):
Code: Select all
$ 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):
Code: Select all
$ 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

James

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

Post by James » Thu Feb 25, 2016 9:33 pm
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/viewtopic.php?f=7&t=34

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
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

viscogrem

Posts: 12
Joined: Tue Feb 23, 2016 9:06 pm

Post by viscogrem » Thu Feb 25, 2016 10:02 pm
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

sbarnea

User avatar
Posts: 12
Joined: Thu Oct 20, 2016 4:27 am

Post by sbarnea » Fri Dec 09, 2016 10:40 pm
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/question ... -conf-file but no answer yet.

James

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

Post by James » Mon Dec 12, 2016 12:17 pm
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/ar ... -settings/

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
5 posts Page 1 of 1