Fail to connect - crypto_alg: SHA*: bad digest for data channel use #221
-
|
Describe the bug 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:
Trying to open session with:
The connection cannot be established, getting errors (in journalctl) such
as seen below:
Expected behavior Version information (please complete the following information):
|
Beta Was this translation helpful? Give feedback.
Replies: 18 comments
-
|
Here's another extract from journalctl log, where the same error is visible:
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@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! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Removed the line |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@schwabe I'm a bit puzzled here ... when did |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
You could rename the option and keep the --enable-legacy-algorithms as hidden compat option. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@schwabe On Debian 12 bookworm -- openvpn v2 is at version 2.6.3 and it works just fine with my config and remote server. |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
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
--enable-legacy-algorithms