SparkLabs Forum.

Community Help.


Split DNS failing on one client

Hello, I have a very perplexing question. I have two win7Pro machines both patched to the same level one works perfectly and one does not.

The OPENvpn server is a remote pfSense box.
One machine works perfectly - it connects with split dns using automatic mode. Upon connection the ipv4 dns is set to 127.0.0.1 and my ipv6 dns is set to ::1. Both domain and internet dns resolve as they should. Upon disconnect the dns servers for both ipv4 and ipv6 revert back to automatic.

The issue is the second machine. Upon connection the ipv4 dns is set to 127.0.0.1 and the ipv6 dns is set to ::1. nothing will resolve, and upon disconnection the dns servers for both ipv4 and ipv6 stay as 127.0.0.1 & ::1.

When I run a nslookup on the working machine while connected I see:
C:\>nslookup
Default Server: Viscosity
Address: ::1
>

When I run a nslookup on the failing machine while connected I see:
C:\>nslookup
DNS request timed out.
timeout was 2 seconds.
Default Server: UnKnown
Address: ::1
>

I can't find any discrepancy in the connection logs between both machines (with the exception of IP's and identifiers) The configuration of the Viscosity is the same near as I can tell so what am I missing? The connection log for the problematic connection is below, thanks in advance for the help.

Apr 03 3:15:11 PM: State changed to Connecting
Apr 03 3:15:11 PM: Viscosity Windows 1.6.8 (1477)
Apr 03 3:15:11 PM: Running on Microsoft Windows 7 Professional
Apr 03 3:15:11 PM: Bringing up interface...
Apr 03 3:15:11 PM: Checking reachability status of connection...
Apr 03 3:15:11 PM: Connection is reachable. Starting connection attempt.
Apr 03 3:15:11 PM: OpenVPN 2.3.14 Windows-MSVC [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Jan 16 2017
Apr 03 3:15:11 PM: library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
Apr 03 3:15:18 PM: Attempting to establish TCP connection with [AF_INET]185.148.47.56:1194 [nonblock]
Apr 03 3:15:19 PM: TCP connection established with [AF_INET]185.148.47.56:1194
Apr 03 3:15:19 PM: TCPv4_CLIENT link local: [undef]
Apr 03 3:15:19 PM: TCPv4_CLIENT link remote: [AF_INET]185.148.47.56:1194
Apr 03 3:15:19 PM: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Apr 03 3:15:20 PM: [PP_Certificate] Peer Connection Initiated with [AF_INET]185.148.47.56:1194
Apr 03 3:15:22 PM: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Apr 03 3:15:22 PM: open_tun, tt->ipv6=0
Apr 03 3:15:22 PM: TAP-WIN32 device [PPRemoteAccess] opened: \\.\Global\{415F5407-6BF3-40BE-A1D7-DB78967DC88D}.tap
Apr 03 3:15:22 PM: Set TAP-Windows TUN subnet mode network/local/netmask = 192.168.124.0/192.168.124.3/255.255.255.0 [SUCCEEDED]
Apr 03 3:15:22 PM: Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.124.3/255.255.255.0 on interface {415F5407-6BF3-40BE-A1D7-DB78967DC88D} [DHCP-serv: 192.168.124.254, lease-time: 31536000]
Apr 03 3:15:22 PM: Successful ARP Flush on interface [23] {415F5407-6BF3-40BE-A1D7-DB78967DC88D}
Apr 03 3:15:27 PM: ROUTE: route addition failed using CreateIpForwardEntry: The object already exists. [status=5010 if_index=23]
Apr 03 3:15:27 PM: env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem
Apr 03 3:15:27 PM: Initialization Sequence Completed
Apr 03 3:15:27 PM: DNS set to Split, report follows:
Server - 192.168.124.1:53; Lookup Type - Split; Domains - localdomain.
Server - 192.168.10.1:53; Lookup Type - Any; Domains - None

Apr 03 3:15:27 PM: State changed to Connected
Hi zenonk,

This is a problem we still see every now and again and have completely failed to replicate in our testing environments. We have some new fixes in our latest beta which we're hoping will resolve this issue, please give it a go.

First, revert your DNS to automatic then restart your PC. After the reboot, update to the latest beta and continue to use Viscosity as normal - http://sparklabs.com/support/kb/article ... -versions/

We'd highly appreciate any feedback at all!

Regards,
Eric
Thanks Eric,

I have done significantly more testing in the last 24 hours and perhaps I can assist with identifying the issue in more detail.

Firstly in reply to your suggestion I installed the beta version on a fresh install using the recommended driver. The same issues still occur, so here is some more detail on what I have found / tested.

Recap of system with issue:
HP Z420 workstation running win 7 pro fully patched
Windows firewall disabled
No AV or other agents running its a fresh bare win 7 install

- If I use full dns mode both internet and vpn domain traffic resolve with no issue. when I run nslookup in full dns mode it shows my vpn gateway as the dns server. So can can narrow that the issue is only when using split dns.

- As I commented in my initial post when running nslookup under a split dns mode it doesn't show the server as viscosity like it does on machines with split dns working correctly. The default server is UnKnown
++ I thought maybe there is some local issue on the loopback, but I confirmed that the viscosity & openvpn processes show as listening on 127.0.0.1 in netstat

Also interesting is that I also tried installing using the legacy driver. the same issue with split dns is there in that the dns server is UnKnown and nothing can resolve, but when I disconnect the dns IP's are reverted to automatic which doesn't happen with the recommended driver.

I've yet to try the beta with the legacy driver, but maybe I'll try that next if you think its worth a shot?

Also possibly not related but worth mentioning if I try to uninstall with the service running the uninstall hangs and never completes I have to terminate the process. when I reboot the application is gone but the service is still there. I get an error if I try and stop the service so the only way to cleanly uninstall is to set the service to disable, restart the computer then uninstall. I thought that was kind of odd behavior.

If you are unable to reproduce but would like more logs or a chance to test the behaviour I'd be happy to help out by making my system available on a remote session just let me know.

Thanks,
Zenon
Hi Zenon,

Thanks for the information. The driver should have no effect on the problem.

Could you please set your DNS back to automatic and reboot again so we're starting clean. Confirm that your DNS is set correctly to Automatic and is resolving. Grab a copy of the following file:

C:\Program Files\Viscosity\Resources\RevertConfig.txt

Connect to a server with split DNS with the beta installed, test DNS resolution, and then disconnect. Once disconnected, can you confirm that loopback is still set as the DNS server and grab another copy of the above file. Could you then post up a before and after of that RevertConfig.

DNS resolution on loopback won't work while there are no active connections, Viscosity's DNS server stops listening, so that is expected behaviour.

Regards,
Eric
Eric wrote:
DNS resolution on loopback won't work while there are no active connections, Viscosity's DNS server stops listening, so that is expected behaviour.


Just want to clarify that I understand that perfectly, I only meant to suggest that I confirmed that the processes were listening on the loopback when the tunnel was connected but that despite listening no dns resolution was being performed. Once disconnected the processes stop listening as expected, but the dns settings are not reverted.
so there are 2 issues:
1. no dns resolution happens (internet or domain) when connected with split mode
2. dns is not reverted back to automatic when upon disconnect.
**As I said I have another machine with the same profile connecting to the same vpn server and everything works fine so I have determined that there is not a problem on the server side of things.

NOTE: All of the following tests are done with the beta using the recommended driver

Eric wrote:
Could you please set your DNS back to automatic and reboot again so we're starting clean. Confirm that your DNS is set correctly to Automatic and is resolving. Grab a copy of the following file:
C:\Program Files\Viscosity\Resources\RevertConfig.txt


HERE IS THE RevertConfig.txt AFTER SETTING DNS TO AUTOMATIC AND REBOOTING:
<?xml version="1.0"?>
<ArrayOfReversionConfig xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ReversionConfig>
<GUID>{8A4F8016-66F1-486C-A18A-92A053210A3A}</GUID>
<IPv4 />
<IPv6 />
<NBT />
</ReversionConfig>
</ArrayOfReversionConfig>

Eric wrote:
Connect to a server with split DNS with the beta installed, test DNS resolution, and then disconnect. Once disconnected, can you confirm that loopback is still set as the DNS server and grab another copy of the above file. Could you then post up a before and after of that RevertConfig.


HERE IS THE RevertConfig.txt AFTER CONNECTING TO THE VPN USING SPLIT DNS AND ATTEMPTING TO RESOLVE BOTH A INTERNET AND LOCAL HOST:
<?xml version="1.0"?>
<ArrayOfReversionConfig xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ReversionConfig>
<GUID>{8A4F8016-66F1-486C-A18A-92A053210A3A}</GUID>
<IPv4>127.0.0.1</IPv4>
<IPv6 />
<NBT />
</ReversionConfig>
</ArrayOfReversionConfig>

BELOW IS THE CMD DETAIL OF NSLOOKUP BOTH FOLLOWING THE REBOOT AND WHEN CONNECTED TO THE VPN:

---------FOLLOWING REBOOT

C:\>nslookup
Default Server: my.firewall
Address: 192.168.10.1

> google.com
Server: my.firewall
Address: 192.168.10.1

Non-authoritative answer:
Name: google.com
Addresses: 2607:f8b0:4009:815::200e
172.217.8.174

> ppqnap.localdomain
Server: my.firewall
Address: 192.168.10.1

*** my.firewall can't find ppqnap.localdomain: Non-existent domain
> exit

---------WHEN CONNECTED TO VPN

C:\>nslookup
DNS request timed out.
timeout was 2 seconds.
Default Server: UnKnown
Address: ::1

> google.com
Server: UnKnown
Address: ::1

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

> ppqnap.localdomain
Server: UnKnown
Address: ::1

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

Could you please email us [email protected] and we'll send you a debug build so we can try to see what is causing this behaviour.

Regards,
Eric
Hi Eric,

I've sent the email off to support.

Thank you kindly.
-Zenon
Hi Zenon,

Thank you very much for your assistance gathering information for us, we highly appreciate it!

For other users encountering this issue, we have narrowed it down to a bug in old versions of .NET 4.0. Updating to the latest version of .NET (4.6.2 at the time of writing) will resolve these issues - https://www.microsoft.com/en-au/downloa ... x?id=53344

Regards,
Eric
8 posts Page 1 of 1

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy