Version 1.10.6: DNS stopped working

[gerwim]

When connecting with version 1.10.6, the DNS is set to full mode, however DNS does not work properly:

Code: Select all

2023-07-06 09:47:18: DNS mode set to Full
2023-07-06 09:47:18: DNS Server/s: 192.168.0.92, 10.0.0.93
2023-07-06 09:47:18: State changed to Connected
2023-07-06 09:47:18: DNS Engine Running
2023-07-06 09:47:18: Listening on [127.0.0.1]:52126, [::1]:52126
2023-07-06 09:47:18: Primary upstream endpoint/s: 192.168.0.92:53, 10.0.0.93:53
2023-07-06 09:47:19: DNS Engine Running
2023-07-06 09:47:19: Listening on [127.0.0.1]:52156, [::1]:52156
2023-07-06 09:47:19: Primary upstream endpoint/s: 192.168.0.92:53, 10.0.0.93:53
2023-07-06 09:47:21: DNS Engine Running
2023-07-06 09:47:21: Listening on [127.0.0.1]:52167, [::1]:52167
2023-07-06 09:47:21: Primary upstream endpoint/s: 192.168.0.92:53, 10.0.0.93:53
2023-07-06 09:47:26: DNS Engine Running
2023-07-06 09:47:26: Listening on [127.0.0.1]:52172, [::1]:52172
2023-07-06 09:47:26: Primary upstream endpoint/s: 192.168.0.92:53, 10.0.0.93:53

Code: Select all

➜  ~ dig google.com

; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

Sometimes, DNS lookups work, but they randomly break and stay broken.

[James]

Hi gerwim,

The rapid "DNS Engine Running" messages likely indicate that something on your machine is terminating Viscosity's DNS process (com.viscosityvpn.ViscosityHelper). I recommend you try temporarily disabling any tools that could potentially cause this (such as firewall software, endpoint security software, endpoint management software, antivirus software, DNS filtering software, etc.) and see if the issue persists. If this is a work managed computer, you may also need to reach out to your IT administrator to make sure they don't have any policies that could be blocking it either.

It could also be that the DNS process is exiting on its own for some reason (although this should be unlikely). If that's the case, more information would be available in the Console log:
https://www.sparklabs.com/support/kb/ar ... nsole-log/

Please note that "dig" doesn't use the macOS resolver system, and so can't be used to properly test if DNS lookups are working. Please see the "Notes for Linux/Unix Users" section at the link below for more information:
https://www.sparklabs.com/support/kb/ar ... unix-users

You can instead use the "dscacheutil" command to test lookups from the command line:
https://www.sparklabs.com/support/kb/ar ... omain-name

Cheers,
James

[minusbat]

We have started seeing the same thing since the upgrade to 1.10.6 (1641) yesterday. In our case it's IPv6 which doesn't work. This occurs on all the work machines we have upgraded so far, and these are personal machines, so theres no common security policy which is going on here, or common antivirus, or anything like that. I am seeing the same thing on my Mac in the UK as my colleage is seeing on his at home in Poland.

I need a fix for this urgently 0 is there a way to downgrade to the previous version until this can be fixed ?

[James]

Hi minusbat,

Please ensure that you're using 1.10.6 build 1642, rather than build 1641. Build 1642 did fix an issue that could cause DNS settings to be ignored if they had mixed case/capitalisation. It's possible this may have affected IPv6/AAAA record resolutions for you.

If you're still stuck, please send along a copy of the details listed in the following article and we can take a closer look for you:
https://www.sparklabs.com/support/kb/ar ... ort-staff/

If you need it, version 1.10.5 can be downloaded from here.

Cheers,
James

[[email protected]]

I can confirm via console I am getting crashes, and have attached one such crash log.

It has crashed multiple times as can be seen in the log:

Code: Select all

2023-07-11 13:01:19: DNS mode set to Full
2023-07-11 13:01:19: DNS Server/s: 10.120.30.53, 10.120.40.53
2023-07-11 13:01:20: State changed to Connected
2023-07-11 13:01:20: DNS Engine Running
2023-07-11 13:01:20: Listening on [127.0.0.1]:49817, [::1]:49817
2023-07-11 13:01:20: Primary upstream endpoint/s: 10.120.30.53:53, 10.120.40.53:53
2023-07-11 13:06:09: DNS Engine Running
2023-07-11 13:06:09: Listening on [127.0.0.1]:50008, [::1]:50008
2023-07-11 13:06:09: Primary upstream endpoint/s: 10.120.30.53:53, 10.120.40.53:53
2023-07-11 13:23:50: DNS Engine Running
2023-07-11 13:23:50: Listening on [127.0.0.1]:50475, [::1]:50475
2023-07-11 13:23:50: Primary upstream endpoint/s: 10.120.30.53:53, 10.120.40.53:53
2023-07-11 13:37:25: DNS Engine Running
2023-07-11 13:37:25: Listening on [127.0.0.1]:50941, [::1]:50941
2023-07-11 13:37:25: Primary upstream endpoint/s: 10.120.30.53:53, 10.120.40.53:53
2023-07-11 13:45:33: DNS Engine Running
2023-07-11 13:45:33: Listening on [127.0.0.1]:51199, [::1]:51199
2023-07-11 13:45:33: Primary upstream endpoint/s: 10.120.30.53:53, 10.120.40.53:53
2023-07-11 13:46:44: DNS Engine Running
2023-07-11 13:46:44: Listening on [127.0.0.1]:51264, [::1]:51264
2023-07-11 13:46:44: Primary upstream endpoint/s: 10.120.30.53:53, 10.120.40.53:53
2023-07-11 13:46:45: Primary IPv4 service change detected (en0->en6), restoring DNS settings
2023-07-11 13:46:45: DNS Engine Running
2023-07-11 13:46:45: Listening on [127.0.0.1]:51276, [::1]:51276
2023-07-11 13:46:45: Primary upstream endpoint/s: 10.120.30.53:53, 10.120.40.53:53

There are other issues, such as sometimes it will write

Code: Select all

nameserver 127.0.0.1

into

Code: Select all

/etc/resolv.conf

which can cause all sorts of issues with some applications, as the port Viscosity brings up is not the default port 53, so things reading resolv.conf can't communicate with the nameserver at all.

Then another issue is things that depend on c-ares assume all system DNS servers are on port 53. I have created a PR for this https://github.com/c-ares/c-ares/pull/534 ... but obviously it takes a long time for updates like this to make the rounds.

I really think this "new way" needs to be optional, I don't see any way to disable this new DNS Engine in 1.10.6.

[James]

Hi Brad,

Thanks for the technical information - much appreciated. We believe the crash in your report should be fixed in the latest beta version of Viscosity:
https://www.sparklabs.com/support/kb/ar ... -versions/

The legacy resolv.conf containing the 127.0.0.1 resolver is likely a result of the crashes, and not intended behaviour. Your VPN DNS server/s should instead be listed, not the local DNS resolver (when using Full DNS).

Cheers,
James

[gerwim]

With the help of James (had email contact so these messages are not available here on the forum) my issues have been fixed since beta version 1.10.7b6.

[Equipment5164]

Hi Brad,

Thanks for the technical information - much appreciated. We believe the crash in your report should be fixed in the latest beta version of Viscosity:
https://www.sparklabs.com/support/kb/ar ... -versions/

The legacy resolv.conf containing the 127.0.0.1 resolver is likely a result of the crashes, and not intended behaviour. Your VPN DNS server/s should instead be listed, not the local DNS resolver (when using Full DNS).

Cheers,
James

on MacOS 12.6.7 both version 1.10.6(1642)) and 1.10.7b6(1648) don't work and work only using DNS Setting Mode: Full DNS .

do you know if it's possible to set Push from the OpenVPN server to be set by default Full DNS ?

[James]

Hi Equipment5164,

I recommend checking your connection log. It sounds likely Split DNS is being used, however one or more valid DNS domains are not being set. Please see:
https://www.sparklabs.com/support/kb/ar ... -problems/

If you would prefer to use Full DNS, information on how to push the DNS Mode from the OpenVPN server can be found at:
https://www.sparklabs.com/support/kb/ar ... the-server

Cheers,
James

[devZer0]

hello,

from time to time i also have problems with split DNS in viscosity and i need to reboot.


i'm getting

2023-10-18 11:11:12: DNS mode set to Split
2023-10-18 11:11:12: WARNING: Split DNS is being used however no DNS domains are present. The DNS server/s for this connection may not be used. For more information please see: https://www.sparklabs.com/support/kb/ar ... e-present/

in the logs

it seems that viscosity either fails to read the dns servers from push message or fails to apply those

what could be the reason for that ?

it's not a server or configuration problem, it just happens from time to time and needs reboot

uninstall of viscosity including purge of helper tool and reinstall does NOT help