openvpn should check that there's a working TAP before even attempting to create a tunnel

[jhaar]

Hi there

We've been having problems with running openvpn as a service. Under some still unknown circumstances (I suspect Cisco Anyconnect is involved), a working openvpn Windows install will suddenly find itself with a disabled TAP interface.

What seems to happen is openvpn negotiates the tunnel successfully, and at the last moment starts interacting with the TAP interface - and fails. It then goes into a retry infinite loop (not sure if that's openvpn or the service manager we're using, but I *want* openvpn to auto-retry - except in this situation!). The problem is the valid client is looping and this causes a large load on the server - due to the vast range of scripts we call on "--up". This nails the server - which nails all other happy clients

So my point is that I don't see why openvpn needs to let this happen. Couldn't openvpn be re-coded to check that there's a working TAP interface before even attempting to negotiate? ie if the TAP is disabled, then openvpn should just exit - it's never going to work - so why bother trying. I don't care if that leads to a load problem on the client - I just want to get the load off the server :-)

Thanks

Jason

[Gert Döring]

2.4.0 should behave more nicely here, read: the "reconnect after <x> seconds" part *should* increase exponentially to a configurable upper limit (default 2 hours, I think). I'm not sure if that actually applies to TAP init fails, too... could you test and show a log with 2.4.0?

As for "testing whether the tap is working" - it could be done, but would be a fairly large code reorganization. Right now the assumption is "tun/tap devices do work, network fails occasionally" so we try the "can fail" bit first... not sure how to tackle this.