Version 1.9.4 DNS Issues

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

ITGregg

Posts: 4
Joined: Sat Sep 04, 2021 4:22 am

Post by ITGregg » Sat Sep 04, 2021 5:01 am
Hello I am supporting 1000+ users who are on Viscosity and if they upgrade to version 1.9.4 they lose the ability to reach any external websites. On version 1.9.4 they can only access internal sites because of a DNS issue. If the VPN is disconnected the problem goes away immediately. I have tested this on many laptops and can reliably reproduce the same issue each time, and we have to revert to 1.9.3. I have already tried the steps in the knowledge base. We know it's a DNS issue- i.e. can ping 8.8.8.8 but not www.google.com- but that's only while connected to Viscosity. We get this error in the logs- "WARNING: A .local domain is present in the DNS domain list. The .local domain is reserved for mDNS. Using it as a DNS domain may cause DNS resolution attempts to fail or unexpected DNS behaviour." There is a section for this error in the knowledge base but it links to a dead link for more information - https://www.sparklabs.com/support/kb/ar ... d-domains/

My config file has been uploaded in txt format, and I've attached the verbose logs as well. Please let me know the fix for the error, "A .local domain is present in the DNS domain list." And I'd appreciate it if in your answer you could be sure to address the fact that this issue is not present with version 1.9.3 and that upgrading to 1.9.4 is the only change that has been made- same config file, same server-side settings, same client-side settings, same Windows version, etc. Thank you.
Attachments
config.txt
(492 Bytes) Downloaded 1328 times

Viscosity Log Verbose.txt
(9.4 KiB) Downloaded 1287 times

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Sep 06, 2021 9:53 am
Hi ITGregg,

Thanks for the heads up on that dead link, I'll get that fixed. The correct link is https://sparklabs.com/support/kb/articl ... ed-domains

On an effected machine, could I please get you to try the following commands from a Command Prompt and post the results, please ensure the dot after google.com is included where present.
Code: Select all
nslookup google.com
Code: Select all
nslookup google.com.
Code: Select all
nslookup google.com. 192.168.1.1
Code: Select all
nslookup google.com. 2001:1998:f00:1::1
Code: Select all
nslookup google.com. 2001:1998:f00:2::1
Code: Select all
route print
Regards,
Eric
Eric Thorpe
Viscosity Developer

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

ITGregg

Posts: 4
Joined: Sat Sep 04, 2021 4:22 am

Post by ITGregg » Fri Sep 10, 2021 3:51 am
Thanks for the reply. Here's the results of that:

C:\Windows\system32>nslookup google.com
Server: Viscosity
Address: fd53:7061:726b:4c61:6273:5669:7344:4e55

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to Viscosity timed-out

C:\Windows\system32>nslookup google.com.
Server: Viscosity
Address: fd53:7061:726b:4c61:6273:5669:7344:4e55

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to Viscosity timed-out

C:\Windows\system32>nslookup google.com. 192.268.1.1
*** Can't find server address for '192.268.1.1':
Server: Viscosity
Address: fd53:7061:726b:4c61:6273:5669:7344:4e55

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to Viscosity timed-out

C:\Windows\system32>nslookup google.com. 2001:1998:f00:2::1
Server: UnKnown
Address: 2001:1998:f00:2::1

*** UnKnown can't find google.com.: No response from server

C:\Windows\system32>route print
===========================================================================
Interface List
18...c0 25 a5 45 d6 97 ......Realtek PCIe GbE Family Controller
41...bc c6 53 11 eb 9f ......Viscosity Virtual TUN Adapter
16...dc 21 5c 3b 13 8a ......Microsoft Wi-Fi Direct Virtual Adapter
6...de 21 5c 3b 13 89 ......Microsoft Wi-Fi Direct Virtual Adapter #2
4...dc 21 5c 3b 13 89 ......Intel(R) Wi-Fi 6 AX201 160MHz
12...dc 21 5c 3b 13 8d ......Bluetooth Device (Personal Area Network)
1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.31.98.1 172.31.98.216 35
0.0.0.0 0.0.0.0 10.0.140.93 10.0.140.94 1024
10.0.60.0 255.255.255.0 10.0.140.93 10.0.140.94 50
10.0.61.0 255.255.255.0 10.0.140.93 10.0.140.94 50
10.0.74.0 255.255.255.0 10.0.140.93 10.0.140.94 50
10.0.100.0 255.255.255.0 10.0.140.93 10.0.140.94 50
10.0.128.1 255.255.255.255 10.0.140.93 10.0.140.94 50
10.0.140.92 255.255.255.252 On-link 10.0.140.94 281
10.0.140.94 255.255.255.255 On-link 10.0.140.94 281
10.0.140.95 255.255.255.255 On-link 10.0.140.94 281
10.1.84.0 255.255.255.0 10.0.140.93 10.0.140.94 50
10.1.90.0 255.255.255.0 10.0.140.93 10.0.140.94 50
10.2.100.0 255.255.255.0 10.0.140.93 10.0.140.94 50
10.30.0.0 255.255.0.0 10.0.140.93 10.0.140.94 50
10.40.0.0 255.255.0.0 10.0.140.93 10.0.140.94 50
12.68.230.0 255.255.255.0 10.0.140.93 10.0.140.94 50
12.107.3.0 255.255.255.0 10.0.140.93 10.0.140.94 50
63.80.152.0 255.255.255.128 10.0.140.93 10.0.140.94 50
67.106.145.0 255.255.255.0 10.0.140.93 10.0.140.94 50
70.42.22.0 255.255.254.0 10.0.140.93 10.0.140.94 50
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.56.49.53 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
172.31.98.0 255.255.254.0 On-link 172.31.98.216 291
172.31.98.216 255.255.255.255 On-link 172.31.98.216 291
172.31.99.255 255.255.255.255 On-link 172.31.98.216 291
173.226.108.0 255.255.255.0 10.0.140.93 10.0.140.94 50
198.105.200.64 255.255.255.192 10.0.140.93 10.0.140.94 50
216.211.163.0 255.255.255.0 10.0.140.93 10.0.140.94 50
216.211.175.0 255.255.255.0 10.0.140.93 10.0.140.94 50
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 172.31.98.216 291
224.0.0.0 240.0.0.0 On-link 10.0.140.94 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 172.31.98.216 291
255.255.255.255 255.255.255.255 On-link 10.0.140.94 281
===========================================================================
Persistent Routes:
None

IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
1 331 fd53:7061:726b:4c61:6273:5669:7344:4e53/128
On-link
41 281 fd53:7061:726b:4c61:6273:5669:7344:4e55/128
On-link
4 291 fe80::/64 On-link
41 281 fe80::/64 On-link
4 291 fe80::bc10:c96:cc43:c580/128
On-link
41 281 fe80::e863:3b5b:6bc2:d9e4/128
On-link
1 331 ff00::/8 On-link
4 291 ff00::/8 On-link
41 281 ff00::/8 On-link
===========================================================================
Persistent Routes:
None

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Fri Sep 10, 2021 8:54 am
Hi ITGregg,

There's a few things going on here. You have two IPv6 DNS servers, however you have no IPv6 routes. Viscosity should be detecting these aren't reachable but isn't, so we'll look into why that is, however they will be timing out one by one and leading to no DNS via Viscosity. Please remove these IPv6 DNS servers from your network adapter and try again.

Secondly, you mistyped your IPv4 DNS server when doing the test, however by your route table this one should work. I'd recommend having a route to 192.168.1.1 though on your local network interface to prevent issues. If you test this again and it times out like your IPv6 DNS servers though, this will be an issue on your local network.

Thirdly you have a .local domain being pushed, we have some more information about why this is a bad idea and can cause issues here (this is the corrected dead link you noted if you've already read it) - https://sparklabs.com/support/kb/articl ... ed-domains

Viscosity 1.9.4 had some changes to prevent DNS leaks between adapters and obey DNS rules like obeying NXDomain responses more closely. The reason for 1.9.4 not working when 1.9.3 maybe did, is the older versions are more lenient to misconfigured network setups like this one. It's possible when changing this we introduced a bug that is not detecting IPv6 reachability correctly for DNS servers, or your operating system is falsly identifying it is reachable for some reason and the older versions leniency simply ignored the misconfiguration, this could have lead to DNS leaks. We'll investigate this and get back to you with a beta to try when we can. In the mean time, please try adjusting your DNS configuration on your local adapters and see if this helps.

Regards,
Eric
Eric Thorpe
Viscosity Developer

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

dankuz83

Posts: 1
Joined: Sat Sep 11, 2021 4:32 am

Post by dankuz83 » Sat Sep 11, 2021 4:59 am
Having what seems to be this exact same problem with 1.9.4.
Had to downgrade to 1.9.3 and immediately starts working again.
Have warned my users to not upgrade for now.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Sep 13, 2021 5:28 pm
Hi dankuz83,

As mentioned above, there are some changes in 1.9.4 that may cause issues with misconfigured setups. You're welcome to post your log and copy of your config and we can take a look.

Regards,
Eric
Eric Thorpe
Viscosity Developer

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

ITGregg

Posts: 4
Joined: Sat Sep 04, 2021 4:22 am

Post by ITGregg » Tue Sep 14, 2021 2:32 am
Here's the result from that corrected typo:

C:\Users\AWL>nslookup google.com. 192.168.1.1
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.1.1

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

Also, in response to the comment about having 2 DNS servers, I can't remove these IPv6 DNS servers from my network adapter, as everything is set to automatic and no servers are specified. I can tell you, however, that based on this feedback I did try changing the IPv4 DNS server to manual on the adapter and set it to 8.8.8.8, and this appeared to resolve the issue. I do not have access to my local network interface.

As for the .local domain, I can see mention of that in the Viscosity logs but there is no mention of it in the VPN config file. So when you say it's being "pushed" what do you mean by that?

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Tue Sep 14, 2021 7:24 am
Hi ITGregg,
As for the .local domain, I can see mention of that in the Viscosity logs but there is no mention of it in the VPN config file. So when you say it's being "pushed" what do you mean by that?
It means the server is sending the command to your client to configure. If you look at your server configuration, you will see a line like "push dhcp-option DOMAIN awl.local".
I can tell you, however, that based on this feedback I did try changing the IPv4 DNS server to manual on the adapter and set it to 8.8.8.8, and this appeared to resolve the issue. I do not have access to my local network interface.
I'm afraid it's hard to provide much advice other than to check your entire network setup to ensure everything is reachable. You have a 192.168.1.1 DNS, however no local routes or interfaces with this IP range, so you will need to add routes accordingly or adjust your DHCP. It's possible your IPv4 DHCP server is pushing IPv6 DNS servers for example which isn't best practice.

Regards,
Eric
Eric Thorpe
Viscosity Developer

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

ITGregg

Posts: 4
Joined: Sat Sep 04, 2021 4:22 am

Post by ITGregg » Thu Sep 16, 2021 4:44 am
Ok, thanks for the reply. Sounds like I will have to reach out to the people who manage our network.

rps

Posts: 11
Joined: Wed Mar 18, 2015 5:05 am

Post by rps » Tue Sep 21, 2021 11:22 pm
In our case we selectively push routes based on where the connection is coming from.

If a user is connecting from a trusted on-premise network then the VPN allows the connection but doesn't push any routes so local traffic isn't forced through a VPN to work around users being bad about not disconnecting when moving around.

The DNS servers that are pushed are valid and will respond from the local on-prem network but no routes will be pushed for them.

The DNS servers provided by the VPN can potentially be identical to the DNS servers provided via DHCP on the LAN interface.

Is this what is triggering the problem of the VPN breaking connectivity? If so, what is the best work-around? To push routes for the DNS servers or to not push DNS servers at all?
15 posts Page 1 of 2