I just set this up the other day, and I got my ping to drop from 16 to 10ms, and my bandwidth tripled, when connecting from a remote natted site to a matter desktop my house. Together with Moonlight/Sunshine I can now play Windows games on my Linux desktop from my MacBook, with 50mbps/10ms streaming. So far so good!
Not a single port forwarded, I just set my router up as peer node.
Neat use case. But in fairness, you've simply 'offloaded' NAT traversal/port forwarding to automagic helper protocols over which you have no control even if you wanted it.
I recently tried whitelisting IPv6 prefixes at the network border and running straight IPv6 traffic from end to end.
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 ¯\_(ツ)_/¯
That seems really exciting! If you wanted to share game streaming to a general public would they have to install tailscale on their device/login? How does that work? Am I right in assuming that tailscale is built mostly for sharing resources with people you trust instead of the general public?
I'm confused.
I wanted to do this too with an OpenWRT router, but I was under the impression I still had to open a 40000 port so my NAT devices can see it. Wouldn't it still be on the exposed public Internet?
There are several ports open (you dont open them, Tailscale does), including for peer relay. Some are vpn ports, but the ports for relay servers are not for VPN so my guess is that the software that listens to those ports is a lot less secure (compared to Wireguard or OpenVPN).
Yes my router has open ports, but it does not do any port forwarding. So I can 'directly' connect any device behind my router without my router needing to know any specifics of which device that is. And I don't need to do any port forwarding of anything on my network and thus expose them to the whole internet; I just expose them to the users of my tailscale network (only me)
How does Tailscale make money? I really like their service but I'm worried about a rug pull in the future. Has anyone tried alternative FOSS solutions?
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.
Our company pays for the premium business plan, $18/mo/user. You have to pay for at least the lower tier plan once your team grows beyond a handful of people. And there's several quite useful features (though maybe not essential) on the premium plan like serve/funnel and SSH.
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).
Zerotier is not the same as tailscale although both can be used to do the same, but under the hood both are fundamentally different, ZT is layer2 like switch, so it’s like an Ethernet meanwhile TS is built on top of wireguard and is layer3. ZT allows broadcast/multicast and has own protocol, TS don’t. I use both among others, and ZT since around 2019, I found it reliable in some cases in IoT world while TS had better throughput in usual applications.
I've used serve/funnel on the tailscale free tier... definitely agree that the team size limit seems like it would move companies to the paid plan though.
How do you handle the do-before-thinking devs? Or the kinda low-to-mid performing devs? Most companies has one or a few of those, right? They help the company machine go around by doing the somewhat boring stuff over and over again.
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?
> Also, sometimes it seems like I get rate limited on Tailscale.
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.
The Tl;Dr here is that the cost to them of operating the free tier is lower than what they estimate their Customer Acquisition Cost would be without a free tier, so the free tier generates better leads/conversions to their paid products at a lower cost than traditional sales and marketing.
As long as these economics continue to hold they'd be stupid to discontinue the free tier.
Tailscale is a perfect example of using a free tier to become popular with developers, who then evangelize the product to their employers. The employers pay for business scale plans.
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.
I have the same fears. Last year they have publicly stated they are not interested in acquisition [0]
> 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!
At this point Tailscale is working so well and I'm so happy with it that I'm afraid it's time to start migrating to Headscale [0] for my home network. The rag pull may just be too painful otherwise!
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.
I self-host a few apps and use Tailscale to access them remotely. It's worked well, so I recommended it as a possible solution to allow employees at my company to remotely access some on-prem resources while remote, and that's being considered. If we go with that, then that'd be Tailscale making money from me using the free plan.
Free personal tier is basically a cheap advertisement for them. You try Tailscale personally and get used to it, then it is very likely you would want to deploy it at your work seeing the benefits scaling even more with more people.
And then they make money.
1000%. Tailscale is the first VPN I've used that makes my life easier, and I'm using it for personal access to my selfhosted servers at home. I will definitely recommend it to companies I work for in the future.
Most posters on HN barely know what a subnet is so it's not that simple
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.
I do, I use a VPS (at OCI free) to host Wireguard. My home systems (running my production web sites and email) are on my VPN and mine and my wife's phones. I hand configured it all but it wasn't difficult for me.
There are a number of features and teamsizes that they provide where you have to pay money. Most company users are going to end up paying them money. But also their emphasis on P2P connections means their costs are quite low. It doesn't add much overhead to have the smallish number of personal users out there. They've talked about how having the free tier helps to force them keep those costs down in useful ways.
“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...
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'd love to have someone else chime in on this because I did some spelunking and am not sure if this comment is true.
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:
Pretty much this. DNS, SNI, and otherwise plaintext traffic sniffing. That together with user/device 'fingerprinting' (a much more amorphous concept), and that's why such-and-such thing you were just talking about with so-and-so pops up on your screen/feed/whatever, sometimes only minutes later.
I highly doubt any of this can actually be opted-out of. How else would they stay in business?
I'm having a hard time understanding how this is different from a bastion server, where you're tunneling through an intermediary server that you've deployed in the target network.
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've setup and used peer-relays since it was first announced and they've been great, but they do solve a somewhat specific problem.
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 :)
I think that biggest difference is that your client applications don't need to be explicitly configured to use the bastion server. For example ssh, web browsers, rdp, samba and so on can just pretend that you are inside the target network. Doubly useful if this is a "customer" network and you are working with multiple customers.
I wonder if someone might indulge me by answering a question or two about Tailscale. I have a self-managed wireguard network which works, but probably isn't very smart or elegant.
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?
It's difficult for us to maintain documentation of exactly the kind you'd want there, though we do try to keep up with docs as best we can. In particular there is a fairly wide array of heuristics in the client to adapt to the environment that it's running in - and this is most true on Linux where there are far far too many different configuration patterns and duplicate subsystems (example: https://tailscale.com/blog/sisyphean-dns-client-linux).
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.
I really like Tailscale. Recently though I’ve been having some hard-to-diagnose slowdowns even on a direct (non DERP) connection. I’m not sure if it’s something to do with MTUs or my ISP.
If you're sold on Tailscale due to them "being open" (as they semi-officially support the development of Headscale), keep in mind, that at the same time some of their clients are closed source and proprietary, and thus totally controlled by them and the official distribution channels, like Apple. Some of the arguments given for this stance are just ridiculous:
> 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.
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 don't understand this attitude. Some humans have to eat and put a roof over their heads sometimes, and extracting consulting fees from open-source work (i.e. the Redhat model) is not always a paying business model. A hybrid model is often the best way to compromise.
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)
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.
The bigger problem is that making software easy to use is stupidly expensive and hard and is usually the kind of work devs hate. So it’s usually not possible for free software to do it, hence free software usually makes no impact outside very technical circles.
Personally, I understand people need to make money but this tends to be a death spiral (enshittification). So I tend to go for solutions without those incentives at all. Or at least use the free self hosted option.
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.
The logic of putting roof over the head is a point that is too broadly used is not at all valid for things like tailscale as... eventually most businesses at that level (tailscale revenue in 2025 was $45.2M) are crushing the customers. Either entshittification or lock-in. There is a loss of trust. The trust on SV/software is as much as bankers (during Lehmann bros crisis). Some people in HN think oh, we are growing small farmers/engineers from grassroots etc Yes, maybe - but their thinking is to exploit customers sooner or later. These smaller ones (as compared to FAANG etc) think that common man thinks that FAANG are the exploitative ones. But no. The public is getting aware that every damn calendar app or pdf viewer or router is increasing prices or wants subscription or planned obsolescence.
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...
They don't have access to the same information as us. There's another comment that replied to you who brought up enshittification. I guarantee you he has not read the blog post by apenwarr. Or even knows who apenwarr is.
Thats actually a good way to split a project up into closed/open imho. Open the functional part so people can see you're not sending data to hq behind their backs and make the boring time consuming ui closed. I like it. Then make money out of a service rather than the software. As we all know, tech people will see a piece if challenging software and go out of their way to replicate it and release it for free, for whatever reasons. So open sourcing that part takes the challenge away.
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?
can you say more about this. I've been considering adding tailscale to some products but if my (nerd) perspective is to survive corporate realism I need more than a 1-liner to justify. seriously curious. Also how would I pitch it to a EU based crowd that wants increasingly less to do with US based tech?
"Support free alternatives if you can, even if they underperform by some measure."
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
Basically a lot of current software teams operate like many modern video game companies. Ship the broken thing, (maybe) repair/improve it as people suffer through the experience.
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.
Seems like an odd thing to be concerned about. Most of the apps on my Mac are closed source, that little Tailscale menu bar item is really insignificant. You can always control it through the command line if you're really bothered by it. I'm pretty sure tailscale is on brew.
That justification honestly doesn't sound that ridiculous to me, especially if the closed-source stuff is mostly just platform-specific GUI and integration code. Is there even a practical mechanism to open source an iOS app and then letting users verify that the version they're downloading from the App Store is exactly the same version that is open sourced?
I've been relatively happy with Headscale, but now that I have MacOS/iOS users I'm in the process of testing alternatives like Netbird. I was also surprised that the Tailscale Kubernetes operator is not compatible with Headscale.
As a developer who have been built some tailscale-based clients, I think this maybe acceptable because they running a business with money from the VCs.
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.
I keep hoping to switch to Netbird, but run into the same issue every time for the last couple of years I've been trying it - peers randomly drop of the network. There's a longish standing open issue on their GitHub.
where were the alternatives before tailscale? we could only read bout BeyondCore with envy before tailscale. i'm going to keep supporting them unless they do something naughty.
Readit News
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 ¯\_(ツ)_/¯
Deleted Comment
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?
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-...
[0]: https://headscale.net/
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:
[0]: https://login.tailscale.com/admin/logs/networkI highly doubt any of this can actually be opted-out of. How else would they stay in business?
https://github.com/openziti/ziti
Deleted Comment
Dead Comment
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?
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).
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.
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
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.