This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Fail to connect - crypto_alg: SHA*: bad digest for data channel use #220
Comments
|
Here's another extract from journalctl log, where the same error is visible:
|
|
Can you please increase the log levels to For the log service: The client config depends on how you start it. If you have used the Otherwise you need to modify the While the Also, please use the |
|
@dsommers thanks for the instructions, i did exactly as advised. here are the log lines obtained with After this it just repeats all over, and hangs in the terminal, have to kill the process. Thanks for the help! |
|
Alright, this gives much better hints. So the issue here is related to the SSL/TLS configuration. This smells like an inconsistency between the OpenVPN server configuration and your local configuration profile. Can you try to comment out the |
|
Well... this is the VPN for a company I work for... While it works fine with OpenVPN v2, I can't really tell them to change the config for me, when nobody else has issues with it. You can see from the log they are running a WatchGuard Fireware VPN server. I will try to comment that line out in the client config and report back. |
|
Removed the line |
|
Hmmm ... alright, that begins to smell like a bug in the OpenVPN 3 Core library. Would you be willing to share (feel free to use mail) your configuration file? This would need some more testing of the configuration profile. Keying material and |
dsommers
changed the title
dsommers
changed the title
|
Here's one clue that I think will help you: the last Debian package of Until then, here is my Appreciate your work and the help! |
|
You probably do not have the enableNonPreferredDCAlgorithms (not sure how openvpn3-linux exactly calls it) option enabled. Without that option openvpn3 will refuse CBC and SHA as data channel ciphers. Looks like the option is called |
|
@schwabe I'm a bit puzzled here ... when did |
|
OpenVPN 3 Linux is the only OpenVPN software that calls them legacy algorithms. The other software and internally we just call them non-preferred ( We also have "true" legacy algorithms that include MD5, DES, 3DES and BF-CBC that are enabled by |
|
Duh! Right, I see the error here now. Alright, yeah, I see that OpenVPN 3 Linux classifies all non-AEAD as legacy. In hindsight, that might not have been the right decisions in commit ff944ec. But it's probably not something which should be changed too hastily - to ensure we don't weaken already configured installs. |
|
You could rename the option and keep the --enable-legacy-algorithms as hidden compat option. |
|
Okay, this knowledge is gold, but it is hidden for the user because the error message says nothing that helps the user. I've removed and re-added the connection, then enabled the "legacy" algorithms:
As a user and a developer, I would like to suggest two things, you do what you think is best of course:
Thank you for your time, my issue is now resolved, but there might be other (Linux) users out there missing out on this fine software. |
|
Unless you are using very old OpenVPN 2 version older than 2.4.0, you do not need that option. All 2.4.0+ OpenVPN 2.x versions will try to negotiate to AES-GCM by default. But yeah we can probably extend the error message that this algorithm might be disabled. |
|
@schwabe On Debian 12 bookworm -- openvpn v2 is at version 2.6.3 and it works just fine with my config and remote server. |
|
@sid-the-sloth unless you manually fiddle with data-ciphers on OpenPVN 2.6.x will also not support AES-CBC on the data channel as well. You might wnat to post your openvpn 2.x log to double check that. Also the log you have in #220 (comment) does not show the server pushing a |
|
Yeah, I agree that this is not a good user experience. And we need to look into how to improve that. However, if an OpenVPN 2.4 or 2.5 server is deployed with When the OpenVPN Data Channel Offload (DCO, The option should have been called something like This is not something which will come too soon, but something to consider for a future release. JFTR, since this turned out to not be a bug - but a configuration issue; I'll convert this discussion into a GH discussion instead of GH issue. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Describe the bug
OpenVPN3 gets stuck in opening a session.
Running openvpn3, on Debian 12 bookworm, installed from the repo as described in https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux.
To Reproduce
Imported connection with:
$ openvpn3 config-import --config /etc/openvpn/my-connection.ovpn --persistentTrying to open session with:
$ openvpn3 session-start --config /etc/openvpn/my-connection.ovpnThe connection cannot be established, getting errors (in journalctl) such
g_object_unref: assertion 'G_IS_OBJECT (object)' failedas seen below:
# journalctl --since today -u dbus | less +GExpected behavior
I expect it to connect. Same connection file works with OpenVPN2 client.
Version information (please complete the following information):
The text was updated successfully, but these errors were encountered: