It’s basically a Wireguard Mesh VPN

Disclaimer

I’m not an affiliate of Tailscale or any company related to it. I’m blogging about it because I think it’s a really good idea. This post makes no money fromTailscale or any other affiliation.

Oh, and for the spelling pedants, I try my best, however, I’m not a media editor, I’m 1 bloke on a small corner of the web.

Normally when you’re setting up a VPN for people or sites the traffic aims for a single point of entry (or multiple points of entry if you have failover).

This example has satellite sites and users connecting to the central VPN in the head office. If Traffic from NYC needs to get to Austin it goes via the VPN Hub. This VPN Hub may be a failover pair or cluster however from a connectivity standpoint it’s not efficient.

It’s possible to use more traditional methods of connectivity to do this more efficiently using private networks, multiple VPN Endpoints and other methods, these start adding to complexity and cost.

If I look at my own setup

Even with my two sites, I’d need to, in the traditional sense of networking add an external VPN device on each end and set that up as a point to point tunnel, add the routes in and firewall rules then monitor the logs.

That’s cost (direct at the Vultr end) and another box to maintain.

So what does Tailscale do differently?

With Tailscale each device on the Tailscale Lan is an endpoint, allowing for a mesh to be created. This removes the single point of failure and potential latency issues as there can be multiple paths to the same endpoint…

If AUS went down PDX could still communicate with CHS via DTT.

This however is all being done using an agent on servers rather than separate hardware.

To quote the website

The service handles complex network configuration on your behalf so that you don’t have to. Network connections between devices pierce through firewalls and routers as if they weren’t there, allowing for direct connections without the need to manually configure port forwarding. It allows for connection migration so that existing connections stay alive even when switching between different networks (e.g., wired, cellular, Wi-Fi, etc). With MagicDNS, you don’t have to deal with IP addresses – you can SSH or FTP into your device, transfer files between devices, or access a web server or database by just using a memorable hostname.

There is a really good explanation on the Tailscale site about this and more about how it works.

How Tailscale works
People often ask us for an overview of how Tailscale works. We’ve been

As described in our blog post about how Tailscale works, the coordination server is the single, centralized component of Tailscale’s architecture. It is responsible for distributing public keys and firewall rules to all Tailscale devices on your network. However, if the coordination server goes down your Tailscale network will mostly continue to function:

  • Tailscale does not route any traffic through the coordination server. Instead, Tailscale makes a best effort to create a direct connection between each pair of devices communicating with each other. In cases where a direct connection cannot be established, devices will bounce traffic off of one or more DERP servers, located in different regions all over the world.
  • Devices’ keys are stored locally. Devices can continue to communicate with each other until one of the device’s keys expires. Note that the expiry time is device-dependent (based on the last time an authentication took place), which might be different between devices in a given network.
  • Firewall rules are cached and enforced on each device, meaning that your existing rules and ACLs will continue to function.

On the other hand, without the coordination server in place:

  • New users and devices cannot be added to the network.
  • Keys cannot be refreshed and exchanged, meaning that existing devices will gradually lose access to each other.
  • Firewall rules cannot be updated.
  • Existing users cannot have their keys revoked.

Tailscale – My Journey

When you put your services on multiple locations, you start to work in the world of cross-site routing, or linking sites to each other and making there work seamlessly together.

When I started looking into this my first inclination was to link the two sites (home and Vultr) using a Wireguard VPN Tunnel. the driver for this. It’s usually more simple to set up than OpenVPN. However yet again I fell foul of an issue I have at home because of a Double Nat environment I have set up.

I went back to the drawing board and asked myself what was I looking to do?

I wanted all the servers at home and Vultr to be able to communicate with each other.

After a bit of googling, I came across Tailscale, the answer to this and many other questions.

What is Tailscale?

Tailscale is a zero-config VPN.

A solution where an agent is installed on every device you want on a VPN mesh. This agent sets up a new network endpoint/card on that device and assigns a Tailscale managed IP unique to your login which is static (it’s assigned by DHCP, but doesn’t change) to each device running the agent.

Traditionally networking between sites would look like this

With Tailscale it looks like this

Because each device is running on the same IP network irrelevant of location, it’s essentially one large network.

To get this all working login and create an account at Tailscale.com

Run

curl -fsSL https://tailscale.com/install.sh | sh

On a headless server, this will install and prompt you to run

tailscale up

This will on the initial run ask for a login to be run, provide a link, which is used to connect the device to your account and you are done.

There will be a new NIC on your server and you’ll be able to ping any other Tailscale devices you have registered on their Tailscale IP

 tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500link/none inet 100.194.45.123/32 scope global tailscale0   valid_lft forever preferred_lft forever

Tailscale runs as a service tailscaled and when installed it’s set to enabled so the Tailscale network comes up on boot.

I can use the Android app on my phone or the Chromebook to access the Tailscale network.

Tailscale Interface

The web interface

This is a functional interface and has the obvious items in it. the ones which stand out are:

A list of servers attached to your subscription/Tailscale network.

Because there is only me on the network I’m not worried about access controls, its good to see that they can however be configured per user.

The DNS was interesting, they have something called MagicDNS which at the time of writing was a list made up of the hostnames given by the machines in the machine list.

I however installed pi-hole on an Ubuntu machine at home and pointed the Global Nameserver for Tailscale to that address. I added .tailscale as a local domain and added them as local DNS entries on the pi-hole. Once this was done I pointed Tailscale at the Tailscale IP of the pi-hole server and had my own local DNS.

There is more…

Tailnet

I mentioned that when you run the Tailgated it creates a 100.x.x.x network, this is referred to as a tailnet

There are a few reasons to use this address space in particular:

  1. It doesn’t conflict with the commonly-used private addresses your network might already use (10.0.0.0/8, 192.168.0.0/16, etc).
  2. The addresses are intended to be used for intermediate NATted traffic that is neither on your LAN nor on the public Internet. When a device on this network wants to reach the public Internet, they are expected to be NATted once more. This matches how Tailscale uses the addresses.
  3. The addresses are supposed to be used by Internet Service Providers (ISPs) rather than private networks. Philosophically, Tailscale is a service provider creating a shared network on top of the regular Internet. When packets leave the Tailscale network, different addresses are always used.

A tailnet is your private network. When you log in for the first time to Tailscale on your phone, laptop, desktop, or cloud VM, a tailnet is created.

For personal users, you are a tailnet of many devices and one person. Each device gets a private Tailscale IP address in the CGNAT range and every device can talk directly to every other device, wherever they are on the internet.

Your tailnet is your space. The internet cannot reach it. Think of it like a conference room with only people you have invited inside. Your tailnet can be a safe network where you are free to explore without the rest of the internet watching.

What is a tailnet?
A tailnet is your private network. When you log in for the first time to Tailscale on your phone, laptop, desktop, or cloud VM, a tailnet is created.

What are these 100.x.y.z addresses?
Tailscale assigns each node on your network a unique 100.x.y.z address. This address stays stable for each node (a device or a server), which means it should not change, no matter where the device moves to in the physical world.

Subnet Router

It’s possible on some devices you can’t install Tailgate so for such an occasion there is the Subnet Router

in some situations, you can’t or don’t want to install Tailscale on each device:

  • With embedded devices, like printers, which don’t run external software
  • When connecting large quantities of devices, like an entire AWS VPC
  • When incrementally deploying Tailscale (eg. on legacy networks)

In these cases, you can set up a “subnet router” (previously called a relay node or relaynode) to access these devices from Tailscale. Subnet routers act as a gateway, relaying traffic from your Tailscale network onto your physical subnet. Subnet routers respect features like access control policies, which make it easy to migrate a large network to Tailscale without installing the app on every device.

A diagram showing how subnet routers relay traffic between a subnet (eg. your local network) and Tailscale, connecting devices that can't install Tailscale.

Devices behind a subnet router do not count toward your pricing plan’s device limit. However, we encourage you to install Tailscale directly on devices wherever possible, for better performance, security, and a zero-configuration setup.

Subnet routers and traffic relay nodes
Tailscale works best when the client app is installed directly on every client, server, and VM in your organization. That way, traffic is end-to-end encrypted, and no configuration is needed to move machines between physical locations.

pfSense

It can be used with pfSense

As a router/firewall, pfSense may also be providing Internet connectivity for LAN devices that themselves have a Tailscale client installed. The NAT implementation in pfSense is an Endpoint-Dependent Mapping, or “hard” NAT, which means that LAN devices have difficulty making direct connections and often resort to DERP Relays.

Enabling NAT-PMP in pfSense can enable devices on the LAN to make direct connections to remote Tailscale nodes. NAT-PMP is a protocol by which LAN clients can ask the firewall to temporarily create port mappings.

pfSense settings to enable direct connections
pfSense is an open source router and firewall platform built using FreeBSD. Tailscale clients behind a pfSense firewall can benefit from a settings change.

A Community project

While you’ll often hear it, Tailscale is actually about community, you can for their code, do stuff with it, report back, and they are really happy about it.

One of the founders Avery Pennarun is as mad as a box of ferrets, in the best way ever and a prolific writer of blog posts. Well worth a follow.

Because the underlying SW is Open Sourced and people love to fiddle with new technologies there are some great howtos like this one where someone has outlined how to get an Amazon Firestick working with Tailscale.

https://www.reddit.com/r/fireTV/comments/r5fiom/guide_on_how_to_get_tailscale_working_with_a_fire/

or this one on using Tailscale to access LAN locked machines over SSH

A couple more interesting (to me anyway) posts

GitHub – adamgoose/tsk: Quickly connect to your Kubernetes Cluster with Tailscale
Quickly connect to your Kubernetes Cluster with Tailscale – GitHub – adamgoose/tsk: Quickly connect to your Kubernetes Cluster with Tailscale

Building a secure remote access setup using Tailscale – Jussi Roine
Previously, I’ve had a lot of different remote access methods. Even if I spent most of my time at home, I still frequently need to ..

Ansible Galaxy
Jump start your automation project with great content from the Ansible community

GitHub – mattn/tailscale-systray: Linux port of tailscale system tray menu.
Linux port of tailscale system tray menu. Contribute to mattn/tailscale-systray development by creating an account on GitHub.

Expose web services at home via Tailscale for fun – init8.lol

Release v0.4.0 · davidsbond/terraform-provider-tailscale
What’s Changed Support custom derp servers by @pwyliu in #45Add tests for the tailscale client implementation by @davidsbond in #46 New Contributors @pwyliu made their first contribution in #45…

You can use Tailscale with Kubernetes, you know
Given that this week is the epic all-things-cloud-native reunion in LA, we thought we might crash your little party and mention that Tailscale already works well with containers and Kubernetes. Many of us here at Tailscale used to work on Kubernetes, and keep it close to our hearts even if we’re not…

Final Thoughts

Tailscale falls for me under the category of systems like packer and ansible, in so much as if I’d had them years ago, I’d have saved many hours of pain in my life. It’s a quick easy solution to an age-old problem, and it won’t work for everyone. It will however solve problems for many forward-thinking individuals.  

By davidfield

Tech Entusiast