Tailscale Peer Relays is now generally available(tailscale.com) |
Tailscale Peer Relays is now generally available(tailscale.com) |
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.
Tailsacle provides managed, policy-driven secure connectivity, where the network admin controls access, and where packet payloads are end-to-end encrypted between their nodes using device-to-device links that are WireGuard-based. Their TCP relay system (DERP) helps connectivity when direct peer-to-peer isn’t possible, but traffic through DERP still remains end-to-end encrypted.
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.
Not a single port forwarded, I just set my router up as peer node.
It works really well so long as there's an encrypted transport, although I'm a little annoyed that the routes are very different and the ping times are different too. Although at the moment I can't remember if they're worse ¯\_(ツ)_/¯
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.
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?
Some of our users experienced fairly limited throughput from time to time. Under certain circumstances (eg. always ipv4 NAT/double-NAT, never for ipv6) their Tailscale client couldn't establish a direct connection to the Tailscale node in the datacenter, so data was relayed through Tailscales public relay nodes. Which at times was rate limited/bottleneck - in all fairness, that is to be expected according to their docs.
The first mitigation was to "ban" the specific public relay they were using in the policy. Which helped, but still not a great solution and we might just end up in a weird whack-a-mole-ish ban game with the public peer relays in the long run.
So we setup a peer relay, which networking-wise is in a DMZ sort of network (more open), but location wise still in the datacenter and allowed it to easily reach the internal (more restricted networking) Tailscale nodes. Which solved all throughput problems, since we no longer have users connecting through the public relays.
Also, the peer relays feels a little bit magic, once you allow the use of them in the Tailscale policy, it just works(tm) - there is basically zero fiddling with them.
EDIT: I'll happily provide more details if interested - we did a fair amount of testing and debugging along the way :)
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.
What's the big deal here? Any good reason to switch (besides Tinc's obscurity?)
> 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.
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?
Also, offtopic question: is Tailscale named after the idea of UDP packets “tailgating” a connection?
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.
Does Tailscale maintain an q&a agent, mcp, or llms.txt that anyone is aware of?
I’m trying to use Tailscale across my personal networks - without investing a lot of time - and so I’m throwing agents at it. It’s not going well, primarily because their tools/interfaces have been changing a lot, and so tool calls fail (ex ‘tailscale serve —xyz’ is now ‘tailscale funnel ABC’ and needs manual approval, and that’s not in the training set).
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.
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.
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.
The point about AWS NAT restrictions is a big one. I think a lot of people underestimate how often 'enterprise-grade' networking actually becomes a bottleneck for direct P2P. Moving that burden away from custom DERP management makes the 'it just works' magic of Tailscale feel much more sustainable for small teams.
Having said this, it’s been almost a year since the last incident of this. It’s been rock solid the last months. Ok sure using these new peer nodes will greatly reduce this from even a chance of happening anymore. :hacks away:
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?
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.
The hoops you have to jump through to be on two different tailnets might dissuade some home users from even bringing it up at work.
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-...
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.
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.
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?
To try and take a general poke at the question in more of the context you leave at the end:
- We use rule based routing to try to dodge arbitrary order conflicts in the routing tables.
- We install our rules with high priority because traffic intended for the tailnet hitting non-tailscale interfaces is typically undesirable (it's often plain text).
- We integrate with systemd-resolved _by preference_ on Linux if it is present, so that if you're using cgroup/namepsace features (containers, sandbox runtimes, etc etc) then this provides the expected dns/interface pairings. If we can't find systemd-resolved we fall back to modifying /etc/resolv.conf, which is unavoidably an area of conflict on such systems (on macos and windows they have more broadly standard solutions we can use instead, modulo other platform details).
- We support integration with both iptables and nftables (the latter is behind manual configuration currently due to slightly less broad standardization, but is defaulted by heuristic on some distros/in some environments (like gokrazy, some containers)). In nftables we create our own tables, and just install jumps into the xtables conventional locations so as to be compatible with ufw, firewalld and so on.
- We do our best in tailscaled's sshd to implement login in a broadly compatible way, but again this is another of those places the linux ecosystem lacks standards and there's a ton of distro variation right now (freedesktops concerns start at a higher level so they haven't driven standardization, everyone else like openssh have their own pile of best-guesses, and distros go ham with patches).
- We need a 1360 byte MTU path to peers for full support/stability. Our inner/interface MTU is 1280, the minimum MTU for IPv6, once packed in WireGuard and outer IPv6, that's 1360.
I can't answer directly based on "very custom" if there will be any challenges to deal with. We do offer support to work through these things though, and have helped some users with fairly exotic setups.
Suggestion: let an LLM maintain it for you.
Alternate suggestion for OP: let an LLM generate the explanations you want from the code (when available).
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.
Preferring open source is a risk mitigation strategy. The closed alternative may have better features to make them worth that risk though.
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.
A roof over the head is OK but the price increases are usually to put private Yachts. The income earned by majority of these founders is already good to have lots of roofs.
Maybe my local corner coffee shop is one fellow I would not mind having subscription with...
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?
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
go install tailscale.com/cmd/tailscale{,d}@latest
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.
And I am also very grateful that tailscale implement some workaround for systems such as apple-based OS with core APIs built into the open source code, thus if you really need you can just look the open source code and doing accordingly, though it really need some research work.
For the long term if they really do not want to open source the core client code (which I do not believe at the moment), I think support a fully open source coordinator and open source client based on the fork will still be doable.
Otherwise there's native ZeroTier and WireGuard, but no Tailscale.
For technically complex things, they EXTRA suck.
This is a bad idea.
The difference is architectural; Tailscale is a mesh VPN, whereas OpenZiti is an identity-first, zero trust overlay network. This makes OpenZiti service-centric and deny-by-default, not network-centric. Instead of “join a private network,” you get access only to explicitly authorised services — with no ambient reachability at all. Its also 100% open source. If you want a simple productised, SaaS experience, NetFoundry, the company behind OpenZiti provides that.
Tailscale is engineered under the assumption that any client connected to our control plane could potentially differ from our canonical OSS codebase.
This is so problematic that I'm considering looking into Tailscale, I understand they work very differently but it looks like my use case could be covered by both.
# Replace feth1234/feth2345 with your active interface
sudo ifconfig feth1234 mtu 1400
sudo ifconfig feth2345 mtu 1400
..and for working with Windows peers, manually "Orbit" the Windows Peer as well as adding a direct routing hint for the internal ZeroTier IP. ZT definitely takes some effort for tuning.
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.
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.
Maybe? Things like super yachts are just offensive.
Do you realize how out-of-touch with reality this sounds? For every $45M Tailscale there's a hundred companies you likely never heard of making respectable but not-very-excessive money in niches here and there. For example, I have a high school friend who owns one: https://speedify.com Thing is, you can't have one without the other. Hell, that's the kind of success (as in "moderate") I'm actually targeting with my work. Which is why comments like this irritate me.
Go make something that other people want and then try to live off it. Offering all of it for free won't cut it, because we don't live in a communist dictatorship (not that any of them might approve you spending your time on your pie-in-the-sky "contributory idea" in the first place).
By the way, in working on the thing I want to sell, I've made a number of offshoot projects open source as a side effect. Check my github, it's never been more active.
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?
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?
I had to install openwrt on my router so that I could restrict access to upnp by mac address just to my gaming pc (imo this should be standard on any router as an advanced setting, most are just upnp yes/no) so that I can still play online games.
But even power users have to pick and choose their battles.
If I had a nice tailnet home setup going I might be seriously miffed if I had to try to fit in some of my devices to a corporate tailnet I didn't control.
I still hope to get back to that and try to get it to a state where it can be merged, but I need to figure out how to test the MDM parts of it properly, and ideally get a bit of guidance from the tailscale team on how it should work/is my implementation on the right track (think I had some open questions around the UI as well)
You’re also operating under the assumption that people always have a choice.
The concept is separate from 'zero config' (https://en.wikipedia.org/wiki/Zero-configuration_networking), which Tailscale's low technical barrier to entry evokes.
In the simplest case, if a person has two different sets of systems they desire to access from a cellphone, and an unwillingness to carry two different cellphones around with them, then it becomes a business decision of whether that person is valuable and trustworthy enough to allow access to work systems and "other" systems from that cellphone.
Who pays for the cellphone, and whether this extends to laptops or not, are questions of degree.
The amount of businesses closed, sold and products abandoned or swapped for the more controlled/exploitable ones is numerous, on the other hand.
This sounds a lot like a circular definition.
An "open source contributor" is not gonna wake up at 2AM on a Saturday because the business that someone else partially built on their free code suddenly went down.
This is ALSO, conveniently, why AI's will never completely replace human developers. You cannot blame, reward, or punish an entity that has no such sensitivities.
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.
The traffic that does go through their servers is encrypted, and bandwidth limited on the free plan. Any snooping on client behavior would have to be done client side, and the clients are all open source. To some extent the coordination server might be able to deduce some metadata about connections; but definitely not snoop all plaintext traffic.
I think they do have some “service detection” which can basically port-scan your devices to make services visible in the web UI. But that is easy to disable. And premium/enterprise tiers can intentionally log traffic statistics.
Metadata is as good as data for deducing your behavior. Think what conclusions can be drawn about a person's behavior from a log of their network connections, from each connection's timestamp, source, destination, and port. Think about the way each additional thing-which-makes-network-requests increases the surveillance value of all the others.
Straight away, many people's NTP client tells the network what OS they use: `time.windows.com`? Probably a Windows user. `time.apple.com`? Probably Mac or iOS. `time.google.com`? You get the idea. Yeah, anyone can configure an NTP client to use any of those hosts, but the vast vast majority of people are taking the default and probably don't even know what NTP is.
Add a metadata point: somebody makes a connection to one of the well-known Wi-Fi captive portal detection hosts around 4PM on a weekday? Maybe somebody just got home from school. Captive portal detection at 6PM on a weekday? Maybe somebody just got home from work. Your machines are all doing this any time they reconnect to a saved Wi-Fi network: https://en.wikipedia.org/wiki/Captive_portal#Detection
Add a metadata point: somebody makes a network connection to their OS's default weather-widget API right after the captive-portal test, and then another weather-API connection exactly $(DEFAULT_INTERVAL} minutes later? That person who got home is probably still home.
Required reading: https://kieranhealy.org/blog/archives/2013/06/09/using-metad...
This is one the the most fundamental components of SaaS accounting, it’s absolutely not a “wild guess”.
Welcome to economics.
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?
Products that have no free tier where everything is behind a scheduled sales demo present a huge barrier to entry.
The integrated service is very valuable and obviously genuinely popular.
If it is not, I go somewhere else. “Going somewhere else” is not always an option when it comes to computers/software.
I value a great video game or piece of software often despite its bugs and issues. If they had fewer bugs and issues I’d value it more. It would be better.
We should not conflate tolerance and appreciation. Just because people tolerate it doesn’t mean they value it.