How Tailscale Works
tailscale.com
tailscale.com
My main concern currently is the coordination server which does not fit the zero trust claim.
I know that the traffic between peers is end-to-end encrypted and you did a good job designing your DERP protocol. However, the ability of the coordination server (login.tailscale.com) to add arbitrary nodes to my private network without my consent scares me.
Maybe you can use Wireguard's PSK to add an additional pre-shared-key to all nodes that is not managed by the coordinator (and never transferred to it)? This would make the setup slightly more difficult (you need to login to tailscale.com AND you need to provide your PSK), but it would at least ensure that the system can never talk to foreign nodes added by the coordinator itself (because the foreign nodes do not know the PSK).
If you already use the PSK for something else, another passphrase/key-file that is never transmitted and is XOR'ed over the PSK will do the trick. The firewall configuration that is pushed to all clients should be probably signed by a local key too, since it is rather critical.
Another possible attack of the coordinator would be if he pushes a configuration with correct VPN IPs and correct public keys, but changes the mapping between them. Since the IP within a wireguard network is usually used as an identity, this might be a huge problem.
We have considered other certification options, but so far they boil down to running a part of the coordination server on-prem. Still exploring the space though.
(I work at Tailscale)
I think tailscale could become the #1 solution for personal users and small / mid-sized companies (some of them might not even have an IT dept). At least the easy installation, the single process design (no separate IKE service etc.) and the opinionated modern cryptography - that deliberately does not allow any configuration at all - would make it a really good candidate for those use cases.
This users can probably rent a cheap $3 VPS easily and use it as an on-prem coordination server. However, this increases the installation effort considerable and trusting the cheap $3 VPS to be an essential part of your cooperate network might be a deal breaker. Many of those users might not even have a dedicated team for server maintenance and might not apply security updates regularly.
So, please add an (optional) additional PSK (or key pair / certificate) to each node that is not shared with the coordination server and can be used to sign / verify the configuration on each client. Users that do not care don't have to specify anything (they just have to log-in and everything works). Users that do care would have to login and provide the PSK on each device.
(And to be clear, the problem is not that I do not trust you. I am sure you are doing a great job and I would really like to use your service. But you are an US based company and with the new data protection laws within the EU it might not be easy to convince all customers that potentially sending all their data to a third-party company within the US is necessary.)
With ZeroTier, the client connects to the network using a private shared key and then needs to be approved on the control plane independently.
We have plans to address this ourselves more with a higher level UI to build rules from intents and common patterns. Also have more auth integration planned, but the list is long.
The firm doing our security audits is an extremely well known one. Don't want to reveal the name quite yet.
It's possible that some of that won't land fully formed right away in 2.0 but will follow shortly thereafter, but the performance, auditing, crypto, and multicast will be there.
There is mention of STUN, but CGNAT is a whole new level of ugly and there is often NAT behind the CGNAT.
If not, do nodes that can get incoming connections become relay "super nodes?"
IIUC it’s an application of one of my favorite design patterns: “this part needs CP, the rest is more flexible”.
It’s remarkable how far this gadget can take you.
http://adamierymenko.com/decentralization.html
It describes a route whereby I got to the concept, but I doubt I'm the first one there. Everything gets reinvented over and over again in this field.
Seems like I would need to setup a bastion device (virtual machine / container / other) with port forwarding for each Load Balanced Application since ACLs are set on the device level. The bastion would then be a single point of failure. Is there another way?
(Tailscale co-founder)
Hopefully we can make this self-serve at some point. It's on the TODO list.
(Tailscale co-founder)
I think the ideal case is Tinc continuing to manage the control plane for mesh networking, integrated with Wireguard as the actual VPN under the hood (given its rapid emergence as the de-facto "Linux VPN"), combined with a (currently absent) central identity management system like what tailscale provides.
Windows Server with file share behind a sonicwall firwall. Large (now very large) number of remote users need to access file share.
Currently users connect using a VPN that terminates at the firewall, with access rules allowing access to file share.
Is this use case supported with tailscale? Ie, run something on server, allow users to run something, they can then connect to file share?
Anything to do on firewall to make this all go faster / easier?
As others have mentioned - we cannot let third party add nodes to our network without approval. Adding a PSK or something to let us lock network down a bit more would be good I think.
Edit: Installing at home (google wifi for router) and work machine (behind sonicwall) - can't get RDP/Remote Desktop to connect but client install / login is great and would be much easier than current approach if it worked.
I am a newbie and would like to understand.
They'll be assigned IPs and can reach each other.
(I'm a co-founder of Tailscale.)
Tailscale offers a centralized server to allow nodes to provision themselves. It bootstraps that trust/account system of of logging in with some account, such as via a google oauth login.
I use ansible to keep all our computers up to date and maintain an ldap server for some basic information; my parents are old and not tech savvy, so I do my best to make it easy for them.
Initially I set up tailscale, but the lack of an android client and the difficulty of setting up the raspberry service made me to switch to zerotier. Thing is, I really wanted that to work, as the ping with wireguard between the mesh instances was so low that surprised me.
Oh well, zerotier achieves what I want for now and it has the added benefit of letting you choose the private IP range that you like. I'll definitely keep an eye out for tailscale in the future though.
Good job on open sourcing your work and best of luck.
In any case the one concern I had was the coordination server being able to add new nodes as another commenter mentioned. Indeed when I first set it up, they added some dev node for chat to my peers by default! That worries me a bit. You basically have to trust their coordinator is super secure. Otherwise if someone can abuse it, they could add nodes to your very private network.
TCP hole punching - I don't understand this, can you elaborate? By running Tailscale you can just talk to the machines on your Tailscale network, no hole punching required. At the transport layer we might do NAT traversal shenanigans to get the mesh network up, but that's invisible to the "user layer". I'm guessing you mean something slightly other and I'm just not parsing correctly?
TCP hole punching uses symmetrical TCP open trick to establish a proper TCP session between nodes each behind its own NAT. Roughly the same idea as with UDP h/p, but requires a coordinating server to make it work. Useful for cases when UDP punching doesn't work or when UDP is blocked completely.
My first concern was how it will be abused by malware and blocked by different networks. For example ngrok.io is classified as "proxy avoidance" which means if I use it and go to a client site that blocks it,it will create an awkward situation. But I think requiring 3rd party idP might solve this issue with tailscale.
Example: Start it on all your devices and you can always access the shared files from your PC at home on your phone or tablet, no matter where you are. If you happen to be at home, no packages will be sent over your internet connection (so you can easily use it to stream 4k movies for example), but the way to access those files is always the same (fixed IP) and always secure.
An additional advantage of Wireguard (which is used behind the scenes) is that it maintains a strict mapping of IP addresses and identities. Therefore, you can usually restrict access to services by IP (instead of using TLS certificates or complicated authentication mechanisms).
It scales great, not concentrating connections makes it easy. Tunnels are very lightweight and the only machines with lots of tunnels are servers that are already provisioned for talking to lots of machines.
(Tailscale co-founder)
Additionally, we rotate keys. For security sensitive users we can rotate these keys daily.
update: apparently, only Linux client is open-source. My bad.
That said, I'd like to open source a server. We need a reference implementation of our control protocol so it can be properly analyzed by security experts. Not sure what form that should take yet, but I'd like it to be usable.
Your coordination server tells every node about every other node and distributes the keys for the entire network. Everything on a tailscale network implicitly trusts your coordination service.
If an individual client is compromised, code or otherwise, the effect is more limited than your coordination service being compromised, in which case the entire system's trust is broken.
Rename this website to Tailscale News.
What are you doing that's interesting? Post it here and you can get the free advertising too.