tinc is not a secure choice! Have you seen their documentation?

https://www.tinc-vpn.org/documentation/Security.html#Securit...

The default cipher is from 1993 and its creator recommends everyone updates.

32 bit MACs are hilariously tiny.

Home rolled authentication based around RSA.

Their own documentation even states: ”tinc’s security is not as strong as TLS or IPsec."

DO NOT USE tinc!

New deployments should be with 1.1 using its new protocol.

https://www.tinc-vpn.org/documentation-1.1/Simple-Peer_002dt...

That does look a lot better, however:

a) its not supported by the stable release

b) There are no claims about downgrade resistance. The manual specifies the new transport protocol is used if both clients support it and both have changed their configs to enable experimental mode. Can an attacker still force them to connect with legacy mode?

c) Users have to ensure every single config on every client has the correct setting.

d) It still doesn't have the identity hiding features of Wireguard. (Someone observing your network traffic can see which servers you are talking to from the transmitted signatures)

You can disable legacy support by not generating any RSA keys, or by building with DISABLE_LEGACY.

Huh, interesting... I am definitely going to be doing some reading about this one. I wonder what the logic of the project maintainers, whom seem to maintain it, have in keeping with this method of encryption.

Tinc is really cool. I like that you can give it a partial mesh and it will figure out how to create a full mesh from it. A few years ago I was talking to the author, Guus, about using WireGuard as the underlying backhaul in Tinc while preserving the neat Tinc meshing magic. I've since gotten super busy getting the core WireGuard stuff completed, but at some point I'd really like to circle back to Guus and make something like that happen.

That would be awesome. I think WireGuard + Tinc + userland windows + iOS support would be the ultimate VPN solution. Bringing WireGuard back hail to Tinc would bring that one important step closer.

Tinc is also completely userland (as opposed to implemented in a kernel module), and therefore slow enough to be practically unusable unless you're on a very slow connection.

Compare this to something like IPSec, where the userland is typically only used for the control part; once a connection exists, the packets don't leave the kernel, so no context switch needed.

I dont know about tinc, but we've benchmarked ZeroTier which is user land and gotten results close to IPSec. The tun/tap overhead is low. It might matter if you are pumping serious traffic, like encrypting a data center or leased fiber line.

If tinc is crazy slow I suspect it's an implementation issue.

I'm sure you could make a userland tun/tap decently fast, but Tinc isn't it. Back when I was testing it, it was about 40% slower than IPsec.

Our stats were within 5% of IPSec, so that's definitely an implementation issue.

Please don't recommend this insecure garbage.