Choose your own IP(tailscale.com)
tailscale.com
Choose your own IP
https://tailscale.com/blog/choose-your-ip/
177 comments
"I know, I'll use NAT!" Now you have two problems.
(Just in case you don't recognize the allusion:
https://arstechnica.com/information-technology/2014/05/what-...
(Just in case you don't recognize the allusion:
https://arstechnica.com/information-technology/2014/05/what-...
Posts from Ars say, pre-2018/2017 should be left alone. No need to remind ourselves about how far they've fallen.
I immediately thought of this line from my favorite episode of Everybody Love Raymond. Ray's dad says: "Didn't I teach you anything, you gotta problem with your woman you don't go out and get another one. Then you got two problems."
That episode aired in 2001. I wonder if the NAT quote is inspired by that?
That episode aired in 2001. I wonder if the NAT quote is inspired by that?
The original quote was about regexps, not NAT. But I have no idea whether JWZ invented it or was took it from ELR.
Full story here: <https://news.ycombinator.com/item?id=5188060>
I thought it was always DNS?
I thought it's BGP? Or maybe that's just the cause of all problems, hmm...
My understanding of BGP is that it’s so old (and was relatively well designed) that it could now be considered an arcane magic once widespread but now only known by some old wizards.
The problem with both is that they were both designed long ago, without much regard to bad actors. They have been around so long replacing would be a herculean effort.
For some reason whenever I interview very junior candidates - every _single_ one of them has BGP on their resume as a skill.
0% of them have correctly been able to explain what BGP is used for.
0% of them have correctly been able to explain what BGP is used for.
Would answer "I use it host servers at home and have load-balanced access to internet via several end-users ISPs(no BGP sessions with ISPs so 2 VPN tunnels from home to server + 2 BGP sessions from home to said server via tunnels and server itself have session with it's ISP) count?" :)
Would "I'm just getting lists of IPs blocked by local censorship authority/IPs which are better to access via IP from OTHER country to put them all in VPN" count? :)
p.s. I'm not network admin and never put "BGP" on resume.
Would "I'm just getting lists of IPs blocked by local censorship authority/IPs which are better to access via IP from OTHER country to put them all in VPN" count? :)
p.s. I'm not network admin and never put "BGP" on resume.
Junior candidates for what position?
> Or maybe that's just the cause of all problems, hmm...
It sure is the cause of some of the worst problems.
It sure is the cause of some of the worst problems.
That'a just all the problems, no solutions.
Yes, but it's also an issue with IPv6. NAT is nearly always involved with whenever you touch IPv4.
You could easily get away with IPv6 only networks in some countries.
It's usually NAT, with DNS as a very close second place.
NAT is great. I can think of no problems caused by NAT. I can immediately think of my experiences with IPv6 and all loss of privacy.
Can't tell whether this is trolling or serious. Breaking the end-to-end principle has had profound effects on the Internet as a whole for the last 2 decades, centralization being the most obvious one.
I used to keep a copy of this paper with me: <https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...>
Trolling? No. NAT breaks something? No. IPv6 breaks privacy at a minimum and probably opens our devices to security issues. IPv6 is what's broken.
Citation needed on "breaking privacy". You have at least 2^64 IPv6 addresses per household, cycle through them and stop worrying about IP tracking.
Oh, and I can give citation on how NAT breaks something. Until the day we can magically remove application-level gateways[0] I consider NAT a fundamentally broken hack.
[0]: https://en.wikipedia.org/wiki/Application-level_gateway
Oh, and I can give citation on how NAT breaks something. Until the day we can magically remove application-level gateways[0] I consider NAT a fundamentally broken hack.
[0]: https://en.wikipedia.org/wiki/Application-level_gateway
That's not how any of this works.
> To address this (no pun intended),
Liars, you definitely did.
I was a bit surprised when I learned tailscale was addressing out of a single global pool and wondered how they would fix it when they ran out of IPs (and I knew they would, Tailscale was and is obviously that good to me). I vaguely suspected this would be kind of solution they would employ because it's really perfect from an end-user experience point of view, but, thought they might not because it's definitely more complex on their side. Shame on me for misunderestimating the tailscale team.
Liars, you definitely did.
I was a bit surprised when I learned tailscale was addressing out of a single global pool and wondered how they would fix it when they ran out of IPs (and I knew they would, Tailscale was and is obviously that good to me). I vaguely suspected this would be kind of solution they would employ because it's really perfect from an end-user experience point of view, but, thought they might not because it's definitely more complex on their side. Shame on me for misunderestimating the tailscale team.
Hot take: The Tailscale team is the highest concentration of leading network engineers from any company in the world today, at least when it comes to consumer products. If we ever get a true 'next gen' internet that removes the protocol cruft we've layered on over the years, I could see it coming out of them moreso anyone else.
I'm a very happy Tailscale user and am impressed by its quality and reliability... But why is the team constantly put on the highest of pedestals here on HN? They seem like one of many groups of competent people making good software to me. Perhaps the answer is that they're so good that I vastly underestimate the complexity of the problem Ts solves?
Their devrel is incredible, and to be fair the UX of their product is really good and resembles magic to someone unfamiliar with wireguard.
HN falls for dev marketing really hard every time (see: vercel, stripe, etc)
HN falls for dev marketing really hard every time (see: vercel, stripe, etc)
they take a complex problem, AND a complex solution, and make it beautifully simple so /it just works/, in a way no other system has. The documentation is superb and frequently just makes sense when you do it.
Well that's certainly a hot take. While I have no doubt the Tailscale team has some talented minds, I am not so naive as to expect a truly reimagined Internet—i.e. one that puts privacy, anonymity in first place, and removes the need for Cloudflare-like MITM—to come out of a government or private company, especially one that's fueled by grow-fast venture capital money.
I'm talking more at the protocol level. My number 2 contender would be Google with spdy/quik, but that was 2009/early 2010s.
I'm probably biased because some tailscale employees gave me some of the best written explanation for the evolution of networking infra protocols I've seen, will dig it up from my comment history in a sec
I'm probably biased because some tailscale employees gave me some of the best written explanation for the evolution of networking infra protocols I've seen, will dig it up from my comment history in a sec
> We all know how well IPv6 adoption has gone
What frustrates me is that people keep building solutions like this that heavily rely on IPv4, even when forward-compatible options exist. With clever use of IPv6 transition technologies, you could have retained support for legacy devices while generally using IPv6 everywhere else.
What frustrates me is that people keep building solutions like this that heavily rely on IPv4, even when forward-compatible options exist. With clever use of IPv6 transition technologies, you could have retained support for legacy devices while generally using IPv6 everywhere else.
Tailscale supports IPv6. But their IPv6 support is useless to you if your ISP doesn’t support IPv6.
This is a needed feature if you have no IPv6 AND are stuck in CGNAT hell.
And I’m an IPv6 evangelist.
This is a needed feature if you have no IPv6 AND are stuck in CGNAT hell.
And I’m an IPv6 evangelist.
No, Tailscale creates both IPv4 and IPv6 connectivity over .. well pretty much anything. If there's IPv4 - it will use it, if there's IPv6 - it will use it. If there's some traversable NAT - it will use it. I think we should dig out the old meme about ADSL running over a pair of wet strings.
> If there's some traversable NAT - it will use it.
But there is no traversable NAT if you’re stuck in CGNAT hell with no IPv6 and the CGNAT subnet they gave conflicts with the one you have. Unless you NAT it again or do some other route fuckery.
NAT4444 sounds really great!
But there is no traversable NAT if you’re stuck in CGNAT hell with no IPv6 and the CGNAT subnet they gave conflicts with the one you have. Unless you NAT it again or do some other route fuckery.
NAT4444 sounds really great!
> IPv6 support is useless to you if your ISP doesn’t support IPv6.
I can't upvote this enough. It is my experience that IPv6 advocates deflect hard when this gets brought up.
The vibe I get is people stuck with IPv4-only IPSs are insignificant and unimportant. They simply do not matter.
I can't upvote this enough. It is my experience that IPv6 advocates deflect hard when this gets brought up.
The vibe I get is people stuck with IPv4-only IPSs are insignificant and unimportant. They simply do not matter.
> And I’m an IPv6 evangelist.
Nice! Learning ipv6 is on my bucket list, any resources that you like to recommend?
Nice! Learning ipv6 is on my bucket list, any resources that you like to recommend?
I kind of just winged it. But IPv6 is really super similar to IPv4. The key differences are:
- 128-bit addresses, expressed in hexadecimal. A single character is 4 bits (making every 4 bits a nibble boundary, making allocations really easy)
- All subnets are /64 (if you really want to have a different size subnet, you can, but it’s against the standard, and anything other than /64 will break SLAAC. There is one exception to the standard—point to point links are allowed to have a /127)
- The concept of a network address or a broadcast address within the subnet doesn’t exist. ff02::1 is the all-nodes link-local multicast address (serves the same purpose as a broadcast address in v4).
- ARP is gone. A very similar protocol, ND takes its place
- The preferred way to assign addresses to endpoint devices is SLAAC. Which is basically the router telling the endpoints to self-assign. Ridiculously small chance of a collision, and in case a collision happens, just run the rng again. It’s 64 bits after all. You can use DHCPv6 instead or in tandem with SLAAC if you need more granularity.
- You don’t need to use NAT. Which means you have to set up a firewall on the router correctly. Default-deny, while still allowing ALL ICMP traffic through, as ICMP is kinda vital for IPv6 because it’s used to communicate error conditions.
I’m sure I’ve missed something, but these are all the differences I can recall from the top of my head.
- 128-bit addresses, expressed in hexadecimal. A single character is 4 bits (making every 4 bits a nibble boundary, making allocations really easy)
- All subnets are /64 (if you really want to have a different size subnet, you can, but it’s against the standard, and anything other than /64 will break SLAAC. There is one exception to the standard—point to point links are allowed to have a /127)
- The concept of a network address or a broadcast address within the subnet doesn’t exist. ff02::1 is the all-nodes link-local multicast address (serves the same purpose as a broadcast address in v4).
- ARP is gone. A very similar protocol, ND takes its place
- The preferred way to assign addresses to endpoint devices is SLAAC. Which is basically the router telling the endpoints to self-assign. Ridiculously small chance of a collision, and in case a collision happens, just run the rng again. It’s 64 bits after all. You can use DHCPv6 instead or in tandem with SLAAC if you need more granularity.
- You don’t need to use NAT. Which means you have to set up a firewall on the router correctly. Default-deny, while still allowing ALL ICMP traffic through, as ICMP is kinda vital for IPv6 because it’s used to communicate error conditions.
I’m sure I’ve missed something, but these are all the differences I can recall from the top of my head.
> You don’t need to use NAT. Which means you have to set up a firewall on the router correctly. Default-deny, while still allowing ALL ICMP traffic through, as ICMP is kinda vital for IPv6 because it’s used to communicate error conditions.
I do think using NAT in the form of NPTv6 is awesome for home use because it allows you to have a consistent address regardless of your ISP prefix assignment.
Think of NPTv6 as a kind of "stateless NAT" where the prefix is mapped 1:1 to your internal prefix. This means if your ISP changes your address, you only need to your external DNS versus all of your devices.
I do think using NAT in the form of NPTv6 is awesome for home use because it allows you to have a consistent address regardless of your ISP prefix assignment.
Think of NPTv6 as a kind of "stateless NAT" where the prefix is mapped 1:1 to your internal prefix. This means if your ISP changes your address, you only need to your external DNS versus all of your devices.
> This means if your ISP changes your address
Yes. If your prefix is dynamic, stateless NAT66 can reduce some headaches. But that’s just about the only use case.
Yes. If your prefix is dynamic, stateless NAT66 can reduce some headaches. But that’s just about the only use case.
You don’t need a system for assigning IPv4LL addresses (169.254.0.0/16), since IPv6 has automatic link-local addresses on all interfaces.
Do the hurricane electric IPv6 stuff. You need a Linux box and a domain maybe.
https://ipv6.he.net/certification/
When you run into issues, google.
https://ipv6.he.net/certification/
When you run into issues, google.
IPv6 for IPv4 Experts: https://sites.google.com/site/yartikhiy/home/ipv6book
this looks cool but the "DRAFT" watermark makes it un-readable.
If you have an agent installed on every node that can already traverse NAT, you don't have to care about what your ISP supports.
There are many more IPv6-centric solutions to their problem. Sounds like they didn't even try to think of alternatives and instead reached straight for NAT. That wasn't necessary, at least from the amount of information we can glean from this one post.
There are many more IPv6-centric solutions to their problem. Sounds like they didn't even try to think of alternatives and instead reached straight for NAT. That wasn't necessary, at least from the amount of information we can glean from this one post.
(Tailscale cofounder here) Tailscale already gives every node on every tailnet a globally unique internal IPv6 address, that is reachable even if you don't have IPv6 on the "outside" network. If your apps and OSes are all willing to use IPv6, you haven't had a problem since the early days of Tailscale; they've been solved for years.
Alas, the "apps and OSes are all willing to use IPv6" problem is a persistent one, so we have to make IPv4 work too.
Alas, the "apps and OSes are all willing to use IPv6" problem is a persistent one, so we have to make IPv4 work too.
We considered so many alternatives actually.
are those discarded documented somewhere so we don't walk in circles?
i'm at ipv6 luddite
i don't agree with any addressing that can append or encode a mac address into the tcp/ip stack
One problem is not acknowledging just how bad ipv6 is being rolled out in the US.
Once promoted as a way to give every internet device you would like a reachable external IP … has instead been a new protocol locked behind giant corporations and telecoms. Now mobile providers and some ISP play gatekeeper … don’t allow you to keep any IPv6 devices (rotate assignments) so we end up with little benefit to the end consumer.
The idea that a home user ca setup a desktop and share anything I want via IPV6 another person without the need for a middle man “cloud” provider just didn’t happen. In fact requesting blocks of IPv6 is not easy … and at the end of the day for the average user who cares.
Great so Verizon can now assign my phone and IPv6 address… that I can literally do nothing with.
Corporate greed / government control have severely limited any usefulness of IPv6 at least here in the US
Once promoted as a way to give every internet device you would like a reachable external IP … has instead been a new protocol locked behind giant corporations and telecoms. Now mobile providers and some ISP play gatekeeper … don’t allow you to keep any IPv6 devices (rotate assignments) so we end up with little benefit to the end consumer.
The idea that a home user ca setup a desktop and share anything I want via IPV6 another person without the need for a middle man “cloud” provider just didn’t happen. In fact requesting blocks of IPv6 is not easy … and at the end of the day for the average user who cares.
Great so Verizon can now assign my phone and IPv6 address… that I can literally do nothing with.
Corporate greed / government control have severely limited any usefulness of IPv6 at least here in the US
> Now mobile providers and some ISP play gatekeeper … don’t allow you to keep any IPv6 devices (rotate assignments) so we end up with little benefit to the end consumer.
I see this as a feature not a bug. Use dynamic DNS if you need a stable endpoint here.
> The idea that a home user ca setup a desktop and share anything I want via IPV6 another person without the need for a middle man “cloud” provider just didn’t happen.
You can, you likely just need to change the default firewall settings on a typical ISP provided router.
> Corporate greed / government control have severely limited any usefulness of IPv6 at least here in the US
I don't see how either of those have to do with this.
I see this as a feature not a bug. Use dynamic DNS if you need a stable endpoint here.
> The idea that a home user ca setup a desktop and share anything I want via IPV6 another person without the need for a middle man “cloud” provider just didn’t happen.
You can, you likely just need to change the default firewall settings on a typical ISP provided router.
> Corporate greed / government control have severely limited any usefulness of IPv6 at least here in the US
I don't see how either of those have to do with this.
Dynamic DNS for example through cloudflare … is a middleman. Great effort has been taken to make obtaining a small block of IPv6 addresses difficult for the end user.
It’s true a few isps will provide you a static up but most will not.
https://www.arin.net/resources/guide/ipv6/first_request/
In most implementations the end user sees no benefit from IPv6 or simply an isp using carrier grade NAT. When IPv6 first rolled out it was promoted as a way for everyone to easily obtain addresses .. reality is not so much. End user functionality crippled Or gatekeeped
Hypothetically should be to host a simple file share of let’s say photos on a desktop and share using SMB or another protocol via IPv6. No need for cloud provider / iCloud Photos, Google or whatever. Just a direct connection with a desktop that stays on 24/7. This is not the case and effort has been made to make IPv6 really more of a useful protocol to mobile isps managing large numbers of new devices.
IMO #lame
It’s true a few isps will provide you a static up but most will not.
https://www.arin.net/resources/guide/ipv6/first_request/
In most implementations the end user sees no benefit from IPv6 or simply an isp using carrier grade NAT. When IPv6 first rolled out it was promoted as a way for everyone to easily obtain addresses .. reality is not so much. End user functionality crippled Or gatekeeped
Hypothetically should be to host a simple file share of let’s say photos on a desktop and share using SMB or another protocol via IPv6. No need for cloud provider / iCloud Photos, Google or whatever. Just a direct connection with a desktop that stays on 24/7. This is not the case and effort has been made to make IPv6 really more of a useful protocol to mobile isps managing large numbers of new devices.
IMO #lame
> Use dynamic DNS if you need a stable endpoint here.
How do you tell an embedded device to push a DDNS update?
How do you tell an embedded device to push a DDNS update?
I don't use Tailscale, I use my own VPS and Wireguard but no way in my lifetime will I allow IPv6 to have any prevalence on any of my systems.
The only thing preventing me from using tailscale is that to register I need to give my data to shitty companies like Google, Microsoft or apple but i used it when I was at a company where I had a company github account and it was nice, but personally it’s not even for privacy, i just want nothing to do with those companies
So i hope one day you will be able to register with user and password
So i hope one day you will be able to register with user and password
They support OIDC login now, so you don't need an Apple/Google/Microsoft account.
There's an open source server implementation called headscale that works with the tailsxale clients
I think it's interesting that all recent contributions to this "open source alternative" are done by a tailscale employee. Wonder what's preventing them from making the official client open-source
https://github.com/juanfont/headscale/commits/main/
https://github.com/juanfont/headscale/commits/main/
I’m curious if anybody else sees tailscale / headscale in the same way that I do — I was avoiding signing up to tailscale because I didn’t want to be locked into a proprietary platform, but since learning that headscale exists and is “good enough”, I’m now happy to be a tailscale customer safe in the knowledge that I can fall back to self-hosting when needed.
(Yes the company _could_ do a sudden 180 and start intentionally breaking compatibility and forbidding that their clients be used with third-party servers - but the risk of that doesn’t seem much different than the risk of an open-source alternative being abandoned)
(Yes the company _could_ do a sudden 180 and start intentionally breaking compatibility and forbidding that their clients be used with third-party servers - but the risk of that doesn’t seem much different than the risk of an open-source alternative being abandoned)
>Wonder what's preventing them from making the official client open-source
Probably having a full time job that people will actually support? Open source software doesn't reward effort.
Headscale does not have a nice UI, its basically all CLI usage. There's very good reason to use Tailscale for companies and there's also good reasons for Tailscale to support an opensource implementation of their control server, I've seen it from both ends as people go either way, it's a symbiotic relationship and probably one of the best examples in open source today.
Probably having a full time job that people will actually support? Open source software doesn't reward effort.
Headscale does not have a nice UI, its basically all CLI usage. There's very good reason to use Tailscale for companies and there's also good reasons for Tailscale to support an opensource implementation of their control server, I've seen it from both ends as people go either way, it's a symbiotic relationship and probably one of the best examples in open source today.
It's more interesting that Headscale is officially "encouraged": https://tailscale.com/opensource/#encouraging-headscale
I haven't tried it yet, but you can use a Yubikey now.
https://tailscale.com/kb/1269/passkeys/
https://tailscale.com/kb/1269/passkeys/
I tried, you can use a yubikey only to log in a existing enterprise account
Does this not work for you?
https://tailscale.com/kb/1240/sso-custom-oidc/
https://tailscale.com/kb/1240/sso-custom-oidc/
Casdoor seems to be a good fit as a free solution of SSO: https://casdoor.org/
For companies this is the way. But I guess for personal use a private Keycloak instance is a bit overkill?
You certainly don't need a full on Keycloak installation here, if you don't want to go that far. There's various OIDC providers, some more complex than others!
If you already have LDAP or some other backing auth, setting up Dex for OIDC is pretty easy. Took me less than an hour or so.
If you want something fancier Authelia isn't too bad, I got that running in an evening and hooking it up to Tailscale took another hour or two. Most of that spent figuring out how I want to do webfinger.
If you want something fancier Authelia isn't too bad, I got that running in an evening and hooking it up to Tailscale took another hour or two. Most of that spent figuring out how I want to do webfinger.
Curious, do you any blog/post that you used to guide your set up that you can share?
I haven't written one yet, but the provided docs are pretty easy to follow:
1. Tailscale has their custom OIDC docs that tell you everything you need, plus the Webfinger setup: https://tailscale.com/kb/1240/sso-custom-oidc/
2. I set up Webfinger first, so assuming you're setting it up from scratch you can either run a Webfinger server yourself, or just configure the paths in whatever web server you have for your base domain. I didn't feel like running Yet Another Server and since the Tailnet's only for me I just plugged the following section into Caddy:
3. For Dex you can just set it up like any OIDC connection; Authelia was about the same but they have their own page: https://www.authelia.com/integration/openid-connect/tailscal...
Took me about an hour or two, most of that being wishy-washy on how I wanted to serve Webfinger.
1. Tailscale has their custom OIDC docs that tell you everything you need, plus the Webfinger setup: https://tailscale.com/kb/1240/sso-custom-oidc/
2. I set up Webfinger first, so assuming you're setting it up from scratch you can either run a Webfinger server yourself, or just configure the paths in whatever web server you have for your base domain. I didn't feel like running Yet Another Server and since the Tailnet's only for me I just plugged the following section into Caddy:
@webfinger {
path /.well-known/webfinger
method GET HEAD
query resource=acct:MY@EMAIL
}
rewrite @webfinger /webfinger.json
header @webfinger {
Content-Type "application/jrd+json"
Access-Control-Allow-Origin "\*"
X-Robots-Tag "noindex"
}3. For Dex you can just set it up like any OIDC connection; Authelia was about the same but they have their own page: https://www.authelia.com/integration/openid-connect/tailscal...
Took me about an hour or two, most of that being wishy-washy on how I wanted to serve Webfinger.
I setup authelia specifically for this and it was barely a morning's work, and works beautifully.
I guess I'm doing overkill then. I actually use Keycloak for Tailscale. It also serves as authentication for my Nextcloud and Mastodon instances, so maybe slightly less overkill.
I'd want to run the console myself anyway.
If the admin console is run by them, it's pretty trivial for them or an attacker to add nodes to my network. Zerotier suffers from the same issue.
Tailscale is cool and the third party login is also a problem for me, but the hosted service in general is a much bigger core issue with it for me that not only affects privacy but also security.
If the admin console is run by them, it's pretty trivial for them or an attacker to add nodes to my network. Zerotier suffers from the same issue.
Tailscale is cool and the third party login is also a problem for me, but the hosted service in general is a much bigger core issue with it for me that not only affects privacy but also security.
You can host the independently implemented OSS version yourself: https://github.com/juanfont/headscale
For me the headache of running my and maintaining my own server isn’t worth it (+ would still require a GCP/AWS account)
For me the headache of running my and maintaining my own server isn’t worth it (+ would still require a GCP/AWS account)
Cool, I didn't know this existed. It seems to be a third party server similar to what vaultwarden does for bitwarden?
But why would it need a gcp or aws account? It could run on any vps right? I'd run it on something much cheaper like scaleway.
But why would it need a gcp or aws account? It could run on any vps right? I'd run it on something much cheaper like scaleway.
It doesn't. You can run it on a VPS and you have an option to use SSO with OIDC integration.
No local logins? I don't really want that SSO stuff. Just a local username/pw combo would be perfect :)
By default, headscale doesn't have a web interface/login as such and all configuration is done via the CLI on the server running headscale. So, your login is effectively PAM. You use authkeys etc to add machines.
By reading the title I imagined a brand new way address routing. That’s how high I regard Tailscale, I guess.
I remember watching many years ago a talk about a mesh network scheme where its users would unambiguously assign themselves addresses through some hash function. I was fascinated by this concept of generating my own address (instead of having it assign to me) and that it could possibly be mine forever, perhaps associated with some biometric marker.
Anyway, this is also cool, just less ambitious :)
I remember watching many years ago a talk about a mesh network scheme where its users would unambiguously assign themselves addresses through some hash function. I was fascinated by this concept of generating my own address (instead of having it assign to me) and that it could possibly be mine forever, perhaps associated with some biometric marker.
Anyway, this is also cool, just less ambitious :)
> I remember watching many years ago a talk about a mesh network scheme where its users would unambiguously assign themselves addresses through some hash function.
Was it this one -> https://github.com/cjdelisle/cjdns/ ?
Anyway, I fully agree with you. Assigning meaningless (and therefore collision-prone and spoofable) numbers to people/machines just seems like such an arcane idea in light of all the cryptographic advances people have made.
Whatever network I configure, I always need to worry about collisions or possible misconfigurations. Whether I set up some private VPN for myself and have to worry about potential spoofed IP packets from outside, or whether I connect to a corporate VPN from home and suddenly I can no longer ping 1.1.1.1 because their IT department couldn't be bothered to configure their routes correctly. It's insane.
Was it this one -> https://github.com/cjdelisle/cjdns/ ?
Anyway, I fully agree with you. Assigning meaningless (and therefore collision-prone and spoofable) numbers to people/machines just seems like such an arcane idea in light of all the cryptographic advances people have made.
Whatever network I configure, I always need to worry about collisions or possible misconfigurations. Whether I set up some private VPN for myself and have to worry about potential spoofed IP packets from outside, or whether I connect to a corporate VPN from home and suddenly I can no longer ping 1.1.1.1 because their IT department couldn't be bothered to configure their routes correctly. It's insane.
I was thinking it might be https://yggdrasil-network.github.io/
Maybe it was cjdns, I don’t know, but I couldn’t find the particular talk on YouTube by that name.
But yes, someday, maybe we’ll laugh at the current state of things and the shortage of IPs.
But yes, someday, maybe we’ll laugh at the current state of things and the shortage of IPs.
I hope they are working on improving firewall traversal. Lots of firewalls don't allow symmetrical UDP NAT ports, causing clients to fall back to DERP relays on TCP port 443. It's a lot slower. It is possible to work around this by statically mapping inbound UDP ports but that is clearly not an ideal situation. I generally love Tailscale though, amazing work all around.
From the extensive blog posts about all the tricks they already use, I’d assume they’ve squeezed all the juice from that orange.
https://tailscale.com/blog/how-nat-traversal-works/
https://tailscale.com/blog/how-nat-traversal-works/
Do you know of a straightforward way to identify that this is happening: where one node is using DERP or one link between your nodes is falling back to DERP?
`tailscale status` should tell you which nodes do or don't have a direct connection.
Oh I wasn't aware of this, thanks for sharing this.
Tailscale is needed if you require site to site connectivity via something like Starlink.
I may be putting my ignorance on display here, but I recently completed a site-to-site network between two farms in rural America, no other ISP can serve these farms, and they needed to communicate cow data between the different farms. Tailscale did the majority of the heavy lifting thankfully, and we were able to get them all sorted out.
I could not get Wireguard to work, and that may be down to my limitations in networking, but I was sucessful with tailscale, so make of that as you will.
I may be putting my ignorance on display here, but I recently completed a site-to-site network between two farms in rural America, no other ISP can serve these farms, and they needed to communicate cow data between the different farms. Tailscale did the majority of the heavy lifting thankfully, and we were able to get them all sorted out.
I could not get Wireguard to work, and that may be down to my limitations in networking, but I was sucessful with tailscale, so make of that as you will.
Lack of Wireguard docs/tutorials is unfortunate, because I'm in the same boat. I'm using Tailscale now because I just don't know enough about linux networking to figure out why my packets aren't going where they should. I suspect it's a very simple config error, but I don't know how to debug or where to look. I like Tailscale, but I'd much rather use real wireguard and eliminate a dependency on tailscale, but I can't find guides/tutorials/etc.
If anyone knows of a Wireguard walk-through to bridge two separate LANs together, I'd love to see it
If anyone knows of a Wireguard walk-through to bridge two separate LANs together, I'd love to see it
> Lack of Wireguard docs/tutorials is unfortunate
The thing about Wireguard is that it's very simple and minimal. It does just one thing, and that is - establishes a layer 3 tunnel for sending IP packets between local machine and some other peers. It doesn't do mesh, it doesn't do routing (it just knows the IPs of its direct peers and that's all it does), it doesn't do bridging - all this stuff is done by other pieces such as Linux kernel, but not Wireguard itself.
> Wireguard walk-through to bridge two separate LANs
Same or different subnets for those LANs? If they're different and non-intersecting, and if you don't need cross-LAN broadcast or multicast, the simplest option is to establish a Wireguard connection between those LAN's default gateway routers (assuming you can do this), and on each of those routers set up a route that sends opposite LAN's traffic to the opposite gateway (in case of iproute2: `ip route add my.other.lan.subnet/mask via my.other.lan.gw`, how to make this persistent depends on your distro). Then, on each gateway, allow packet forwarding between Wireguard and LAN interfaces (with e.g. iptables or nftables or whatever you use there).
If you can't run Wireguard on gateways, the overall principle holds, but you'll need to distribute routes to your respective LANs via Wireguard-running routers through DHCP or whatever you use for routing on your LANs (e.g. OSPF).
And if your LANs both have the same subnet, or if you need multicast, things get significantly trickier (plus, there's inevitable question of what should happen if two machines on different LANs have the same IP). You'll probably need to run something like L2TP or GRETAP (or something else that can encapsulate you layer 2) over Wireguard.
Or maybe just use OpenVPN in TAP mode (if you want all stuff independent of any third parties) or Tailscale (because it already works).
The thing about Wireguard is that it's very simple and minimal. It does just one thing, and that is - establishes a layer 3 tunnel for sending IP packets between local machine and some other peers. It doesn't do mesh, it doesn't do routing (it just knows the IPs of its direct peers and that's all it does), it doesn't do bridging - all this stuff is done by other pieces such as Linux kernel, but not Wireguard itself.
> Wireguard walk-through to bridge two separate LANs
Same or different subnets for those LANs? If they're different and non-intersecting, and if you don't need cross-LAN broadcast or multicast, the simplest option is to establish a Wireguard connection between those LAN's default gateway routers (assuming you can do this), and on each of those routers set up a route that sends opposite LAN's traffic to the opposite gateway (in case of iproute2: `ip route add my.other.lan.subnet/mask via my.other.lan.gw`, how to make this persistent depends on your distro). Then, on each gateway, allow packet forwarding between Wireguard and LAN interfaces (with e.g. iptables or nftables or whatever you use there).
If you can't run Wireguard on gateways, the overall principle holds, but you'll need to distribute routes to your respective LANs via Wireguard-running routers through DHCP or whatever you use for routing on your LANs (e.g. OSPF).
And if your LANs both have the same subnet, or if you need multicast, things get significantly trickier (plus, there's inevitable question of what should happen if two machines on different LANs have the same IP). You'll probably need to run something like L2TP or GRETAP (or something else that can encapsulate you layer 2) over Wireguard.
Or maybe just use OpenVPN in TAP mode (if you want all stuff independent of any third parties) or Tailscale (because it already works).
A few years ago I decided to get my own ASN. I have a couple of VPSes running BGP with my upstreams at geographically diverse but relatively close locations (10 to 15 ms ping.) I have Wireguard tunnels between the VPSes and also from each VPS to my home network, forming a mesh w/OSPF. Originally, I was only injecting default routes into OSPF so I'd have basic redundancy if things failed, treating one provider as a secondary, not caring much about outgoing load balancing. I recently switched to internal BGP though, and am doing some load balancing w/partial tables. Pretty cool stuff. I used BIRD for OSPF and BGP.
The end of your comment “or use Tailscale” sums up why I would use Tailscale here.
Of course. Picking a tool is always a matter of what one already knows. If you've already learned Tailscale and it fits all your requirements - that means you go with it, unless you have some reasons not to do it (which is rare).
And Tailscale surely has one benefit here - it's one single product, with essentially no variations, so it's (I presume, I haven't ever used Tailscale myself - never needed it) easy to write a step-by-step instructions for. Generic "GNU/Linux software router with Wireguard" is an extremely vague target that impossible to give instructions for, unless you spend a lot of time describing the problem in finer detail.
And Tailscale surely has one benefit here - it's one single product, with essentially no variations, so it's (I presume, I haven't ever used Tailscale myself - never needed it) easy to write a step-by-step instructions for. Generic "GNU/Linux software router with Wireguard" is an extremely vague target that impossible to give instructions for, unless you spend a lot of time describing the problem in finer detail.
> I like Tailscale, but I'd much rather use real wireguard and eliminate a dependency on tailscale, but I can't find guides/tutorials/etc.
You could use Headscale, which is an open-source/self-hosted reimplementation of Tailscale control plane, so you can eat your cake and have it too.
Curious to know, why does distrust towards Tailscale come up so often around here? They seem extremely transparent about their strategy and incentives.
You could use Headscale, which is an open-source/self-hosted reimplementation of Tailscale control plane, so you can eat your cake and have it too.
Curious to know, why does distrust towards Tailscale come up so often around here? They seem extremely transparent about their strategy and incentives.
> Curious to know, why does distrust towards Tailscale come up so often around here?
I have a guess - I suspect it's because in the domain it addresses, attitudes are towards self-reliance, privacy and autonomy.
If someone uses Tailscale in some cloudy (aka all someone else's computers) setup, they probably don't bother. They already shift trust and rely on other people.
But Tailscale is infrequently used to manage own devices, which is why it clashes with self-reliance attitudes. If you run your own private hardware and networks, all or many of those in your own castle, it may bug you to introduce (or I'd rather say trust) a third party unless you're forced to. Not because it's not trustworthy, but because of the self-reliance attitude and desire to have full control over what you think of your own systems.
Sure, you're forced to trust your electricity provider (but you have an UPS) or network uplink (and even then you make security precaution), but trust in Tailscale is kind of optional (it's not irreplaceable), and not everyone feel like they want it.
Pretty much the same why a lot of people frown upon IoT stuff, even if it's from rare vendors who go extra mile to make things reliable - because of the hypothetical "but what if?" and feeling that you're losing the control here.
Just a guess, though. Others' mileage may vary.
I have a guess - I suspect it's because in the domain it addresses, attitudes are towards self-reliance, privacy and autonomy.
If someone uses Tailscale in some cloudy (aka all someone else's computers) setup, they probably don't bother. They already shift trust and rely on other people.
But Tailscale is infrequently used to manage own devices, which is why it clashes with self-reliance attitudes. If you run your own private hardware and networks, all or many of those in your own castle, it may bug you to introduce (or I'd rather say trust) a third party unless you're forced to. Not because it's not trustworthy, but because of the self-reliance attitude and desire to have full control over what you think of your own systems.
Sure, you're forced to trust your electricity provider (but you have an UPS) or network uplink (and even then you make security precaution), but trust in Tailscale is kind of optional (it's not irreplaceable), and not everyone feel like they want it.
Pretty much the same why a lot of people frown upon IoT stuff, even if it's from rare vendors who go extra mile to make things reliable - because of the hypothetical "but what if?" and feeling that you're losing the control here.
Just a guess, though. Others' mileage may vary.
I think that's a pretty good guess.
In my personal case, It's a mix of self-reliance and a committment to open source that makes me want to have an alternative to tailscale (although I use Tailscale for company stuff and that was my call). On top of that, for personal stuff I just have very simple networking needs, and I don't want to add yet another service (a headscale instance) I have to maintain and keep running, and in the case of headscale it's particularly important because I might lose my network if it goes down! For that reason, a tailscale-only solution that is all client and no server is attractive.
Side note: the existence of headscale is the reason why I decided to pay Tailscale for company stuff. Had the clients not been open source, and there had not been a compatible FOSS server implementation, I would have spent the time/money slinging wireguard or using some other solution. I love Tailscale for opening the clients and allowing/even supporting headscale.
In my personal case, It's a mix of self-reliance and a committment to open source that makes me want to have an alternative to tailscale (although I use Tailscale for company stuff and that was my call). On top of that, for personal stuff I just have very simple networking needs, and I don't want to add yet another service (a headscale instance) I have to maintain and keep running, and in the case of headscale it's particularly important because I might lose my network if it goes down! For that reason, a tailscale-only solution that is all client and no server is attractive.
Side note: the existence of headscale is the reason why I decided to pay Tailscale for company stuff. Had the clients not been open source, and there had not been a compatible FOSS server implementation, I would have spent the time/money slinging wireguard or using some other solution. I love Tailscale for opening the clients and allowing/even supporting headscale.
I found the blog articles on https://www.procustodibus.com/blog/ super helpful and well written.
You don't have to use their service to implement what they describe, in most cases.
You don't have to use their service to implement what they describe, in most cases.
Create a wireguard interface on each end, add the keys to them, open up the allow list for each subnet, assign a IP from a /30 (or /31) subnet on each end, set static routes to point to other end or use a dynamic routing protocol.
There are tools to automate this like wg-quick and systemd-networkd, depending on your preference.
There are tools to automate this like wg-quick and systemd-networkd, depending on your preference.
On my synology ds418j Tailscale was faster than WireGuard over the same interface. WireGuard used 30 to 50 percent more cpu.
Was strange, but not a real problem. Just an anecdote.
Tailscale userland go WireGuard implementation is often faster and uses less CPU that the kernel one.
> no other ISP
I live in Iowa and the problem we have is nobody markets their stuff very well. We have a fixed wireless provider that, looking at their website, looks like they are just a cell tower climbing service. But they also lease space on just about every tall structure in the region (grain elevators etc) and can connect anything to anything. We got to them because we asked a WISP if they would do a private backhaul and the guy referred us over to somebody's cell phone. I guess they are happy to just have word of mouth and only have the website to reel in bonus work with the out of town telcos.
Never had worse than next day service on any lightning strike event from this guy, which is more than I can say for mediacom or lumen lol.
I live in Iowa and the problem we have is nobody markets their stuff very well. We have a fixed wireless provider that, looking at their website, looks like they are just a cell tower climbing service. But they also lease space on just about every tall structure in the region (grain elevators etc) and can connect anything to anything. We got to them because we asked a WISP if they would do a private backhaul and the guy referred us over to somebody's cell phone. I guess they are happy to just have word of mouth and only have the website to reel in bonus work with the out of town telcos.
Never had worse than next day service on any lightning strike event from this guy, which is more than I can say for mediacom or lumen lol.
> but I recently completed a site-to-site network between two farms in rural America, no other ISP can serve these farms, and they needed to communicate cow data between the different farms.
This may be verging on off-topic, but it's too good an opportunity to not deliver this very fitting reminder: in 2018 Anja Karliczek, then-Minister of Science of Germany, made headlines for the quote "5G nicht an jeder Milchkanne notwendig" [1] ("you don't need 5G on every milk jug") aka the rural areas (that had been left behind even with prior mobile phone/data and even landline DSL deployments) didn't have enough need for fast Internet access.
So, to answer her question, what exactly are these farms doing that they need to exchange cow metrics? Tracking of milk production per cow?
[1] https://www.spiegel.de/politik/deutschland/anja-karliczek-br...
This may be verging on off-topic, but it's too good an opportunity to not deliver this very fitting reminder: in 2018 Anja Karliczek, then-Minister of Science of Germany, made headlines for the quote "5G nicht an jeder Milchkanne notwendig" [1] ("you don't need 5G on every milk jug") aka the rural areas (that had been left behind even with prior mobile phone/data and even landline DSL deployments) didn't have enough need for fast Internet access.
So, to answer her question, what exactly are these farms doing that they need to exchange cow metrics? Tracking of milk production per cow?
[1] https://www.spiegel.de/politik/deutschland/anja-karliczek-br...
That's a fair question, I assume it's milk production tracking, health status of each cow, etc. That's a bit out of my wheel house. This was previously 2 different farms owned by two different families, but after 2020 a lot of these places sold off their farms due to financial hardships. I lost a ton of clientele over the course of 2020 due to mega farms buying them out for pennies on the dollar.
I don't think you need Tailscale for this.
You need tailscale when:
1) You have a lot of road-warriors
2) You need decent ACLs that isn't just IP based.
3a) You don't ability to directly connect to a site (just one needs to be accessible)
3b) You can't add 3rd site to relay traffic or punch holes in NAT.
4) You're afraid of terminals and/or text editors.
Here is a good write-up on the subject: https://www.procustodibus.com/blog/2021/11/wireguard-nftable...
You need tailscale when:
1) You have a lot of road-warriors
2) You need decent ACLs that isn't just IP based.
3a) You don't ability to directly connect to a site (just one needs to be accessible)
3b) You can't add 3rd site to relay traffic or punch holes in NAT.
4) You're afraid of terminals and/or text editors.
Here is a good write-up on the subject: https://www.procustodibus.com/blog/2021/11/wireguard-nftable...
Starlink's IPv4 is behind CGNAT, and their IPv6 prefixes are not stable.
The good news is that it's relatively easy to punch through the NAT. This blog post describes an approach that is working well for me: https://www.jordanwhited.com/posts/wireguard-endpoint-discov...
The good news is that it's relatively easy to punch through the NAT. This blog post describes an approach that is working well for me: https://www.jordanwhited.com/posts/wireguard-endpoint-discov...
I'll take a look at this, thanks for the link!
The beauty of Starlink is while they use a cgnat for ipv4 they assign you fully routable ipv6 addresses. So Tailscale has no problem making that bridge, it just uses ipv6.
If I had to guess, it's probably the NAT hole-punching or use of tailscale servers as an intermediary.
If you signed up for a $5 VPS to forward packets you probably would have been fine.
If you signed up for a $5 VPS to forward packets you probably would have been fine.
Tailscale is free for 3 users and up to 100 devices, so it's a fine solution vs running your own VM for hole punching. Consider your time value. You can even pay for Mullvad exit node access for devices in your net and configure the coordination layer accordingly.
Free was the price, client didn't want to pony up for any additional monthly fees. In the past I would've included it into my monthly "on call fee" but now I value my free time too much to the point where clients aren't interested in having me as an emergency line.
I'm sure I'm leaving money on the table, but I'm a one man show, and I have trust issues with relying on others, so here we are.
I'm sure I'm leaving money on the table, but I'm a one man show, and I have trust issues with relying on others, so here we are.
Who takes care of the VPS then? You're paying for something somewhere if you're not donating your time for free to the client.
> Tailscale is needed if you require site to site connectivity via something like Starlink.
You should be able setup a Wireguard instance on some cloud provider like AWS, then setup each Starlink endpoint to point to that public cloud IP. I have done this for some time on a cheap $5/mo Digital Ocean droplet to work around my old ISP giving me a RFC to 1918 addresses.
Also don’t forget that if you have a line of sight between the two farms you can use the unlicensed 60Ghz spectrum and grab some cheap Ubiquiti millimeter wave gear.
You should be able setup a Wireguard instance on some cloud provider like AWS, then setup each Starlink endpoint to point to that public cloud IP. I have done this for some time on a cheap $5/mo Digital Ocean droplet to work around my old ISP giving me a RFC to 1918 addresses.
Also don’t forget that if you have a line of sight between the two farms you can use the unlicensed 60Ghz spectrum and grab some cheap Ubiquiti millimeter wave gear.
1:1 Nat is a great solution... except in cases where IP Addresses of peers are transmitted as part of the protocol, like in Gossip structures or (Not that anyone should be using this!) FTP. Most games do this, though explicitly to get around NAT so they understand which packets are coming from where.
Honestly, in none of my use-cases will it matter - I can't see myself running a gossip protocol across servers that I do and don't control.
Honestly, in none of my use-cases will it matter - I can't see myself running a gossip protocol across servers that I do and don't control.
> Most games do this, though
This can be fixed by manually setting the IP in the Tailscale console though, so for this particular usecase I think it's okay, too.
This can be fixed by manually setting the IP in the Tailscale console though, so for this particular usecase I think it's okay, too.
Thank you to everyone at TS involved in this feature!!
It will solve a big pain point for us re reserved CGNAT ranges that were causing conflicts.
Cheers
I'm glad they released this feature. There are databases/services which require you to input the IP address to listen on instead of the network interface. This will greatly simplify configuring those services.
I just set up Tailscale for work last week. I've been really impressed with it.
What does it give you that Wireguard doesn't (or OpenVPN)? Just easier to configure + setup + a nice UI? Just making sure I'm not missing something, not trying to knock Tailscale.
Do the "minimalist" people have good reason to prefer "anything-else" other than "heavy feature-rich Tailscale"?
Do the "minimalist" people have good reason to prefer "anything-else" other than "heavy feature-rich Tailscale"?
Yeah, I think "Just" is doing a lot of heavy lifting in that question :)
I've never configured Wireguard from scratch but I have managed an OpenVPN deployment in the past. One of the most fabulous aspects of Tailscale is that it's very self-served; we configured our Tailscale account to allow email addresses from our main domain name with O365 integration. When someone wants to bring a new node online, they log in with their O365 credentials and magically new keys are assigned to the node and associated with the user who created them. In the past with the OpenVPN deployment, it would usually take me 15-30 minutes to get a new node online (generating keys, getting them handed off to the user, helping them debug, etc); now it takes me 0 minutes because the user can just generate their own keys and I can be completely hands off, while still having a nice view that I can use to revoke keys if needed.
I've never configured Wireguard from scratch but I have managed an OpenVPN deployment in the past. One of the most fabulous aspects of Tailscale is that it's very self-served; we configured our Tailscale account to allow email addresses from our main domain name with O365 integration. When someone wants to bring a new node online, they log in with their O365 credentials and magically new keys are assigned to the node and associated with the user who created them. In the past with the OpenVPN deployment, it would usually take me 15-30 minutes to get a new node online (generating keys, getting them handed off to the user, helping them debug, etc); now it takes me 0 minutes because the user can just generate their own keys and I can be completely hands off, while still having a nice view that I can use to revoke keys if needed.
To be fair, Wireguard is incredibly easier to setup and maintain than OpenVPN, pretty much not comparable. I don't know how easy it is with Tailscale though so I can't comment as to how much harder Wireguard is compared to it.
I haven't tried setting up Wireguard manually but just had a scroll through this page: https://www.wireguard.com/quickstart/
In comparison here's the Tailscale setup instructions: https://tailscale.com/download/linux. If you're into running shell scripts that you pull with curl, you can set up Tailscale on a new node with:
I will probably try playing with naked Wireguard at some point for my own home network (since the Tailscale client doesn't seem to handle two orgs at the same time very well).
In comparison here's the Tailscale setup instructions: https://tailscale.com/download/linux. If you're into running shell scripts that you pull with curl, you can set up Tailscale on a new node with:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
I will probably try playing with naked Wireguard at some point for my own home network (since the Tailscale client doesn't seem to handle two orgs at the same time very well).
Certainly, don't use OpenVPN in 2023 if you can avoid it. WireGuard is much faster and more secure, and significantly easier to set up.
If you're a home user, the advantage to Tailscale is that it's going to "just work", with a couple clicks, on any supported device (of which there are lots). There's no configuration to get started and, for a lot of users, no configuration ever after that. The onboarding experience is spooky; it's upsettingly good.
If you're a corporate user, the advantages are drastically greater: you get SSO integration (this is historically one of the annoying pain points of corporate access VPNs, to the point where a significant fraction of pre-Tailscale netsec teams just punted on this problem and hand-provisioned VPN creds for people, which is a nightmare) and trivially simple group-based access control.
If you're a home user, the advantage to Tailscale is that it's going to "just work", with a couple clicks, on any supported device (of which there are lots). There's no configuration to get started and, for a lot of users, no configuration ever after that. The onboarding experience is spooky; it's upsettingly good.
If you're a corporate user, the advantages are drastically greater: you get SSO integration (this is historically one of the annoying pain points of corporate access VPNs, to the point where a significant fraction of pre-Tailscale netsec teams just punted on this problem and hand-provisioned VPN creds for people, which is a nightmare) and trivially simple group-based access control.
The combination of 'it just works' and 'SSO integration' is a killer.
To be honest, in 20+ years of working in IT, I never understood the point of the latter until recently, on a gig salvaging systems for a client with ~650 users after their sole IT guy unexpectedly resigned after 20 years and left for the mountains.
IRL, SSO is gold. Many hackers, like me, underestimate it.
To be honest, in 20+ years of working in IT, I never understood the point of the latter until recently, on a gig salvaging systems for a client with ~650 users after their sole IT guy unexpectedly resigned after 20 years and left for the mountains.
IRL, SSO is gold. Many hackers, like me, underestimate it.
And not just SSO, but OIDC. You don't even have to be an admin on your domain to set it up. If you have a Gmail or Office 365 e-mail address @mycorp.com, you can set up SSO for it on your tailnet in seconds. Your team members authenticating for the same domain will join your tailnet automatically.
And that's for the free and cheap tier. If you want the fancy stuff (like SAML and automatic user provisioning / filtering), they've apparently got that, too, but it's in the more expensive tiers.
And that's for the free and cheap tier. If you want the fancy stuff (like SAML and automatic user provisioning / filtering), they've apparently got that, too, but it's in the more expensive tiers.
SSO is basically tablestakes for compliance: customers would ask about your access control (or just if you have _that_ audit report, which has a lot of questions about it).
And trying to do access control without SSO is crazy: you need to keep track of application and users and their interactions. I wouldn't run any team with more than 10 people without it.
And trying to do access control without SSO is crazy: you need to keep track of application and users and their interactions. I wouldn't run any team with more than 10 people without it.
Worth pointing out that "just use Wireguard" is way different than "just use Tailscale". The latter has solutions for common problems, the former is not even remotely comparable feature-wise to OpenVPN. If the only choice is between OpenVPN or Wireguard, often OpenVPN is the only acceptable option, because it has all the features you need.
And if you are working for the military or a bigco you should use StrongSwan.
>What does it give you that Wireguard doesn't (or OpenVPN)? Just easier to configure + setup + a nice UI? Just making sure I'm not missing something, not trying to knock Tailscale.
I personally haven't deployed it though I've toyed with it, but I think as well as UI and integrations a core topology differentiator is that, like Nebula, Tailscale does/can do meshing. Plain vanilla Wireguard is pure classic hub-and-spoke, which is 100% fine for a basic VPN use case like "I'm out somewhere on the WAN and want to talk to this LAN stuff" or "I want to tunnel some/all my traffic through some specific alternate exit".
But say you've got main site A which has a public static IP and is where support is for administrating others, site B which has a full backup server but no public IP, and then sites C/D/E/etc where people are doing work and having significant on-site storage and comms needs, all of which are behind typical ISP NAT from multiple different ISPs with no static IPs. Everyone wants to be able to do high bandwidth things like video chat directly together, or back up/restore to site B. Plain WG could do that, but would funnel it all through site A's link which isn't very scalable and likely to become a choke point in a hurry. A meshing VPN can let two private sites talk directly with a public address only serving to facilitate hole punching and setting up the connection each time. It's definitely of real value. Another thing would be not bandwidth but latency. If you're within a few hundred miles on land that probably is irrelevant. But if different sites/people are across continents adding an unnecessary extra hop may become a very big deal even for simple web apps. Resiliency also enters the equation, what if site A goes down? A mesh can help with those too.
Then Tailscale adds a lot of cool QoL on top. Meshing does raise new challenges in terms of access control vs when everything is funneled through a single convenient point. But regardless, other topologies can be of basic interest too even without extra sugar.
I personally haven't deployed it though I've toyed with it, but I think as well as UI and integrations a core topology differentiator is that, like Nebula, Tailscale does/can do meshing. Plain vanilla Wireguard is pure classic hub-and-spoke, which is 100% fine for a basic VPN use case like "I'm out somewhere on the WAN and want to talk to this LAN stuff" or "I want to tunnel some/all my traffic through some specific alternate exit".
But say you've got main site A which has a public static IP and is where support is for administrating others, site B which has a full backup server but no public IP, and then sites C/D/E/etc where people are doing work and having significant on-site storage and comms needs, all of which are behind typical ISP NAT from multiple different ISPs with no static IPs. Everyone wants to be able to do high bandwidth things like video chat directly together, or back up/restore to site B. Plain WG could do that, but would funnel it all through site A's link which isn't very scalable and likely to become a choke point in a hurry. A meshing VPN can let two private sites talk directly with a public address only serving to facilitate hole punching and setting up the connection each time. It's definitely of real value. Another thing would be not bandwidth but latency. If you're within a few hundred miles on land that probably is irrelevant. But if different sites/people are across continents adding an unnecessary extra hop may become a very big deal even for simple web apps. Resiliency also enters the equation, what if site A goes down? A mesh can help with those too.
Then Tailscale adds a lot of cool QoL on top. Meshing does raise new challenges in terms of access control vs when everything is funneled through a single convenient point. But regardless, other topologies can be of basic interest too even without extra sugar.
> Wireguard is pure classic hub-and-spoke
No it's not. You can do any to any just fine (and any topology in between these extremes).
No it's not. You can do any to any just fine (and any topology in between these extremes).
Nice job skipping the explicit qualifier of "plain vanilla"? Being able to build your own version on top isn't the same as an existing tested product.
Not sure what you mean by "on top". All you need is to configure not just a single endpoint in each node's wireguard config, but all of them. That's still as vanilla and as "tested product" as it gets. It's just a regular wireguard configuration.
You can do any to any just fine [open NAT ports, run your own distributed fallback network of TURN/STUN relays, add the adequate routing entries to your routing tables on both sides, exchange certificates, all of this for every extra N connections], you just probably don't want to do (and then fix if it doesn't work or stops working) that if N is too big.
Yes. I may also run it on top of IPv6 and not care about all that, except for public key distribution.
IPv6 when it works is awesome.
However, outside some well-connected datacenters with multiple peering exchanges, I have no clue where in the world you can run everything in IPv6 with even a single nine in availability.
On my home I would say assuming single nine availability of IPv6 traffic is too much availability - it's very common that IPv6 is borked for several months in a row.
However, outside some well-connected datacenters with multiple peering exchanges, I have no clue where in the world you can run everything in IPv6 with even a single nine in availability.
On my home I would say assuming single nine availability of IPv6 traffic is too much availability - it's very common that IPv6 is borked for several months in a row.
It does OIDC integration out-of-the-box and for their free and cheap tiers. OIDC is like the "login with Google" stuff that doesn't require any setup. So I was able to have SSO setup immediately with our Office 365 domain without bothering to setup SAML or anything.
The VPN clients for Mac and iOS are on the App Store, which may not mean much, but having developed VPN apps for both, what it means is: it is far less likely break or muck with your OS's networking in practice because it's sandboxed and can only use Apple's SDK for interfacing with the OS. This is compared to every OpenVPN client I've used on various platforms, which must run as root and often is setting up and tearing things down with shell scripts that can get hairy as you add more complexity / moving parts.
(Note that this is also true for Wireguard's client, just not OpenVPN)
The first three users are always free, so we're able to demo it easily. It's also listed on AWS marketplace, so as we move to start buying some licenses, it's billed through our AWS bill (i.e. I don't need an act of Congress to get a credit card number entered and a new monthly invoice reconciled within my company).
You can configure how often it forces reauthentication, which is probably the biggest benefit over vanilla Wireguard. Wireguard doesn't have mechanisms for expiring and replacing keys, so it solves that.
There's also an open source implementation of the master service (called headscale) that you can run on your own, and I was able to fairly easily set it up and get the existing Tailscale apps from the App Store to be reconfigured to utilize.
Honestly it's the cleanest VPN experience I've had if you need to deal with any kind of SSO and/or dynamic user/client provisioning. If you're just setting up point-to-point between a few of your own servers and clients that won't change, maybe just stick to Wireguard. But once you start needing anything more than that--I'd give Tailscale a shot first.
The VPN clients for Mac and iOS are on the App Store, which may not mean much, but having developed VPN apps for both, what it means is: it is far less likely break or muck with your OS's networking in practice because it's sandboxed and can only use Apple's SDK for interfacing with the OS. This is compared to every OpenVPN client I've used on various platforms, which must run as root and often is setting up and tearing things down with shell scripts that can get hairy as you add more complexity / moving parts.
(Note that this is also true for Wireguard's client, just not OpenVPN)
The first three users are always free, so we're able to demo it easily. It's also listed on AWS marketplace, so as we move to start buying some licenses, it's billed through our AWS bill (i.e. I don't need an act of Congress to get a credit card number entered and a new monthly invoice reconciled within my company).
You can configure how often it forces reauthentication, which is probably the biggest benefit over vanilla Wireguard. Wireguard doesn't have mechanisms for expiring and replacing keys, so it solves that.
There's also an open source implementation of the master service (called headscale) that you can run on your own, and I was able to fairly easily set it up and get the existing Tailscale apps from the App Store to be reconfigured to utilize.
Honestly it's the cleanest VPN experience I've had if you need to deal with any kind of SSO and/or dynamic user/client provisioning. If you're just setting up point-to-point between a few of your own servers and clients that won't change, maybe just stick to Wireguard. But once you start needing anything more than that--I'd give Tailscale a shot first.
We also just adopted Tailscale for our org and I can answer that one:
SSO for Auth: before we had to go through the key exchange process for every employee and then manually update the Gateways wg conf. Now it’s just: login here with your work account and you’re done.
Authorization config: I like the ACL abstractions on top of Wireguard. It’s a part is completely missing and building it yourself would be a nightmare. I also don’t want to manage iptables for every device.
All of the nice little feature that they provide:
Funnel Kubernetes operator Magic DNS
SSO for Auth: before we had to go through the key exchange process for every employee and then manually update the Gateways wg conf. Now it’s just: login here with your work account and you’re done.
Authorization config: I like the ACL abstractions on top of Wireguard. It’s a part is completely missing and building it yourself would be a nightmare. I also don’t want to manage iptables for every device.
All of the nice little feature that they provide:
Funnel Kubernetes operator Magic DNS
> What does it give you that Wireguard doesn't
Less battery life on your iPhone. :)
I have both in my home network and love both.
At work, I have used Tailscale in my Kubernetes clusters to allow devs to get into the private subnets, so that is awesome, and way better than trying to give a group wireguard key pairs.
Less battery life on your iPhone. :)
I have both in my home network and love both.
At work, I have used Tailscale in my Kubernetes clusters to allow devs to get into the private subnets, so that is awesome, and way better than trying to give a group wireguard key pairs.
Yes, the battery drain on iOS is also the thing stopping me from having it on my iPhone. Wireguard is way better in that regard, but has other issues (e.g. no split dns, no dns re-resolve for dyndns or for network changes).
Other than that tailscale is really great. It just works.
Other than that tailscale is really great. It just works.
Yep, I have my Wireguard client connect when I am off my network and I split DNS so I can continue to use my ad blocker when off my network and on the macro network. For that it is perfect.
You can set it up on most of your devices, including mobile, with a couple clicks/taps, and not having to read any manpages. You can achieve having e.g. an Apple TV as a VPN network gateway with similar ease.
A technical person who’s familiar with what a VPN is and does but has never configured one can have it working on a bunch of their devices in like 30 minutes flat, with no notable ongoing maintenance to worry about.
If you’re already configuring your home networking with Ansible or Helm or something, it’s probably not a win.
A technical person who’s familiar with what a VPN is and does but has never configured one can have it working on a bunch of their devices in like 30 minutes flat, with no notable ongoing maintenance to worry about.
If you’re already configuring your home networking with Ansible or Helm or something, it’s probably not a win.
https://tailscale.com/compare/wireguard/
Here is what I will say. I manually setup wireguard for my home network, it was annoying but doable. Then when tailscale started to get interesting I just decided try it out using a free account and rolled back my wireguard configuration... and never went back. It's so much less fiddly.
Here is what I will say. I manually setup wireguard for my home network, it was annoying but doable. Then when tailscale started to get interesting I just decided try it out using a free account and rolled back my wireguard configuration... and never went back. It's so much less fiddly.
Tailscale is basically automation and authentication/authorization and UI on top of Wireguard. You could do it all manually, but you'll need to know the details of how to configure raw wireguard exactly how you need it, which for many people is above their heads. There are a lot of things that tailscale automates, so you have to know a great deal in order to configure a wireguard net yourself to the equivalent
My mum could probably install on her phone, and configure an exit on her computer, without knowing what Wireguard or `-j MASQUERADE` means ;)
For me the key additions are: 1) integration with our org Identity Provider 2) NAT traversal + DERP relay fallback 3) Tailscale’s ACL functionality.
The eternal problem with companies like Tailscale (and Cloudflare, Google, etc. etc.) is that, by solving a problem with the modern internet which the internet should have been designed to solve by itself, like simple end-to-end secure connectivity, Tailscale becomes incentivized to keep the problem. What the internet would need is something like IPv6 with automatic encryption via IPSEC, with IKE provided by DNSSEC. But Tailscale has every incentive to prevent such things to be widely and compatibly implemented, because it would destroy their business. Their whole business depends on the problem persisting.
I setup a proxmox on a bare metal server to create development VMs. The solution that works for me is IPv6. Every VM that I create is publicly accessible, it's secured by a firewall and openssh public key only access. It's standards compatible, every smartphone and tablet has access, including chromebooks. Tailscale is not available on chromebooks.
If tailscale looks interesting for your use case, but you'd rather have a standards compliant solution, look into IPv6. From an engineering perspective, it's a much cleaner solution.
You can install Tailscale on a Chromebook[0], you can also install it in the linux environment, and you can even get an SSH console from a browser that uses WASM to spin up an ephemeral node[1].
I used to have open ports publicly, but have since closed everything down and set up tailscale. Got tired of having to manage a firewall, religiously keeping everything up to date, and script kiddies trying to get in.
Tailscale reduces management to near zero, or as close to zero as you can probably get. Even family members can use it, and without my help.
On Android I don't want Tailscale connected all the time, so I have Tasker auto-connect whenever I open an app that needs LAN access. It's pretty convenient, but I'd still say it's the most inconvenient part of my current setup.
[0] https://tailscale.com/kb/1267/install-chromebook/
[1] https://tailscale.com/tailscale-ssh-console/
I used to have open ports publicly, but have since closed everything down and set up tailscale. Got tired of having to manage a firewall, religiously keeping everything up to date, and script kiddies trying to get in.
Tailscale reduces management to near zero, or as close to zero as you can probably get. Even family members can use it, and without my help.
On Android I don't want Tailscale connected all the time, so I have Tasker auto-connect whenever I open an app that needs LAN access. It's pretty convenient, but I'd still say it's the most inconvenient part of my current setup.
[0] https://tailscale.com/kb/1267/install-chromebook/
[1] https://tailscale.com/tailscale-ssh-console/
[deleted]
> It's standards compatible
What standard is Tailscale breaking? I agree your solution is more elegant and simple with less running components, but the trade off is more setup.
What is the advantage of using the CGNAT range instead of 10/8?
That'd probably have a lot of conflicts with people's LANs.
You're much more likely to be already using 10/8 as a part of your setup, whereas 100.64/10 has only really been a thing for residential/mobile ISPs. (I have no idea what happens to Tailscale when your carrier gives you a 100.64/10.)
Typically that CGNAT IP would just sit on the WAN port of your router. So in theory none of your LAN devices would hit that IP anyway (the router would be NATing everything). Your clients having a route to 100.64/10 pointing to the tailscale VPN interface shouldn't have an issue (unless you install Tailscale on your actual router, that would take some special setup).
Ok that’s fun. My home network is 10.3.x.x … can I somehow script to get my tailnet onto 100.103.x.x ?
Now I need to investigate!
Now I need to investigate!
Looks like you can configure that in the tailnet policy, according to the article.
I'm not sure how many have done this as well, but I've deliberately allocated lots and lots of elastic IPs on AWS in order to find one that I liked, for use by a long-living instance.
There’s gotta be an overlap of people who do that and people who pick their phone numbers based on look, right? Which I do. I also recently changed my Tailscale host name (animal-animal.ts.net) and spent enough time cycling through choices to find a short, memorable, and pleasing one that I even started to question how I was spending my time.
Next thing: Vanity 100.xxx.xxx.xxx IP addresses.
How about IPv6 with distributed acl?
Stumbel guis
This blog is blocked by DNS Security solution because of "personal VPN".
NAT... the cause of, and solution to, all of life's problems.