Blog

Lots of community contributions to highlight this month! Thank you to everyone writing and sharing their enthusiasm for Tailscale. This month includes a community AWS Lambda Layer for Tailscale, Tailscale v1.12, and Taildrop for Android.

It has been another productive month for the team here at Tailscale, and we are brimming with community contributions including a getting started video tutorial from David Burgess and a new guide by Justin Rhee on setting up a Tailscale VPN on Kubernetes. Let us jump in!

Today, we’re announcing a new pricing model for Tailscale that makes it less expensive for everyone, and easier to scale from a small test deployment to something your whole friend group, startup, or organization can use.

Check out the new pricing, or read on for details about what’s changed and why.

Tailscale 1.10 is now available on all platforms (pending iOS approval to the App Store — we expect it to go through this weekend). Learn how to update or read on for details. While this was generally a bug fix and cleanup release, a few noteworthy changes happened in and around this release worth highlighting.

Taildrop was the first test of an experimental p2p app discovery layer in Tailscale. Let’s talk about why it was so easy to build, and where we go from here.

Use Tailscale to set up your NAS for access from any device

A lot of people use Tailscale with Network Attached Storage (NAS) devices. In an effort to make this technology more accessible we’re publishing this transcript of a conversation about the basics of Network Attached Storage between our past co-op student Naman Sood, and our Archmage of Infrastructure, Christine Dodrill. Enjoy!

This has been a busy month, with the launch of Tailscale v1.8 and a new feature, Taildrop, that lets you easily send files between your devices.

Taildrop is a feature that makes it easy to send files between your personal devices on a Tailscale network. Unlike cloud-based file transfer services, Taildrop’s peer-to-peer design makes it well-suited for lots of kinds of files you might want to send.

We track a single packet from creation in one process to arrival in another, far away.

Automating deployment of a web server using GitHub Actions should be DevOps 101, so as a university student, it is the perfect time for me to be learning this. But what if, for security reasons, the server is accessible only over Tailscale?

The latest version of Tailscale is available today! Learn how to update or read the full release notes on GitHub. This release contains a lot of general improvements, along with support for some upcoming feature previews.

April has us hard at work on our 1.8 stable release. We’ve got lots of great community contributions to highlight this month.

A brief history of DNS on Linux systems and what steps we are taking to ensure it is configured consistently in Tailscale 1.8.

March brings Tailscale v1.6, including IPv6 support, exit nodes, netstack integration, and more. We also have writing about using Tailscale to create a Dropbox-like system, and details about the new library Tailscale uses for IP addresses behind the scenes.

The Go standard library’s net.IP type is problematic for a number of reasons. We wrote a new one.

Tailscale is split into a control plane and a data plane. The data plane is built out of direct WireGuard links that provides end-to-end encryption between any two machines on the network. The control plane is responsible for verifying the identity of users, validating machine keys, and delivering the public keys of peers to each machine in the network. This document focuses on the management of keys in the control plane. For a broader overview of Tailscale, see “How Tailscale Works.”

Lately, I get people asking me when microservices are a good idea. In systems design explains the world, I talked about big-picture issues like second system effect, innovator’s dilemmas, and more. Can systems design answer the microservices question?

Yes, but you might not like the answers. First, we'll need some history.

If you’re like most people, your answer to this is… “What? Why?”

When ssh was introduced back in the 1990s, its appeal was simple. Passwords are too short, too guessable, too phishable, too often stored incorrectly, too MITM-able, too brute-forceable. Also its primary competition was rsh’s classic “no authentication,” but we don’t talk about that.

This past month we announced our sharing beta, released v1.4, and have a slew of new writing and podcasts about Tailscale to share with you all.

Tailscale enables you to create networks between people you are close to. This article spells out our philosophy of social proximity networks as opposed to physical proximity networks you use today.

Today, we’re launching sharing as a public beta feature. Sharing lets you invite users outside your network to access your private devices securely. It makes it easy to host game servers with friends, host open-source software for family, collaborate with contractors, and much more.

How to provision a new NixOS machine on Digital Ocean with nixos-infect and automatically connect it to your Tailscale network, then use that server to set up a fully private Minecraft world.

As we start the new year, we want to take a moment to thank the community around Tailscale for making 2020 a stand out year, reflect on where we’ve been, and where we’re headed next…

When I first joined Tailscale, I was horrified to learn that “the database” was a single JSON file that was rewritten on any change. We migrated to something better.

The team has been hard at work making Tailscale more Tailscale-y. Today we’re announcing v1.2 is stable and ready for teams and hobbyists alike. Most notably, this release includes MagicDNS for everyone and major improvements for our Windows client.

How to update:

• Linux: update instructions (apt update, install, etc.)
• Windows: update instructions
• macOS: update via the Mac App Store*
• iOS: update via the App Store*
• Android: update via the Play Store

*For macOS and iOS, you may need to quit Tailscale first; the App Store doesn’t seem to update running VPN apps.

Big news today! We’ve raised US$12 million in Series A funding led by Accel, with participation from Heavybit and Uncork Capital. The new funding follows the seed round we announced just a few months ago in April, and will allow us to build out our team and product at a faster pace, given the level of demand accompanying the world’s shift to remote work.

October brings two exciting new features courtesy of our summer co-op students, and some writing about Tailscale on Wi-Fi routers & NixOS from the community.

Did you know that our CEO, apenwarr, is something of a B-list Internet celebrity? Part of his claim to fame is a pithy-but-informational blog, which contains a pithy-but-informational post detailing exactly how to handle and parse a distributed logging system correctly. Tailscale’s logging infrastructure follows this system in broad strokes.

August brings Tailscale v1.0, now available for all platforms. It also brings new relay servers in Bangalore and Tokyo, and a new “guides” section to our knowledgebase, inspired by members of our community.

We covered a lot of ground in our post about How Tailscale Works. However, we glossed over how we can get through NATs (Network Address Translators) and connect your devices directly to each other, no matter what’s standing between them. Let’s talk about that now!

Tailscale is the easiest way to create simple, secure networks for teams of any size.

Today we are announcing our Android App is officially out of beta and generally available in the Google Play Store. Android support has been one of our most requested features, and we are genuinely excited to bring it to everyone.

We’re once again happy to announce a new version of Tailscale.

What comes after 0.99? 0.100, of course!

This is a pretty notable release, containing a major rewrite of our “magicsock” connection code that sits between WireGuard and the network, finding the best path between peers and getting through NATs.

If you’ve had any connection woes previously, definitely give this a try.

One catch, though: the new 0.100 connectivity code only kicks in if two peers trying to connect to each other are both running 0.100 or later. So make sure you update all your devices.

How to update:

• Linux: see https://pkgs.tailscale.com/stable/ (apt-get update, upgrade, etc)
• Windows: from that same page, download tailscale-ipn-setup-0.100.0-107.exe
• macOS: update from the Mac App Store (you’ll likely need to stop Tailscale first; the App Store doesn’t seem to update VPN apps that are running)
• iOS: we’re giving it a few days until we mark 0.100 as our stable build on iOS, but you can join our TestFlight beta program to get it today
• Android: the latest Tailscale Android beta builds use the new 0.100 connectivity code

In addition to the connectivity improvements, there are a number of other fixes and cleanups:

• The Linux client now respects DNS settings set in the Tailscale admin panel.
• The Windows client now has “About” and “Exit” menu options. The “About” dialog will show the current stable version. (No auto-update option yet, but it’s a start.) Windows service start-up errors are now also surfaced in the UI, which is still a sad experience if it happens but should make for better Windows bug reports at least. We’re working on those. Long tail is long.
• The macOS client now stays off when you turn it off via the OS network settings.
• The tailscale status subcommand (only currently included on Linux) now consistently shows asterisks around a peer endpoint address only when that path is active, and also now shows asterisks around DERP relays if that’s what’s being used.

Enjoy!

And as always, email us or tweet us (@tailscale) if you have any problems and we’ll try to help.

A few years ago I wrote The World in Which IPv6 was a Good Design. I’m still pretty proud of that article, but I thought I should update it a bit.

No, I’m not switching sides. IPv6 is just as far away from universal adoption, or being a “good design” for our world, as it was three years ago. But since then I co-founded a company that turned out to be accidentally based on the principles I outlined in that article. Or rather, from turning those principles upside-down.

In that article, I explored the overall history of networking and the considerations that led to IPv6. I’m not going to cover that ground again. Instead, I want to talk about attitude.

Another month brings another round of updates: we released Tailscale v0.99, improved memory usage of our iOS app, and now have a public Android beta.

At the beginning of May we welcomed our first ever batch of interns to the Tailscale team! They’ve all been hard at work the past few weeks, and we want to formally introduce them.

Joining us from the University of Waterloo are Zijie, Wendi, and Dmytro:

Zijie Lu (@lzjluzijie) is a Mathematics student at Waterloo. Originally from Beijing, Zijie has experience writing Go, React, and Vue, and is most known for his websocks project, a secure WebSocket-based HTTP proxy. (As soon as we saw that project, we knew he’d be a great fit.)

Zijie has never used, let alone owned an Apple device, instead preferring to run a dual-boot Fedora / Windows machine. In his spare time, he plays DOTA2, and is currently ranked in the top 2000 players in the Americas!

This term, Zijie will improving our network admin panel, to make managing devices and auth settings easier for teams.

Wendi Yu (@wendi-yu) is studying Software Engineering. She’s a member of Waterloo’s rocketry design team, building tools to model tank fill and P&ID systems for rocket launches. (Tailscale’s own rocketry fans are excited to have another member join.) And if that wasn’t enough, she’s also a sousaphonist for Waterloo’s concert band. As she puts it, “There’s something immensely liberating about being able to honk back at the geese who attack me when I walk through campus.”

Currently based in Edmonton, Wendi is working on real-time auditing and visualization of networks to help teams secure and monitor their devices.

Dmytro Shynkevych (@dshynkev) is pursuing his Computer Science degree, and has already completed internships at SideFX, Cognite, and Kik Interactive, working on machine learning and 3D rendering projects.

Originally from Ukraine, in his spare time, Dmytro pseudonymously translates online content, mostly songs:

Doing so well, which is to say, localizing instead of merely translating, and preserving the rhythm (if not the rhyme) of poems and songs is a fun challenge!

He’s also excited about cybersecurity, and regularly participates in CTF competitions on weekends. He’s particularly proud of his 2018 team’s work in the CSAW Quals: “we were motivated, efficient, and worked in perfect synchrony.”

While at Tailscale, Dmytro is developing our MagicDNS feature, letting teams access network devices with memorable names, in addition to Tailscale IP addresses.

We’re happy to have Wendi, Zijie, and Dmytro with us! You’ll likely see their contributions on our public repositories over the next few months.

During April we’ve released the latest version of the Tailscale client (v0.98), launched a new relay server in Sydney, and more. Plus, we have an Android beta coming soon.

We’re happy to announce a new version of Tailscale. This minor release fixes various connectivity issues and squashes some annoying platform-specific bugs. Thanks to everyone who wrote in to report these issues!

A few highlights from the complete changelog on GitHub:

• We now prefer IPv6 over IPv4 when sending encrypted packets between nodes. Note: this does not yet make IPv6 available inside the Tailscale network.
• Switching between different networks is now smoother than ever, particularly between Wi-Fi and LTE, or when moving a sleeping laptop between different networks.
• Windows no longer resets active connections when new nodes get added to the network.
• We’ve adjusted MTU settings to avoid packet loss for users on Google Cloud or DSL.

This release only contains connectivity and stability fixes, so we recommend everyone update to the latest version. You can see out-of-date nodes on the machines page of your admin panel.

You can find update instructions for your platform.

An article by Michael Tremer titled Why not WireGuard is sometimes shared in VPN discussions. Unfortunately that article contains several misconceptions and some out-of-date information that deserves to be addressed.

Let’s go through his arguments section by section.

Just over a year ago, we founded Tailscale with a common sense of nostalgia for the “good old days” of LANs. In our collective opinion (then and now) networking and cloud infrastructure has become too complicated. Attempts to increase team connectivity and migrate towards remote work results in a corresponding burden of security. This reduces productivity. Systems and approaches don’t scale without significant time and effort. Everyone suffers.

That’s why we are happy to announce that we’ve raised a $3M seed round, led by Heavybit with participation from Uncork Capital and others. This investment sets the expectation on what we’re aiming to achieve: a return to simple computer networking for everyone that works anywhere you can access the Internet.

People often ask us for an overview of how Tailscale works. We’ve been putting off answering that, because we kept changing it! But now things have started to settle down.

Let’s go through the entire Tailscale system from bottom to top, the same way we built it (but skipping some zigzags we took along the way). With this information, you should be able to build your own Tailscale replacement… except you don’t have to, since our node software is open source and we have a flexible free plan.

We have some catching up to do. Tailscale opened our waitlist for signups in April 2019, almost a year ago, but we haven’t shared much news! It’s time to rectify that.

Over the past 11 months we’ve grown the team and narrowed our focus to just one core product: a company-wide mesh overlay network based on the WireGuard® VPN.

As a “fully remote work” company, we had to make some choices about the technologies we use to work together and stay in touch.

We decided early on — about the time we realized all three cofounders live in different cities — that we were going to go all-in on remote work, at least for engineering, which for now is almost all our work. As several people have pointed out before, fully remote is generally more stable than partly remote. In a partially remote team, the remote workers seem to always end up treated as an underclass, overlooked in meetings, bypassed for promotions, fired when they eventually refuse to relocate because the remote work policy inevitably changes (hi, Yahoo!), etc.

The good news with our plan is the founders could “dogfood” a few different remote work ideas ourselves before we ever hired anyone. So we decided to try some stuff. Here’s what we discovered.

Some news — we have deb and rpm package repositories up!

pkgs.tailscale.com

Currently serving unstable-track packages for tailscaled, a replacement for our current linux relaynode.

If you’re brave, give it a try! Stable release with docs coming soon.

We just made the first bits of the Tailscale code public, starting with the Linux client and its dependent/common code.

https://github.com/tailscale/tailscale

Still lots of rough edges & TODOs everywhere so temper expectations accordingly. We want to hack in open and not wait until it’s perfect.

I used to tolerate and expect complexity. Working on Go the past 10 years has changed my perspective, though. I now value simplicity above almost all else and tolerate complexity only when it’s well isolated, well documented, well tested, and necessary to make things simpler overall at other layers for most people. For example, the Go runtime is relatively complex internally but it permits simple APIs and programming models for users who then don’t need to worry about memory management, thread management, blocking, the color of their functions, etc. A small number of people need to understand the runtime’s complexity, but millions of people can read & write simple Go code as a result. More importantly, Go users then have that much more complexity budget to work with to build their actual application. I would’ve never built Perkeep had I needed to fight both its internal complexity and the complexity imposed on me by other contender languages/environments at the time.

All that is to say, simplicity is not only refreshing, but it also enables. Go made me feel productive in a way I hadn’t felt in many years where everything just felt like it was getting more complex. Ever since finding Go, I’ve been regularly hunting for other technologies that provide simplicity as a feature.

I started programming in the 1990s living above my parent’s medical practice. We had 15 PCs for the business, and one for me. The standard OS was MS-DOS. The network started off using IPX over coax to a Novell Netware server, the fanciest software we ever owned. IPX was so much easier than TCP/IP. No DHCP and address allocation, it just worked.

Eventually the PCs would run Windows, and a Windows NT server took over file sharing over TCP/IP. The business software survived this transition unchanged, though there was more operational overhead. We assigned IPs manually.

Long ago, I wrote git-subtree to work around some of my annoyances with git submodules. I’ve learned a lot since then, and the development ecosystem has improved a lot (shell scripts are no longer the best way to manipulate git repos? Whoa!).

Thus, I bring you: git-subtrac.

It’s a bit like git-subtree, except it uses real git submodules. The difference from plain submodules is that, like git-subtree, it encourages you to put all the contents from all your submodules into your superproject repo, rather than scattering it around across multiple repositories (which might be owned by multiple people, randomly disappear or get rebased, etc).

Identity on the internet is messy. The result is some things that should be easy are hard. The Identity Stack This is an attempt to document how we define a person on the modern Internet. It is analogous to an OSI model for identity. Layer 1: IP addresses The story so far: In the beginning the IP address was created. This has made a lot of people very angry and been widely regarded as a bad move. IP addresses give us everything, and yet surprisingly little. Scribble one on a packet, send it out, and maybe it will get somewhere. Where is anybody’s guess. After a while some packets come back with the that IP address in the sender field. Maybe it’s from them, maybe it makes sense, maybe some got lost on the way. Layer 2: Brands Next come the true foundation of the modern internet: brands. A brand is a domain name that you recognize.

I am leery of jargon. I am as guilty of using it as the next engineer, but there comes a point where there are just too many precise, narrowly-understood terms polluting your vocabulary. The circle of people you can talk to shrinks until going to the store to buy milk feels like an exercise in speaking a foreign language you took one intro course to in college. Less jargon is better.

Thus the first few times I heard the terms zero trust network and microsegments I ignored them. The conversation went on even though I was a bit confused. Eventually I heard these enough that I had to figure out what these words mean. Turns out they are useful!

So what are they?

Growing up, I, like many computery people of my generation, was an idealist. I believed that better, faster communication would be an unmitigated improvement to society. “World peace through better communication,” I said to an older co-worker, once, as the millennium was coming to an end. “If people could just understand each others' points of view, there would be no reason for them to fight. Government propaganda will never work if citizens of two warring countries can just talk to each other and realize that the other side is human, just like them, and teach each other what’s really true.”

“You have a lot to learn about the world,” he said.