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
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])
[0] https://github.com/slackhq/nebula [1] https://github.com/naggie/dsnet
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 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.
What do you use that fits that philosophy and offers the basic functionality (NAT traversal, Magic DNS, failover relaying) TS provides?
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.
But all that I've seen are still centralized/federated
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.
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.
So yes it is a differentiated thing between wireguard and tinc, as you phrased it in your other comment.
tinc: One public node, thousands of private nodes, with NAT punching. That's fine and typical in my experience.
Hundreds of TB over what timeframe? It does seem like quite a bit of data.