> If users are comfortable running non-open operating systems or employers are comfortable with their employees running non-open operating systems, they should likewise be comfortable with Tailscale not being open on those platforms.
https://github.com/tailscale/tailscale/issues/13717
A solution like this can't really be relied in situations of limited connectivity and availability, even if technically it beats most of the competition. Don't ever forget it's just a business. Support free alternatives if you can, even if they underperform by some measures.
I value _control_ more than I do performance
Better performance is, IMHO, not a reason to sacrifice _control_, but that's just me
If users have control, i.e., can compile from source, then in theory performance improvement is possible through DIY or work of others. However performance is not always the only important issue. Today's commercial software tends to be rushed, lower quality, bloated. Releasing work-in-progress software that requires constant remotely-installed "updates" in place of a thoroughly-tested final product is a norm
Without control, if performance, _or anything else about the software_, is unsatisfactory, then there is nothing users can do
Not a single port forwarded, I just set my router up as peer node.
I guess the difference is the fact that the intermediary server doesn't need a port open (as standard nat punching will work)? Or are there other big differences?
We also have plenty of customers running in restrictive NAT environments (AWS being a common example), where direct WireGuard tunnels just aren’t always possible. In those cases, something like Peer Relays is essential for Tailscale to perform the way larger deployments expect.
So yes, it improves latency and UX for self-hosters, but it also helps us support more complex production environments without requiring folks to run and manage custom DERP infrastructure.
Also, sometimes it seems like I get rate limited on Tailscale. Has anyone had that experience? This usually happens with multiple SSH connections at the same time.
On the other hand, I do wonder about zerotier. before tailscale we used zerotier for a few years, and during the first 3-4 years we paid nothing because as far as I can recall there was nothing extra that we needed that paying would've gotten us. Eventually we did upgrade to add more users, and it cost something like $5/mo (total, not per user).
Tailscale in a company/developer env seems awesome when you know what you are doing and (potentially) terrifying otherwise.
Does someone set up detailed ACLs for what's allowed? How well does that work?
Isn't that exactly what tailscale is built to accommodate - zero trust?
You set up ACLs and other permissions to not allow people to do more than the damage you can tolerate.
Unless one considers the meta data such as src/dest IP are visible to Tailscale sw.
Right?
The concept is separate from 'zero config' (https://en.wikipedia.org/wiki/Zero-configuration_networking), which Tailscale's low technical barrier to entry evokes.
As I understand it if everything is working properly you should end up with a peer to peer wireguard connection after initial connection using tailscales infrastructure. ie, there should be nothing to rate limit. There are exceptions depending on your network environment where you need one of the relays noted in this post.
As for opensource alternatives:
https://github.com/juanfont/headscale can replace tailscales initial coordination servers
and https://netbird.io/ seemed to be a rapidly developing full stack alternative.
As long as these economics continue to hold they'd be stupid to discontinue the free tier.
This is one the the most fundamental components of SaaS accounting, it’s absolutely not a “wild guess”.
Welcome to economics.
Salesforce, stay away from it!
> Pennarun confirmed the company had been approached by potential acquirers, but told BetaKit that the company intends to grow as a private company and work towards an initial public offering (IPO).
> “Tailscale intends to remain independent and we are on a likely IPO track, although any IPO is several years out,” Pennarun said. “Meanwhile, we have an extremely efficient business model, rapid revenue acceleration, and a long runway that allows us to become profitable when needed, which means we can weather all kinds of economic storms.”
Nothing is set in stone, after all it's VC backed. I have a strong aversion to becoming dependent upon proprietary services, however i have chosen to integrate TS into my infrastructure, because the value and simplicity it provides is worth it. I considered the various copy cat services and pure FOSS clones, but TS are the ones who started this space and are the ones continuously innovating in it, I'm onboard with their ethos and mission and have made use of apenwarrs previous work - In other words, they are the experts, they appear to be pretty dedicated to this space, so I'm putting my trust in them... I hope I'm right!
[0] https://betakit.com/corporate-vpn-startup-tailscale-secures-...
Tailscale have build great product around wireguard (which is quite young) and they have great marketing and docs. But they are hardly first VPN service - they might not even be the most popular one.
As far as I understand Tailscale brought NAT busting mesh networking to wireguard + identity first access control, and reduced configuration complexity. I think they were the first to think about it from an end to end user perspective, and each feature they add definitely has this spin on it. It makes it feel effortless and transparent (in both the networking use sense and cryptography sense)... So i suppose that's what I mean by started, TS was when it first really clicked for a larger group of people, it felt right.
Just like cloudflare, a healthy free offering makes lots of happy/loyal developer users. Some of those users have business needs / use for the paid features and support and will convince their managers to buy in.
Just like cloudflare, a healthy free offering makes lots of happy/loyal users. Some of those users have business needs / use for the paid features and support.
They spy on your network behavior by default, so free users are still paying with their behavioral data. See https://tailscale.com/docs/features/logging
“Each Tailscale agent in your distributed network streams its logs to a central log server (at log.tailscale.com). This includes real-time events for open and close events for every inter-machine connection (TCP or UDP) on your network.”
They know what you're doing, when, from where, to where, on your supposedly “private” network. It's possible to opt out on Windows, on *nix systems, and when using the non-GUI client on macOS by enabling the FUD-named “TS_NO_LOGS_NO_SUPPORT” option: https://tailscale.com/docs/features/logging#opt-out-of-clien...
It is not currently possible to opt out on iOS/Android clients: https://github.com/tailscale/tailscale/issues/13174
For an example of how invasive this is for the average user, this person discovered Tailscale trying to collect ~18000 data points per week about their network usage based on the number of blocked DNS requests for `log.tailscale.com`: https://github.com/tailscale/tailscale/issues/15326
I highly doubt any of this can actually be opted-out of. How else would they stay in business?
The core client code is open source, feel free to inspect it yourself.
Don't let that deter you from trusting whomever you choose, though.
There's two key features
1) Tunnel management
Tailscale will configure your p2p tunnels itself - if you have 10 devices, to do that yourself you'd have to manage 90 tunnels. Add another device and that goes upto 100. Remove a device and you have 9 other devices to update.
2) Firewall punching
They provide an orchestration system which allows two devices both behind a nat or stateful firewall to communicate with each other without having to open holes in the firewall (because most firewalls will allow "established" connections - including measuring established UDP as "packet went from ipa:porta to ipb:portb 'outbound', thus until a timeout period any traffic from ipb:portb to ipa:porta will be let through (and natted as appropriate)".
The orchestration sends traffic from ipa to ipb and ipb to ipa on known ports at the same time so both firewalls think the traffic is established. For nats which do source-port scrambling it uses the birthday paradox to get a matching stream.
I believe you can run a similar headend using "headscale" yourself.
From what I can gather, Tailscale does a lot of "magic" things to accomplish its goals, and some of them actually have "magic" right in the name. As a system administrator by trade, I have been bitten SO MANY TIMES by things that try to automagically mess with DNS resolution, routing tables, firewall rules, etc in the name of user-friendliness. (Often, things that even ship with the OS itself.)
Are there any documentation or articles detailing exactly what it's doing under the hood? I found https://tailscale.com/docs/concepts but it doesn't really cover everything.
If I have a virtualization host with, let's call it a "very custom" networking configuration, how likely is it to interfere with things? Is it polite and smart about working around fancy networking setups, or does it really only handle the common cases (one networking interface, a default route, public nameserver) elegantly?
0: https://i.postimg.cc/14h3Q9mD/Screenshot-20260219-001356-Chr...
Edit: Nvm, found it. Weird place to put it.
cc: @apenwarr (tailscale founder), might want to have someone fix this and move the close button to the top right of the modal, not the bottom right.
Secondly, peer relays support UDP while DERP is TCP-only. That would be fixable by simply improving the DERP protocol, but as we explored that option, we decided to implement the Peer Relay layer instead as a more complete solution.
What would allow a given pair of nodes access a peer relay? Isn’t the peer relay by default also accessible by every node on the tailnet since it’s in the tailnet as well?
Nothing they do was impossible before, but their big win is making world wide private networking easy and accessible.
I’ve been on-boarding my friends who have their own local media servers setup so we can all share/stream content from each other.
So it runs a STUN server or similar, for discovery and relaying.
Conversely Peer Relays are built on top of the shoulders of DERP. For example, they don't need to do peer discovery set connections up end to end - instead connections are brokered via our DERP fleet and then in a sense "upgraded" to an available Peer Relay or Direct connection. Because of that they're super lightweight and much easier to deploy + manage. And, they scale horizontally so you can deploy many peer relays across your network, and they're resilient to downtime (we'll just fall back to DERP).
The issue I have is I’m trying to connect two devices where one is behind a CGNAT that always causes the connection to be relayed even though the other one is not behind a cgnat with proper port forwarding. Would a peer relay solve this but is it like a DERp where I have to host it on a VPS separate from my existing two networks or is this something different where I can host the peer relay on the network not behind a CGNAT and somehow it will link the two networks through it?
This solved every last remaining problem of my CGNAT'd devices having to hop through STUN servers (with the QoS being noticable), now they just route through my own nodes.
If you feel that tailscale will fold, or the free plan will be future limited, then you can drop in headscale which is a near 1:1 API open source tailscale central server.
If you always want to be open source and not rely on API changes or staying up to green on the headscale development (made by a third party), then you can set up netbird, which is both hosted (for free) as an alternative to Tailscale more tailored for developers, but they also open-sourced their entire stack, so you can always leave and use that on your own servers.
Anybody wanting to see what Tailscale is able to see can simply sniff any router interface passing outbound traffic before it enters the WireGuard tunnel interface.
Which is then when I realized it was less a piece of software and more so an auth management provider with some vaguely helpful auxillary services.
For anyone worried about the "rug pull" concern raised in another comment — this actually makes me more optimistic, not less. By distributing relay infrastructure to the edges, Tailscale is reducing its own operational cost per user while improving performance. That's the kind of flywheel that makes a generous free tier more sustainable, not less. Each new node potentially helps the whole network.
