support "--pre-start" script option

[jhaar]

Hi there

We use openvpn as a service under both Windows and Unix - so don't rely on the user to start/stop or otherwise make decisions. However, there are decisions we'd like to make that require openvpn to be able to block right at the beginning and await the decision of an external script - a "--pre-start" option.

I'd envis*ge (that's an "a" - your antispam system would accept the word) a setting that would run the script, and:

• exit status 0: re-read entire config, ignore "--pre-start" and start initializing tunnel/etc
• exit status 99: re-read entire config, including "--pre-start" option (why 99 - see sendmail :-)
• exit status "other": exit openvpn

That way we could make decisions within a "--pre-start" script like:

1. if Intranet-only HTTPS webserver is available, you are on the internal network, so sleep for 10 minutes then exit 99. (ie don't run openvpn to tunnel back to the network you're already on)
2. if default route shows this to be a GPRS link, sleep 10 minutes then exit 99 (ie we don't want openvpn to run over expensive GPRS links)
3. resolve the openvpn server DNS name to it's IPs, ping them and choose the one that is closest to your current position. Then REWRITE the config to use that IP as the server name, then exit 0

You have so many brilliant hooks for calling external scripts, this is basically the only one left. On Unix systems this is easy to compensate for by "wrapping" a script around your openvpn startup, but Windows services are a different matter. Instead of creating a different Windows service hook, adding an extra script support seems more in keeping?

Thanks for listening

Jason

[David Sommerseth]

Hi,

This is a very interesting proposal, and at first glance I was thinking "of course!". But then I began thinking. And even though the proposal is very good, it has a very good use case and is even very much useful; I do have some doubts.

First of all, this is an issue which is hit because, as you say, in the *nix world you script yourself around this with a wrapper and this is not so easy in the Windows world. And this describes the core roles.

OpenVPN should provide a VPN tunnel. OpenVPN should not consider what kind of environment it is tried to be run in, as that would be a pretty impossible task - as the variety is so enormous. So including some scripting possibility is a natural step, to indicate if the environment is fine or not. And I'm willing to accept these arguments ... however ...

There is a security aspect here as well. OpenVPN could easily be abused to run "whatever" as a service, and then making OpenVPN more than just a VPN tunnel provider.

This possibility will most likely make at least some sys-admins frown and scream at us. (I'm not a fan of being yelled at ;-). So to calm things down a bit, we would probably need to provide two different OpenVPN versions - with all the challenges that brings in.

Or ... it could be provided as a separate solution which is able to be run as a service, which would provide the needed functionality/flexibility for such environment analysis. It would most likely need to provide some scripting possibility. But having this as something separate, not part of OpenVPN provides a better scenario in my eyes:

• OpenVPN does not get increased complexity in regards to security issues
• A more generic solution which can be used more broadly than just for OpenVPN
• OpenVPN cannot be abused to run xyz.bat as a service, even though it doesn't need any networking at all ... which leads to -> OpenVPN doesn't get all the complaints
• Freedom: People disliking this feature don't need to install it, people who wants/need it can easily get it.

Or am I too conservative?