OpenVPN client export (Windows) broken on 16.7

[woo]

Hi OPNsense team,

I've recently installed 16.7 as what is going to be our upcoming VPN concentrator,
and so far the configuration etc all worked really fine - thanks for all that!
Just the OpenVPN client exporter seems to produce invalid archive files.
I've tried all four Windows clients (XP and 6, both 32 and 64 bit), and the resulting exes all produce a window "Extraction Failed - Unsupported Method" on execution.
The clients work fine when I manually extract them with 7zip and then run the files inside, but I can't trust our users to get this right.
How exactly is OPNsense generating these customized installers, and is there any way I can assist with debugging this issue? I'd really like to see this working.

Thanks,
 ~woo

[AdSchellevis]

Hi woo,

The windows installers are old, we should have removed them before 16.7, they are up for removal for one of the next releases.

More information can be found here:

https://github.com/opnsense/core/issues/994

We use viscosity at our office, which has a very easy installation and config import for osx and windows.

Regards,

Ad

[woo]

meh.. at least the OpenVPN client is free and OSS, while Viscosity costs 9$ per client.
Well, as long as the profile export for the OpenVPN client stays, I'm kinda OK with it. Gonna bundle it myself then.

[AdSchellevis]

We're certainly not going to drop the config exports, we just don't want to bootstrap (windows) executable files.
If there will be another free alternative which can accept simple (plain text) configuration data, we might consider adding that at a later time.

[fabian]

You can still use OpenVPN on windows - just download it here: https://openvpn.net/index.php/open-source/downloads.html
It is just that the installers are not shipped anymore which means you have to configure it by yourself.

[fabian]

Here is the diff where it got removed: https://github.com/opnsense/core/commit/35b96a9da653bbae5d3ec4e766a1c79ffb8a3989

[franco]

There are simple problems with it: they are really heavy, nobody maintains them from the OPNsense side, and they aren't used as frequently as expected. I think a plugin could bring them back, but we should make sure to load the binary files on demand, not push and update them in the repository anymore.

[silent_mastodon]

Just as some user feedback, I would prefer a link to the official OpenVPN binaries in the client export section if opnsense isn't going to track and ship them itself. The plugin isn't a bad idea either, but I don't personally consider "just use Viscosity" as an alternative, as it is not Libre software.

As an aside, one of the reasons that I migrated away from the Sophos UTM (which was Astaro before that) software was the ridiculous licensing requirements for "commercial" use of OpenVPN and other features that are themselves libre software.

I will pay for human support; I will not pay for "integration" work that just amounts to slapping a gui on a tool/service, much less $xxxx/yr because you have 50+ total clients...

Maybe that just makes me a jerk, but whatever.

[fabian]

The link is already there: https://github.com/opnsense/core/blob/35b96a9da653bbae5d3ec4e766a1c79ffb8a3989/src/www/vpn_openvpn_export.php#L706

[silent_mastodon]

Okay...I suppose that's true. I'm comfortable enough with opnsense that I generally don't enable the help text, so it would be useful if those links were simply shown by default, especially if the installer is to be removed.

[franco]

I've changed visibility here: https://github.com/opnsense/core/commit/84b04888

FWIW, it was a mistake to embed the binaries into the core.git repo as they are huge and move along with each OpenVPN version. And I think the same problem will apply for plugins.git. Since the files are known they could be downloaded by the new plugin, checksum-verified and then used.

Problematic is that it's off the beaten track even with a full plan on how to do it: coding it cleanly and lightly and then keeping it up to date, best by someone who uses it every single week. It's not a lot but without proper incentive it becomes a side-show that will keep valuable resources away from improving the core system further, let alone testing difficulties.

If you have such a use case, sponsoring or contributing code may be worth it. Otherwise we'll end up in a "as soon as somebody steps up everybody will benefit". I don't believe that's how it works. It should be more along the lines of "I step up and everybody benefits".

And if nothing comes of this, it may be ok too.


Cheers,
Franco