OpenVPN Support Forum

Apologies if this is a duplicate thread.

I am having trouble with one of three devices on our network. Two of the three work fine over VPN, both internally and to external sites/addresses.
The third however eventually times out with an inactivity error that can happen whether the system is actually dormant or even while someone is using it.
There is no specific time range - we've seen as short as one minute, and up to as long as an hour.

This happens when using both Viscosity and a generic Open VPN client.

Viscosity gives this inactivity log error :
Dec 30 01:45:43: [*.earthvpn.com] Inactivity timeout (--ping-restart), restarting
Dec 30 01:45:43: SIGUSR1[soft,ping-restart] received, process restarting
Dec 30 01:45:43: State changed to Connecting


Open VPN gives this inactivity error :
0x8007274C: A connection failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Tests done :
Ran ping -t on an internal network address and a Google DNS server. The VPN connection held stable for over an hour. Removed the internal address ping; connection was still stable. Removed the DNS address ping; connection shortly after spit out the inactivity error.

Misc notes :
-Only happens on wireless connections (so far that I can tell; did brief wired test for half hour and seemed ok)
-Two different wireless adapters were used. The only other 'error' listing in the log, would happen BEFORE the connection was established, meaning it didn't stop the connection from proceeding. Note that this only happened once per adapter - mayble fluke?
Adapter 1 ROUTE: route addition failed using CreateIpForwardEntry: The object already exists. [status=5010 if_index=11]
Adapter 2 Warning: route gateway is ambiguous: 192.168.0.1 (2 matches)

-Have used different ports/protocols and DNS settings across all systems - they all connect, but only the one computer fails with the inactivity error
-Subnet for the internal network is 192.168.0.x subnet for VPN adapters is 192.168.179.x
-No gateway number listed for the VPN adapters

Debbie,


The product/service is Open VPN via Earth VPN. For clients, I use either Viscosity or Open VPN 2.2.2 normally. I've also tried Earth VPN's own in-house client which is a small stripped down version of 2.2.2(from what I can tell).

I wanted to present a quick log file, unfortunately cannot :

Already thinking this may be something to do with a powered down state causing the inactivity, I changed the VPN adapter's "Media State" to Always Connected instead of Application Managed. It went for about two hours and then did a soft reset of the connection. Where as before it mentioned inactivity, now it only had the two lines :

SIGUSR1[soft,ping-restart] received, process restarting
State changed to Connecting


It then tried to reconnect - as it always does. It never actually makes it though, and eventually it gave up and officially disconnected.
Dormant for about another hour, I woke the computer about twenty minutes later and it connected again (I have the options set for it to reconnect when computer wakes). I browsed for a few minutes with no problems and then the computer froze taking the log with it.

Here is the most recent log file.


Jan 01 01:07:39: State changed to Connecting
Jan 01 01:07:39: Viscosity 1.0.0 (1034)
Jan 01 01:07:39: Running on Microsoft Windows 7 Ultimate
Jan 01 01:07:41: Bringing up interface...
Jan 01 01:07:45: Checking reachability status of connection...
Jan 01 01:07:45: Connection is reachable. Starting connection attempt.
Jan 01 01:07:46: OpenVPN 2.3.2 Windows-MSVC [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Dec 13 2013
Jan 1 01:07:48: Attempting to establish TCP connection with [AF_INET]109.123.107.155:443 [nonblock]
Jan 1 01:07:49: TCP connection established with [AF_INET]109.123.107.155:443
Jan 1 01:07:49: TCPv4_CLIENT link local: [undef]
Jan 1 01:07:49: TCPv4_CLIENT link remote: [AF_INET]109.123.107.155:443
Jan 1 01:07:49: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jan 1 01:07:50: [*.earthvpn.com] Peer Connection Initiated with [AF_INET]109.123.107.155:443
Jan 1 01:07:56: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jan 1 01:07:56: open_tun, tt->ipv6=0
Jan 1 01:07:56: TAP-WIN32 device [Viscosity] opened: \\.\Global\{7E508408-B72F-4EE9-B087-D31365C936F2}.tap
Jan 1 01:07:56: Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.179.21/255.255.255.252 on interface {7E508408-B72F-4EE9-B087-D31365C936F2} [DHCP-serv: 192.168.179.22, lease-time: 31536000]
Jan 1 01:07:56: Successful ARP Flush on interface [15] {7E508408-B72F-4EE9-B087-D31365C936F2}
Jan 1 01:07:56: Options error: unknown --redirect-gateway flag: def
Jan 1 01:08:02: Initialization Sequence Completed
Jan 01 01:08:02: State changed to Connected
Jan 1 01:10:50: read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Jan 1 01:10:50: Connection reset, restarting [-1]
Jan 1 01:10:50: SIGUSR1[soft,connection-reset] received, process restarting
Jan 01 01:10:50: State changed to Connecting

I only got two minutes as per the stamps, before it gave up, where as sometimes it can be as much as an hour.
This time however the error did not mention inactivity, it states connection timed out.

One thing I have noticed is that the behavior of the VPN becomes more erratic if I try to browse local network shares/folders while the VPN is connected.
I have seen a few logs where it mentions that it cannot connect to a folder on a shared drive.

I do not understand why the VPN cares; shouldn't it be ignoring local activity unless specified otherwise?

Hi Debbie,

That's a possibility, however two things :

A) What are the odds two wireless adapters are failing?
B) I tried them on the other computer which is setup very similar and has identical Viscosity /OPen VPN settings. The wireless did not disconnect.

I've also down continuous pings with ping -t Google DNS servers.
As long as that's running, the connection holds.

Viscosity has some config settings for persistent remote and local ping however that doesn't work.
I've also tried adding keepalive 10 600 as a command, with no success.

Here is a recent log(see bolded) that had a message about gateway flag - which is promising. It could be a case of where one end of the VPN is trying to set the VPN endpoint as the default gateway.
Then followed by the second error of connection timed out.

Jan 01 01:07:39: State changed to Connecting
Jan 01 01:07:39: Viscosity 1.0.0 (1034)
Jan 01 01:07:39: Running on Microsoft Windows 7 Ultimate
Jan 01 01:07:41: Bringing up interface...
Jan 01 01:07:45: Checking reachability status of connection...
Jan 01 01:07:45: Connection is reachable. Starting connection attempt.
Jan 01 01:07:46: OpenVPN 2.3.2 Windows-MSVC [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Dec 13 2013
Jan 1 01:07:48: Attempting to establish TCP connection with [AF_INET]109.123.107.155:443 [nonblock]
Jan 1 01:07:49: TCP connection established with [AF_INET]109.123.107.155:443
Jan 1 01:07:49: TCPv4_CLIENT link local: [undef]
Jan 1 01:07:49: TCPv4_CLIENT link remote: [AF_INET]109.123.107.155:443
Jan 1 01:07:49: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jan 1 01:07:50: [*.earthvpn.com] Peer Connection Initiated with [AF_INET]109.123.107.155:443
Jan 1 01:07:56: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jan 1 01:07:56: open_tun, tt->ipv6=0
Jan 1 01:07:56: TAP-WIN32 device [Viscosity] opened: \\.\Global\{7E508408-B72F-4EE9-B087-D31365C936F2}.tap
Jan 1 01:07:56: Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.179.21/255.255.255.252 on interface {7E508408-B72F-4EE9-B087-D31365C936F2} [DHCP-serv: 192.168.179.22, lease-time: 31536000]
Jan 1 01:07:56: Successful ARP Flush on interface [15] {7E508408-B72F-4EE9-B087-D31365C936F2}
Jan 1 01:07:56: Options error: unknown --redirect-gateway flag: def
Jan 1 01:08:02: Initialization Sequence Completed
Jan 01 01:08:02: State changed to Connected
Jan 1 01:10:50: read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Jan 1 01:10:50: Connection reset, restarting [-1]
Jan 1 01:10:50: SIGUSR1[soft,connection-reset] received, process restarting
Jan 01 01:10:50: State changed to Connecting



I'll work on adding others later.

While VPN should automatically route all traffic over the network, it’s possible that with wireless connections this is not happening by default and thus requires you to force it to route all traffic.
Fortunately my client had a simple check box for this and it's resolved the issue.