Hi, I had to redo all my customized OpenVPN settings on my Synology NAS, as I have lost the possibility to sign new client certificates with the original CA I used when I set up the environment in 2016. Now when I am doing all things from "scratch" again, I don't seem to get past the tls-auth part of the connection, if I understand correctly. The end part of the logfile (with verb 11) is: Thu Feb 3 02:14:04 2022 us=805713 Diffie-Hellman initialized with 4096 bit key Thu Feb 3 02:14:04 2022 us=807197 Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found Thu Feb 3 02:14:04 2022 us=807269 Exiting due to fatal error I have created a new PKI with all the needed certs and keys using XCA on Windows, and generated the 'ta.key' on the Synology NAS itself (if that would even matter). I also exported the client cert/key to a PKCS#12 file that I imported to Windows credential storage in the same way I had it before. The only thing that I am doing differently on purpose is that I increased the dh key to 4096 bits from 2048 bits that I used before. The (pre-installed) openvpn version on the Synology NAS is somewhat old (?): Thu Feb 3 02:14:04 2022 us=702225 OpenVPN 2.3.11 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Sep 22 2021 Thu Feb 3 02:14:04 2022 us=702271 library versions: OpenSSL 1.0.2u-fips 20 Dec 2019, LZO 2.09 What can be wrong? Where to start looking? I checked the source code to get an understand what part is throwing the error but could not really understand how the function is called: [code]static const mbedtls_md_info_t * md_get(const char *digest) { const mbedtls_md_info_t *md = NULL; ASSERT(digest); md = mbedtls_md_info_from_string(digest); if (!md) { msg(M_FATAL, "Message hash algorithm '%s' not found", digest); } if (mbedtls_md_get_size(md) > MAX_HMAC_KEY_LENGTH) { msg(M_FATAL, "Message hash algorithm '%s' uses a default hash size (%d bytes) which is larger than " PACKAGE_NAME "'s current maximum hash size (%d bytes)", digest, mbedtls_md_get_size(md), MAX_HMAC_KEY_LENGTH); } return md; } bool md_valid(const char *digest) { const mbedtls_md_info_t *md = mbedtls_md_info_from_string(digest); return md != NULL; }[/code] Shall I interpret the error that openvpn can't access the file for some reason? I made sure to set root as owner for the file and folder and access rights are '400', i.e. the same as for 'dh4096.pem' that is in the same folder. Part of openvpn config: [code] dh /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/dh4096.pem ca /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/XXXXXXXXXXX_CA.crt cert /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.crt key /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.key tls-auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0 [/code] The ta.key is added inline in the 'client.ovpn' configuration file. I plan to post more details about server and client config files as soon as I have time.

Full server config: [oconf=Server Config] push "route 192.168.111.0 255.255.255.0" push "route 10.8.0.0 255.255.255.0" # Use routing instead of bridging dev tun server 10.8.0.0 255.255.255.0 management 127.0.0.1 1195 # The backup task will include this location dh /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/dh4096.pem ca /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/XXXXXXXXXX_CA.crt cert /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.crt key /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.key tls-auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0 max-clients 5 #comp-lzo cipher AES-256-CBC data-ciphers AES-256-CBC persist-tun persist-key # verb 3 # Verbose logging for debug verb 11 # Don't forget logrotate script log-append /var/log/openvpn.log keepalive 10 60 reneg-sec 0 plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf # KEEP THIS DISABLED #client-cert-not-required username-as-common-name duplicate-cn status /tmp/ovpn_status_2_result 30 status-version 2 proto udp6 port 1194 [/oconf] Client ovpn file: [oconf=Client ovpn file] client dev tun proto udp remote ..com 1194 resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server # WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.

[quote=gartom post_id=104709 time=1643889139 user_id=56111] Thu Feb 3 02:14:04 2022 us=807197 Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found [/quote]This error message suggest that you have the following in your server config [code]auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0[/code]Note: 'tls-' is missing. (I presume this key is inlined in your client).

[quote=TinCanTech post_id=104713 time=1643907130 user_id=37053] This error message suggest that you have the following in your server config [code]auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0[/code]Note: 'tls-' is missing. (I presume this key is inlined in your client). [/quote] Thanks for the suggestion. Unfortunately that does not seem to be the issue as shown in my 2nd post above. You are correct, the key is inlined in the client config (also shown in 2nd post above).

[quote=gartom post_id=104709 time=1643889139 user_id=56111] The (pre-installed) openvpn version on the Synology NAS is somewhat old (?): Thu Feb 3 02:14:04 2022 us=702225 [b]OpenVPN 2.3.11[/b] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] [b]built on Sep 22 2021[/b] Thu Feb 3 02:14:04 2022 us=702271 library versions: [b]OpenSSL 1.0.2u-fips 20 Dec 2019[/b], LZO 2.09 [/quote]Actually, the openvpn version is old but it was built recently. Anyway, the error message is due to not being able to find a HASH algorithm and nothing to do with either --tls-auth or a missing file. I have no idea how your NAS works, so you may have to report this to your NAS vendor.

Ok, thanks for helping. What I don't understand is why it stopped working when I replaced the keys and certificates. How can the inability to find a HASH algorithm be related to that change?

Sorry, your OpenVPN version is not supported by us any longer: https://community.openvpn.net/openvpn/wiki/SupportedVersions The version that you have has been built in 2019 and then you updated your NAS and installed it. I would check to see if there is an up to date version of openvpn available and if not then complain to your vendor. Considering how easy it is to keep openvpn upto date on their devices, I must conclude that they are all ..

Yes, I understand that it is an old version of openvpn on the NAS, but what I don't understand is why it stopped working with my new configuration.

Try setting it up again. If it happens again then it's possibly a bug in the NAS GUI.

Thanks for supporting. I am not using the NAS OpenVPN GUI at all as it does not enable enough security to be set up. Instead, It recognizes that I define my own configuration file and the GUI can be used for enabling/disabling OpenVPN. The only other change I made (except updating certificates) was to update dh to 4096 bits instead of 2048 bits. I will try to go back to 2048 to see if that makes a change. If not, I will try to set up OpenVPN in my router instead (that I just found out have the possibility as well).

The OpenVPN settings in my router did not provide the security options that I want, so I am still trying to get the OpenVPN configuration to work on my NAS (despite the old OpenVPN server version). In an effort to start over from the beginning, I tried to restore everything to the original settings with my old CA configuration. The strange thing is that I now get the same error message with the [i]old[/i] configuration. Any ideas around what can be the issue? Log file entry with original CA setup: [code] Wed Feb 2 18:46:37 2022 Diffie-Hellman initialized with 2048 bit key Wed Feb 2 18:46:37 2022 Control Channel Authentication: using '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' as a OpenVPN static key file Wed Feb 2 18:46:37 2022 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed Feb 2 18:46:37 2022 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication [/code] First log file entry after changing to new CA setup: [code] Wed Feb 2 23:03:22 2022 Diffie-Hellman initialized with 4096 bit key Wed Feb 2 23:03:22 2022 Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found Wed Feb 2 23:03:22 2022 Exiting due to fatal error [/code] Log file entry when reverting to original CA setup: [code] Sat Feb 12 11:43:20 2022 Diffie-Hellman initialized with 2048 bit key Sat Feb 12 11:43:20 2022 Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found Sat Feb 12 11:43:20 2022 Exiting due to fatal error [/code] I guess the old saying "don't fix it if it ain't broke" applies... :-) (but in this case it was actually my only option to change CA setup to be able to add users as I lost the ability to add users in my old CA config)

Message hash algorithm '/<path>/ta.key' not found

TinCanTech

How did you fix:

TinCanTech wrote
gartom wrote Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found
The command you have in your config is incorrect.

that :roll:

gartom

TinCanTech wrote How did you fix:
TinCanTech wrote
gartom wrote Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found
The command you have in your config is incorrect.
that :roll:

It was not super clear for me what the fix for this actually was. I tried to change one thing at a time but the actual error message was not consistent when I started over from scratch. One thing that seems to have impact is the setting "auth SHA256". When this option is commented out, the server log file shows this at server startup:

Sun Feb 13 10:25:47 2022 Diffie-Hellman initialized with 4096 bit key
Sun Feb 13 10:25:47 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Feb 13 10:25:47 2022 TUN/TAP device tun0 opened

When the option "auth SHA256" is included in the server config file, the server log file looks like this:

Sun Feb 13 10:31:50 2022 Diffie-Hellman initialized with 4096 bit key
Sun Feb 13 10:31:50 2022 Control Channel Authentication: using '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' as a OpenVPN static key file
Sun Feb 13 10:31:50 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Feb 13 10:31:50 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Feb 13 10:31:50 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Feb 13 10:31:50 2022 TUN/TAP device tun0 opened

BTW, any idea why I need to specify the route to the local LAN in the client config, i.e. why pushing the route does not seem to work?

Edit: I just realized that i changed the "verb" level when starting from scratch. Maybe the error is hidden in the log above. I may test that some day.

TinCanTech

gartom wrote It was not super clear for me what the fix for this actually was. I tried to change one thing at a time but the actual error message was not consistent when I started over from scratch. One thing that seems to have impact is the setting "auth SHA256".

Just remove --auth from your server and client.

The default for --auth is SHA1, which is fully suitable for how openvpn uses it.

gartom wrote any idea why I need to specify the route to the local LAN in the client config, i.e. why pushing the route does not seem to work?

If pushing routes did not work then openvpn would be about a useful as a chocolate teapot.

Check your logs at --verb 4 for errors.

gartom

TinCanTech wrote Just remove --auth from your server and client.

The default for --auth is SHA1, which is fully suitable for how openvpn uses it.

OK, I'll try that

TinCanTech wrote If pushing routes did not work then openvpn would be about a useful as a chocolate teapot.

😃
I understand your point. Nevertheless, I don't seem to get the routing to work by pushing the network setup from the server. I guess I don't know enough around network routing to understand how to do it...

TinCanTech

TinCanTech wrote Check your logs at --verb 4 for errors

If you post your logs here, sanitize them first.

gartom

TinCanTech wrote
TinCanTech wrote Check your logs at --verb 4 for errors
If you post your logs here, sanitize them first.

When it comes to the original issue for this thread, the "Message hash algorithm...", I don't have that issue any longer. I don't think I will spend more time to understand what actually was wrong as I have a working setup now.

I have createad a separate thread in order to sort out the config setup to have remote access to my home LAN without "hard coding" routing on client side.

« Previous Page