Opened 5 years ago

Last modified 9 months ago

#533 new Bug / Defect

openvpn should check the tap interface will work before even attempting server connection

Reported by: jhaar Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.5 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: windows
Cc:

Description

Hi there

We run openvpn under Windows as a service and have had a couple of
situations where users for one reason or another have decided to disable
openvpn by disabling the TAP interface instead of shutting down the
openvpn service. The problem is that openvpn doesn't appear to look too
hard at the enable/disable state of the adaptor and goes through the
entire connection to server, negotiating ip addresses, etc - before
noticing and crashing/exiting. This causes an infinite loop: the client
connects, crashes, sleeps, connects, etc - and the load on the server
goes through the roof - all from one user. We can blame the service
manager for that - but frankly I *want* it to restart openvpn on error -
just not this error

Telling users what to do is fine and sensible, but has a 0% chance of
working. Wouldn't it be better than openvpn checks the state of the
interface right at the beginning and simply refuses to connect if it's
in an unusable state? I'd rather the client went into an infinite loop
of starting, checking, exiting, starting, etc than involve the server
(which affects other users). A 5-10 second delay after such a condition
was detected would help reduce any client impact too of course

Change History (2)

comment:1 Changed 5 years ago by Samuli Seppänen

Keywords: windows added

comment:2 Changed 9 months ago by tincantech

This is very similar to #435 and a solution has been provided to back off the client retries.

However, having openvpn test the state of the Windows TAP Adapter, prior to starting the connection process, is still a valid possibility.

Note: See TracTickets for help on using tickets.