Inconsistencies about OpenVPNServiceInteractive

[tschoening]

If OpenVPNServiceInteractive is not started, the GUI provides an error message telling a user so, even though the service is not needed in some cases at all. If e.g. a user doesn't use connections which push additional routes, the GUI warns about the not running service, but it is able to successfully create the connection and that connection works.

If the user tries to start a connection which in theory pushes additional routes, establishing that connections seems to fail ultimately. The problem is that, it worked in former version of OpenVPN: Without this service you logged that you can't add routes because of ERROR_ACCESS_DENIED, but simply continued successfully and called e.g. an up-script in which I could create a needed route manually. Those connections are not working anymore without running the interactive service, I needed to downgrade to 2.3.14 and the connections workes as expected again.

If OpenVPNServiceInteractive is running instead, I'm forced to add my current user to a special group before I'm able to use any connection, even those which has been successfully started without the service running before and even though in former versions without such service I was allowed to start my user defined connections as well without any admin privileges or special group membership.

That doesn't make sense to me. While I appreciate your affords regarding the interactive service for adding routes and such for the default user, because it surely makes life easier for those, I don't see why it's a good thing to break with the former working behaviour if the service is not available for some reason.

Just log your error message like you have done before and keep going. I would even reconsider the warning message about the not running service, because in default installations it will be running and if things don't work people will notice error messages in the log and such.

Your current behaviour is making life worse for people like me, which stop your service for some reason: I don't want your service to add arbitrary routes pushed by an arbitrary OpenVPN server to my local network. I have some up/down-Scripts managing routes of connections manually by purpose, because of overlapping networks and various other problems. In such cases I simply benefit of OpenVPN not being able to apply pushed routes automatically, have a place to document which routes make problems to me and which do I need. Those scripts are using "runas" and simply work.

I know this is not for the general user, but your former behaviour worked very well for me and that and the new service are perfectly compatible as I see it. You just need to make sure that in case of a not running service your behaviour is the same as before, especially just continue to establish a connection like you did in former versions. The average user won't stop that service, but if I do to get the old behaviour back, I think this should work.

Thanks!

P.S.: The attached screenshot is one connection which pushes routes and did work without the service and without admin privileges before. The bottom error message didn't occur, but instead the up-script was executed.

[tschoening]

OpenVPN-GUI connection error w_o running iservice

[Selva Nair]

In 2.3 it was not possible to store configs in user profile. So if you want 2.3 behaviour keep all your configs under the global location (C:\Program Files\OpenVPN\config by default) and keep interactive service running. That way both connections needing admin access (say for routes) and not needing admin access will work without any special privileges available to the user.

The need for adding user to "OpenVPN Administrators" group arise only if the user saves the config in their profile. That was not supported by 2.3 so its a new feature and has new requirements.

If you must absolutely add routes using an upscript you have to anyway run the GUI as admin and then interactive service will automatically stay out of the way and openvpn will be started directly by the GUI. This is not recommended for obvious reasons but if you must you may.

If interactive service is buggy -- say fails to add routes or whatever, please file a bug report with config and logs.

[Samuli Seppänen]

Also, if you want to ignore routes pushed by the OpenVPN server, have a look at the new --pull-filter option.

[tschoening]

Replying to selvanair:

In 2.3 it was not possible to store configs in user profile.

Of course it was, I'm doing exactly that and it works for years. One only needs to change the default registry entries to contain e.g. %APPDATA% in the paths for config_dir and log_dir and the GUI uses individual per user dir structures by default. With the benefit that users can't change that easily as well. One doesn't necessarily need admin privileges for successful connections as well, it simply depends on the VPN network.

If you must absolutely add routes using an upscript you have to anyway run the GUI as admin[...]

No I don't, I can simply use "runas" or something comparable in scripts. The benefit is that the GUI doesn't have admin privileges longer than really necessary.

If interactive service is buggy -- say fails to add routes[...]

I don't want it to be able to add routes, that's one of the main points. But thanks for the hint to "--pull-filter", that looks promising to achieve my goal even with the iservice running.

[Selva Nair]

Replying to tschoening:

If interactive service is buggy -- say fails to add routes[...]

I don't want it to be able to add routes, that's one of the main points. But thanks for the hint to "--pull-filter", that looks promising to achieve my goal even with the iservice running.

Ok, let me try again.. Your original usage was dependent on openvpn's failure to add routes when run without admin privileges, and the GUI ignoring such errors. Do not depend on such "mis-features". Most people would have achieved that using route-noexec instead. In 2.4 you can get finer control using --pull-filter. One of these days we may also fix the GUI to not show "successfully connected" after route errors.

By the way version 2.3 is still available.

[tschoening]

Replying to selvanair:

Do not depend on such "mis-features".

That's your point of view, others might have interpreter the old behaviour as a feature for good reasons:

Defensive programming is a form of defensive design intended to ensure the continuing function of a
piece of software under unforeseen circumstances.

​https://en.wikipedia.org/wiki/Defensive_programming