“Check route timeout” failed on every server

[aironedo 0]

It‘s no problem when i used win xp.

But it's a lot problem when i use win 7.

check route   timeout  all the time ,all the severs.  no matter tcp or udp.

only ssl can connected ,but the speed is too low

 

 

anyone know  why?

 

this is  one log:

! 2016.11.16 13:19:33 - Ready

. 2016.11.16 13:19:37 - Systems & servers data update completed

I 2016.11.16 13:19:42 - Session starting.

I 2016.11.16 13:19:43 - IPv6 disabled.

I 2016.11.16 13:19:43 - Checking authorization ...

! 2016.11.16 13:19:47 - Connecting to Heze (United States, Fremont, California)

. 2016.11.16 13:19:48 - OpenVPN > OpenVPN 2.3.8 i686-w64-mingw32 [sSL (OpenSSL)] [LZO] [iPv6] built on Aug 13 2015

. 2016.11.16 13:19:48 - OpenVPN > library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.08

. 2016.11.16 13:19:48 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100

. 2016.11.16 13:19:48 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file

. 2016.11.16 13:19:48 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

. 2016.11.16 13:19:48 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

. 2016.11.16 13:19:48 - OpenVPN > Socket Buffers: R=[8192->131072] S=[8192->131072]

. 2016.11.16 13:19:48 - OpenVPN > UDPv4 link local: [undef]

. 2016.11.16 13:19:48 - OpenVPN > UDPv4 link remote: [AF_INET]46.21.151.106:443

. 2016.11.16 13:19:48 - OpenVPN > TLS: Initial packet from [AF_INET]46.21.151.106:443, sid=75e4e992 fde70206

. 2016.11.16 13:19:48 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org

. 2016.11.16 13:19:48 - OpenVPN > Validating certificate key usage

. 2016.11.16 13:19:48 - OpenVPN > ++ Certificate has key usage  00a0, expects 00a0

. 2016.11.16 13:19:48 - OpenVPN > VERIFY KU OK

. 2016.11.16 13:19:48 - OpenVPN > Validating certificate extended key usage

. 2016.11.16 13:19:48 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

. 2016.11.16 13:19:48 - OpenVPN > VERIFY EKU OK

. 2016.11.16 13:19:48 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org

. 2016.11.16 13:19:51 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key

. 2016.11.16 13:19:51 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

. 2016.11.16 13:19:51 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key

. 2016.11.16 13:19:51 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

. 2016.11.16 13:19:51 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA

. 2016.11.16 13:19:51 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]46.21.151.106:443

. 2016.11.16 13:19:53 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

. 2016.11.16 13:19:53 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.4.0.1,comp-lzo no,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.17.239 255.255.0.0'

. 2016.11.16 13:19:53 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified

. 2016.11.16 13:19:53 - OpenVPN > OPTIONS IMPORT: LZO parms modified

. 2016.11.16 13:19:53 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified

. 2016.11.16 13:19:53 - OpenVPN > OPTIONS IMPORT: route options modified

. 2016.11.16 13:19:53 - OpenVPN > OPTIONS IMPORT: route-related options modified

. 2016.11.16 13:19:53 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

. 2016.11.16 13:19:53 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0

. 2016.11.16 13:19:53 - OpenVPN > open_tun, tt->ipv6=0

. 2016.11.16 13:19:54 - OpenVPN > TAP-WIN32 device [鏈湴杩炴帴 2] opened: \\.\Global\{70580C34-0802-47EF-B9A9-1E36741B62BE}.tap

. 2016.11.16 13:19:54 - OpenVPN > TAP-Windows Driver Version 9.21

. 2016.11.16 13:19:54 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.4.0.0/10.4.17.239/255.255.0.0 [sUCCEEDED]

. 2016.11.16 13:19:54 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.4.17.239/255.255.0.0 on interface {70580C34-0802-47EF-B9A9-1E36741B62BE} [DHCP-serv: 10.4.255.254, lease-time: 31536000]

. 2016.11.16 13:19:54 - OpenVPN > Successful ARP Flush on interface [16] {70580C34-0802-47EF-B9A9-1E36741B62BE}

. 2016.11.16 13:19:58 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up

. 2016.11.16 13:19:58 - OpenVPN > C:\windows\system32\route.exe ADD 46.21.151.106 MASK 255.255.255.255 192.168.8.1

. 2016.11.16 13:19:58 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4

. 2016.11.16 13:19:58 - OpenVPN > Route addition via IPAPI succeeded [adaptive]

. 2016.11.16 13:19:58 - OpenVPN > C:\windows\system32\route.exe ADD 192.168.8.1 MASK 255.255.255.255 192.168.8.1 IF 12

. 2016.11.16 13:19:58 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4

. 2016.11.16 13:19:58 - OpenVPN > Route addition via IPAPI succeeded [adaptive]

. 2016.11.16 13:19:58 - OpenVPN > C:\windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.4.0.1

. 2016.11.16 13:19:58 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4

. 2016.11.16 13:19:58 - OpenVPN > Route addition via IPAPI succeeded [adaptive]

. 2016.11.16 13:19:58 - OpenVPN > C:\windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.4.0.1

. 2016.11.16 13:19:58 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4

. 2016.11.16 13:19:58 - OpenVPN > Route addition via IPAPI succeeded [adaptive]

. 2016.11.16 13:19:58 - Starting Management Interface

. 2016.11.16 13:19:58 - OpenVPN > Initialization Sequence Completed

I 2016.11.16 13:19:58 - DNS of a network adapter forced (Intel® 82566MM Gigabit Network Connection)

I 2016.11.16 13:19:59 - DNS of a network adapter forced (TAP-Windows Adapter V9)

I 2016.11.16 13:19:59 - Flushing DNS

I 2016.11.16 13:19:59 - Checking route

W 2016.11.16 13:20:59 -Time out

! 2016.11.16 13:21:00 - Disconnecting

. 2016.11.16 13:21:00 - Management - Send 'signal SIGTERM'

. 2016.11.16 13:21:00 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'

. 2016.11.16 13:21:00 - OpenVPN > SIGTERM received, sending exit notification to peer

. 2016.11.16 13:21:00 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info

. 2016.11.16 13:21:00 - OpenVpn Management > SUCCESS: signal SIGTERM thrown

. 2016.11.16 13:21:05 - OpenVPN > C:\windows\system32\route.exe DELETE 46.21.151.106 MASK 255.255.255.255 192.168.8.1

. 2016.11.16 13:21:05 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]

. 2016.11.16 13:21:05 - OpenVPN > C:\windows\system32\route.exe DELETE 192.168.8.1 MASK 255.255.255.255 192.168.8.1

. 2016.11.16 13:21:05 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]

. 2016.11.16 13:21:05 - OpenVPN > C:\windows\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.4.0.1

. 2016.11.16 13:21:05 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]

. 2016.11.16 13:21:05 - OpenVPN > C:\windows\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.4.0.1

. 2016.11.16 13:21:05 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]

. 2016.11.16 13:21:05 - OpenVPN > Closing TUN/TAP interface

. 2016.11.16 13:21:05 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting

. 2016.11.16 13:21:05 - Connection terminated.

I 2016.11.16 13:21:06 - DNS of a network adapter restored to original settings (Intel® 82566MM Gigabit Network Connection)

I 2016.11.16 13:21:06 - DNS of a network adapter restored to original settings (TAP-Windows Adapter V9)

[grok 3]

For me, upon a recent Win 10 update, Kaspersky AV (it's apparently often an AV issue) began blocking DNS in the GUI (can still ping IP and named servers).

 

So maybe your log stops at 'Checking route' -- but the issue is actually likely the next step: 'Checking DNS'.

 

M$ is the culprit here: (not 'playing ball' with Kaspersky and other AV companies...)

 

 

What to do...