Unable to establish new connections... sometimes

john5

Hi all,

Every so often, my OpenVPN stops connecting to remote addresses until I reboot.

When this occurs, I'm able to ping, tracert, and resolve these remote addresses as normal. Connections that have already been established (IRC, instant messenger, et al) continue to function, but new connections through my OpenVPN adapter simply don't respond.

Until last week, I was running OpenVPN 2.2.2 on Windows 7 x64. I've since downgraded to 2.1.4 to match my server's version, but this had no effect. I don't dare risk a server upgrade to 2.2.2, both because my server's update repository doesn't contain it and because this OpenVPN is currently my only means of internet access. If something goes wrong, I'm boned.

Sometimes, simply waiting a while resolves this issue. If I'm busy doing something that doesn't require internet access, sometimes I find I'm able to access the internet again in ten minutes, sometimes in several hours, sometimes never again until I reboot. I can confirm this phenomenon is in no way related to the hourly handshake, as I've seen my connectivity disappear and then reappear before the next handshake.

Restarting OpenVPN GUI doesn't help, restarting OpenVPN itself doesn't help, repairing the associated network adapters doesn't help, nor does logging off help; nothing short of a reboot (or the miraculous phenomenon described in the previous paragraph) seems to have any effect.

Client config:

client
dev tun
proto tcp
remote <ip> <port>
resolv-retry infinite
nobind
persist-key
persist-tun
socks-proxy <ip> <port>
ca ca.crt
cert home.crt
key home.key
ns-cert-type server
tls-auth tls.key 1
cipher AES-256-CBC
comp-lzo adaptive
verb 3
connect-retry 1
route-metric 1
route-nopull
route 0.0.0.0 0.0.0.0
up-restart

Server config:

local <ip>
port <port>
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.4.4"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
tls-server
tls-auth tls.key 0
cipher AES-256-CBC
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 3
chroot /var/empty

If restarting the OpenVPN client doesn't resolve the issue, clearly, the OpenVPN client isn't at fault. If rebooting my system resolves the issue, clearly, the OpenVPN server isn't at fault. What, then, could possibly be wrong here? I'm at a complete and total loss.

Mimiko

When traffic is stuck, post a log with "verb 4" from the client, when you try to restart OpenVPN GUI.

As you've discovered, it's something with the system. I am thinking more a problem with the phisical network interface or the drivers for it. Try do repair the system with "sfc /scannow" and update network drivers.

john5

It appears this is caused by my LAN adapter (which has no internet connectivity at this time) somehow pushing its way to the top of my route table. When this is at the top, OpenVPN is fine:

0.0.0.0 0.0.0.0 10.8.0.5 10.8.0.6 30

When this is at the top, however, no connectivity:

0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.2 10

Short of disabling the LAN adapter (which I need to access my LAN), what else can I try here? I already have my OpenVPN adapter at the top of the list in Network Connections > Advanced > Advanced Settings, but apparently, that has no effect.

Mimiko

Don't use "route 0.0.0.0 0.0.0.0 10.8.0.5" in your clients config, as in server config is present "push redirect-gateway". That's why routing table get messed.

john5

I have that in there because, sometimes, it doesn't redirect the default gateway as instructed. I've been running with that line commented out for the past few weeks, though, and the problem persists -- my LAN keeps pushing its way to the top of my routing table. Any other ideas?

Mimiko

In windows 7, open Network Connections, find the adapter with 192.168.1.2 and in advanced IPv4 configuration set metric to automatic. If that doesn't help, then set it manually to something 100 or more.

john5

It was already set to automatic. I tried 100, and the problem recurred; I tried setting the OpenVPN adapter to 5, and the problem recurred; I tried setting the OpenVPN adapter to 5 and the LAN adapter to 100, and the problem recurred. This really, really doesn't make any sense...

Mimiko

Windows 7 does not use the metric you set as a real. The real value is lower. Don't know why, may be a bag. So it has to be set to values higher than 100 anf lower than 255.

john5

Connection just died again. To confirm whether or not routing was the culprit, I've been running with the following settings for the past few days:

route-metric 1
route-nopull
route 0.0.0.0 0.0.0.0

OpenVPN adapter forced metric = 1
LAN adapter forced metric = 9999

I also saved a copy of the output of "route print" while my connection was working and compared it to the output when it died. The routing tables were identical. I guess this eliminates the routing theory and puts us right back at square one.

john5

Turns out this is two separate issues: the routing one (which is resolved by not specifying a manual route), and a mysterious secondary one which appears to be server-side. This explains why my connection sometimes began working again without intervention -- the routing issue required a reboot, while the server-side one resolved itself after a short period of time.

I'm now running without manual routes, and I now have an alternate OpenVPN server. When my connection last hung, I connected to the alternate server and was able to surf without issue; I then reconnected to the main server, and the connection was still hung, but it resolved itself after about five minutes. This tells me it's a server-side issue. What could be wrong?

(I'd prefer not to use the alternate server as anything but a backup, as I don't trust it nearly as much, and it's not nearly as fast.)