[SOLVED] Open VPN connection dropping outside network activity on only one of three devices

[newconroer]

54 minutes and counting; no inactivity errors and connection still working.
Downstairs computer disconnected again, this time though I got the error I was expecting to see :

Maybe it is just that computer. Hmm.

 

[newconroer]

You could try restarting your DHCP service and if it doesn't help try resetting winsock in cmd as admin:

netsh winsock reset

I did this winsock reset and now even when the computer is not on a VPN, I am getting resolving host/cannot load webpage errors and flash videos such as Youtube sometimes do not auto play - I have to manually action them...

 

[Aquinus]

Can you run a couple continuous pings until the connection dies? If the connection dies do both pings die?

ping -t 1.2.3.4

Replace 1.2.3.4 with a host on the VPN end of the network and one to the internet, say 8.8.8.8 (one of google's dns servers.)

 

[newconroer]

I did continuous ping on another device in the network and a Google DNS server.

At forty-one minutes I browsed several web pages and the connection was still working.
My network address pings have timed out a handful of times, but never back to back or close together. The Google DNS never timed out it seems.

I did notice though that when watching a Youtube video, my pings shot up quite drastically.

I am going to stop one of the pings and see what happens.

 

[newconroer]

I stopped the internal ping, connectivity remained.
I stopped the second ping (DNS server) and the connection died out a bit later with the same inactivity message from VPN log.

 

[Aquinus]

I stopped the internal ping, connectivity remained.
I stopped the second ping (DNS server) and the connection died out a bit later with the same inactivity message from VPN log.

I would disable an power saving for the wireless adapter to make sure it isn't falling asleep when the connection is idle.

 

[newconroer]

Adapter settings are listed below. Cannot see anything obvious that should or should not be enabled/disabled.

Viscosity /VPN adapter - The only thing that seemed of interest was the 'Media State,' which was set to Application Managed. I have changed it to Always Connected though the other working computer had it at Application Managed.

In the Power Plan for Windows, Wireless Adapters are set to Maximum Performance mode.

 

[newconroer]

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

With 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 :

Dec 30 01:45:43: SIGUSR1[soft,ping-restart] received, process restarting
Dec 30 01:45:43: 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 I woke the computer 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.

 

[remixedcat]

I think the VPN software is way too touchy.

 

[Steevo]

Most have a idle timeout as part of the security features, it prevents VPN data replay and MITM attacks on VPN tunnels, disable it or increase the timeout setting.

 

[newconroer]

I think the VPN software is way too touchy.

Seems that way. I rebooted the computer and tried again. This time, got the inactivity error and disconnect like before.
So the Media State setting is not relevant it seems.

Most have a idle timeout as part of the security features, it prevents VPN data replay and MITM attacks on VPN tunnels, disable it or increase the timeout setting.

In terms of a lease, see end of this line :

Dec 30 04:38:40: Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.179.13/255.255.255.252 on interface {7705A231-89E9-48A1-B0BC-289AFC23A14D} [DHCP-serv: 192.168.179.14, lease-time: 31536000]

I do not know what that number equates too, however there's a few things to consider.

A) On this machine, I haven't any disconnects like that - yet the VPN settings are the same.
B) The client has an option to disconnect clients after XX amount of time. That feature is not checked.

I wish it was that simple!

Here's all the client options:

There's a comment elsewhere that reads :

The restart is occuring because a keepalive ping was not received during
the required time interval.

This usually happens because of short-term network outages. You can make
OpenVPN less sensitive to network outages by using a large keepalive
timeout. For example,

keepalive 10 600

will send a ping every 10 seconds, but only restart if a ping hasn't been
received from the peer for 10 minutes.


Also appended with :

I’ve been seeing bizarre problems with my openvpn client (on linux) over the last couple of days. It would connect, and I could access the network, but the VPN would regularly restart itself and connections would be closed, seeing messages like

Tue May 22 13:19:43 2012 [OpenVPN_Server] Inactivity timeout (--ping-restart), restarting
Tue May 22 13:19:43 2012 TCP/UDP: Closing socket

I saw these problems when I tried my profile on several different computers.

I was unable to find anything on the internet about this (possibly my google fu was weak), but we’ve finally managed to track down the problem. I thought I’d put this here in case other people had the same issue.

This seems to happen when you’re running two openvpn clients with the same profile from different computers. I have two computers I use, and I’d left one idle running the VPN client. When I then tried to connect to the VPN from the other computer I would see this behaviour. I then (foolishly) left that computer trying to use the VPN when I went back to the first computer, so now the problem had mysteriously appeared there too.

http://serverfault.com/questions/104154/why-is-duplicate-cn-not-recommended-in-openvpn

Might be on to something, but the first computer and the Android device are never affected by the status of the second computer.

 

[remixedcat]

persist local and persist remote ip... check these.

 

[newconroer]

No dice. Both or just one at a time, still crashes. And accessing my network internally with the VPN running, gives an error in the VPN log about failed to access shared folders .. as if it's affecting the traffic internally.
Of course only from that computer; from the other side, I can have the VPN running and access the network.

 

[remixedcat]

are the settings the same on all devices?

 

[newconroer]

Yes on the two computers.

 

[remixedcat]

Have you also made sure your drivers are updated as well?

 

[newconroer]

Yes, reinstalled them anyways - no change.

Here is log from this morning's attempt :


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

The first bold could be unimportant, though the second is interesting because it says timed out instead of inactivity.

 

[Steevo]

The first bold is a configuration item on one end of the VPN trying to set the VPN endpoint as the default gateway for all traffic.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx

The second error is due to the connection timing out after it drops. I am guessing that if you remove the default gateway rule it will fix the issues, there may be rules in effect at the remote end that prevent communications and then windows/drvice driver is resetting the network adapter and it drops the VPN.

 

[newconroer]

Hey Steevo,

That sounds promising. How would I remove the gateway rule?
Here is an example of one of the config files.

#-- Config Auto Generated By Viscosity --#

#viscosity protocol openvpn
#viscosity name EarthVPN-USA-LosAngeles2
#viscosity autoupdate false
#viscosity device OpenVPN
remote los2-us.earthvpn.com 80 tcp-client
pull
auth-user-pass
tls-client
persist-key
ca ca.crt
nobind
persist-tun
dev tun
remote-cert-tls server
cipher AES-128-CBC
reneg-sec 0
auth SHA1
resolv-retry infinite
route-delay 5

 

[Steevo]

Somewhere it will say something about the remote or default gateway update for all traffic, and or it may be a check box, or simply a option to force all VPN traffic through the remote gateway, or only routed traffic.

Server side there should show rule violations before the drop for at least your primary VPN IP that will give the reason or rule that is causing the issue or configuration problem.

 

[newconroer]

Hi Steevo, only options are the ones I put in screenshots several posts above.
There is a tick option for route all traffic over VPN, though that did not solve it.

As for server side - I have asked them but since they don't keep logs, how would they know?

 

[Aquinus]

Connect and do a traceroute to any address, that will tell you very quickly if the VPN is changing your default gateway. I'm pretty sure that you need to specify it for it to use a gateway on the other end of the VPN. I use OpenVPN for work and it never changes my default gateway. It does however change my primary DNS server which does make a difference when connecting to resources inside the VPN network since there certain names only resolve to the internal address when you use the DNS server inside the network that we run, but that's in my case.

Considering it only happens when you use the wireless network adapter, I'm inclined to believe that something is happening with the adapter itself.

 

[newconroer]

Hey Aquinus,

I am one step ahead of you. After reinstalling the client, I have enabled 'route all traffic' and the connection has held for over two hours.
In most cases VPN should automatically route all traffic. it’s possible that with wireless connections this is not happening by default and thus requires you to force it to route all traffic.


What you said about the change of DNS though might also be of interest to me. I have noticed that when the VPN is connected I cannot browse network shares however I can still connect if I create a manual path/shortcut. I thought this might have something to do with DNS and the VPN not making an exception for local traffic (like you see in IE proxy settings).

 

[Steevo]

Switch to Open DNS as it will redirect back to internal addresses.

I was going to suggest the same thing, the adapter may be the weakest link here, or the drivers.

 

[newconroer]

Already using open DNS and ensured the VPN adapter is using it as well.
Unfortunately doesn't change the internal network browsing. I may figure it out eventually though just happy to have seemingly solved the VPN issue, and I can still direct connect over network.