Windows, client, service: No auto-connect, control via CLI?

[DMahalko]

I have set up the Windows client OpenVPN point-to-point using the default install, running the GUI program as admin, and without the service, and in general it is working, so no need to debug any of that.

However the end-user experience for using OpenVPN is a mess of "click on this, click on that, click on that other thing, then that thing, then that..."

I want to streamline it down to a single icon that doesn't need administrative rights to use.

What I want:
Start OpenVPN Service, but don't auto-connect anything. Wait for commands to connect/disconnect from non-admin user.

Batch file on desktop when clicked, that does not need admin rights to work:
- Send command to OpenVPN service to start a VPN connection
- Wait for success response
[..... do stuff .....]
- Send command to OpenVPN service to stop VPN connection
- Wait for success response
- Exit

The first part regarding loading the OpenVPN service but not doing anything, I believe I understand that. Just don't put any .ovpn config files in the default location and the service won't do anything when it starts.

However, I don't see any documentation of how to send connect and disconnect commands to the service via the command line from a non-admin user, and to read back status from the service of whether the command completed or failed.


(Full planned process:)
Batch file on desktop when clicked, that does not need admin rights to work:
- Send command to OpenVPN service to start a VPN connection
- Wait for success response
- Map network drives for user
- wait for success response
- Start program that needs the VPN connection
- wait for it to close
- Disconnect the network drives
- Wait for success response
- Send command to OpenVPN service to stop VPN connection
- Wait for success response
- Exit

[DMahalko]

After digging some more, apparently control of the service via the management interface does work?

So then, non-admin control should be possible with a tiny program that starts a brief telnet-like session, sends the management commands to open an .opvn config, waits for a response of succesful connect, and quits.

Do I have this right? There is no admin privilege needed to run telnet, or to open a port to localhost.

[DMahalko]

Sorry, I'm new to this game, but um, why was it designed like that?

If the problem is that rogue programs could initiate VPNs on their own via a passwordless management interface, it seems a simple enough matter for there to be a separate non-administrator password that user/client programs need to know in order to connect to the service.

[DMahalko]

Or hey how about this:

* "Only OpenVPN profiles in the Windows \Program Files path can be started and stopped without any management interface authentication."

* "programs without UAC elevation cannot cannot directly specify a path to a profile to use, but can only refer to profiles in \Program Files via a profile name or ID number"

This prevents rogue programs without UAC elevation from attempting to open a rogue VPN connection, since they cannot modify the OVPN profiles in the \Program Files path.