Hacker News Reader

Comment by nh2 | Hacker News Reader

This looks like the much older Tinc VPN (https://www.tinc-vpn.org), but in Rust.

It would be great to have a comparison between the two. I've been using Tinc for many years; it's been working quite well, but about once a year I get a segfault (and then it gets restarted). It might be appealing to reduce the chances of that via Rust.

One commonality I found is that both are single-threaded.

I believe I've also heard of the idea of a future version of Tinc potentially using Wireguard as the underlying transport, and building its meshing on top of it. I wonder if that's on the table for VPNCloud as well.

View on HN

Yes I use tinc too. The only problem I have with it is that it's not very performant. For example video streaming through it always causes hiccups.

There's other options I've looked at too: Zerotier (discounted it because it uses cloud-based configuration that's hard to self-host). And Nebula. The latter I still have to try.

I have an added requirement of needing a mobile client too (which tinc now has) so I don't think VPNCloud will work for me :(

> For example video streaming through it always causes hiccups.

This sounds weird to me. either there are enough resources available to sustain the bandwidth requirements or not. this changes with time and usage of the machine but just as it does without tinc. Depending on the hardware used it should not be too hard to stream common videos with something like 20mbit at max...

However, i just wanted to say; maybe you had MTU issues?

It's possible that a future version of tinc could use WireGuard as the data plane, but comes with a few drawbacks. See comment on this very thing: [0]

[0] https://news.ycombinator.com/item?id=19304624

I think there is an inaccuracy in that comment. Double check this: wire guard encapsulates L3 IP packets, not L2 Ethernet frames. This means ARP is handled locally instead of being transmitted over the wire (or the need for an arp responder)

You are right, I wrote it backwards -- WireGuard supports only IP packets, not Ethernet frames while tinc supports both. The example that I gave why Ethernet frames is more useful is correct, just the factual part is reversed.

IMO tinc is really awesome. I've been using it for years to connect my servers, laptops and desktops into a VPN.

Including my RPI (running PiHole in my LAN) into the tinc VPN gave me an easy way to access my home network from anywhere in the world. One of my dedicated servers would automatically take care of routing the traffic and I can just `ssh foo@10.0.0.42` to connect to the RPI and be inside my home network.

IIRC tinc implements some tricks like TCP/UDP hole punching. So best case I end up with an actual p2p connection between my remote device and home network after connecting via tinc.

IIRC ZeroTier borrowed the NAT hole punching code.

Tinc is even more awesome than that -- if you are using it on the same LAN as other nodes on the VPN it will try to make sure traffic between those nodes stays on the same LAN (it has a special broadcast beacon it sends out to find these).

It ALSO supports arbitrary commands for connecting, like ProxyCommand in OpenSSH so you can proxy through any kind of thing manually if you need to.

Tinc is really awesome !

I setup a Wireguard VPN on a Pi and it is very stable, not sure what a P2P VPN would add.

P2P here means it will form a mesh network which itself means every node in the network (your clients) tries to connect to each other as "directly" as they determined possible by some routing algorithm. This is in contrast to a a hub and spoke model for example, where every node will connect to a central hub and communication between nodes need to pass through that hub.

I guess that would be most useful if you don't have any reliable 24/7 internet connection to install a PiVPN server on...

while that would partially help, i think there are better use cases for this type of setup. it is less about discovering endpoint addresses of peers (you could setup a statically configured mesh network too) and more about moving packets efficiently between peers. it can reduce load, latency and bandwidth requirements all while being more resilient to outages... a full mesh network should still work after any other node/peer fails, making only itself unreachable to others. a mesh network could even be able to reroute packets avoiding the failing paths if possible at all. for example your phone could be connected to your home network and your mobile ISP network, so when your home network loses internet connection peers could still route traffic through your phones mobile isp network to other peers in your home network. if you use your VPN to connect home from abroad it is pretty useless though. a mesh network between two computers makes no sense and probably should not be called like that. However, just connecting few sites and some road warriors makes this option quite attractive already.

Reply on news.ycombinator.com