This was better solved by tinc about 20 years ago. All tinc nodes can work as relays (but you can disallow that if you want), it does not rely on a centralized server, and works fine without access to the internet. It is a true mesh. The world would be better served by porting tinc to wireguard and some memory safe language instead of reimplementing parts of its functionality from scratch.
Heh. I have a 30-nodes Tinc network over the internet but some hosts are behind a NAT. It keeps randomly losing routes between these nodes. It even has the infuriating behavior that often it loses the route a few seconds after I successfully established a SSH connection.
Also, traffic seems to be decrypted and re-encrypted by relaying nodes. For end-to-end encryption, you need "ExperimentalProtocol = yes" added by Tinc 1.1, which was never formally released.
I'd like to rewrite something like it in a language I'm familiar with (perhaps based on cjdns' protocol which is better documented than Tinc's) but it's not easy.
I remember using Tinc a lot and really liking it. But as 1gbit+ speeds became more common, tinc struggled to maintain that much throughput on lowend hardware.
I also didn't know that tinc was still around, I might give it a try again just to play around with it and see what's changed.
Wireguard can't punch through NATs or firewalls without third party software like Tailscale. Also I'm pretty sure each peer to peer connection needs to be individually set up in a config file ahead of time
Nebula[0] addresses this and is IMO an improvement over WireGuard. Came out of Slack originally, and it supports peer discovery, NAT hole punching, and some other cool features. Also still uses the Noise Protocol.
In practice, the extra networking features + better first class peer config management baked in is very nice (Nebula’s “lighthouses” are configured with a tool similar to DSNet for Wireguard[1])
People keep saying that, but haven't we learned already that eventually Tailscale gets bought, then priorities change, then they make incompatible changes because they're need to grow, and headscale either can't keep up, or gets pushed away by Tailscale themselves, and we're back to using $TailscaleCompetitor who promises to not do the same thing.
Just don't rely on centralized for-profit entities, rely on stuff produced by non-profits and foundations, that you know isn't gonna screw you over as soon as they need money.
> Just don't rely on centralized for-profit entities, rely on stuff produced by non-profits and foundations, that you know isn't gonna screw you over as soon as they need money
What do you use that fits that philosophy and offers the basic functionality (NAT traversal, Magic DNS, failover relaying) TS provides?
While I agree in spirit, I find this logic around for profit FOSS projects a little backwards sometimes, because it implies forking Tailscale wouldn't save much time.
What makes you think we'd be better off building a competitor to something open source if it has all the features we want now? The reason we don't see open source competitors to big products is not because people are too dumb to try it. It's because it's way, way harder. It makes way more sense to Fork and work from there while we're still getting this momentum from Tailscale.
If you think Headscale is going to have problems keeping up with a private Tailscale, good luck rebuilding Tailscale.
It punches through my NAT just fine without third party software.
It's not as simple to make it reliable as it is with Tailscale, but it works
It doesn't universally work without a helper script and a STUN server, though - you need a suitably "friendly" NAT that has reasonably predictable behaviour with respect to port mapping and/or just one side of each pair behind a NAT.
We have _some_ NAT traversal logic in place, but it's very basic. Tailscale does a much more thorough job on it. It would be cool to add peer relays to innernet but I imagine it's a fair amount of work.
From what I recall, tailscale has their own Wireguard implementation so they have more control over the socket and how things are routed. innernet is just a wrapper around managing wireguard peer lists, and yeah there's a central coordination server which is unfortunate. If the server goes down, you can still connect to peers so thankfully it doesn't bring down your whole network, but you won't be able to learn about new peers or peer endpoints over time until you re-establish connectivity with the coordination server.
> Wireguard can't punch through NATs or firewalls without third party software like Tailscale.
That's a false or incorrect statement, I've been using Wireguard and a cheap VPS (actually free on OCI) for several years, and with a cheap VPS at AWS Lightsail before that. No third party software in use at all. The only thing running on the VPS is Wireguard. The only thing running on my peers is Wireguard.
> Also I'm pretty sure each peer to peer connection needs to be individually set up in a config file ahead of time
That's how I do it but there are tools available to make it easy.
Yes. I’m replying to a comment thread debating WireGuard vs tinc where someone said that WireGuard couldn’t, as if it was a differentiated thing between them.
When networks get used for unethical or criminal workloads, reliability problems aren’t the tooling's fault. A tiny VPS does the job fine for the rest of us.
