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.
Ah, perfect. The Mikrotiks weren't as straightforward earlier but maybe it's easier now. Glad to know it works on EdgeOS. Did you just use this? https://github.com/jamesog/tailscale-edgeos
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)
Within my risk appetite on trusted network segments. I have bigger issues if malware is operational within the trust boundary, it can do what it needs using outbound connections just fine (recon, lateral movement, etc). Your risk appetite might differ.
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.
Agreed with OP. It's very handy. I made the switch after trying to tinker with running third party utilities to do this and running into issues. I found Apollo and it all just worked. Now I can stream in 4K HDR to my living room TV (which is not even what my physical PC display is). It's compatible with all the regular clients too which is nice.
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?
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.
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!
Just note i doubt Tailscale were first popular vpn manager as i remember many hobby users are Zerotier converts and also much older products like Hamachi.
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.
Yes, I ambiguously said "started this space"... and to be honest even in the most generous interpretation that's probably incorrect, maybe ZeroTier started "this space", in that it had NAT busting mesh networking first.
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.
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.
All it takes is for the decision-maker who gets the credit for cutting costs by removing the free tier to be a different person from the one who gets the blame for higher customer acquisition costs. Not saying it'll happen, just that it being a bad move isn't a guarantee.
But it isn't 'economics' as there is no actual data or science here, just a wild guess about what customer acquisition might currently cost. All it takes to rug pull is some exec speculating that 'the economics' have changed.
Acquisition cost can definitely be calculated. I'm pretty sure they know how many customers do convert into paying users from their free tier and how much does it cost to get them through other channels
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.
And they have become quite infamous for having aggressive sales tactics for anyone going over their internal metrics for the free tier (still under the public metrics for free).
Also the fact it means companies can run a demo themselves without having to contact sales, after they see it works on their system they pay to add all the users they will need.
Products that have no free tier where everything is behind a scheduled sales demo present a huge barrier to entry.
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.
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!
> 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.
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.
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).
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.
I think how it works usually is that they let you use the features from higher tier plans than the one you're on; once you use them enough they send you an email asking to upgrade. That's what happened to us and I've seen other users mention it. Not sure how I felt about it, OTOH maybe it was less friction than explicitly subscribing for some "2 weeks free trial" or whatever but OTOH it did feel weird and unexpected. Anyway, we felt the extra features were worth it so ended up paying.
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?
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.
Yeah, they're not direct replacements. I think both models have have their pros and cons. In fact I tried both around when covid shutdowns started (server being in the office, me at home), and liked zerotier better; it was faster, and a more generous free tier. But now tailscale has won out for a couple of reasons; the main one, it's simply less flaky for us on macOS, especially for devs working overseas. No idea why and maybe there's simple fixes (that don't involve repeated connections/disconnections, hopefully). The other, tailscale has a few extra things that are nicer and easy to use like identity-based ACLs, funnel/serve, magicDNS, ssh management, etc.
I had to do MTU tuning on macos on the ZeroTier interface (find your feth name via ifconfig)
# 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.
Zerotier works fine for me, but with a huge exception which I just can't figure out. On my Linux laptop which also runs OpenVPN and with some specific routing set up, Zerotier will, after a minute or so, completely take over the routing and default everything through Zerotier, and nothing I do with the routing tables will change this. I have to stop ZT at this point and then it reverts to normal.
Every other computer in my ZT network behaves fine.
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.
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?
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.
There are a lot of workarounds these days, such as tailnet switching, and, of course, if you're admin on both tailnets, you're practically golden with the "share" option.
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.
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.
“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
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?
The `TS_NO_LOGS_NO_SUPPORT` option opts out of all log collection, and says in the name why it is collected in the first place. Tailscale has support for all users, including free, and having access to logs has to be how they can provide free support. Having quick access to logs reduces the time it takes to handle tickets, so they can help more people quickly and don't need to limit support to only paying users.
The core client code is open source, feel free to inspect it yourself.
They specifically avoid sending traffic through tailscale servers whenever possible. That’s how the free tier stays free. Most connections are direct, P2P.
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.
I don’t mean P2P in the same sense that BitTorrent or something is P2P. (Splitting one connection into many distributed ones) But more like how a game that does P2P multiplayer has the clients connect directly instead of through a centralized service.
> To some extent the coordination server might be able to deduce some metadata about connections; but definitely not snoop all plaintext traffic.
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.
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:
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.
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.
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.
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.
If you're worried about a rug pull, you should be. Not because Tailscale is shady, but because that's just how VC-funded infrastructure works. The free tier exists to build lock-in, not out of generosity. Headscale exists but honestly it's a pain to run compared to just paying Tailscale $18/user. The real answer is: if it's critical infrastructure, you should be running Wireguard directly and owning the coordination layer yourself. Everything else is renting convenience.
It happened to others but there are also some very good examples like Veeam community edition which, IMO, is the best backup software. They had lots of discussions and even pressure from management to terminated, but the numbers made a lot of sense and they kept it. Tailscale is in disadvantage here because they are in a very crowded market and it will be very easy to slip into one corner and let way for others like netbird, netmaker, nebula(?), wireguard (like u said), etc.
I have my homenas set up with Node Proxy Manager container forwarding requests to different docker machines:ports e.g. I have some TTS/STT/LLM services locally hosted. To increase bandwidth to internet facing nodes, would you use this or some other simpler solution?
I assume so; I use the same thing with my Unraid box and then create the DNS entries in the unifi panel so I get jellyfin.lan, minecraft.lan, etc inside the house.
One of the many use cases, but basically yes. Other use cases: Home automation, remote backups, media servers, photo libraries, AI assistants... you name it!
It's a vpn from the original definition before vpn meant a proxy to get around geoblocks. I use tailscale for my home servers, my routers, for servers I have in other houses all behind NAT. I have half a dozen raspberry pi print servers in two warehouses also behind NAT and they can connect to each other and I can connect to them from CGNAT
Peer relays are a bit different from our previously available Custom DERP servers. While the custom DERPs do relay traffic, they also require a bunch of configuration and management for their other jobs and they open up availability concerns that are pretty tough for our average customer.
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).
I’m so confused. What is the difference between a peer relay and a DERP server that is self hosted?
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?
You should be able to stand up a peer relay on an existing tailscale device - so your proposal is correct! Try setting one of the devices up as a peer relay per the docs here: https://tailscale.com/docs/features/peer-relay
I never brought my self to use tailscale because it has a login screen and I absolutely despise that even as a concept for a private NAT. I know headscale exists, but it doesn't seem to even support the features I really want.
I can't believe this isn't a show stopper for more people here. I literally couldn't figure out how use it the first time tried because I didn't know how to comprehend that it was trying to get me to auth via browser window. I kept digging around for a tailscale.conf.
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.
Tailscale simp here, been using this feature since it launched in beta, can't believe it didn't exist earlier.
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.
The peer relay approach is interesting because it essentially turns every node in your tailnet into a potential relay for other nodes. This is a meaningful architectural shift from relying on Tailscale's centralized DERP servers.
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.
It's a bit disingenuous to present solutions like Tailscale as more secure than opening a VPN port on one's on machine. The latter solution should always be preferred when available just because you don't want your infrastructure to depend on a "free" service which might cease to be free tomorrow.
Things are much more unscrupulous than potentially ceasing to be free tomorrow. Nobody who values their privacy would ever route their network traffic through a 'free' service.
They need to know how/where to route your outbound traffic. That inherently includes plaintext DNS, TLS handshakes, and otherwise plaintext traffic (like HTTP for example).
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.
No, that’s not quite true. The wireguard tunnels that the Tailscale daemon creates only go to your own machines. Nothing going through those tunnels goes to or is seen by Tailscale the company. Sometimes those tunnels go through a proxy (especially when you’re afflicted by CGNAT), but the proxy sees only encrypted traffic.
Tailscale is not marketed as an "anonymity VPN". You're still using the devices in your Tailnet.
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.
This is a more all-included and resilient system, especially for logging, than just opening a VPN port. I do a lot of corporate installs, and if we had a system like Tailscale then I would be in heaven. The amount of user-created systems are heinous in regards to security, and hard to setup and keep running. Tailscale lets you setup quickly, and reliably with minimal errors OOTB.
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.
(Alex from Tailscale here) I've sent this to the web team, we'll take a look first thing in the morning. Sorry y'all had to look at my ugly mug a bit longer than is ideal just now.
(Tailscale founder here) Two main differences: first, every DERP server used by your tailnet must be accessible by every node on your tailnet at all times, otherwise you get hard-to-debug netsplits. That's a very high bar to maintain so we've historically recommended you don't try. In contrast, peer relays are "if a given pair of nodes can connect through any of the relays, go for it" so deploying one is always a performance and reliability improvement.
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.
Hmm got it not sure I entirely understand. The issue I have is I’m trying to connect two devices where one is behind a hard 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 same network not behind a CGNAT and somehow it will link the two networks through it?
> every DERP server used by your tailnet must be accessible by every node on your tailnet at all times, otherwise you get hard-to-debug netsplits.
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?
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 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.
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.
Let's stop moving the goalposts. Open source has a specific definition, and "they merge whatever code I want them to" isn't part of it. Just fork the client, compile it, and run it yourself.
Heh, that's my PR. Initially I thought it would be a trivial change, but then I realized I hadn't considered how it should interact with MDM / device posture functionality - these aren't features I'm personally using with the Android client, but are understandably important to enterprises.
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)
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?
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?
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.
"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.
I don’t value the imperfections. I value the experience despite the imperfections.
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. I don’t value the imperfections.
We should not conflate tolerance and appreciation. Just because people tolerate it doesn’t mean they value it.
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?
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.
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.
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.
To be fair, only the mesh part of the problem is quadratic. Reliable hole punching is not that easy either. As far as I know, there is a level of circumvention in case the unwrapped WG is blocked too.
The integrated service is very valuable and obviously genuinely popular.
That doesn't really help. It still happens. And you still need to move to something else. And they'll try to tie you in by making migration as tough as possible.
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.
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...
Then ask all the billionares or people like you to give jobs/salaries/allowances/holidays at SV level to everyone in the world. Lets all build yachts. I am happy to get that level of pay.
I understand it. It's just ignorance. They simply don't have access to the information we do. 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.
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.
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.
I looked into tailscale in the past as a way to host a game server such as minecraft on my local machine publicly without port forwarding . It seems that tailscale is mostly configured only to work with people you know and trust. I was hoping that Peer Relays would help alleviate some restrictions with tailwind funnel. Does anyone know any alternatives?
if you have a cheap vps you can use it to forward the traffic to for some benefit, that is what i have been doing when i need compute accessible online and don't want to pay for cloud.
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.
The shift from managed DERP to decentralized Peer Relays is a massive win for self-hosters with difficult NAT situations. I’m curious if this significantly reduces Tailscale's own egress costs or if the primary goal was just improving latency for users who can't establish a direct WireGuard tunnel. Either way, removing the 'hassle' of setting up a custom DERP server is a great UX improvement.
Alex from Tailscale here... We’re users just like you, and we felt this pain point ourselves. The good news is that Peer Relays were able to build on a lot of the existing subnet router and exit node plumbing, so it wasn’t a huge engineering lift to bring to life.
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.
We’ve had issues with the centralized DERPs just blackholing traffic when we startup ephemeral nodes in CI. This is despite us ensuring that all important peers can establish direct connections to each other. But there is some bootstrapping that is happening before both peers negotiate.
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:
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?
Real-world CGNAT use case that might be relevant here: I'm running an industrial AI monitoring system (computer vision on live RTSP camera feeds) deployed on Google Cloud Run. The cameras are behind an ISP that blocks port forwarding entirely — a common apartment/SMB situation.
Tailscale solved this completely. The Cloud Run container joins the tailnet, the camera's RTSP server gets a 100.x.x.x address via MediaMTX, and the container reads the stream over the private mesh as if everything were on the same LAN. No public exposure, no ISP negotiation, no port forwarding rules.
The Peer Relay announcement matters for this setup specifically: my Cloud Run instance spins up fresh containers under load, and DERP relay fallback was occasionally adding latency during the NAT traversal handshake on cold starts. Peer Relays distributing that relay burden to edge nodes should reduce that.
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?
UDP support in peer relays is crucial. DERP relies solely on TCP, which causes latency-sensitive applications like game streaming and voice to experience head-of-line blocking along with poor routing. With peer relays using UDP on your own nodes, the fallback path becomes effective for real-time traffic when direct WireGuard fails. Additionally, you can easily enable this feature on an existing subnet router without the need to set up and manage a separate DERP instance, making it much simpler to operate.
Three AI-generated positive comments in the row from new (green) accounts, with some being answered by Tailscale employees looks like AI-assisted astroturfing PR in hackernews. It’s rampart on every major social network (Reddit especially), interesting to see it live first time on the HN.
I am not anti advertising, I just think pushing AI into places were people interact is very bad behavior and should be punished.
Oh that's really cool! I hope it alleviates some pressure on the DERP servers, whenever I notice the connection on tailscale is bad, it's usually because the device is connecting over DERP.
For someone who is new in this technically does it work like turn and sturn? Relay communicating over outbound ports? Wouldnt this run into scaling issues?
One thing I haven't quite understood yet: If I have multiple relays, will Tailscale automatically pick the "best one" for a given connection, e.g. the one closest to the destination in terms of latency?
Peer relays solve a real pain point for self-hosted infrastructure. The number of times I have seen teams build elaborate DERP relay chains or maintain dedicated VPN gateways just to get two nodes talking through corporate NATs is absurd.
What is interesting about this from an operations perspective is the observability challenge it creates. When traffic routes through a relay, your network monitoring tools see the relay as the destination, not the actual peer. Suddenly your flow logs, latency metrics, and connection traces all point to an intermediary instead of the real endpoint.
Teams running self-hosted monitoring stacks (Prometheus, Grafana, etc.) behind Tailscale need to instrument at the Tailscale layer, not the network layer, to get accurate topology maps. Otherwise you end up with dashboards that show everything connecting to a single relay node and wonder why your "distributed" system looks like a star topology.
The peer relay GA is great for availability, but I would love to see Tailscale expose relay usage metrics -- how often peers fall back to relays, relay latency overhead vs direct, bandwidth through relays. That data is gold for capacity planning in self-hosted setups.
tda | a day ago
Not a single port forwarded, I just set my router up as peer node.
arjie | a day ago
tda | a day ago
arjie | 22 hours ago
OJFord | 14 hours ago
Otherwise there's native ZeroTier and WireGuard, but no Tailscale.
aborsy | a day ago
tda | a day ago
toomuchtodo | a day ago
bityard | a day ago
toomuchtodo | a day ago
gzread | 22 hours ago
nickburns | a day ago
FrenchTouch42 | a day ago
stavros | 23 hours ago
tietjens | 23 hours ago
stavros | 23 hours ago
StumpChunkman | 21 hours ago
langarus | 15 hours ago
jak6jak | a day ago
flowstraume | 22 hours ago
behnamoh | a day ago
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.
tiernano | a day ago
criddell | a day ago
prodigycorp | a day ago
Salesforce, stay away from it!
politelemon | a day ago
tomxor | a day ago
> 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-...
nerdsniper | a day ago
omnimus | a day ago
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.
tomxor | a day ago
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.
tietjens | 23 hours ago
evmar | a day ago
riknos314 | a day ago
As long as these economics continue to hold they'd be stupid to discontinue the free tier.
wat10000 | a day ago
eleventyseven | a day ago
dagi3d | a day ago
erikpukinskis | a day ago
This is one the the most fundamental components of SaaS accounting, it’s absolutely not a “wild guess”.
roughly | a day ago
Welcome to economics.
hashstring | a day ago
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?
tokioyoyo | 23 hours ago
SahAssar | 21 hours ago
tokioyoyo | 15 hours ago
dawnerd | 21 hours ago
Gigachad | 18 hours ago
Products that have no free tier where everything is behind a scheduled sales demo present a huge barrier to entry.
gz5 | a day ago
https://github.com/openziti/ziti
bityard | a day ago
PLG88 | 13 hours ago
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.
nsbk | a day ago
[0]: https://headscale.net/
sureglymop | a day ago
ErneX | a day ago
vizzier | a day ago
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.
arsome | a day ago
kkapelon | 14 hours ago
eurg | a day ago
thecapybara | a day ago
dimatura | a day ago
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).
gpm | a day ago
dimatura | 22 hours ago
gpm | 22 hours ago
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?
https://tailscale.com/pricing#application-networking
dimatura | 20 hours ago
tamimio | a day ago
dimatura | 23 hours ago
mycall | 19 hours ago
# 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.
Tor3 | 15 hours ago
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.
lysace | a day ago
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?
madeofpalk | a day ago
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.
nickburns | a day ago
tonyplee | a day ago
Unless one considers the meta data such as src/dest IP are visible to Tailscale sw.
Right?
nickburns | a day ago
The concept is separate from 'zero config' (https://en.wikipedia.org/wiki/Zero-configuration_networking), which Tailscale's low technical barrier to entry evokes.
Aurornis | a day ago
zephen | 23 hours ago
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.
baq | 23 hours ago
zephen | 21 hours ago
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.
mrsssnake | a day ago
QuercusMax | a day ago
Lammy | a day ago
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
nickburns | a day ago
I highly doubt any of this can actually be opted-out of. How else would they stay in business?
namtim | a day ago
The core client code is open source, feel free to inspect it yourself.
nickburns | a day ago
Don't let that deter you from trusting whomever you choose, though.
snailmailman | 19 hours ago
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.
nickburns | 9 hours ago
allarm | 5 hours ago
snailmailman | 4 hours ago
Lammy | 4 hours ago
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...
jzelinskie | 23 hours ago
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/networkzaphar | a day ago
dec0dedab0de | a day ago
iso1631 | a day ago
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.
NoiseBert69 | a day ago
newsoftheday | a day ago
Suffocate5100 | a day ago
allthetime | a day ago
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.
allthetime | a day ago
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.
pkulak | a day ago
fdefitte | a day ago
batrat | a day ago
UltraSane | 21 hours ago
jacquesm | 11 hours ago
resiros | 10 hours ago
itissid | a day ago
tecleandor | a day ago
mikepurvis | a day ago
itissid | a day ago
jahrichie | a day ago
nsbk | a day ago
josefresco | a day ago
dwedge | a day ago
aborsy | a day ago
So it runs a STUN server or similar, for discovery and relaying.
kabirx | a day ago
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).
shj2105 | a day ago
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?
kabirx | a day ago
himata4113 | a day ago
earthscienceman | a day ago
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.
yuvadam | a day ago
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.
hashstring | 23 hours ago
kittbuilds | a day ago
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.
drnick1 | a day ago
nickburns | a day ago
jon_adler | a day ago
nickburns | a day ago
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.
db48x | 10 hours ago
nickburns | 9 hours ago
eddyg | 7 hours ago
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.
drannex | a day ago
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.
adithyassekhar | a day ago
0: https://i.postimg.cc/14h3Q9mD/Screenshot-20260219-001356-Chr...
Edit: Nvm, found it. Weird place to put it.
yardstick | a day ago
adithyassekhar | a day ago
a_wild_dandan | a day ago
ChrisClark | a day ago
yardstick | 23 hours ago
drannex | a day ago
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.
alexktz | 17 hours ago
shj2105 | a day ago
allthetime | a day ago
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.
apenwarr | a day ago
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.
shj2105 | a day ago
kwakubiney | a day ago
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?
xeonmc | 23 hours ago
Also, offtopic question: is Tailscale named after the idea of UDP packets “tailgating” a connection?
alberto_delrio | a day ago
ZoomZoomZoom | a day ago
> 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.
xyst | a day ago
8cvor6j844qw_d6 | a day ago
drcongo | 23 hours ago
wolvoleo | 23 hours ago
resiros | 10 hours ago
dizhn | 5 hours ago
uneekname | a day ago
dblohm7 | a day ago
colordrops | a day ago
jbott | a day ago
colordrops | a day ago
Lammy | 23 hours ago
stavros | 23 hours ago
zx8080 | 20 hours ago
It's not "whartever code".
TOMDM | 19 hours ago
mnahkies | 14 hours ago
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)
DyslexicAtheist | 23 hours ago
someone13 | 22 hours ago
dblohm7 | 5 hours ago
ZoomZoomZoom | 23 hours ago
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?
dblohm7 | 4 hours ago
Tailscale is engineered under the assumption that any client connected to our control plane could potentially differ from our canonical OSS codebase.
globalnode | 22 hours ago
dovholuknf | 6 hours ago
1vuio0pswjnm7 | a day ago
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
Forgeties79 | a day ago
baq | 23 hours ago
Forgeties79 | 22 hours ago
You’re also operating under the assumption that people always have a choice.
pastel8739 | 18 hours ago
Forgeties79 | 17 hours ago
If it is not, I go somewhere else. “Going somewhere else” is not always an option when it comes to computers/software.
poszlem | 6 hours ago
Forgeties79 | 5 hours ago
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. I don’t value the imperfections.
We should not conflate tolerance and appreciation. Just because people tolerate it doesn’t mean they value it.
zarzavat | a day ago
tshaddox | a day ago
j-krieger | a day ago
varenc | a day ago
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.
pmarreck | 23 hours ago
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.
wolvoleo | 22 hours ago
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.
gzread | 22 hours ago
ulrttrktwej | 21 hours ago
denkmoon | 21 hours ago
gzread | 20 hours ago
ZoomZoomZoom | 8 hours ago
The integrated service is very valuable and obviously genuinely popular.
wolvoleo | 5 hours ago
wolvoleo | 5 hours ago
api | 18 hours ago
omnifischer | 13 hours ago
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...
mlrtime | 10 hours ago
cap11235 | 10 hours ago
omnifischer | 10 hours ago
allarm | 6 hours ago
Maybe? Things like super yachts are just offensive.
wanderlust123 | 10 hours ago
pitched | 10 hours ago
Preferring open source is a risk mitigation strategy. The closed alternative may have better features to make them worth that risk though.
philipallstar | 9 hours ago
ZoomZoomZoom | 8 hours ago
The amount of businesses closed, sold and products abandoned or swapped for the more controlled/exploitable ones is numerous, on the other hand.
johntash | 5 hours ago
jhatemyjob | 5 hours ago
gzread | 22 hours ago
mintflow | 18 hours ago
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.
segmondy | 18 hours ago
jak6jak | a day ago
Computer0 | a day ago
bityard | a day ago
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?
Computer0 | a day ago
patmorgan23 | a day ago
raggi | 13 hours ago
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.
velcrovan | 5 hours ago
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).
marcosscriven | a day ago
solarisos | a day ago
alexktz | a day ago
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.
ghthor | 18 hours ago
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:
timwis | a day ago
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?
1necornbuilder | 23 hours ago
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?
clarabennett26 | 23 hours ago
samat | 12 hours ago
I am not anti advertising, I just think pushing AI into places were people interact is very bad behavior and should be punished.
noirscape | 22 hours ago
jrm4 | 22 hours ago
What's the big deal here? Any good reason to switch (besides Tinc's obscurity?)
skinner927 | 20 hours ago
pluto_modadic | 19 hours ago
debarshri | 16 hours ago
icfly2 | 14 hours ago
codethief | 13 hours ago
corford | 8 hours ago
jamiemallers | 6 hours ago
What is interesting about this from an operations perspective is the observability challenge it creates. When traffic routes through a relay, your network monitoring tools see the relay as the destination, not the actual peer. Suddenly your flow logs, latency metrics, and connection traces all point to an intermediary instead of the real endpoint.
Teams running self-hosted monitoring stacks (Prometheus, Grafana, etc.) behind Tailscale need to instrument at the Tailscale layer, not the network layer, to get accurate topology maps. Otherwise you end up with dashboards that show everything connecting to a single relay node and wonder why your "distributed" system looks like a star topology.
The peer relay GA is great for availability, but I would love to see Tailscale expose relay usage metrics -- how often peers fall back to relays, relay latency overhead vs direct, bandwidth through relays. That data is gold for capacity planning in self-hosted setups.