Tailscale is needed if you require site to site connectivity via something like Starlink.
I may be putting my ignorance on display here, but I recently completed a site-to-site network between two farms in rural America, no other ISP can serve these farms, and they needed to communicate cow data between the different farms. Tailscale did the majority of the heavy lifting thankfully, and we were able to get them all sorted out.
I could not get Wireguard to work, and that may be down to my limitations in networking, but I was sucessful with tailscale, so make of that as you will.
Lack of Wireguard docs/tutorials is unfortunate, because I'm in the same boat. I'm using Tailscale now because I just don't know enough about linux networking to figure out why my packets aren't going where they should. I suspect it's a very simple config error, but I don't know how to debug or where to look. I like Tailscale, but I'd much rather use real wireguard and eliminate a dependency on tailscale, but I can't find guides/tutorials/etc.
If anyone knows of a Wireguard walk-through to bridge two separate LANs together, I'd love to see it
The thing about Wireguard is that it's very simple and minimal. It does just one thing, and that is - establishes a layer 3 tunnel for sending IP packets between local machine and some other peers. It doesn't do mesh, it doesn't do routing (it just knows the IPs of its direct peers and that's all it does), it doesn't do bridging - all this stuff is done by other pieces such as Linux kernel, but not Wireguard itself.
> Wireguard walk-through to bridge two separate LANs
Same or different subnets for those LANs? If they're different and non-intersecting, and if you don't need cross-LAN broadcast or multicast, the simplest option is to establish a Wireguard connection between those LAN's default gateway routers (assuming you can do this), and on each of those routers set up a route that sends opposite LAN's traffic to the opposite gateway (in case of iproute2: `ip route add my.other.lan.subnet/mask via my.other.lan.gw`, how to make this persistent depends on your distro). Then, on each gateway, allow packet forwarding between Wireguard and LAN interfaces (with e.g. iptables or nftables or whatever you use there).
If you can't run Wireguard on gateways, the overall principle holds, but you'll need to distribute routes to your respective LANs via Wireguard-running routers through DHCP or whatever you use for routing on your LANs (e.g. OSPF).
And if your LANs both have the same subnet, or if you need multicast, things get significantly trickier (plus, there's inevitable question of what should happen if two machines on different LANs have the same IP). You'll probably need to run something like L2TP or GRETAP (or something else that can encapsulate you layer 2) over Wireguard.
Or maybe just use OpenVPN in TAP mode (if you want all stuff independent of any third parties) or Tailscale (because it already works).
A few years ago I decided to get my own ASN. I have a couple of VPSes running BGP with my upstreams at geographically diverse but relatively close locations (10 to 15 ms ping.) I have Wireguard tunnels between the VPSes and also from each VPS to my home network, forming a mesh w/OSPF. Originally, I was only injecting default routes into OSPF so I'd have basic redundancy if things failed, treating one provider as a secondary, not caring much about outgoing load balancing. I recently switched to internal BGP though, and am doing some load balancing w/partial tables. Pretty cool stuff. I used BIRD for OSPF and BGP.
Thanks! It was fun setting it up! I was originally a network engineer working for early ISPs, before moving on to more of a software focus. I was lucky enough to register my own IPv4 block back in the 90's.
Of course. Picking a tool is always a matter of what one already knows. If you've already learned Tailscale and it fits all your requirements - that means you go with it, unless you have some reasons not to do it (which is rare).
And Tailscale surely has one benefit here - it's one single product, with essentially no variations, so it's (I presume, I haven't ever used Tailscale myself - never needed it) easy to write a step-by-step instructions for. Generic "GNU/Linux software router with Wireguard" is an extremely vague target that impossible to give instructions for, unless you spend a lot of time describing the problem in finer detail.
> I like Tailscale, but I'd much rather use real wireguard and eliminate a dependency on tailscale, but I can't find guides/tutorials/etc.
You could use Headscale, which is an open-source/self-hosted reimplementation of Tailscale control plane, so you can eat your cake and have it too.
Curious to know, why does distrust towards Tailscale come up so often around here? They seem extremely transparent about their strategy and incentives.
> Curious to know, why does distrust towards Tailscale come up so often around here?
I have a guess - I suspect it's because in the domain it addresses, attitudes are towards self-reliance, privacy and autonomy.
If someone uses Tailscale in some cloudy (aka all someone else's computers) setup, they probably don't bother. They already shift trust and rely on other people.
But Tailscale is infrequently used to manage own devices, which is why it clashes with self-reliance attitudes. If you run your own private hardware and networks, all or many of those in your own castle, it may bug you to introduce (or I'd rather say trust) a third party unless you're forced to. Not because it's not trustworthy, but because of the self-reliance attitude and desire to have full control over what you think of your own systems.
Sure, you're forced to trust your electricity provider (but you have an UPS) or network uplink (and even then you make security precaution), but trust in Tailscale is kind of optional (it's not irreplaceable), and not everyone feel like they want it.
Pretty much the same why a lot of people frown upon IoT stuff, even if it's from rare vendors who go extra mile to make things reliable - because of the hypothetical "but what if?" and feeling that you're losing the control here.
In my personal case, It's a mix of self-reliance and a committment to open source that makes me want to have an alternative to tailscale (although I use Tailscale for company stuff and that was my call). On top of that, for personal stuff I just have very simple networking needs, and I don't want to add yet another service (a headscale instance) I have to maintain and keep running, and in the case of headscale it's particularly important because I might lose my network if it goes down! For that reason, a tailscale-only solution that is all client and no server is attractive.
Side note: the existence of headscale is the reason why I decided to pay Tailscale for company stuff. Had the clients not been open source, and there had not been a compatible FOSS server implementation, I would have spent the time/money slinging wireguard or using some other solution. I love Tailscale for opening the clients and allowing/even supporting headscale.
Create a wireguard interface on each end, add the keys to them, open up the allow list for each subnet, assign a IP from a /30 (or /31) subnet on each end, set static routes to point to other end or use a dynamic routing protocol.
There are tools to automate this like wg-quick and systemd-networkd, depending on your preference.
On my synology ds418j Tailscale was faster than WireGuard over the same interface. WireGuard used 30 to 50 percent more cpu.
Was strange, but not a real problem. Just an anecdote.
I live in Iowa and the problem we have is nobody markets their stuff very well. We have a fixed wireless provider that, looking at their website, looks like they are just a cell tower climbing service. But they also lease space on just about every tall structure in the region (grain elevators etc) and can connect anything to anything. We got to them because we asked a WISP if they would do a private backhaul and the guy referred us over to somebody's cell phone. I guess they are happy to just have word of mouth and only have the website to reel in bonus work with the out of town telcos.
Never had worse than next day service on any lightning strike event from this guy, which is more than I can say for mediacom or lumen lol.
> but I recently completed a site-to-site network between two farms in rural America, no other ISP can serve these farms, and they needed to communicate cow data between the different farms.
This may be verging on off-topic, but it's too good an opportunity to not deliver this very fitting reminder: in 2018 Anja Karliczek, then-Minister of Science of Germany, made headlines for the quote "5G nicht an jeder Milchkanne notwendig" [1] ("you don't need 5G on every milk jug") aka the rural areas (that had been left behind even with prior mobile phone/data and even landline DSL deployments) didn't have enough need for fast Internet access.
So, to answer her question, what exactly are these farms doing that they need to exchange cow metrics? Tracking of milk production per cow?
That's a fair question, I assume it's milk production tracking, health status of each cow, etc. That's a bit out of my wheel house. This was previously 2 different farms owned by two different families, but after 2020 a lot of these places sold off their farms due to financial hardships. I lost a ton of clientele over the course of 2020 due to mega farms buying them out for pennies on the dollar.
The beauty of Starlink is while they use a cgnat for ipv4 they assign you fully routable ipv6 addresses. So Tailscale has no problem making that bridge, it just uses ipv6.
Tailscale is free for 3 users and up to 100 devices, so it's a fine solution vs running your own VM for hole punching. Consider your time value. You can even pay for Mullvad exit node access for devices in your net and configure the coordination layer accordingly.
Free was the price, client didn't want to pony up for any additional monthly fees. In the past I would've included it into my monthly "on call fee" but now I value my free time too much to the point where clients aren't interested in having me as an emergency line.
I'm sure I'm leaving money on the table, but I'm a one man show, and I have trust issues with relying on others, so here we are.
> Tailscale is needed if you require site to site connectivity via something like Starlink.
You should be able setup a Wireguard instance on some cloud provider like AWS, then setup each Starlink endpoint to point to that public cloud IP. I have done this for some time on a cheap $5/mo Digital Ocean droplet to work around my old ISP giving me a RFC to 1918 addresses.
Also don’t forget that if you have a line of sight between the two farms you can use the unlicensed 60Ghz spectrum and grab some cheap Ubiquiti millimeter wave gear.
I may be putting my ignorance on display here, but I recently completed a site-to-site network between two farms in rural America, no other ISP can serve these farms, and they needed to communicate cow data between the different farms. Tailscale did the majority of the heavy lifting thankfully, and we were able to get them all sorted out.
I could not get Wireguard to work, and that may be down to my limitations in networking, but I was sucessful with tailscale, so make of that as you will.