Not a single port forwarded, I just set my router up as peer node.
What's the big deal here? Any good reason to switch (besides Tinc's obscurity?)
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).
Ok I checked the pricing page and funnel is available in the free tier (limited to 3 users) but not the $6/user/month tier - which you need for more than 6 users... strange pricing structure but I guess I see the logic.
Any chance you were asked to upgrade from $6/user/month to $18/user/month and not free to $18/user/month?
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.
Say 5% of the free tier users converts to a paying customer within 5 years. And user growth is constant. Then over time, you will get a much larger free tier user base, compared to your paying customers (in absolute numbers). At some point, it must become tempting to charge all free tier users a little bit to continue, because the group got so big, so there is a lot that can be earned there.
Is this wrong, or should we expect this?
This is one the the most fundamental components of SaaS accounting, it’s absolutely not a “wild guess”.
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.
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 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 checked my DNS logs and saw zero attempts to resolve `log.tailscale.com` having ran tailscale for many years (I added it to a blocklist anyway). From their admin panel, it appears "networking logging" requires paying for Premium[0], so it's not being used for free users (or Personal Pro).
Also, from looking at some source code (because the docs don't include this), I discovered you can disable logging for the macOS App Store client by doing:
echo "TS_NO_LOGS_NO_SUPPORT=true" > ~/Library/Containers/io.tailscale.ipn.macos.network-extension/Data/tailscaled-env.txt
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.
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.
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.
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?
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?
One question for the Tailscale folks: for ephemeral compute (Cloud Run, Lambda, Fly.io), where containers may spin up/down frequently, how does peer relay selection work when the relaying node itself might be transient?
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.
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?
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.
Also, offtopic question: is Tailscale named after the idea of UDP packets “tailgating” a connection?
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.
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.
> 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.
Disclaimer: I'm pursuing a similar solution on an app I'm working on. The CLI will be free and open-source (and will have feature parity with the GUI), but charging money for the GUI will also help support that development (and put my son through school etc.)
And by "feature parity", I really mean it- The GUI will be translated into 22 languages... and so will the CLI. ;) (Claude initially argued against this feature. I made my arguments for it. It: "You make a compelling argument. Let's do it." LOL)
The lowest level of it is already available and fully open-source: https://github.com/pmarreck/validate
I'm building something on top of that which will have a nice GUI, do some other data integrity stuff, and also have a CLI. And will be for sale in the Mac and Windows app stores.
I wonder why you jumped into the mesh vpn market, it's so saturated. Theres literally hundreds of solutions out there (niche ones included for the mainstream ones it's probably 10 or so), many non profit options included. Is there really a niche you can offer that the others don't?
Edit: ah by doing the same thing you didn't necessarily mean a mesh vpn? I don't really understand what your thing does but not vpn.
I was just saying it because there's a new Show HN mesh VPN thing weekly now.
Although, the problem is not so single-layered. Do I understand the situation correctly, in case of iOS, to not be subject to additional limitations of the platform that restricts the distribution of your products to the extents that the laws of the countries where your business is registered require, all the user has to do is to fork the main repo (which is, thankfully, BSD), build a minimally acceptable GUI, pass Apple certification, publish the app in the app store, and Bob's your uncle?
Versus any mildly-technical user being able to stumble into the option and discover they're being spied on in the first place.
Open source = The maintainers should build exactly what I hysterically scream at them
If I had to choose one definition of open source from these two options, it's going to option 1 I'm afraid.
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
You’re also operating under the assumption that people always have a choice.
So fully available in situations with limited connectivity. The GUI version of the client is closed source though, and it's available as a package or from the app store.