DNS_PROBE_FINISHED_NXDOMAIN Errors whilst using Eddie

[whydoesitmatter 0]

Hello,

I've been reading through all the DNS posts I can find, and I've tried a few things, but I seem to be having a persistant issue.  I've used AirVPN for a good long while without issues at all. I've just moved to NZ and am now using a Fibre provider for my internet. Everything is fine, until I connect to a AirVPN Server, and then after about 30 seconds I cannot browse the web. I've upgraded to the latest Eddie client (I'm on Win10 x64), and I've tried the Experimental version too. I get the same issue with both.  After a while (over 10 mins) the DNS may resolve and the website will load, or I can manually restart the dnscache service and i can immediately (for about a minute) resolve a web address. The only site I can always get is airvpn sites.

 

Here's my airvpn logs

I 2016.12.10 21:26:02 - Session starting.
. 2016.12.10 21:26:05 - Shell of 'cmd.exe','/c net stop dnscache' done sync in 3078 ms
. 2016.12.10 21:26:08 - Shell of 'cmd.exe','/c net start dnscache' done sync in 2610 ms
. 2016.12.10 21:26:08 - Shell of 'cmd.exe','/c ipconfig /flushdns' done sync in 406 ms
. 2016.12.10 21:26:12 - Shell of 'cmd.exe','/c ipconfig /registerdns' done sync in 3406 ms
. 2016.12.10 21:26:12 - IPv6 disabled with packet filtering.
I 2016.12.10 21:26:12 - Checking authorization ...
! 2016.12.10 21:26:13 - Connecting to Alkes (United States, Los Angeles)
. 2016.12.10 21:26:13 - OpenVPN > OpenVPN 2.3.13 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [iPv6] built on Nov 10 2016
. 2016.12.10 21:26:13 - OpenVPN > Windows version 6.2 (Windows 8 or greater) 64bit
. 2016.12.10 21:26:13 - OpenVPN > library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
. 2016.12.10 21:26:13 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2016.12.10 21:26:13 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2016.12.10 21:26:13 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.12.10 21:26:13 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.12.10 21:26:13 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144]
. 2016.12.10 21:26:13 - OpenVPN > UDPv4 link local: [undef]
. 2016.12.10 21:26:13 - OpenVPN > UDPv4 link remote: [AF_INET]199.241.146.180:80
. 2016.12.10 21:26:13 - OpenVPN > TLS: Initial packet from [AF_INET]199.241.146.180:80, sid=56746947 3f1dbee8
. 2016.12.10 21:26:13 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2016.12.10 21:26:13 - OpenVPN > Validating certificate key usage
. 2016.12.10 21:26:13 - OpenVPN > ++ Certificate has key usage 00a0, expects 00a0
. 2016.12.10 21:26:13 - OpenVPN > VERIFY KU OK
. 2016.12.10 21:26:13 - OpenVPN > Validating certificate extended key usage
. 2016.12.10 21:26:13 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2016.12.10 21:26:13 - OpenVPN > VERIFY EKU OK
. 2016.12.10 21:26:13 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2016.12.10 21:26:14 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.12.10 21:26:14 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.12.10 21:26:14 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.12.10 21:26:14 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.12.10 21:26:14 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2016.12.10 21:26:14 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]199.241.146.180:80
. 2016.12.10 21:26:16 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2016.12.10 21:26:16 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.6.0.1,comp-lzo no,route-gateway 10.6.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.6.0.250 255.255.0.0'
. 2016.12.10 21:26:16 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2016.12.10 21:26:16 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2016.12.10 21:26:16 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2016.12.10 21:26:16 - OpenVPN > OPTIONS IMPORT: route options modified
. 2016.12.10 21:26:16 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2016.12.10 21:26:16 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2016.12.10 21:26:16 - OpenVPN > ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=7 HWADDR=8c:89:a5:2a:25:bf
. 2016.12.10 21:26:16 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2016.12.10 21:26:16 - OpenVPN > open_tun, tt->ipv6=0
. 2016.12.10 21:26:16 - OpenVPN > TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{4DF667A8-313D-4C55-9802-FEABD12F2883}.tap
. 2016.12.10 21:26:16 - OpenVPN > TAP-Windows Driver Version 9.21
. 2016.12.10 21:26:16 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.6.0.0/10.6.0.250/255.255.0.0 [sUCCEEDED]
. 2016.12.10 21:26:16 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.6.0.250/255.255.0.0 on interface {4DF667A8-313D-4C55-9802-FEABD12F2883} [DHCP-serv: 10.6.255.254, lease-time: 31536000]
. 2016.12.10 21:26:16 - OpenVPN > Successful ARP Flush on interface [6] {4DF667A8-313D-4C55-9802-FEABD12F2883}
. 2016.12.10 21:26:21 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
. 2016.12.10 21:26:21 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 199.241.146.180 MASK 255.255.255.255 192.168.1.1
. 2016.12.10 21:26:21 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=15 and dwForwardType=4
. 2016.12.10 21:26:21 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.12.10 21:26:21 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.6.0.1
. 2016.12.10 21:26:21 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=15 and dwForwardType=4
. 2016.12.10 21:26:21 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.12.10 21:26:21 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.6.0.1
. 2016.12.10 21:26:21 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=15 and dwForwardType=4
. 2016.12.10 21:26:21 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.12.10 21:26:21 - Starting Management Interface
. 2016.12.10 21:26:21 - OpenVPN > Initialization Sequence Completed
. 2016.12.10 21:26:21 - DNS leak protection with packet filtering enabled.
. 2016.12.10 21:26:21 - DNS of a network adapter forced (Realtek PCIe GBE Family Controller, from manual (192.168.1.1) to 10.6.0.1)
I 2016.12.10 21:26:21 - Flushing DNS
. 2016.12.10 21:26:24 - Shell of 'cmd.exe','/c net stop dnscache' done sync in 3203 ms
. 2016.12.10 21:26:25 - Shell of 'cmd.exe','/c net start dnscache' done sync in 610 ms
. 2016.12.10 21:26:25 - Shell of 'cmd.exe','/c ipconfig /flushdns' done sync in 421 ms
. 2016.12.10 21:26:29 - Shell of 'cmd.exe','/c ipconfig /registerdns' done sync in 3438 ms
I 2016.12.10 21:26:29 - Checking route
I 2016.12.10 21:26:54 - Checking DNS
! 2016.12.10 21:26:55 - Connected.
. 2016.12.10 21:26:55 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2016.12.10 21:26:55 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info

 

As can be seen, I use the default DNS servers for airvpn, and I've previously tested them against ipleak.net and they've been good, with no leakage. 

 

I've disabled IPV6 on both the adapters and in the registry, and I've previously tried setting OpenDNS servers instead of air's.  I have another device in the house that doesn't use AirVPN and that is fine (as is this machine when not connected to Air).

 

I do use Comodo Internet Security with rules for AirVPN, but they've not changed settings for over a year (then again, I hadn't changed Air either until I started getting these issues),  I did wonder if the Fibre provider was causing an issue as I've only ever had copper-wired internet before?  I'm also hard wired to the route, not that that is going to make a difference.  Could there be a very low tolerance for DNS lookups between Air servers and NZ? I find I connect to the US servers with about 2.5 stars latency (126ms).

 

After typing all this up, my DNS now resolves temporarily, and this was my ping response to google.co.uk

Pinging www.google.co.uk [74.125.68.94] with 32 bytes of data:

Reply from 74.125.68.94: bytes=32 time=306ms TTL=43

Reply from 74.125.68.94: bytes=32 time=307ms TTL=43

Reply from 74.125.68.94: bytes=32 time=306ms TTL=43

 

Ping statistics for 74.125.68.94:

    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 306ms, Maximum = 307ms, Average = 306ms

 

Any ideas are much appreciated as I'm going nuts constantly restarting my dnscache service.

[LZ1 673]

Hello!

 

Have you tried using different protocols? In particular SSH or SSL and then one of the other UDP ones.

 

You may wish to use OpenNIC instead of OpenDNS as well, as Air supports them.

 

Are you getting these issues with Network Lock on or off or both?

 

It may also be worth trying to temporarily disable Comodo and check. Especially if you went back to the Stable client.

 

I'm not sure what the "Shell of 'cmd.exe' thing is - is this in the Eddie client or some OpenVPN client?

 

Sent to you from me with datalove