In-Depth
Hands On with Tailscale Zero Trust Mesh VPN for the Enterprise
Tom sets up remote access to his home lab, adds Linux and cloud devices, explores Tailscale's features and technology -- and really likes what he sees.
In a previous article I set up remote access to my home lab using the personal (free) edition of Tailscale. This was one of the easiest products I have ever installed and used. I just needed to create an account on Tailscale and download and install the Tailscale agent on a machine in my home lab and on my laptop. Then, I could access the home lab machine via RDP and use any other network services on it regardless of where I was. It was that easy.
Although Tailscale is incredibly generous in offering a free personal edition of its software, its chief market is enterprise customers who need an easy-to-use enterprise-grade VPN.
In this article, I will explore additional features of Tailscale and explain its technology. If you have not read my previous article on Tailscale, I highly recommend that you do so. It will give you some background on the company and explain how I used it to set up remote access to my home lab.
Installing Tailscale on Linux
I installed the Tailscale agent on a Windows machine in my home lab. From this machine (Jumpbox), I could access the other machines in my home lab using RDP, SSH or any other networking protocols from another system running Tailscale, regardless of where they were located. Since then, I have added Windows machines (nodes) to my Tailscale network (Tailnet). It was just as easy to add these as it was to add my first machines.
I also have Linux systems in my home lab that I access using SSH. As Tailscale supports Linux machines as well as macOS, IOS, Android and Windows OSes, I thought I would see how difficult it would be to incorporate my Linux servers into the Tailnet.
Installing an application on Linux can be challenging due to the wide range of Linux flavors or distributions. However, Tailscale makes it easier with two installation options, allowing users to install it with just one command or manually on most Linux distributions. Additionally, Tailscale is available for both 32-bit and 64-bit distributions of Linux and supports x86 and ARM architectures.
I figured I would first try the one-command install option. The Linux system I used was an old Fedora 34 Linux server that I use as a print server. After logging on to the system, I entered:
curl -fsSL https://tailscale.com/install.sh | sh
After less than a minute, it installed the Tailscale agent and all its dependent packages, set it up as a service and told me to configure it by entering "sudo Tailscale up."
This printed out a URL I pasted into a web browser and authenticated.
The Linux device was then added to my list of Tailscale machines.
From an external network, from my Tailscale-enabled laptop, I could access the Linux machine using SSH and its Tailscale VPN address.
Once again, I was amazed at how simple it was to set this up.
Installing Tailscale on Cloud Devices
After successfully installing Tailscale on devices on my home LAN, I decided to try something more challenging: installing it on a Windows VM in a datacenter across the country protected with different firewalls and security procedures. Again, the installation was painless and worked flawlessly.
I also have an Oracle Cloud Linux VM with which I installed the Tailscale agent without issues.
How Tailscale Works
After having incredible success working with Tailscale, I decided to investigate its workings. I could have examined the open source code, but instead, I looked at the web page explaining it. Below is a short synopsis of how their technology works.
Tailscale uses Wiregaurd, a popular open source VPN that creates a set of extremely lightweight, encrypted tunnels between your computer, VM or container (nodes) and any other nodes. Instead of using a traditional hub-and-spoke topography that relies on a central VPN gateway, Tailscale uses a mesh network to connect each node without going through a central VPN gateway. They call this a Tailnet.
Tailscale's decentralized mesh topography overcomes the limitations of having a central gateway, geographical localization, excessive and hairpin network traffic and a single point of failure.
Using a mesh network is a more elegant way to connect one system to another, but the problem is the control plane, which dictates what can connect to what and has the encryption keys that keep all your transactions from prying eyes. Each Tailnet has it own control plane, called a coordination server, which Tailscale hosts. This contains the nodes' public keys and the policies for a person's VPN. Tailscale doesn't do user authentication; it outsources authentication to others, such as Gmail and Office 365.
With all these pieces in place, the Tailscale nodes can pass information between one another!
It should be evident to the most casual observer that this is a gross simplification of how Tailscale works. If you are interested in further details, visit Tailscale's web page.
Other Tailscale Features
Tailscale has features required by enterprises:
-
LOGS: Audit logs are often a requirement, and Tailscale has a centralized repository for logs that is updated in real time.
- Node Configuration Data: You can see the configuration data for each node from the admin console.
- Users: Tailscale has different user roles that can be used to give others access to the admin console or nodes. To test this, I created a Member user. Member users cannot access the admin console but can connect to nodes as ACLs permit. When I created a user, it created a URL that I sent to the user. After I clicked the URL and authenticated, I could access all the nodes but did not have access to the admin console.
- Access Controls: Policies allow you to specify which users can access nodes. At this time, these are done via JSON text files.
- Services: You can enable Tailscale to monitor the services running in your environment. Once enabled, you can see what services, such as SSH and RDP, are running on the nodes in your Tailnet.
- MagicDNS Names: Remembering IP addresses can be difficult, so Tailscale provides DNS names for the nodes in your Tailnet.
- Subnets: You can set up subnets to expose physical network routes to Tailnet. Subnet routers act as a gateway, relaying traffic from your Tailscale network onto your physical subnet.
- Apps: You can route traffic to third-party Software-as-a-Service (SaaS) apps through connectors on your Tailnet.
These are just a few of the many features that Tailscale has and supports.
Use Cases for Tailscale
The Tailscale business model is not giving away three-user, 100-device licenses to home users. It is to provide a useful product that enterprises will pay for. Some of the use cases for it include replacing site-to-site, AWS and GCP VPNs, transparently interconnecting microservices between datacenters and pods, replacing complex physical network (wired and Wi-Fi) security schemes and other cases where a highly secure, robust and easy to set up VPN is needed.
Tailscale has a web page dedicated to the use case, and the one of use case that caught my eye was how Finter in Norway uses Tailscale with a toll collection system to share traffic information over a 4G network.
Tailscale proves that IT doesn't need to be complicated. In the past, setting up a sophisticated VPN that would allow me to connect to machines in my home lab would have taken me hours, and I would still be worried about its security. However, using Tailscale it took me less than two minutes to set up and start using its VPN. I feel very confident with the security it provides, and in the three weeks I have used it, I haven't had any issues with it.
About the Author
Tom Fenton has a wealth of hands-on IT experience gained over the past 30 years in a variety of technologies, with the past 20 years focusing on virtualization and storage. He previously worked as a Technical Marketing Manager for ControlUp. He also previously worked at VMware in Staff and Senior level positions. He has also worked as a Senior Validation Engineer with The Taneja Group, where he headed the Validation Service Lab and was instrumental in starting up its vSphere Virtual Volumes practice. He's on X @vDoppler.