While this is cool I've had luck just purchasing a domain (not that expensive), and manually setting up DNS through that.
Some advantages that this doesn't look like this would replicate, (1) I can have multiple domains for the same device, say gitea.mytsnetwork.com and netxcloud.mytsnetwork.com can go to the same device (2) I can get real HTTPS certificates for those domains which I consider necessary nowadays if only just to prevent errors (3) it's "real" DNS so when my browser decides to ignore my system settings and use DNS-over-HTTPS instead everything still works.
EDIT: It looks like (2) is solved by the tailscale cert command. I'd replace that point by saying owning the domain is important to controlling the certificate for me. All that said, the more I read into this, this looks like a really well thought-out feature.
One downside of using tailscale cert, or LE for "private" records is that it writes the domain name in a public Certificate Transparency Log [1]. So make sure that the name doesn't contain any sensitive information.
An alternative is to issue wildcard certificates with LE, so that the subdomains names are kept private.
Yes, that's why we came up with the random-hex.ts.net domains and the tails-scales.ts.net domains. This makes less publicly recognizable things like `shark-harmonic.ts.net` get put into the certificate transparency log instead of something like "mycorporationname".
> An alternative is to issue wildcard certificates with LE, so that the subdomains names are kept private.
They'll still show up on crt.sh, though, won't they? All my LE subdomains are visible (non-wildcard) but also my non-LE paid-for 1-year wildcard ones are also showing up with all the subdomains.
Edit: Actually, nevermind, those are Cloudflare. My paid-for wildcard doesn't show up. Well, that's a good reason to pay up I guess.
If a certificate has been issued for a domain, and that domain doesn't show up in the certificate transparency logs, that's not something I'd cheer for: that issuer could just as well hand out certificates for your domain to others without you ever knowing about it.
Conversely, if a domain shows up in the CT logs, then there have been certificates issued for those domains, even if there exists a wildcard certificate that is valid for that domain. If that happens, check your settings, because there's probably something requesting certificates you're not aware of.
> (1) I can have multiple domains for the same device, say gitea.mytsnetwork.com and netxcloud.mytsnetwork.com can go to the same device
I tried setting up caddy on a machine and then using caddy to reverse-proxy requests to each service i.e. `grafana.my-machine.tail-hex.ts.net` and `controller.my-machine.tail-hex.ts`
Obviously, `caddy` has no problem with the reverse proxy bit, but I did fail at being able to point multiple routes or subnet routes at the same machine via tailscle / magic-dns.
I'm sharing because it feels like something I should be able to do, and feel dumb not being able to figure it out.
I'm just running a dnsmasq and using that to alias machines / workloads. For my network I needed to make sure a route to the dnsmasq IP is advertised by a subnet router and then I told tailscale to "override local dns" and make all tailscale clients use that dnsmasq IP as their DNS server.
I have a mix of bare machines and load-balanced workloads behind an nginx-ingress, all with names specified in the dnsmasq config, and because everything on the tailnet resolves names through dnsmasq (and routes through tailscale), everything works beautifully.
I'm still looking forward to this caddy integration, though.
Tailscale's certs are 1-per-machine so if you want to do any kind of SNI-based certificate handling, you're out of luck and need to drop back to real public certificates anyway.
a cool thing you can do with MagicDNS: Set your "global nameserver" to a host within your tailnet and run your own resolver accessible "anywhere".
It's easy enough to set up pi-hole.net on a machine on your LAN and configure your home router to hand out DHCP records that will instruct LAN machines to use it, but if I wanted to have DNS-based ad-blocking at the coffee shop or library or elsewhere I previously had my pi-hole listening on a public IPv4's port 53 and deal with resolve.conf etc... and boy howdy does running an internet-accessible DNS resolver suck! My server would receive millions of requests, weird reflection attacks like [1], probes, the whole nine, it made the dashboarding useless for personal tracking.
But now my pi-hole only listens on my LAN network and its tailnet address, and any machine connected to the tailnet including my phone will use the pi-hole without configuration on any network via MagicDNS.
I have a similar setup but deployed my PiHole in Fly.io using a custom Docker image behind Tailscale. This way I can just connect to Tailscale and I have ad blocking automatically using their custom DNS servers.
Very useful and I use it all the time on my mobile devices including my laptop when I'm using guest wifis.
I have the same setup! Very happy with the Fly pihole + Tailscale combo, but I recently tried the Tailscale + NextDNS combo and I might move to it altogether. Only problem is that NextDNS seems blocked at my university and I am not sure how to solve that yet. Using pihole on Fly with Tailscale works fine.
Just as a side note, I used to do this with plain WireGuard on a Hetzner node. I switched to NextDNS because of latency issues, but if this is not a concern, then it was a great setup, and Tailscale makes it even easier!
Great setup! But you didn’t say anything about MagicDNS, did you? You just set your global Nameserver to something on your tailnet and could disable MagicDNS for this use case?
I set my global nameserver within the MagicDNS configuration to use the pihole IP. If I didn't use magic DNS i would have to do this for each device, and on devices like Android etc each network i connect to. This requires no-thought for each device, just `tailscale up`
I have been using Tailscale for about two weeks now and I am SOO happy with it. It's genuinely joyful software like I haven't used in years. A modern version of the old Hamachi.
Love tailscale! Set it up a couple weeks ago and it’s very fun to use. MagicDns is great! I can go http://macmini anywhere and it just works
Just wish they offered more subnet routers. I’m as much hobby as hobby can be, and already hit the limit (one on my mini k8s cluster, one at home, that’s it. They don’t allow you to have more). Been stuffing the sidecar awkwardly into everything to get around it
If someone from tailscale is reading this - please consider upping the limit of subnet routers. I’ll have to switch to ZeroTier once I want another one which doesn’t have those restrictions.
Even paying for the hobby pro plan is just upping it from 1 -> 2
We're definitely considering it. We introduced the limits a while back as an experiment. In most cases, I believe the current limits don't make a lot of sense. Fundamentally, we were hoping to encourage the deployment of Tailscale to end devices (partially to increase users' security, partially to get a better idea of how widely Tailscale is actually being used). Unfortunately, the limits introduce the kinds of headaches that you're describing (and for IoT it can be a showstopper). The net effect across all users could be to actually discourage people from having fun and tinkering with Tailscale, which is the last thing we want.
Would you mind describing some of the other use cases you have for subnet routers? Do you have other mini k8s clusters you want to use them for? Other things? I'd love to learn more.
> Fundamentally, we were hoping to encourage the deployment of Tailscale to end devices (partially to increase users' security, partially to get a better idea of how widely Tailscale is actually being used).
that makes sense, I also got the feeling that's the recommended way to run tailscale, and it's nice to be able to address services directly by their dns name
> Would you mind describing some of the other use cases you have for subnet routers? Do you have other mini k8s clusters you want to use them for? Other things? I'd love to learn more.
Yes that's mainly it. I am probably an edge case because I have mini k8s clusters for different things. I have 2 main networks: My network at home, then my main k8s for my personal cloud stuff, those 2 are pretty constant (but want to spin up a separate IoT network soon that may or may not need a router). Then depending on what I work on, I might spin up other k8s clusters
(I'm one of those odballs that really enjoys working with k8s for personal stuff)
I think for me it's mainly to have piece of mind to not run into limitations later on, after I'm already locked in and need to rip-out tailscale to replace with ZeroTier
I think most people who are using the limit of the free account should really be paying. I am extremely happy paying for Tailscale, pandering to freeloaders is nice and fun but I really don't think it hurts anyone to charge for what the service is worth.
To xena's point, we're not currently enforcing the limits :) We've been very cautious about that since, as I mentioned in a comment elsewhere, the limits have always been an experiment.
The Github team org plan (for connecting friends and family) had a subnet router limit of 5, if you want to legitly get a higher limit rather than just ignoring the limit that they don't check.
Oh what, is the limit not being enforced? I didn’t even bother trying to spin up another one because everything goes through that admin console, so I was sure there’d be a “you hit your limit” message
AFAIK, they've publicly said they don't enforce any of the limits, at this time, because it's not worth it to do the engineering yet, and might never be worth it.
Is this still incompatible with split horizon DNS? Whenever I'm connected to my corporate tailnet I can no longer resolve hostnames that are registered on my personal, DHCP-assigned DNS server, breaking access to my home network. This also leads me to believe that all my DNS requests are being routed through the magic DNS server which is not cool IMO.
It sounds like your corporate tailnet checked the "override local DNS" setting and provided their own default nameservers, so those are the ones that get used. They could also not do that, at which point your LAN resolver would get consulted, but I presume there's a policy reason in play?
You say "the MagicDNS server" like it's a quad-8 thing out on the internet. That server lives in the tailscale process on localhost. In some configurations on some OSes, we do have to route requests through that in order to polyfill missing OS features (usually, implementing split-DNS policies that the OS cannot represent natively, or transparently upgrading to DoH for upstreams that support it). You can inspect the logic that decides how to implement DNS policy depending on the policy and OS in https://github.com/tailscale/tailscale/tree/main/net/dns, as well as inspect what the in-process DNS forwarder does (extremely boring: match query suffix in configuration, forward packet to appropriate upstreams).
Weird, I asked our TS admin to disable "override local DNS" and he claimed the option was disabled out, seemingly due to magic DNS being enabled or something. I'll see if I can get access myself to try and change it. Thank you for the reply!
If things still aren't behaving, write in to support@tailscale.com and we'll sort you out. It sounds like the corporate setup wants to just push some custom DNS routes for specific suffixes and leave everything else alone, which is definitely a supported configuration.
You're right for most setups, but when Docker also comes into play, systemd-resolved+Tailscale+Docker interacts really badly and containers cannot resolve anything anymore. This caused some serious hair-pulling at work a few months ago.
The only proper solution I could find is disabling systemd-resolved entirely. There doesn't seem to be any way to make it use something other than 127.0.0.1 as its listen address (it's actually hardcoded in systemd-resolved) which means that Docker containers which inherit /etc/resolv.conf rules can't resolve DNS anymore.
As a long time ZeroTier user I want to point out that they have some interesting DNS solutions as well.[1]
(Personally, have not felt the need to change something that has a great free tier, self hosting controllers, etc, and has been working reliably for years... Tailscale looks cool though)
It is! But the usual thing with Tailscale is that this just works out of the box. Any new person starting where I work has Tailscale installed by default. Once they log in, they can access any of our pis/servers that are setup with names like rpi1.
Furthermore, you've got ACLs + Tailscale SSH. That means you can start day 1 and do ssh root@rpi1 and it just works. It's amazing and worth so much money.
Edit: I just really wish they would allow more than being tied to Google SSO. I want to invite people outside of my domain easily :o)
Yeah, it's totally possible to configure a stack like that. I roll my own stack of unbound+nsd as adblocking split-horizon DNS for LAN, roaming and management WG network.
Tailscale value prop as I understand it - they can manage this whole thing for you.
MagicDNS is really cool, but it seems like it is only a useful for ssh-ing into hosts or for tiny home networks where you run a service on a single box. And maybe that is totally fine! I just don't see how to use it in a larger environment beyond `ssh <hostname>`.
In larger environments we never have any kind of internal web site or service running on one host so we can't really have MagicDNS short names for things. It would be nice for users to just be able to type `https://deploy` to get to our deployment tool for example. But that web interface runs across many nodes behind a load balancer so there is no way to use MagicDNS here.
I wonder if some day we can register duplicate hostnames and have it do DNS load balancing? I'm not sure how that would work with the tailscale cert command either. Each node would need the private key.
Anyway, we'll probably start using it but the only real use cases I see right now are for ssh and for users accessing their remote dev boxes.
The way I have it set up is my Tailscale pod redirecting all requests to an ingress controller, and then all subdomains CNAMEd to the Tailscale DNS. That way, all requests are going Tailscale pod -> nginx ingress controller -> service, no matter which node everything is running on.
"[[Tailscale automatically assigns IP addresses for every unique device in your network | https://tailscale.com/kb/1033/ip-and-dns-addresses/ ]], giving each device an IP address no matter where it is located."
That phrasing is a little off. It implies there are situations where your location will affect whether or not you get an IP address. Reading the link makes it clear: it assigns IP addresses that are independent of the device's location. The same device will keep the same IP address even when it moves to another network location, which is not surprising when you are familiar with wireguard configuration.
I hadn't heard of tailscale before this, but this system is what I have always wanted for my devices. I just finished setting this up and it works amazingly well. Now I've got samba/nomachine/syncthing restricted to the tailscale network with aesthetically pleasing device names. Better security and I can roam now.
It breaks things and you have little control over it.
It replaces default search domain with its own.
Also it does't keep your DNS servers in your resolv.conf nor tries to forward your query to them when it fails to resolve it.
So, you may experience a loss of connectivity for short hostnames w/o tailscale (host instead of host.my.domain) or get unnecessary overhead for TS-enabled hosts within your local network.
Great idea, however, I had to disable MagicDNS in few of my machines as tailsscale changed my local DNS with 100.100.100.100 on my resolv.conf filet, yet for some reason that address was impossible to reach internally.
1. We want you to be able to get HTTPS certs for these too without having to manage multiple names, but HTTPS cert names go on the CT log. See https://tailscale.com/blog/tls-certs/ and https://tailscale.com/kb/1153/enabling-https/ . So having your email address in your DNS name (and thus the CT log) from the old beta.tailscale.net forms isn't great.
2. We want you to be able to have multiple separate tailnets per org/account in the future.
While this looks fun, I still prefer to register a short domain (used free *.net.ru before war) and auto-populate DNS with Terraform/Ansible on a provision stage.
I really want to like and recommend Tailscale more (and MagicDNS is another bonus) but with the forced use of Google auth and still no support for fast user switching and connections to multiple networks, it just has too many dealbreakers for me and many colleagues.
Zerotier has had all of that figured out for years, in the meantime Tailscale just locked the thread requesting multiple connection support as "too heated" (after >2 years of no progress).
And putting access to our corporate networks in the hands of Google & Co. and their trigger-happy account-blocking algos means that TS gets an automatic thumbs down from compliance officers at several of our clients. We can read stories on HN every week why such authentication systems are a bad idea, and steadfastly refusing to roll your own account system (all the while justifying it with handwavy security concerns) just seems lazy to me.
I can follow their arguments to some extent, I just don't understand why the TS people insist on exclusionary features rather than letting the user choose. You believe multiple simultaneous connections are somewhat insecure and that's why you won't implement it? Okay, slap a warning sign on it if you want, by all means, but who cares about this if all I want is to connect to 5 branch offices at the same time.
You believe forcing users to use their private, everyday Google or Github accounts for authentication is safer than using a special account registered on TS with safe, unique credentials not used for any other purpose to minimze collateral damage (if the Google or Github credentials get compromised you'd get their emails or a bit of source code, but not access to the WHOLE corporate network)? How about letting the user choose and show some flexibility to use-cases that exist even if you can't imagine them?
Sorry for the rant, again, I want to love TS, it's UX is pretty neat, but something about their supercilious attitude with which they justify their (non-)features just rubs me the wrong way, I guess.
At the risk of downvotes (because I know TS has - rightfully - many fans), if anyone from TS is reading this, I do implore you to be more open-minded and give your users a choice rather than patronising them on multiple fronts when using your product. Feel free to recommend a "best practice" but understand that many users who might love your product will want and have to use it in a slightly different way than you intended - and that should be okay.
I completely agree and judging by the upvoted position of your comment here, lots of other HNers do too. So I hope Tailscale do take note.
I'm a Tailscale customer very reluctantly using their social/SSO login mechanism but to your point, I've already lost access to an earlier Tailscale account due to a screw up (long story) with some changes to the MS corporate account that it was linked to.
I really really dislike forced usage of social/SSO logins and it's one of a couple of reasons I may move away from Tailscale at some point.
Edit: Agree re. fast user switching and connections to multiple networks too - those would be extremely useful
My tailnet is set up using a GitHub organization, without using Google at all. I have sufficient security (2FA with security keys, etc.) enforced for it. I think that hand-rolling their own auth would not be a great idea just yet, while they are still ironing out other features.
There are more options than that, and I see your point.
To take the contrarian stance though: SSO not being paid is kinda nice, and not having yet another password for something is nice. —- double and: then not being able to leak a password or handle 2FA, instead focusing on their actual product.
For free users, it's pretty much just G, MS, and GH (which is currently the only "tolerable" one, but there's no reason why it won't turn into a MS account in the future just like how they killed Minecraft)
If you want to connect to multiple endpoints, use the ACLs. That's what they are there for. Multiple identities at once are a sign that something has gone terribly wrong in your organization's ability to manage access, and if it hasn't gone wrong yet it will.
This is completely ignoring the use case of “multiple organizations”. E.g. a contractor might need access to an agency’s network and a client’s network on the same device.
The very concept of "your organization" is not meaningful for some users. Even when working for a single client organization, I usually need VPN connections to my own servers at the same time - my own business is the second organization.
Typically you start some consulting work for an organization, and they hand you an identity to use for the work. They won't use the one you have already or grant access via an ACL. They give you a new id (yes, a new Gmail address even for an 8 week contract, and you're supposed to check it).
So you're consulting for 3 organizations this Q4, and you've been given 3 identities to use for VPN access.
To actually be useful to them in your consultancy work, you need to connect to your own servers during the day as well. Being able to use those is key to what makes you valuable.
Fast user-switching or even simultaneous login would be handy, and having to agree special arrangements with various IT departments is usually a lot of friction. Slow user-switching is what you end up having to do in practice, and that's a pain. I've had this with other VPNs when doing consulting jobs. Re-logging in via slow dialogs to their VPN 20 times a day, due to switching.
I didn't know Tailscale had this restriction until the GP comment, as I have been avoiding Tailscale due to the social-SSO constraint. I was considering, reluctantly, trying it out with my GitHub credential, the one that I think I'm least likely to lose access to. (But consider that all Russian accounts were suspended abruptly this year.) But I do use multiple VPNs to servers under the control of different organizations through the day, so the switching constraint seems relevant too.
It took me six months to actually set up TS because of the lack of email/password auth. So this is definitely a pain point. It's such a good product that it's annoying that they don't roll their own simple auth.
I eventually gave up and used Github and it's definitely been worth it for my personal use (a personal laptop accessing a Mac Mini in SF while on vacation, as well as setting up exit nodes on VPSs for getting around geo-restrictions).
It's an order of magnitude less effort and risk to defer auth to third parties via SAML/OAuth/etc. versus owning it yourself with email-based (or whatever) logins. That's it. Nothing more.
For the developer, yeah, not for the user though. But "least-effort development" is not generally that meritorious, especially in this area, and arguably a large part of TS's value proposition is about "less effort and less risk" for the user!
For the user this means more effort and more risk if you consider that you've just multiplied your attack surface by combining internal, privileged access to your network (often without any firewalls or per-device authentication) with whatever other skimpy services you use the credentials for. I know we're all supposed to expect zero trust these days and have all these well-designed enterprise IdP systems in place but the reality is starkly different, especially in the SMB space.
I know that there are a lot of things you can do wrong with auth but a company capable of developing something as complex as a zero-config modern mesh VPN should be able to handle rolling their own auth, come on.
And by the way, it's not like they get the third-party SSO right either: Every time we log into the admin panel with our 3rd party (Microsoft/Github/Google) account, we are asked to re-authorize Tailscale ("Tailscale by Tailscale wants to access your data...").
In short, they could really throw some developer hours at this and polish it a bit, roll their own auth (again, can be a tertiary beta option with warning labels at first) etc. This would also leave a good first impression with first time and trial users, and, most importantly, give users an informed choice to leverage the solution that they consider the least effort and least risk for their use case.
Fully agreed. Want you probably want is OpenZiti. It's a modern mesh overlay network which is explicitly built on zero trust principles including using strong embedded identity (with the ability to plug in 3rd party IdP). This ensures per-endpoint authentication and authorisation before any connectivity can be established on the basis of least-privilege and microsegmentation. The connectivity at source and destination is established outbound so no inbound ports are needed while providing private (magical) DNS. It's also completely open source and free. Here is an overview of some of the superpowers - https://www.youtube.com/watch?v=hLEeHit3prY&list=PLMUj_5fkla...
Disclaimer, I do work on the project so take me with a pinch of salt.
> least-effort development" is not generally that meritorious, especially in this area, and arguably a large part of TS's value proposition is about "less effort and less risk" for the user!
Development effort is the dominant variable in engineering cost/benefit analysis. What do you think is the cost of what you're asking for? What do you think is the value?
I'd guess the effort is 50-100% relative to all of the auth schemes currently supported combined, and I'd guess the value is maybe one or two orders of magnitude less than the value delivered by those features.
> Every time we log into the admin panel with our 3rd party (Microsoft/Github/Google) account, we are asked to re-authorize Tailscale ("Tailscale by Tailscale wants to access your data...").
If this were a common problem, don't you think they would have addressed it? I don't have this experience, for the record.
> they could really throw some developer hours at this and polish it a bit, roll their own auth
I don't think you have a realistic understanding of what you're asking for.
Their Team and higher plans integrate with Okta, their Business and higher sync group memberships and deactivated users with Okta, and their "contact us" Enterprise plan supports custom SAML and OIDC. I think this is a fair tradeoff of cost vs benefit given who needs each solution and how much individualized time and energy Tailscale needs to spend per customer to support each of these solutions.
Yeah that makes a lot of sense. Given how the protocol is used in practice it does require a lot of support. I understood the parent comment as them only supporting Google.
They don't support TailScale-specific email and password accounts in any version, and only Google or GitHub login (or maybe MS accounts?) in the free version. That was the basis of the complaint, I think. TailScale has written separately about why they made that choice.
Completely off-topic but a continuously-looping very large GIF smack in the middle of the feature post is really distracting. I appreciate that GIFs are supposed to be animated loops, this one is just too large and moves around too much.
(Side note: setting image.animation_mode = none in Firefox stops the animation.)
All the comments here are about drawbacks and limitations. The upvotes on the submission might be explained by quality of the product, but the comments not so much.
Meaning can be also inferred from context. Even in your example, the conversation context and follow-up statements could home in on the context.
Sure, maybe it would be better if everyone just wrote in a non-ambiguous way, but you're on an international forum where many people don't have a native understanding of the language (me included).
I understood what he meant immediately. I also don't agree with the comment, but that's another subject.
Some advantages that this doesn't look like this would replicate, (1) I can have multiple domains for the same device, say gitea.mytsnetwork.com and netxcloud.mytsnetwork.com can go to the same device (2) I can get real HTTPS certificates for those domains which I consider necessary nowadays if only just to prevent errors (3) it's "real" DNS so when my browser decides to ignore my system settings and use DNS-over-HTTPS instead everything still works.
EDIT: It looks like (2) is solved by the tailscale cert command. I'd replace that point by saying owning the domain is important to controlling the certificate for me. All that said, the more I read into this, this looks like a really well thought-out feature.