Autoconnect and control through GUI are mutually exclusive. (Windows.)

[JN456#]

When on Windows I use the GUI to start OpenVPN at startup, then

(1) the interface starts but the VPN has to be enabled via clicking in menus.

Now, I can get the vpn to go up by creating a scheduled task that does this, on boot:

"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect "<my conf file>.ovpn"

Yet, if I do that, then, while the VPN connects at start, then

(2a) the GUI does not show the VPN as on

and, moreover,

(2b) if I tell the GUI to 'connect', it generates an error about not being able to connect to the management interface. Or at least that happens after I recently updated OpenVPN.

Might I add the following? It was awkward enough having to use the task scheduler workaround - one should not have to resort to the (in itself fragile, and also ungainly) task scheduler; and, now, even that workaround does not work properly.

PS: I may have the version numbers - below - wrong. For, there's one version number for the GUI, I think, and another for the backend . . Anyhow, my OpenVPN log reports this: OpenVPN 2.4.5 x86_64-w64-mingw32; and I'm on Windows 8.1 Pro x64.

[tct]

CC

Also, you cannot start the GUI at boot .. start it at user login.

[Gert Döring]

For "autostart things at boot", there's the OpenVPN service.

Arguably it is not documented very well, and the GUI won't show (I think) sessions started by the service, but that's what we have for this task.

[Selva Nair]

OpenVPN GUI cannot do this [*]. I suggest to use OpenVPNService (not enabled by default) to start the connection at boot and then use OpenVPN-MI-GUI to control it (see ​http://openvpn-mi-gui.inside-security.de/ for a howto). Its probably not actively maintained. There are some caveates like the management interface is left open so anyone with physical access to the machine could access it etc.

I want to make OpenVPN-GUI control such prestarted instances --- we do have a version we use locally, but outdated now and no free time to revive it.

[*] There are some hacks like use an auto-logon task that logs in as user, starts the GUI, and locks the screen etc., but I'd avoid it.

[Gert Döring]

@Selva, do we have a complete documentation on the OpenVPNService somewhere? Like, where exactly does it look for config files, how do they need to be named (.ovpn? .conf? "does not matter, all files in that directory"?)

I tried to find something and came up empty - lots of google hits for "how to turn on a service", but nothing about "... and this is what will happen afterwards". Meh.

[Selva Nair]

No, I don't have any docs on the legacy service or its .NET replacement.

Its settings are determined by the following registry keys:
exe_path -- which executable to start
config_ext -- extension of config files
config_dir -- where configs live (this directory and its immediate subdirectories are scanned)

-- this also becomes the working directory for openvpn.exe

log_dir -- where to create log files
log_append -- append to log or not
priority -- for openvpn.exe process

[Gert Döring]

I think this is something where 2.6 will bring nice improvements, with the GUI being able to control service-controlled configs as well. Right?

[Selva Nair]

Yes :) Keep connection profiles (config files) that should be started at boot in confog-auto folder and have OpenVPNService running as before. Then when GUI is started it will show those connections under a sub-menu: Persistent connections.

As always, the GUI requires uniquely named config files, so if there is a one with teh same name in global or user config folder it will mask the one in config-auto. Always use unique config file names.

[Gert Döring]

Very nice :-) - closing this, with milestone set to 2.6

Happy Christmas to you all!

[Gert Döring]

Maybe I should then actually close the ticket, not just claim so :-)