OpenVPN Windows Client 2.6

[Reiter der OPNsense]

Option 4 only if you can live without community client. Not for me. At least not on my Windows machine, because (at least):
1. No support for multiple, simultaneous connections (occasionally useful for admins).
2. No support for the Wintune driver (as long as OPNsense/FreeBSD does not support OpenVPN Data Channel Offload (DCO)).

And further, if someone wants to password protect their client certificate, they can't use the Connect Client either.

[benyamin]

Option 4 only if you can live without community client. Not for me.  At least not on my Windows machine...

Nor me.  :)

[spetrillo]

What I am seeing is that the Android client connects but my Windows client does not connect. No change to configuration. It seems to be Windows client related?

My Windows client tells me authentication is not right when the Android client connects. I can eliminate password, as I know I am using the same password.

[benyamin]

What I am seeing is that the Android client connects but my Windows client does not connect.

The Android client is openvpn3-based and uses OpenSSL 1.1.1n.

The v2.6+ Windows Community Client uses OpenSSL 3.0 and is incompatible (OPNsense uses OpenSSL 1.1.1t) without one of the workarounds Reiter mentions here. I think #2 is probably the best option for now.

[spetrillo]

Ah, now I see more clearly, thanks for the clarification regarding OpenSSL 3.

Let me sort that out then. So users using the community client have the following options until OPNsense moves to OpenSSL 3. Clarifications and additions are welcome.

1. Stay with client version 2.5.x as long as support is guaranteed (July 2023?).
https://community.openvpn.net/openvpn/wiki/SupportedVersions

2. Use client version 2.6.x, with "providers legacy default" in client config.

3. Choose export type "File only", without possibility to protect the user certificate and private key with a password.

How do I use the providers legacy default, within the context of OPNsense? Do I export the client config and then edit it? Is there an option in OPNsense that supports this?

[Patrick M. Hausen]

Client config is just a text file, so, yes.

[Reiner030]

4. Use the openvpn3-based OpenVPN Connect Clients:

This can I suggest also - still running pfSense but prepared to switch to OPNsense...
We have no problems since nearly one year running the 3.x clients and they offer also 2FA requests (like the Open Source version) and they offer nice autostart/autoconnect service which wasn't availabe in the 2.x versions so far we used them.

[mman2000]

OpenVPN Connect  3 does not work at all. The log say Frame=512/2112/512 mssfix-ctrl=1250 and the app closes without an error on Windows 11 and with a error on Windows 10.

OpenVPN 2.6.6 GUI Community did work after I added "providers legacy default" as a new line config.

[MoonbeamFrame]

I saw something similar recently.

After creating new certificates and exporting the profiles, windows clients reported that there was an unknown parameter in the config file.

Upgrading the windows client to 2.6.5 resolved the issue.

[BISI Sysadmin]

Ah, now I see more clearly, thanks for the clarification regarding OpenSSL 3.

Let me sort that out then. So users using the community client have the following options until OPNsense moves to OpenSSL 3. Clarifications and additions are welcome.

1. Stay with client version 2.5.x as long as support is guaranteed (July 2023?).
https://community.openvpn.net/openvpn/wiki/SupportedVersions

2. Use client version 2.6.x, with "providers legacy default" in client config.

3. Choose export type "File only", without possibility to protect the user certificate and private key with a password.

Can confirm with win10 OpenVPN GUI (community edition) v2.6.0 that appending

Code Select Expand

providers legacy default
to the config file named CLIENT_userID.ovpn
stifled the requirement for an encrypted CLIENT_userID.p12 file.

That is, the dialog box "OpenVPN - Private Key Password (CLIENT_..." did not appear, and the connection was made as it has always been.  screen shot of the offending dialog box attached, just to remove all doubt