security/tinc: 1.0.36 fails to setup meta connection

[andrewhotlab]

I've verified that after commit opnsense/ports@cc4c8af (contained in OPNsense 19.7.4) tincd is not able to connect to other nodes anymore (running either 1.0.35 and 1.0.36), with the following error:

Failed to generate meta key (error:24064064:lib(36):func(100):reason(100))

Downgrading the package back to 1.0.35 solves the problem.

I also managed to get connected a couple of FreeBSD machines running a mix of 1.0.35 and 1.0.36 versions, thus it looks like the issue is not directly related to tinc version.

[andrewhotlab]

Just tested with the latest version of the os-tinc plugin (1.4_5), but the problem persists.

[Nico82x]

We see the same problem and cannot connect to a latest pfSense with 1.0.35.

[andrewhotlab]

I'm not a developer, but I gave a look at tinc source code and I found that this log error is triggered by this code in src/protocol_auth.c:

  if(1 != RAND_bytes((unsigned char *)c->outkey, len)) {
    int err = ERR_get_error();
    logger(LOG_ERR, "Failed to generate meta key (%s)", ERR_error_string(err, NULL));
    return false;
  }

Maybe the cause is related to the RAND_bytes function of OpenSSL? If so, it would be interesting to know if someone running the LibreSSL flavor of OPNsense is experiencing the same issue.

[xpac1985]

@andrewhotlab I run os-tinc 1.4_5, tinc 1.0.36 on OPNsense 19.7.8-amd64, FreeBSD 11.2-RELEASE-p16-HBSD, LibreSSL 3.0.2.

My tinc can connect without issues to the tinc on a Debian box and can be connected to from that Debian box and a Windows laptop.
Hope that helps.

[andrewhotlab]

Thank you @xpac1985, I just switched from OpenSSL to LibreSSL and tinc 1.0.36 started working flawlessly! Thus, guessing that this issue is related to OpenSSL version, I switched back to the OpenSSL flavor, then I reverted it with this command:

opnsense-revert -r 19.7.3 openssl

But tinc 1.0.36 still returned the same error! :(

After that, I focused back to the tinc package, and I found that if I install tinc-1.0.6.txz from the "official" FreeBSD repository it works, while using the same release from the OPNsense pkg repository, the issues comes back again!
So we can argue that the problem is someway related to the method used by OPNsense developers to build/package the flavor of tinc 1.0.36 which is linked to OpenSSL libraries.

[fichtner]

We set official „ssl=openssl“ setting and that‘s it. FreeBSD doesn’t use this setting in their packages. It‘s still odd as LibreSSL uses „ssl=libressl“ and that works ok.

[andrewhotlab]

Thank you Franco, it looks to me there is some other differences between the two packages, for example: the OPNsense's tinc port has a couple of options which FreeBSD port does not have (I guess it derives from HardenedBSD/hardenedbsd-ports). And shared libs requirements look different too.

Here is the output of pkg info tinc for the FreeBSD package:

Name           : tinc
Version        : 1.0.36
Installed on   : Tue Jan  7 16:48:57 2020 CET
Origin         : security/tinc
Architecture   : FreeBSD:11:i386
Prefix         : /usr/local
Categories     : security net-vpn
Licenses       : GPLv3
Maintainer     : dinoex@FreeBSD.org
WWW            : http://www.tinc-vpn.org/
Comment        : Virtual Private Network (VPN) daemon
Shared Libs required:
	liblzo2.so.2
Annotations    :
	FreeBSD_version: 1103000
	cpe            : cpe:2.3:a:tinc-vpn:tinc:1.0.36:::::freebsd11:x86
	repo_type      : binary
Flat size      : 294KiB

And here is the OPNsense's one:

Name           : tinc
Version        : 1.0.36
Installed on   : Tue Jan  7 17:27:12 2020 CET
Origin         : security/tinc
Architecture   : FreeBSD:11:i386
Prefix         : /usr/local
Categories     : security net-vpn
Licenses       : GPLv3
Maintainer     : dinoex@FreeBSD.org
WWW            : http://www.tinc-vpn.org/
Comment        : Virtual Private Network (VPN) daemon
Options        :
	PIE            : on
	RELRO          : on
Shared Libs required:
	liblzo2.so.2
	libcrypto.so.9
Annotations    :
	FreeBSD_version: 1102000
	cpe            : cpe:2.3:a:tinc-vpn:tinc:1.0.36:::::freebsd11:x86
	repo_type      : binary
	repository     : OPNsense
Flat size      : 301KiB

[fichtner]

Doing a trail and error approach here is rather time consuming. PIE and RELRO might be problematic, but they very rarely are once the build went through ok.

[marvinwankersteen]

I also had this problem with OPNsense 19.7.10_1 (amd64/OpenSSL) and tinc 1.0.36.
Then I switched to OPNsense 19.7.10_1 (amd64/LibreSSL) and tinc 1.0.36 is working now. It's also working with OPNsense 20.1 (amd64/LibreSSL).
Thanks @xpac1985

[andrewhotlab]

I just tested the latest build (OPNsense 20.1) which runs OpenSSL 1.1.1d,1 (previous ones ran OpenSSL 1.0.x) and tinc seems working again! :)
Since most of our firewall nodes are managed through tinc tunnels, now I have to get my way to upgrade them from 19.7.3 to 20.1 without losing connectivity during the process... I'll let you know about that ASAP.

[andrewhotlab]

Ok, I can confirm that the issue with OpenSSL is gone with OPNsense 20.1! :)
In order to upgrade from 19.7.3 without breaking your tinc-based management link, you have to follow these steps:

1. lock the tinc package (under System > Firmware > Packages);
2. follow the upgrade procedure until you reach the 19.7.10 release;
3. unlock the tinc package, then upgrade to the latest OPNsense release.

P.S.: I guess that it would have been sufficient to rebuild the package tinc-1.0.36, but "All's well that ends well"! ;)

Thanks to anyone who contributed to this thread!