Taildrop was kind of easy
tailscale.com
tailscale.com
Even supporting WireGuard's Share Secret feature would be a start.
As long as that's not addressed, not a chance in hell I'm going to deploy this.
PRs welcome :)
Tailscale was on the list for services to check, but if what you say is true, then I will look elsewhere.
I believe that the free tier is capable of running clusters of up to 50 machines. Really nice to use + truly trivial to set up.
Even bare Wireguard is a joy to set up, to my endless surprise, if you’re fine administering things as a traditional small-scale LAN, manual routing and all.
ZT is vulnerable to this because we actually try to make everything decentralized and self hostable. We are not making a cloud silo play where we try to lock everyone into our hub to do their networking, so we have to be able to monetize by licensing as well as SaaS. Our SaaS is optional.
This wasn’t an issue a decade or two ago when existing FOSS licenses were created. It’s an issue now, and is why other people working on decentralized easy to set up systems like CockroachDB use the same license we do. If CockroachDB were liberal FOSS someone would fork it and slap their name on it and scoop them, since by not having to do the hard work of actually developing it they could focus exclusively on marketing.
(You can self host ZT controllers, and roots become easier to self host in the next major release. Once we do that the protocol could theoretically outlive the company with no loss of functionality including its unified namespace.)
More generally, I like what you said a little while back in the thread about the Mighty remote browser [1]:
> (2) The hopelessly naive idea that "information wants to be free" and everything has to be "free" (as in beer) needs to die, be cut into a thousand pieces, burned, encased in concrete, and sunk to the bottom of the ocean. Nothing is free. Software takes a vast amount of labor to produce, and that must be funded. If it's not funded directly and honestly it will be funded indirectly and dishonestly (surveillance capitalism, cloud lock-in, etc.). "Everything has to be free" and piracy actually help push us toward a surveillance capitalist panopticon future.
That point should be front and center in all discussions on FOSS sustainability (or lack thereof).
You’re absolutely brilliant (like Cloudflare), your goal does not seem evil (similar to that of Cloudflare), neither do the consequences of achieving it (somewhat less like Cloudflare), and you haven’t done outright evil things like patent clever but fundamentally simple tricks (have I mentioned I’m conflicted about Cloudflare?). And when all is said and done, you do have to pay your bills, and only you can say what works and what does not in that respect.
So I applaud you when you say, loudly and honestly, that the goal of your licensing model is to pay for the development by making yourself an essential part of it. I believe you when you say your work couldn’t exist otherwise. But my mental model of (dev– and knowledge-of-humankind–centric) open source (unlike that of user-centered free software) is that its very essence is the original developer making themselves unessential or at least not using legal threats to preserve their special position.
Thus I am explicitly not saying that your non-open-source approach is evil—that would be unjustified purism; morality judgments are difficult and best not employed as one-sided proclamations. I am not expecting that you will go home ashamed or mend your dastardly ways, because you have nothing to be ashamed of, your ways are not dastardly, and I have no idea how you could mend them and still survive. I am saying that your non-open-source approach disagrees with the very core of the open source idea as I best understand it, not on a purist technicality but in a fundamental way.
Bruce Perens co-founded the OSI. He seems to have given up on the idea of open source in the age of mainframe providers wielding armies of star programmers, and probably would not have any issue with your strategy. I am younger and have not given up yet, so I look upon your strategy with sadness and a longing for a better world.
Bruce Perens is much smarter than me in more ways than one.
Closed silos don't have that constraint so they will win by sheer muscle power.
The BSL (our current license) sort of sucks, and I look at it as a stopgap until we can come up with something better. I have some ideas, but they need to be developed and so far I have not had time to develop them further since coding and running a company are fairly demanding.
They deserve a blog post at least.
Outstanding reply BTW.
Please do note that zerotier is still source available (with 2025 - 5 years? Transition to apace Foss license): https://github.com/zerotier/ZeroTierOne/blob/master/LICENSE....
So, AFAIK you can self-host, audit and patch.
(lots of great discussion on Foss vs non-foss, pragmatism etc in this thread, to which I can't add much)
I guess nebula is: https://github.com/slackhq/nebula
Anyone tried it vs zerotier/wireguard/tailscale? I must admit building on wireguard is a major draw for tailscale.
Roots in ZeroTier are harder to self host right now (it’s getting easier in the future) but they are just dumb STUN/TURN equivalents. They have no power to grant access and can’t even see what networks you join or what you are doing.
Do you also manufacture your own silicon in fear of being owned by your hardware vendors?
Write all your own software?
In fear of being owned by zero days in open source?
Security breaches happen every day, with serious consequences. These are real threats, and there are ways to mitigate against them.
A target like that coordination server is particularly risky because, as we saw with the massive Solarwinds attack, attackers will look for and expend effort to compromise the most attractive targets, and that's a particularly juicy one.
Dismissing such threats with false equivalences is a pretty good way to find yourself on the wrong side of a security breach.
Either you trust the entity whose code you are consuming or you don't.
Do you trust WireGuard to not get owned via a supply chain attack? Like Solar Winds.
Do you trust any open source project you currently use to be free from bugdoors? Like University of Minnesota recently demonstrated by submitting intentionally-vulnerable patches to the Linux kernel.
An always-on service is an ongoing, continuous trust relationship with continuous temporal vulnerability
Consequently, while I can reasonably safely apply a lower bar of trust to libraries and code, someone asking to be continuously trusted must be held to a distinctly higher standard.
It is can be valid to trust that as well, but you're operating from a crippled starting point for your security engineering if you don't see those as separate categories of issues to address.
You are lying to yourself.
You are necessarily claiming that a single person (you) is capable of adequately verifying the trustworthiness of the work of hundreds (perhaps even thousands) of developers.
That's just the story you tell yourself to convince yourself that you are in control.
Mean while FAANG have been doing it all wrong by hiring thousands of security engineers. They should've hired you.
Also, this seems backwards to me. You trust Tailscale at the network layer. If they abuse your trust to inject routes/keys your machine becomes network-reachable but all of your other controls are still in tact.
That's not true when you applications violate trust.
You can do AppSec if you don't trust the network. You can't to NetSec if you don't trust the application.
I guess you could split it in half, and pair it with some actual service that the customer runs, and let it just be a dumb relay of encrypted/signed/whatever data.
"Bust a NAT" is anything but easy, however.
With a Cisco ASA or Fortigate which tends to keep the same source port where possible you'll converge far more quickly. When there's a central server to help it's even quicker and most of the time will just work.
(sometimes it's not possible to keep the same port when source-natting -- with two devices from 192.168.0.1:9000 -> 1.1.1.1:53 and 192.168.0.2:9000 -> 1.1.1.1:53, the second will have to have a mapping to non-:9000 source IP, but in my experience, Cisco, Fortigate and Mikrotik (thus linux) all support the "only change if needed" option)
Basically, Knuth was writing a beautiful but excessively low level program. His challenger wrote a dozen lines of shell-script.
I guess, if you really wanted to solve this fast, you'd massively parallelize.
In any case, this was more about easy of implementation than about runtime speed.
Incidentally, a couple of days after that thread, the current fastest submissions (which, like Knuth, all use tries) were posted at the question https://codegolf.stackexchange.com/questions/188133/bentleys... mentioned in a sibling comment. (AFAICT that comment should say "200 times faster", not "30 times faster", but anyway in light of the original context it's not meaningful to compare the two approaches either for efficiency or ease of implementation or anything else.)
Yes, my 'challenger' didn't mean to imply a formal contest.
The data plane is how the bulk of your packets get sent from one place to another, which in Tailscale is peer-to-peer (as long as your network is not completely blocking NAT traversal for some reason). Even if NAT traversal is blocked and we have to relay your data through the cloud (through our DERP network) to make it work, the data plane is still end-to-end encrypted using private keys that only exist on each node. The private keys never leave each node. The DERP servers are just relaying opaque byte streams, like any IP router would do.
On the other hand, the Tailscale control plane uses a central coordination service. It's used to exchange public keys and STUN information between nodes, but this is a tiny amount of information updated rarely (and therefore reasonably cheap for us to handle at scale). These public keys are not enough for an attacker (us or anyone else) to be able to decrypt your data traffic.
So when we say taildrop never sends your files through the cloud, that's because taildrop exists entirely inside the data plane, sending data through e2e encrypted tunnels that have already been established with the help of the coordination service, STUN, etc.
Because the coordination service is cheap for us to run, we can have a really generous Tailscale free plan without losing all our money. The paid plans are intended to be for "corporate network" situations where people want more centralized controls, audit trails, and so on.
Out of curiosity, how often does this happen in practice? Also, how would you even do this? Isn't NAT traversal a direct consequence of how firewalls work and always possible?
Tailscale has an article called How NAT Traversal Works with considerably more gory details if you’re interested.
How do you assign devices to logical networks?
How many virtual networks can be run concurrently on a single device?
The way tailscale networks (tailnets) work is probably not how you’re used to thinking about them. Each node has its own view of the world, based on which nodes and services are shared with it in particular. We have security policy settings per domain, and a node sharing UI that lets you share any of your devices with anyone else.
The default model is that all devices belonging to someone in the same domain, say tailscale.com, can see each other. But we’re working on making that even more flexible since it doesn’t always do what you want for huge orgs (like universities).
Do you think it is sufficient to rely on update channels via distributions? Wouldn't a bug in your code potentially expose an internal node to the internet?
> Each node has its own view of the world
I haven't read the docs enough, but can a node belong to many domains at once? If so, does it need one port per domain that it is shared on?
Tailscale employee here. Most officially supported distributions use our own package repo server (https://pkgs.tailscale.com), which would pull Tailscale updates in your normal system updates. The other distributions that aren't in the package repo server (Alpine, Arch, Gentoo, NixOS, Void Linux, etc.) use packages made by the distribution themselves. We do our best to make sure they get updated (contacting the maintainers can be a slog at times), but we do not completely control the update process for them.
> I haven't read the docs enough, but can a node belong to many domains at once? If so, does it need one port per domain that it is shared on?
Not currently, follow this bug (https://github.com/tailscale/tailscale/issues/713) to be updated on the details for this. You can sorta hack around it with node sharing (https://tailscale.com/kb/1084/sharing/), but that's unidirectional instead of bidirectional.
re:whois: I presume this is in control of a central identity service. I see that the private tailscale network is (mostly) p2p and (always) e2e, so wondering if you envision a future where the tailscale network goes decentralized without a central control àla BitTorrent / LimeWire (despite [0])?
re:peerapi: Excuse my naivety, but couldn't this binary transport be used for file transfers too? Or, does http simply provide too many (file transfer) options [1] to not bother re-implementing it in a custom protocol?
Thanks.
[0] https://apenwarr.ca/log/20201227 (when's vol.2 out?)
[1] I can see screensharing up next, a keybase-like chat client, and even live video / event streaming?
You’ve correctly guessed that blog link [0] that explains the reason I don’t think we’d ever want to try making a distributed coordination service. Most importantly, corporate customers absolutely love having a single control and registration point for every corporate authorized device on their network (and thus, a way to instantly deauthorize stolen devices). What we’re going to do though is add private audit trails and tamper proofing, kind of like TLS certificate transparency, so that the central instructions can be validated in a decentralized way, if that makes sense. More on that later. :)
Re: peerapi, there are lots of ways to build app layer protocols once you have tailscale making the connection itself easier. We picked http since it was the fewest lines of code and it makes an easy example.
Re: live video, Jitsi already works fine on a tailscale network if you want to try that.
Curious about the underlying design decision on why a separate peerapi layer if a golang http/2 server is listening already (or is peerapi running over http, too)?
> What we’re going to do though is add private audit trails and tamper proofing, kind of like TLS certificate transparency, so that the central instructions can be validated in a decentralized way.
Exciting. Reminds me of: https://blog.okturtles.org/2014/09/the-trouble-with-certific... and https://book.keybase.io/docs/teams/sigchain
> ...there are lots of ways to build app layer protocols once you have tailscale making the connection itself easier.
True. My previous employer built an internal service similar to tailscale but it worked over bluetooth, wifi-direct in addition to ICEing NATs out. It made device discovery, cross-app, cross-device, cross-service communication super easy.
Thanks again.
This enables unauthenticated file transfers between hosts on the same network.
Given the world we live in today is that RCE vulnerabilities are relatively common, what happens when host1 gets some malware and uses this to transfer itself onto host2?
I assume this has been considered, and it's been decided that the convenience of the feature outweighs the security and reputation risk considerations?
That still allows malware on a trusted end device to connect to you, but then if you've got malware on the box chances are it will have access to the private keys, authentication cookies etc, anyway - at least currently.
But my personal experience is that most software is completely hostile to good security practices and you end up having some perimeter security as well.
This is one reason we limited taildrop to only transfer between devices owned by a single user for now, and only to drop files into controlled locations. Tailscale also has ACL policies for when you don’t trust all the endpoints to just do anything.
Lets you choose which users/machines/tags can talk to who. Tags are like groups.
Is the GUI open source somewhere?
> Everything in Tailscale is Open Source, except the GUI clients for proprietary OS (Windows and macOS/iOS), and the 'coordination/control server'.
Keeping the GUI clients for proprietary operating systems closed-source is certainly a valid business decision. It's just unfortunate that it means we don't get to fix any issues we find that may matter more to us than they currently do to the Tailscale team, e.g. accessibility.
Edit: Yes, I know, to be fully consistent on this point, I should run an open-source OS. But then, the proprietary operating systems have accessibility teams, while presumably Tailscale does not.
To give a concrete example, I had been dragging my feet on moving some old but useful keys/tokens between my Windows desktop and MacBook — using taildrop, the transfer was both easy and virtually instantaneous.
Historically, it's always been such a pain to either have to upload/download the file(s) from a cloud service (what if I need to move private keys? that adds another layer of complexity/annoyance because then I need to encrypt them) or find a usb drive, plug it in, copy the files, eject, find the adapter for my macbook, plug it in, copy the files, eject, etc. Taildrop completely fixes all of that — it's amazing!
> Sign up with your identity provider...
This frightened me enough not to use Tailscale, I don't want Google / Microsoft sharing any more of my data. Is this still the case?
If I use an OAuth integration I'm involving a third party
Some people use a third party email provider, but chances are they aren't supported (even if your mail provider offers oauth integration) -- the only support is with Google and Microsoft
Now that aside, I support the idea of tailscale not creating its own identify provider. BYOI is far better than yet another supplier to leak information and yet another password to manage.
If I were interested in integration with my company's SSO, I'm sure they'd be able to support our OAuth endpoint.
For personal use, chances are you have an identity with one of the providers, and the information leaking to that provider (that you use tailscale) is minimal and seems like a good solution.
Why would it be? It's a commercial service.
>Such that I can set this up myself for my own purposes 1:1?
I'm guessing both peers ping a central server in order to discover each other, which is why it's integrated with tailscale at all. If you're in the tiny segment of the population who is already paying for a server with a public IP, and have the technical ability to deploy services to it, I feel like it would be marginally less effort to just sftp the file to that server rather than try to clone the feature set of taildrop.
Tailscale could theoretically publish a docker container that contains the guts of this service, but it'd be rather a lot of work, for no money.
>>Sign up with your identity provider...
I have not seen a lot of evidence that regular users care about identity provider privacy, seeing as how Facebook had 2.8 billion monthly active users last quarter. That customer segment (half of the world population) might be more interested in signing up for the free tier of tailscale and getting magic file sharing than they would be in administering their own linux server.
Open source is a good way to get community buy in, because it improves transparency and reduces lock-in. There are lots of open source commercial services, including the Tailscale client service.
https://github.com/zerotier/ZeroTierOne/blob/master/LICENSE....
I'm personally really tired of fake open source projects like this.
Btw, there is no IdP support in Headscale. You need to have access to the machine where you are running it, and use the CLI to register your machines (or use a authkey, ofc).
It doesn’t seem like a scenario / use case envisioned in their pricing page.
In theory a bunch of individuals on the free plan should be able to build arbitrarily complex networks by using the (also free) node sharing feature: https://tailscale.com/kb/1084/sharing/
In practice, probably needs more stuff added before that's truly realistic. But we're always looking for feedback on how to make it easier.
I get that Tailscale didn't invent this capability, but they do a nice job of showing how it would work, some of the pieces (wireguard-go), and so on.
They do seem aware: https://github.com/tailscale/tailscale/issues/204
Might have been better if they built on bonjour/zeroconf rather than make a "tailscale" api though... on the other hand, I guess bonjour/zeroconf works oob on tailscale anyway.
Which makes this more of a marketing for a new api/app platform?
LAN discovery is handled by Tailscale's network engine, a couple layers of abstraction below the file sending. We're going to add some mdns stuff in there at some point (similar to WebRTC's privacy-preserving LAN endpoint discovery), but the benefit of running this all over Tailscale's network engine is that file transfer works exactly the same whether you're on the same LAN as the target, or halfway across the internet. The only variable is how fast the file moves.
For others: therr others that will appreciate the better security offered by using public key cryptography while still having a lightwight but decentralised setup?
You can also achieve something similar with WebRTC in any browser and "zero" dependencies.
If you have tailscale installed on your machines you already have a secure communication channel available to you.
There may be good reasons. But they'll need to be explicitly spelled out for most users.
If you just have mobile devices and always take them with you, or don't care about accessing a desktop computer when you're away, it's maybe not that interesting?
The tailscale team has gone through great lengths to handle a lot of edge cases and hacks in the infrastructure at many corporate networks.
It let me SSH back into my Mac Mini to compile elixir and run VS Code Remote and not kill my battery, but still have zero latency UIs over cellular tethering.
I tried Zerotier a few years ago and maybe I just did something wrong but I couldn't get it working for an hour and gave up.
Basically sign up for account -> install -> allow to join network in Dashboard. That was it.
- Tailscale is an IPv4 vpn. Zerotier is a virtual ethernet switch.
- Tailscale does not do ipv6, ipx, or any other protocol. Zerotier doe.
- Zerotier supports multiple networks. Tailscale only has 1 network per account. So it's not possible to be connected to WORK1, WORK2, HOME at the same time.
- Zerotier handles broadcast / multicast perfectly.
- Tailscale uses wireguard, whichs means it's probably going to be more compatible
- Tailscale forces SSO on certain domains (for example gmail). I really don't like being forced to use this. It's nice to have the option, but usually they require too much information.
- Tailscale uses login credentials to link machines, vs using machine keys in zerotier. I prefer zerotier's method, as I really don't want do the whole login flow all machines.
- Tailscale by default expires the sessions after X amount of time. Super annoying when you discover things are not working, because you didn't change a setting somewhere
- On mac, tailscale uses a VPN tunnel. Zerotier creates a virtual interface. I prefer zerotier's method.
- Because of this, tailscale is available via the appstore (mac). I like that. Both are available on the ios app store
- Both have some sort of SDN language / configuration.
- Tailscale is only an ACL type config, which is good enough for most
- Zerotier's is more extensive, and allows cool things such as redirecting packets to a different machine for inspection. Great for security monitoring and other stuff.
- Tailscale comes with a built-in dns, which is nice. Zerotier is working on that
- Zerotier has public networks. While I think it's a bad idea, it's pretty fun and dangerous
In terms of stability and performance, they're both stable and fast. Somehow zerotier does not get as much love as wireguard. Or nobody talks about it ;-)
Tailscale seems to forcus more on higher layer apps (filedrops, service discovery (just a portscan), simple firewall rules), while Zerotier seems to focus more on the technicalities. Tailscale is trying to look for which value adding features are popular amongst clients.
This makes sense, as tailscale simply uses wireguard, and zerotier is their own tech. Zerotier seems to be run by networking people. This is also the things that works against zerotier.. UI is clunky, the SDN language is difficult, no service discovery.
Imo zerotier's updates and development is very slow. Not sure why.. Maybe they lack a roadmap.
For zerotier to be easier to use, they could create a visual editor for the networks, by actually showing a switch, using cables on the ports, and different colors for different rules. This is more in line of what they do (global ethernet switch), instead of a VPN.
Also, I think zerotier should do more official integrations with routers / nas. Wireguard at a certain point will be integrated in all routers, because it's in the linux kernel.
Tailscale does! https://github.com/tailscale/tailscale/issues/19
$ ip addr show dev tailscale0
4: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 100.67.184.57/32 scope global tailscale0
valid_lft forever preferred_lft forever
inet6 fd7a:115c:a1e0:ab12:4843:cd96:6243:b839/128 scope global
valid_lft forever preferred_lft foreverMy only complaint is that there is no good alternative to authentication other than using Google for small deployments like this. I don't want to pay an auth provider, and none of them offer a simplified plan for 3-4 users.
I’m definitely not using Google for auth if I can avoid it.
Aren't you afraid that a family member compromises "your" network? I would be cautious to let my parents operate within my intranet unchecked.
Does Tailscale have any means to monitor or tie this down without being a drag?
I am still stuck with doing TeamViewer into family devices, because it seems less risky.