I am manually managing a Mesh network but as the number of nodes get larger copying config entries is getting a tad tedious. And its sending of 'you are probably doing it wrong' signals. How do you/others manage a WG only (no thirdparty) mesh network? Have you written any config scripts (bash/Powershell/python) to add entries to some master config?

We use a Python Fabric script to automatically generate the conf and deploy it to each server when a new server, or client user, is added to the wireguard network.

The master config is essentially the Fabric script. It contains each servers IP, public key, etc. We even do server-server pre-shared keys.

Tailscale uses Wireguard, but offers so much more on top. I used to think the same, but I think I was mixing it up with Zerotier; had a play with it and now think it's pretty great.

For example, you can set ACL rules for which devices can access which others (or the internet, if you have explicit exit nodes) - it's using Wireguard for networking, but you can't do that with (just) Wireguard, it's not just 'make Wireguard easier to set up', as you said that doesn't really need doing.

I see. I use firewalls to control which devices can access which others. To each their own.

This is a chud "Dropbox is just rsync" attitude.

There's value to some to having networking config centralised like that. It allows things like auto adding certain clients to certain rules/groups automatically.

Not spending time cycling through each server to poke iptables.

My computers are behind firewalls and I need Tailscale to do the NAT punching. I don't see another tool that does the job as well as Tailscale.

The hub and spoke configuration bypasses firewalls and NAT, which WG can do natively.

Though doing this "well" is subjective, so I can understand someone preferring Tailscale because it's easier to use.

not familiar with wireguard per se, but afaik it's using udp-packets which get translated/mapped just fine by any NAT implementation. nothing in need of punching imho.

if your access concentrator (server) is behind a nat, you'll need a port-forwarding from the outside but that's rare.

Tailscale builds a mesh, where the participants can communicated directly, so it's common for all nodes to be behind a FW that does NAT. There is a very interesting blog post from tailscale about all the trickery they pull to reliably deal with NAT: https://tailscale.com/blog/how-nat-traversal-works/

i stand corrected. thanks!

> I just don't trust it that it's not phoning home or leaking data.

This is just irrational. The client is open source. You can build it and run it from source.

"This is just irrational."

The sentence following the one about phoning home/leaking data explains the rationale. The computer user prefers simpler software. It's great that it's possible to compile a client provided by Tailscale from source, but this does not address the complexity issue.^1

Is the Tailscale control server open source. Why not. What's the rationale for that.

There's no problem IMHO with arguing Tailscale can make its own decisions and do whatever it wants. However the same argument must apply to the computer user. He can make his own decisions and do whatever he wants.

1. Wireguard was allegedly written at least in part because OpenVPN, another open source option, was excessively complex. Tailscale relies on Wireguard. If avoiding complexity was irrational, and people behaved rationally, then perhaps Wireguard would not have been written and Tailscale would not exist.

Avoiding complexity where possible sounds rational to me.

Headscale is the open source central server for tailscale - it implements the same protocols etc and when you use tailscale client with it it only connects to the login server you gave it.

The official reason for why there's no official open source server is that headscale got there first, before tailscale team could (their words, not mine) the unholy mess that was the production server into something people could compile and deploy themselves.

> This is just irrational. The client is open source. You can build it and run it from source.

Something I don’t understand is if the client is open source, why is it not in the fedora repos? Why do I need to add a new repo to dnf?

Unless you want to deal with Fedora's release cycle, you're not going to push software through their repos. This isn't a Tailscale thing, this is a "just about everyone" thing.

>Something I don’t understand is if the client is open source, why is it not in the fedora repos? Why do I need to add a new repo to dnf?

Just because one group of people haven't done something doesn't mean it doesn't qualify. To show the exact opposite, look at OpenBSD. They have included Wireguard into their kernel.

Fedora not including Wireguard may be political, personal, or none-of-the-above. Maybe somebody hasn't offered to take on that task/responsibility.

I'm not sure if GP was referring to a wireguard package or a tailscale one. But to complete the picture, there's also a tailscale package in OpenBSD's repos.

To be fair, I'm not familiar enough with Tailscale to claim that it does any of these things. I know that parts of it aren't OSS, but can be replaced with a 3rd-party alternative that is.

Even so, software being open source doesn't make it inherently trustworthy. I would have to look into it, or trust that the community has done due diligence. My default stance towards all software is to not trust it, which can change as I get familiar with the project.

And then there's the complexity. I prefer using simpler tools if they accomplish what I need. It's less surface area for me to trust, and less chances for bugs. Not that Wireguard is necessarily simple, but since Tailscale is a wrapper around it with additional features, none of which I need, I'm perfectly fine using WG directly.