OpenVPN routing fails, but only sometimes. (windows client)

[bae3]

I use Windows 7 and openvpn gui 2.1.4 client (with the "run as admin" checked) connecting to 2.1.4 server on linux.

I can't get it to fail locally on my home network, but when on the road connected wirelessly at some hotel, the openvpn says it is connected but the default routing has failed and I can't use the vpn properly, but openvpn will sit there as if it were properly connected. This is very frustrating as it isn't consistently failing. Only sometimes...

When it fails, my client logs show a loop of these:

Code: Select all

Fri Feb 04 05:56:19 2011 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Fri Feb 04 05:56:19 2011 Route: Waiting for TUN/TAP interface to come up...

and the TAP Adapter shows its IP as not having been set:

Code: Select all

TAP-Win32 Adapter V9
  IP = 169.254.167.27/255.255.0.0 

I have added "route-delay 0 60" to my client config, but that loop just gets longer (1 minute) but it still fails.

When it works, which is about 70% of the time it is usually successful (u/d=up) on the first attempt, but occasionally it might loop a few times before it is successful:

Code: Select all

Wed Feb 02 19:18:40 2011 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Wed Feb 02 19:18:40 2011 Route: Waiting for TUN/TAP interface to come up...
Wed Feb 02 19:18:41 2011 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Wed Feb 02 19:18:41 2011 Route: Waiting for TUN/TAP interface to come up...
Wed Feb 02 19:18:42 2011 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up

TAP-Win32 Adapter V9
  IP = 192.168.111.2/255.255.255.192 

Sometimes when it fails I see this:
WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: The system cannot find the file specified. (code=2)
or:
WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: The name specified in the network control block (NCB) is in use on a remote adapter. The NCB is the data. (code=5322)
or:
TAP: DHCP address renewal succeeded

But sometimes when it succeeds I see this:
WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: The system cannot find the file specified. (code=2)

So I don't know if it is related.

Is there any way to make it reliable without changing to some other non-dhcp/default route setup? I like it the way it is when it works, I just want it to reliably set the route. (setting a longer timeout on the attempts doesn't seem like a way to gain reliability, it might just loop for 5 minutes and fail...)

server config:

Code: Select all

dev tun-tcp
persist-key
persist-tun
ca ca.crt
cert server.crt
key server.key  
dh dh1024.pem
tls-auth ta.key 0 
cipher AES-128-CBC
comp-lzo
topology subnet
ifconfig-pool-persist ipp.txt
server 192.168.111.0 255.255.255.192
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option WINS 192.168.1.1"
keepalive 10 120
status openvpn-status.log
verb 3

client config

Code: Select all

client
dev tun
nobind
persist-key
persist-tun
ca ca.crt
cert client2.crt
key client2.key
tls-auth ta.key 1
cipher AES-128-CBC
comp-lzo
verb 3
show-net-up
dhcp-renew
route-delay 0 60

[hostizzle]

To me, this is the biggest issue reducing the uptake and installation of OpenVPN worldwide. I have far, far more downloads than I do installations on my server, and I think the routing issue is why.

Why is it that the Windows native PPTP client routes faultlessly in any configuration, yet the OpenVPN client has to be explicitly told how to route and many times still fails at this task?

Plenty of users have told me they run the client explicitly as admin under Windows 7, yet still fail at setting up routing.

I don't mean to offend anyone here who has worked on this excellent project--it truly must be a labor of love.

Routing is a huge mystery to even me, an OpenVPN server admin. Surely it must be just as mysterious to end users all over the world.

[bae3]

There is no solution? I can not find anything in the configuration that is wrong.

It just doesn't work "sometimes" which is very frustrating.

[janjust]

try adding

Code: Select all

  route-method exe
  route-delay 20

to your client config file.

As for OpenVPN not being to route properly vs the Windows native PPTP client: in a lot of cases the client is running some kind of antivirus software which is tested against the native PPTP client but which has not been tested against OpenVPN's TAP-Win32 adapter. This often causes problems. The routing capabilities of OpenVPN far exceed those of the native PPTP or L2TP clients but as always, with great power/flexibility comes great responsibility.

[bae3]

try adding

Code: Select all

  route-method exe
  route-delay 20

to your client config file.

That didn't help -- it still fails, sometimes.

I tried setting the TAP device to "Always active", but that didn't help either.

It seems to fail more frequently after a hibernation ... but I can't force it to fail on demand.

I can't find a way to have it auto disconnect/reconnect if the TAP-Win32 adapter has an IP of 169.254.. or 0.0.0.0 either.

[billb3]

Been having the same issue for months. Very frustrating, since it is the thing holding up our Windows 7 roll-out. Have you had any luck fixing this?

Here is a bug I opened:

https://community.openvpn.net/openvpn/ticket/71

It was also discussed on the mailing list. A few responses from Samuli:

http://article.gmane.org/gmane.network. ... user/31177
http://article.gmane.org/gmane.network. ... user/31385

[Daniel S]

Any updates on this one? I know it's an old thread, but this has been a well documented problem for some time now.

[JStone]

Thank goodness someone was having the same issue as me. Thank you for such an informative post

[Mimiko]

On windows systems espacially on server ones, the APIPA technology causes problem to bringin up the TUN interface. The issue varies from system to system and depends on the drivers of the networks that joins the system core with network drivers. So there is two possibilities to resolve:
1) Disable APIPA and set the IP to tun interface as static (there is a bug in windows which disables dhcp retriving of IP when APIPA is disabled).
2) Use route-delay 60 60 (the first parameter delays IP set to the tun interface, not the second, and it must be the minimum amount of time for the system to bring up interface and set IP using APIPA, otherwise it will fail).

From my experience, slower hardware will need more time to bring up TUN interface. While Windows 2008 server seems have resolved the issue, so a default route-delay of 10 seconds is enough.

[heart058]

This is a relief. I have been scanning the threads for the same problem. Thanks a lot!