Tailscale Funnel(tailscale.com)
tailscale.com
Tailscale Funnel
https://tailscale.com/blog/introducing-tailscale-funnel/
247 comments
And even if everything is secure right now, you cannot guarantee this stays the case in the future. By using the "tailscale ecosystem" you are locking yourself into a provider that can change the ecosystem (clients, services, servers) or put things behind a paywalls anytime. Or create add-ons that are useful and no longer privacy-preserving. The fact that they are a VC-funded business makes me believe this is how the company will end up: Customer data will be monetized in one way or another. How else are going to create returns for shareholders that justify their valuation? Certainly not by open sourcing stuff and not looking at your data. We've seen these VC incentives play out again and again in other companies.
Just use wireguard. It really isn't that hard.
Just use wireguard. It really isn't that hard.
Not really true, tailscale clients do allow you to point to different control servers and open source implementations do exist[1] and are thriving. The clients are also open source and you can even create one yourself if you are willing to.
The thing is, what makes tailscale works really well as a "central" control server is that it makes a lot easier to connect your personal machines. You don't need to deploy your own server, or mess with networking stuff. You just download it, log-in and there you go. I myself have invited some non-tech friends to my network for playing lan games from time time and they find pretty easy to setup tailscale on their side.
[1]: https://github.com/juanfont/headscale
The thing is, what makes tailscale works really well as a "central" control server is that it makes a lot easier to connect your personal machines. You don't need to deploy your own server, or mess with networking stuff. You just download it, log-in and there you go. I myself have invited some non-tech friends to my network for playing lan games from time time and they find pretty easy to setup tailscale on their side.
[1]: https://github.com/juanfont/headscale
Yeah, but having that is clearly not aligned with making money. They could make it more difficult or impossible to use headscale at any moment.
Once a FOSS ecosystem exists, it can always be maintained as such.
What may theoretically happen is that the same client won't be able to join both an open-source controller and a controller from Tailscale-turned-evil.
I suppose that corporations, especially those without huge IT departments, will and do happily pay Tailscale the reasonable money, and have their secure VPN just working. For them, it's no different than paying for Zoom or Office365, only cheaper. They totally do not want to depend on in-house networking expertise.
So I think Tailscale will be doing well financially,
What may theoretically happen is that the same client won't be able to join both an open-source controller and a controller from Tailscale-turned-evil.
I suppose that corporations, especially those without huge IT departments, will and do happily pay Tailscale the reasonable money, and have their secure VPN just working. For them, it's no different than paying for Zoom or Office365, only cheaper. They totally do not want to depend on in-house networking expertise.
So I think Tailscale will be doing well financially,
They could, but let's cross that bridge when we get to it. You're trying to justify the dislike of a product because of what they might do. That's a pretty weak argument.
> Just use wireguard. It really isn't that hard.
For us. For the folks who browse HN all day, yeah. But have you tried getting a non-technologist to use it? I set a friend up with Tailscale between her Synology and laptop and it was a breeze - something I could do over the phone. For me getting Wireguard set up wasn't tricky, but I definitely leaned on Google some, and I would argue I know what I'm doing.
I would love for a company to release bridge as open source that I could deploy on a VM somewhere but still have it be Tailscale easy for normal folks, but there's no money in that model.
For us. For the folks who browse HN all day, yeah. But have you tried getting a non-technologist to use it? I set a friend up with Tailscale between her Synology and laptop and it was a breeze - something I could do over the phone. For me getting Wireguard set up wasn't tricky, but I definitely leaned on Google some, and I would argue I know what I'm doing.
I would love for a company to release bridge as open source that I could deploy on a VM somewhere but still have it be Tailscale easy for normal folks, but there's no money in that model.
I fail to see how that is any different to other modern network control solutions out there? Every major network vendor is moving towards a cloud control service of some kind.
Further, Honestly at this point I would trust TailScale over say OpenVPN, or Cisco, or .....
Further, Honestly at this point I would trust TailScale over say OpenVPN, or Cisco, or .....
Having evaluated them --
Road 1: Sale to usual suspects like Palo Alto (though that window is closing due to raising $100M) or Cisco (that window may close if they raise again?). It is basically modern vpn, though will be years with a big enterprise culture reset & a consumer tier for that to become true. They will run out of acquirers soon who would have the incentive to overpay, eg, if they raise more and narrows down to say oracle, ms, apple, and google, not sure why any would buy vs build. Hopefully they will not dip much into the funds so they can cleanly exit without forcing an acquirer to screw over their users. (See: Evernote)
Road 2: IPO and become a platform for bigger stuff... Like end-user-friendly VPN. Who knows, but good luck! Flipping to 'real' enterprise sales and figuring out the consumer tiers are big culture shifts, but luckily... Hireable.
Meanwhile, growing just with more niche/skilled Linux power user teams gets them far -- the compliance checkbox is huge for growth, see Drata and Vanta -- so am not worried :)
Agreed with the OSS concern so we decided against putting them in the critical path of our enterprise offering (a shame!), but as an internal tool, it looks great!
Road 1: Sale to usual suspects like Palo Alto (though that window is closing due to raising $100M) or Cisco (that window may close if they raise again?). It is basically modern vpn, though will be years with a big enterprise culture reset & a consumer tier for that to become true. They will run out of acquirers soon who would have the incentive to overpay, eg, if they raise more and narrows down to say oracle, ms, apple, and google, not sure why any would buy vs build. Hopefully they will not dip much into the funds so they can cleanly exit without forcing an acquirer to screw over their users. (See: Evernote)
Road 2: IPO and become a platform for bigger stuff... Like end-user-friendly VPN. Who knows, but good luck! Flipping to 'real' enterprise sales and figuring out the consumer tiers are big culture shifts, but luckily... Hireable.
Meanwhile, growing just with more niche/skilled Linux power user teams gets them far -- the compliance checkbox is huge for growth, see Drata and Vanta -- so am not worried :)
Agreed with the OSS concern so we decided against putting them in the critical path of our enterprise offering (a shame!), but as an internal tool, it looks great!
> Just use wireguard. It really isn't that hard.
In many situations it's not just hard, it's outright impossible.
For example, how would you connect two Raspberry Pis between two CG-NATted internet connections using Wireguard, without resorting to setting up a publicly reachable VPN server?
If you have a public and at least semi-stable IPv4 address and control your firewall/NAT, great. But unfortunately less and less people do, these days.
In many situations it's not just hard, it's outright impossible.
For example, how would you connect two Raspberry Pis between two CG-NATted internet connections using Wireguard, without resorting to setting up a publicly reachable VPN server?
If you have a public and at least semi-stable IPv4 address and control your firewall/NAT, great. But unfortunately less and less people do, these days.
Tailscale actually has a great write-up on the subject [0]
TLDR; Ideally, IPv6. Otherwise, NAT traversal techniques such as STUN, or hole-punching.
[0]: https://tailscale.com/blog/how-nat-traversal-works/
TLDR; Ideally, IPv6. Otherwise, NAT traversal techniques such as STUN, or hole-punching.
[0]: https://tailscale.com/blog/how-nat-traversal-works/
> Ideally, IPv6.
Yes, if you have it everywhere you want to host services and everywhere you want to access these services, that's great. Realistically, I think it's going to be decades until an IPv6-only service is feasible.
> Otherwise, NAT traversal techniques such as STUN, or hole-punching.
Neither of which Wireguard supports out of the box. To be clear, it absolutely shouldn't – it's a different concern, and the appeal of Wireguard is specifically that it isn't trying to do everything and the kitchen sink.
So, is there an easy-to-use NAT traversal orchestration service for Wireguard out there that isn't Tailscale?
Yes, if you have it everywhere you want to host services and everywhere you want to access these services, that's great. Realistically, I think it's going to be decades until an IPv6-only service is feasible.
> Otherwise, NAT traversal techniques such as STUN, or hole-punching.
Neither of which Wireguard supports out of the box. To be clear, it absolutely shouldn't – it's a different concern, and the appeal of Wireguard is specifically that it isn't trying to do everything and the kitchen sink.
So, is there an easy-to-use NAT traversal orchestration service for Wireguard out there that isn't Tailscale?
Yes, see for instance:
https://github.com/malcolmseyd/natpunch-go
https://github.com/malcolmseyd/natpunch-go
"Inspired by Tailscale"
So, before Tailscale there wasn't a solution. Now we have one, but it's yet another tool we have to manually manage.
So, before Tailscale there wasn't a solution. Now we have one, but it's yet another tool we have to manually manage.
Use IPv6?
Not an option, as long as I regularly need to access my devices from IPv4-only networks.
Have you tried using IPv6 on a hotel wi-fi, in-flight, or a corporate guest network?
Have you tried using IPv6 on a hotel wi-fi, in-flight, or a corporate guest network?
>Just use wireguard. It really isn't that hard.
I love WG and use it extensively, but the attraction of Tailscale (and why I use it) is that it takes disparate concepts and gives you a nice visual control panel to manage them and see the status of all your devices in one place.
Nothing. Absolutely nothing exists for Wireguard that does even some of that, which doesn't also cost money.
I don't think Wireguard is even capable of the 'DERP' server concept to get around NAT limitations.
So no, you can't 'just use Wireguard' to accomplish what Tailscale does.
I love WG and use it extensively, but the attraction of Tailscale (and why I use it) is that it takes disparate concepts and gives you a nice visual control panel to manage them and see the status of all your devices in one place.
Nothing. Absolutely nothing exists for Wireguard that does even some of that, which doesn't also cost money.
I don't think Wireguard is even capable of the 'DERP' server concept to get around NAT limitations.
So no, you can't 'just use Wireguard' to accomplish what Tailscale does.
Spoken like somebody who has never had a "Can you help me get my microsoft wifi [Spectrum cable internet] to make sure my gmail [[email protected]] doesn't send my retirement [tax refund] to the hackers" type call.
>And even if everything is secure right now, you cannot guarantee this stays the case in the future. By using the "tailscale ecosystem" you are locking yourself into a provider that can change the ecosystem (clients, services, servers) or put things behind a paywalls anytime.
I can't (and refuse) to live my lie by "what ifs." If they do any of those things, it's easy enough to pivot to the 3 or 4 other providers our there, like ZeroTier, who offer the same thing.
My hope is if they do, the FOSS community will have gotten their act together and built a capable replacement, which is usually the case.
I can't (and refuse) to live my lie by "what ifs." If they do any of those things, it's easy enough to pivot to the 3 or 4 other providers our there, like ZeroTier, who offer the same thing.
My hope is if they do, the FOSS community will have gotten their act together and built a capable replacement, which is usually the case.
At this point you could stir up hysteria over anything. Your cloud provider, ISP, operating system support team, XYZ SaaS provider could also just invent a new billing policy to screw the customer over.
At the same time, ^ the big providers have profitable revenue streams, so they don't have much incentive to change their billing. VC startups of course on growing instead of verifying that their business model actually works, and end up either:
- locking the software behind a paywall
- locking the software behind a paywall
- inventing a proprietary + open-source + pay us royalties license
- pretending that their software is free whilst employing a proprietary + pay us royalties for anything bigger than a hobby project license
- going bust
- locking the software behind a paywall
- locking the software behind a paywall
- inventing a proprietary + open-source + pay us royalties license
- pretending that their software is free whilst employing a proprietary + pay us royalties for anything bigger than a hobby project license
- going bust
I remember reading that Tailscale is "helping out" [1] development of Headscale [2], an open-source re-implementation of their command server so that the two remain compatible as new features are added to the official one.
[1]: https://tailscale.com/opensource/
[2]: https://github.com/juanfont/headscale
[1]: https://tailscale.com/opensource/
[2]: https://github.com/juanfont/headscale
Leaving aside adoption, there is a degree to which HN is impressed that Tailscale has taken a set of technical problems that have caused many of us pain over the years and that drive some less than ideal setups and just made them go away. They are magically taken care of behind an easy to use setup that Just Works. There's basically none of the "you have to tweak this setting under this circumstance" needed to get it working. That is difficult engineering requiring people who understand the problem domain and have a clear picture of the right architecture, as well as good product engineering.
Isn't TailScale "just" WireGuard?
Yes. It is just Wireguard… with a bit of magic on top.
As far as I can tell, the Tailscale magic is maintaining and distributing a wg.conf that is setup for a dynamic mesh Wireguard network. To do this (and in particular the NAT traversal aspect), they use their own software to setup and figure out NAT ports.
One you have Wireguard figured out, it’s pretty easy to setup a hub and spoke model VPN, especially if you have a static server somewhere. Setting up a dynamic mesh VPN is another thing entirely and doing it without requiring a server from Tailscale to be part of the network is, like I said, a bit of magic. It’s a straightforward setup that they explain quite well on their site. But to actually make it work is quite impressive to me.
As far as I can tell, the Tailscale magic is maintaining and distributing a wg.conf that is setup for a dynamic mesh Wireguard network. To do this (and in particular the NAT traversal aspect), they use their own software to setup and figure out NAT ports.
One you have Wireguard figured out, it’s pretty easy to setup a hub and spoke model VPN, especially if you have a static server somewhere. Setting up a dynamic mesh VPN is another thing entirely and doing it without requiring a server from Tailscale to be part of the network is, like I said, a bit of magic. It’s a straightforward setup that they explain quite well on their site. But to actually make it work is quite impressive to me.
> without requiring a server from Tailscale
AFAICT, Tailscale does not route your traffic through its servers (because it would be costly, among other things), but it does control your VPN nodes to distribute all the configuration fairy dust. So a server from Tailscale is still needed (and billed for).
AFAICT, Tailscale does not route your traffic through its servers (because it would be costly, among other things), but it does control your VPN nodes to distribute all the configuration fairy dust. So a server from Tailscale is still needed (and billed for).
Right, the command and control server -- but that server does not need to be part of your private Tailscale/WG network. The Tailscale server is only required for coordinating the WG configuration. My point was that this was all done without the Tailscale server needing to actually participate in your private network. That is to say, the Tailscale server can't monitor your traffic or private servers.
Except of course in the case of Funnel... which is the original subject here. In this case, the Tailscale ingress server is added to your private network/nodelist. This it so that it can communicate with whatever private service you are running and then proxy that back out to the public Internet.
Except of course in the case of Funnel... which is the original subject here. In this case, the Tailscale ingress server is added to your private network/nodelist. This it so that it can communicate with whatever private service you are running and then proxy that back out to the public Internet.
I think tailscale may be the only company that is build on WireGuard but also commits code to wireguard repo itself.
That says a lot, to me at least, but parent's comment on giving the keys to the kingdom to a third party still holds (as it does for many other SaaS/cloud/hosted platforms of course).
That says a lot, to me at least, but parent's comment on giving the keys to the kingdom to a third party still holds (as it does for many other SaaS/cloud/hosted platforms of course).
No. For example: https://tailscale.com/blog/how-nat-traversal-works/
Nope. It's Wireguard 'underneath' but a whole lot more over the top.
Try this: Go set up a Wireguard connection from your PC at home to one at work.
Then do the same thing with tailscale.
One will be a lot easier than the other. And that's only 2 computers...
Try this: Go set up a Wireguard connection from your PC at home to one at work.
Then do the same thing with tailscale.
One will be a lot easier than the other. And that's only 2 computers...
Um. I already have like 100s of WG connection. Office to cloud, various servers all over connected to others, servers on many WG "subnets".
WG is the easiest VPN I've ever used. Dropped all these other crazy rigs (stunnel, ssh-tunnel, etc) cause WG always "just works" and is on every platform.
However, I've spent loads of time as network admin, planning IP-space for VPN layers, first time in 1997.
WG is the easiest VPN I've ever used. Dropped all these other crazy rigs (stunnel, ssh-tunnel, etc) cause WG always "just works" and is on every platform.
However, I've spent loads of time as network admin, planning IP-space for VPN layers, first time in 1997.
[deleted]
I agree it's not ideal, but I can tell you why I'm excited about things like[0] Tailscale, Cloudflare Tunnel, ngrok, etc.
They enable you to move your selfhosted services from expensive, slow VPSes you don't control to fast devices in your own home[4]. IMO this is strictly better than a VPS in terms of privacy and data control. It's a step in the right direction, back towards the initial intent of the internet, but also forward with the lessons we've learned in the real world.
The reality today is that selfhosting is way too hard[1]. It shouldn't be any more complicated or less secure than running an app on your phone.
I think services like Tailscale are going to enable the first generation of selfhosting that approaches that level of simplicity. Once the market is proven, the second generation is going be designed for selfhosters and have features like end-to-end encryption, domain name integration, and simple GUI interfaces.
The other key pieces are strong sandboxing, which is now possible on all major desktop OSes through virtualization (mobile is coming[2]), and dead-simple cloud backups.
The technology for all these things exists, it just hasn't been integrated yet.
[0]: https://github.com/anderspitman/awesome-tunneling
[1]: https://moxie.org/2022/01/07/web3-first-impressions.html
[2]: https://twitter.com/kdrag0n/status/1584017653269958656?lang=...
[4]: I concede that the network upload connection is likely much slower, but expect that to improve over time.
They enable you to move your selfhosted services from expensive, slow VPSes you don't control to fast devices in your own home[4]. IMO this is strictly better than a VPS in terms of privacy and data control. It's a step in the right direction, back towards the initial intent of the internet, but also forward with the lessons we've learned in the real world.
The reality today is that selfhosting is way too hard[1]. It shouldn't be any more complicated or less secure than running an app on your phone.
I think services like Tailscale are going to enable the first generation of selfhosting that approaches that level of simplicity. Once the market is proven, the second generation is going be designed for selfhosters and have features like end-to-end encryption, domain name integration, and simple GUI interfaces.
The other key pieces are strong sandboxing, which is now possible on all major desktop OSes through virtualization (mobile is coming[2]), and dead-simple cloud backups.
The technology for all these things exists, it just hasn't been integrated yet.
[0]: https://github.com/anderspitman/awesome-tunneling
[1]: https://moxie.org/2022/01/07/web3-first-impressions.html
[2]: https://twitter.com/kdrag0n/status/1584017653269958656?lang=...
[4]: I concede that the network upload connection is likely much slower, but expect that to improve over time.
> They enable you to move your selfhosted services from expensive, slow VPSes you don't control to fast devices in your own home[4]. IMO this is strictly better than a VPS in terms of privacy and data control.
How is trusting your network entry point to Cloudflare (or whoever) any better than having it at a VPS? At least with the VPS you know what's happening inside the box.
Here's a better solution: Get a free/cheap VPS. Setup a Wireguard tunnel from your home server to it. Slap a reverse proxy on the VPS that forwards internet traffic through the tunnel to your home server.
How is trusting your network entry point to Cloudflare (or whoever) any better than having it at a VPS? At least with the VPS you know what's happening inside the box.
Here's a better solution: Get a free/cheap VPS. Setup a Wireguard tunnel from your home server to it. Slap a reverse proxy on the VPS that forwards internet traffic through the tunnel to your home server.
> How is trusting your network entry point to Cloudflare (or whoever) any better than having it at a VPS?
I was referring to the other advantages, not the privacy. They're about the same on privacy.
> Here's a better solution: Get a free/cheap VPS. Setup a Wireguard tunnel from your home server to it. Slap a reverse proxy on the VPS that forwards internet traffic through the tunnel to your home server.
Way too difficult for the users I'm trying to reach.
I was referring to the other advantages, not the privacy. They're about the same on privacy.
> Here's a better solution: Get a free/cheap VPS. Setup a Wireguard tunnel from your home server to it. Slap a reverse proxy on the VPS that forwards internet traffic through the tunnel to your home server.
Way too difficult for the users I'm trying to reach.
Strong sandboxing, yes. But I'd especially appreciate it if it was wrapped up in an interface like Sandstorm.io.
I want to teach something like Tailscale about my contacts, so they are allowed to communicate with my services (through their services).
Then I want to run an app inside a strong sanbox that has capability-based APIs to do things kind of like ZeroMQ for sending messages TO THE CONTACTS. I don't want the API to look like a tcp/ip or udp connection. I want the app to think it's sending a message to a contact I've given it permission to talk to.
If this was running in a strong sandbox, I think this would be an awesome way to develop and use simple federated apps. If something like Mastodon existed on top of this, I'd think it would be really secure and much easier to tell people to stand up their own node...
I want to teach something like Tailscale about my contacts, so they are allowed to communicate with my services (through their services).
Then I want to run an app inside a strong sanbox that has capability-based APIs to do things kind of like ZeroMQ for sending messages TO THE CONTACTS. I don't want the API to look like a tcp/ip or udp connection. I want the app to think it's sending a message to a contact I've given it permission to talk to.
If this was running in a strong sandbox, I think this would be an awesome way to develop and use simple federated apps. If something like Mastodon existed on top of this, I'd think it would be really secure and much easier to tell people to stand up their own node...
I consider Sandstorm to sort of be the platonic ideal in many ways. But in practice, the fact that the apps have to be modified to run on it holds it back.
Sure, but I feel like that's just part of the trade-offs. And chicken-and-egg, really.
But if I were really bought in to Sandstorm.io, developing new apps for it would make a lot of sense, and I agree with their assessments about accounts and security - that those are better left to the OS.
So I'm just wanting to build federated apps, using that same philosophy.
And if Tailscale Funnel let me safely run in a sandbox on prem...?
That sounds amazing.
Like, this is the kind of thing where I'd buy a headless PC just to host federated apps for my extended friends and family network, if the config were painless enough and the sandbox secure enough, and the self-updating, self-maintaining story of Sandstorm.io worked well enough...
It's like the Chrome OS of federation, in my head. The OS does exactly and only what you need, making it easy for you to add the business logic of your thing.
Like, I wish this was roughly how SAS worked...
I wish to hell more businesses felt secure in letting their employees stand up convenience servers. And I feel like these are steps in the right direction.
But if I were really bought in to Sandstorm.io, developing new apps for it would make a lot of sense, and I agree with their assessments about accounts and security - that those are better left to the OS.
So I'm just wanting to build federated apps, using that same philosophy.
And if Tailscale Funnel let me safely run in a sandbox on prem...?
That sounds amazing.
Like, this is the kind of thing where I'd buy a headless PC just to host federated apps for my extended friends and family network, if the config were painless enough and the sandbox secure enough, and the self-updating, self-maintaining story of Sandstorm.io worked well enough...
It's like the Chrome OS of federation, in my head. The OS does exactly and only what you need, making it easy for you to add the business logic of your thing.
Like, I wish this was roughly how SAS worked...
I wish to hell more businesses felt secure in letting their employees stand up convenience servers. And I feel like these are steps in the right direction.
Honestly, I hate the idea of having a middle man, but having tried and researched extensively how to make something like a direct tunnel between two clients over the internet it just doesn't always work.
NAT is a godsend for IPv4 exhaustion, but it's also fundamentally crippled the ability for people to host things or make things available directly from their homes.
Hole-punching is an inexact process due to the variety of different NAT types, some of which (e.g. Carrier-grade) simply do not allow that sort of connection. So there must be a middle man that accepts packets on their publicly available port and passes it on to another established connection. TURN/STUN (et. al.) exist but are archaic and do the same thing but with less accountability.
I hate it too but until we have IPv6 by default with user controlled firewalls hosting something in your garage without a business line is not feasible. Hell I have a 5$ a month VPS purely so it can act as the middle man to the servers in my home. At least then I only need to trust myself as the middle man.
NAT is a godsend for IPv4 exhaustion, but it's also fundamentally crippled the ability for people to host things or make things available directly from their homes.
Hole-punching is an inexact process due to the variety of different NAT types, some of which (e.g. Carrier-grade) simply do not allow that sort of connection. So there must be a middle man that accepts packets on their publicly available port and passes it on to another established connection. TURN/STUN (et. al.) exist but are archaic and do the same thing but with less accountability.
I hate it too but until we have IPv6 by default with user controlled firewalls hosting something in your garage without a business line is not feasible. Hell I have a 5$ a month VPS purely so it can act as the middle man to the servers in my home. At least then I only need to trust myself as the middle man.
Their middle man in the data plane handles encrypted packets so that's not the problem here.
The problem is their control plane that controls the encryption keys. A malicious admin inside TS (or a hack) could grant itself membership in any of their customer's networks. (Or at least this is the worry I read from GP)
The problem is their control plane that controls the encryption keys. A malicious admin inside TS (or a hack) could grant itself membership in any of their customer's networks. (Or at least this is the worry I read from GP)
That's definitely a concern, but I feel this can be mitigated by running your own network on top of theirs. Anyone in my home is part of my network, doesn't mean they're in the wg network too.
Aside from that, it's definitely a problem that they could include themselves in any customer network, but the accountability still stands. If someone got in without your screw-up, at least you know who to point the finger at once the dust settles.
I'd argue it should be treated as a base to overlay your network on top of. Although admittedly I say that as someone that doesn't use their services for similar reasons.
Aside from that, it's definitely a problem that they could include themselves in any customer network, but the accountability still stands. If someone got in without your screw-up, at least you know who to point the finger at once the dust settles.
I'd argue it should be treated as a base to overlay your network on top of. Although admittedly I say that as someone that doesn't use their services for similar reasons.
> If someone got in without your screw-up, at least you know who to point the finger at once the dust settles.
How do you know you didn't screw up? There are so many vulnerabilities in the gazillion or random stuff you run every day on your laptop. I'd argue it's more likely that something like that was breached than Tailscaled was breached or rogue.
How do you know you didn't screw up? There are so many vulnerabilities in the gazillion or random stuff you run every day on your laptop. I'd argue it's more likely that something like that was breached than Tailscaled was breached or rogue.
Forget the server, what especially worries me is the client.
For some weird reason the GUI clients for Windows, macOS and iOS are closed-source.
I never understood exactly why that is, considering that the Linux and Android ones are fully open.
The fact that there isn't a reason documented anywhere certainly worries me.
For some weird reason the GUI clients for Windows, macOS and iOS are closed-source.
I never understood exactly why that is, considering that the Linux and Android ones are fully open.
The fact that there isn't a reason documented anywhere certainly worries me.
One can install the FOSS client and daemon on macOS similarly to Linux:
https://github.com/tailscale/tailscale/wiki/Tailscaled-on-ma...
I do that mostly because it's running as a LaunchDaemon.
> Forget the server
Pop the headscale server in and you get a fully FOSS system.
https://github.com/juanfont/headscale
That I don't do, because the coordination server, the relay system (which you can also self-host), and the server side UI are really good.
And also the public behaviour of the persons working at Tailscale as well as Tailscale's approach towards FOSS generally increase my level of trust in them. IOW they strike me as Nice Folks(TM), and if Nice Folks(TM) don't inspire confidence to you then you probably want to run the whole thing as described above.
I mean, please read this in its entirety. They even have a "Encouraging Headscale" section.
https://tailscale.com/opensource/
https://github.com/tailscale/tailscale/wiki/Tailscaled-on-ma...
I do that mostly because it's running as a LaunchDaemon.
> Forget the server
Pop the headscale server in and you get a fully FOSS system.
https://github.com/juanfont/headscale
That I don't do, because the coordination server, the relay system (which you can also self-host), and the server side UI are really good.
And also the public behaviour of the persons working at Tailscale as well as Tailscale's approach towards FOSS generally increase my level of trust in them. IOW they strike me as Nice Folks(TM), and if Nice Folks(TM) don't inspire confidence to you then you probably want to run the whole thing as described above.
I mean, please read this in its entirety. They even have a "Encouraging Headscale" section.
https://tailscale.com/opensource/
> I mean, please read this in its entirety. They even have a "Encouraging Headscale" section.
Honestly that makes it even weirder.
Usually companies will just not acknowledge that an open alternative that plugs into their existing product exists, and if they do it's for enforcement/diverting purposes ("Don't use this, please stick to the official stuff")
If you're at a point where you acknowledge, accept, and even help the unofficial FOSS alternative, why not make your official stuff the same way?
Honestly that makes it even weirder.
Usually companies will just not acknowledge that an open alternative that plugs into their existing product exists, and if they do it's for enforcement/diverting purposes ("Don't use this, please stick to the official stuff")
If you're at a point where you acknowledge, accept, and even help the unofficial FOSS alternative, why not make your official stuff the same way?
Product differentiation. If you run the head scale server, I’m not certain the funnel service will work. And there’s probably other stuff that is not planned to work with the FOSS coordinator server. And of course, one of the big things is: they don’t have to support anything with headscale, even if it’s sort of their software. Use the official stuff, and you get support. Pay, and you get better support.
For that matter one can use Windows’s built-in WSL or Hyper-V functionality to run the Linux tailscale client, too.
In fact, I do this anyway because their Windows client’s subnet router functionality is documented as being less performant than their FOSS client. I use my home desktop running Windows as a subnet router from tailscale into my home network, but when I read the note about performance I quickly installed Alpine Linux on a Hyper-V virtual machine and installed tailscale on there.
That simple Alpine VM takes up so little resources that I don’t even notice any impact on performance with my 2009 12 core Xeon system. (This was a huge system, but I would imagine a modern low-midrange CPU would easily outperform it and likewise handle a micro-VM just as well)
One static route added to my home router, and traffic flows both directions just fine. No need to install the client on any more machines on my network. This also saves on licensing, helping me stay within my free plan. :)
In fact, I do this anyway because their Windows client’s subnet router functionality is documented as being less performant than their FOSS client. I use my home desktop running Windows as a subnet router from tailscale into my home network, but when I read the note about performance I quickly installed Alpine Linux on a Hyper-V virtual machine and installed tailscale on there.
That simple Alpine VM takes up so little resources that I don’t even notice any impact on performance with my 2009 12 core Xeon system. (This was a huge system, but I would imagine a modern low-midrange CPU would easily outperform it and likewise handle a micro-VM just as well)
One static route added to my home router, and traffic flows both directions just fine. No need to install the client on any more machines on my network. This also saves on licensing, helping me stay within my free plan. :)
They’ve said that closed source systems will keep the GUI closed source:
https://tailscale.com/opensource/
https://tailscale.com/opensource/
That doesn't seem to make any sense. It's nice poetically I guess, but that's not the reason.
Maybe it doesn't make sense to you, and you may not agree with it, but if they state that this is the reason why they do it this way, then we should at least consider that it might actually be the reason why they do it this way.
Maybe the codebases need some tidying for open source, the chronology seems to make sense. I guess it isn't as simple as 'make repo public'.
I see no reason why the tidying couldn't be done in public. Why not make a public repo that's closed off to external influence until it's "tidy" enough?
If they use a proprietary third party library, they might not have a source distribution license of said library. The same way that you can't just unilaterally decalare an MIT licensed project is GPL without ensuring that all of the code was dual licensed or covered under a CLA.
EDIT: I saw another comment that says that it's "just" the GUI applications for Windows and Mac that aren't open, but the core functionality is. I know that in Windows-land, it's _very_ common to use proprietary UI libraries like Telerik UI[0], or devexpress [1]
[0] https://www.telerik.com/purchase/individual/winforms.aspx
[1] https://www.devexpress.com/
EDIT: I saw another comment that says that it's "just" the GUI applications for Windows and Mac that aren't open, but the core functionality is. I know that in Windows-land, it's _very_ common to use proprietary UI libraries like Telerik UI[0], or devexpress [1]
[0] https://www.telerik.com/purchase/individual/winforms.aspx
[1] https://www.devexpress.com/
I've had the same thought re: iOS/macOS clients. Oh how I would love to dive into those small codebases and add some simple QOL stuff. I've been watching but they don't seem to be adding any Apple-platforms focused roles/people, which is fine, but I wanna work at Tailscale…
Well, they need something closed source to keep customers and to not end up like Docker, Inc. /s
I think that by the sheer nature of Wireguard, it doesn't matter much. We don't send any readable data to Tailscale, they, for the greater part, handle plumbing between nodes. What goes in the pipes remains unnoticed and unknown to them.
Their MagicDNS feature may raise different concerns though, but I'll let others comment on it.
Their MagicDNS feature may raise different concerns though, but I'll let others comment on it.
This new service allows them (or if they’re hacked - anyone)… to MitM your connections - they state themselves they could ssl terminate the connections as they own the ts.net level, they say they don’t but that’s now…
> This new service allows them (or if they’re hacked - anyone)… to MitM your connections...
TFA mentions that the immutable certificate logs reveal if something spooky is going on. Not enough of a guarantee since the tailscale client may siphon off certs from a local device to its servers anyway. But that's us being extremely paranoid about tailscale (in which case, why use it?).
Second, most services are run behind reverse-proxying load balancers which invariably are setup to "MiTM" aka terminate TLS. The providers running those load balancers control IPs + DNS records too, for good measure.
I guess, supporting a dizzying array of functionality makes Tailscale a decentralised cloud service provider themselves.
TFA mentions that the immutable certificate logs reveal if something spooky is going on. Not enough of a guarantee since the tailscale client may siphon off certs from a local device to its servers anyway. But that's us being extremely paranoid about tailscale (in which case, why use it?).
Second, most services are run behind reverse-proxying load balancers which invariably are setup to "MiTM" aka terminate TLS. The providers running those load balancers control IPs + DNS records too, for good measure.
I guess, supporting a dizzying array of functionality makes Tailscale a decentralised cloud service provider themselves.
Why depend on Tailscale when you can go 100% open source and use slack's nebula or plain old wireguard or one of those open source wireguard manager apps.
Plain old wireguard doesn't do double-nat hole punching. And many of the open-source alternatives (such as innernet) also don't.
"Plain old wireguard"
In my mind wireguard was still the new kid on the block.
Technology moves so fast.
In my mind wireguard was still the new kid on the block.
Technology moves so fast.
Same here. Also, in my mind, wireguard just works. I tried setting up OpenVPN one time and gave up. Wireguard was a breath of fresh air. Generated some QR codes for my mobile devices, rsynced some .conf files to my machines and I was good to go.
Calling something "plain old" in no way implies that it's old.
https://en.wiktionary.org/wiki/plain_old
https://en.wiktionary.org/wiki/plain_old
Have you tried Tailscale? It's just a whole new experience getting all your devices connected in 10 minutes. It's quite something.
I did and the CPU usage on the clients is much higher compared to kernel wireguard or even nebula (userspace, written in go).
Add the fact that it has no advantage over nebula and I stopped using it in a heartbeat.
Add the fact that it has no advantage over nebula and I stopped using it in a heartbeat.
This is true, on my iPhone 12 mini Tailscale is often the heaviest app (now at 17%) whereas Wireguard never really registered. Strange thing is that on some days Tailscale also barely registers. Could be that the Home Assistant app, which also takes a lot off battery connects via the Tailnet, and it communicates a lot in the background (tracks my position and some other Phone sensors.)
Nebula seems to be under Defined Networking (https://www.defined.net/) now. It lacks the ease and tooling of the multitude of others that emerged in the space. My gut is that it's usable for the clever home user but meant for a professional IT dept with the ability/desire to build their own tooling and automation around it. The spartan mobile app is a sign of such. Tailscale is probably more easily usable for the average user than nebula or even vanilla wireguard.
Because the whole point of Tailscale is that it's zero config, I don't really want ot mess about with wireguard.
Former Wireguard user here. It's fantastic for point to point VPN but I moved to Tailscale last week and it's so much better having all of my devices on one flat network. Not to mention getting my parents devices on there with no config.
Now image having twenty employees running Wireguard. Having to send them keys and configs, off boarding and managing it.
Tailscale (or Headscale for that matter if you host it yourself) is magical in comparison.
https://github.com/juanfont/headscale
Tailscale (or Headscale for that matter if you host it yourself) is magical in comparison.
https://github.com/juanfont/headscale
Or why not the open source tool innernet? https://github.com/tonarino/innernet
>But somehow we're all meant to be happy giving full control of our entire network to a commercial company running a closed source command and control server?
Yes, Tailscale is THAT good this tradeoff is worth it.
Yes, Tailscale is THAT good this tradeoff is worth it.
[deleted]
[deleted]
This is huge. One of the last major missing features from Tailscale IMO. I maintain a list of tunneling solutions[0]. Personally, I think the future of p2p networking and selfhosting may be through tunneled, SNI-routed TLS connections (exactly what Tailscale just announced). It solves IP exhaustion, NAT, and IP privacy at the cost of an extra hop and no UDP.
The big question is going to be pricing. The current top player in this space is Cloudflare Tunnel, which is a loss-leader product that technically forbids selfhosting anything other than HTML sites.
Selfhosting media can use tons of bandwidth. Any service that doesn't charge per GB is incentivized to limit your speeds.
[0]: https://github.com/anderspitman/awesome-tunneling
The big question is going to be pricing. The current top player in this space is Cloudflare Tunnel, which is a loss-leader product that technically forbids selfhosting anything other than HTML sites.
Selfhosting media can use tons of bandwidth. Any service that doesn't charge per GB is incentivized to limit your speeds.
[0]: https://github.com/anderspitman/awesome-tunneling
> It solves IP exhaustion, NAT, and IP privacy at the cost of an extra hop and no UDP.
That is awfully expensive for something ipv6 already solves minus the privacy part. I don't see how it can be considered "huge". A slight convenience maybe?
Also, routing everything through a 3rd party is a massive downside.
That is awfully expensive for something ipv6 already solves minus the privacy part. I don't see how it can be considered "huge". A slight convenience maybe?
Also, routing everything through a 3rd party is a massive downside.
IPv6 the technology solves it, IPv6 as it exists in the real world does not. Even if we got 100% IPv6 adoption overnight, you would still not have a universally adopted API for punching holes through router firewalls for p2p applications.
Yep, and such a thing would never be allowed anyway because what network administrator will look at “yes random client devices can punch holes in my network from the outside to your not very securely assigned address” and rightfully say nope.
Here’s the attack:
- You want to get to A
- And you’re on a device B that has access to hole-punch-as-a-service but no direct access to A. Good network administrator / sysadmin!
- Attack NDP (ie ARP spoofing but IPv6 flavored) to trick the firewall just for a moment that you’re A [1] and request the port be opened to your evil server C on the public internet.
- Oops.
Here’s the attack:
- You want to get to A
- And you’re on a device B that has access to hole-punch-as-a-service but no direct access to A. Good network administrator / sysadmin!
- Attack NDP (ie ARP spoofing but IPv6 flavored) to trick the firewall just for a moment that you’re A [1] and request the port be opened to your evil server C on the public internet.
- Oops.
Yep, tunneling is way more secure than direct p2p. Especially if you run the service inside some sort of sandbox/container/VM which is possible on all major OSes these days.
SSL?
How does Syncthing solve this?
AFAIK it doesn't use third party servers and it seems to get through any router just fine...
AFAIK it doesn't use third party servers and it seems to get through any router just fine...
It uses third party (community-provided) relay servers: https://docs.syncthing.net/users/strelaysrv.html
This can have quite an effect on sync speed. I set it up for my dad and initially his PC and laptop were syncing incredibly slowly. It turned out they both thought his home network was a public one, so everything was going out to a relay server and back.
This can have quite an effect on sync speed. I set it up for my dad and initially his PC and laptop were syncing incredibly slowly. It turned out they both thought his home network was a public one, so everything was going out to a relay server and back.
As others have mentioned, NAT traversal and relays. Tailscale has the best article on NAT traversal I'm aware of: https://tailscale.com/blog/how-nat-traversal-works/
WebRTC solves this via signalling servers. Data channels are peer-to-peer and traverse NAT.
... you mean like UPnP?
The first google result for "upnp adoption" is from 2012. The second is from 2022 and recommends you turn it off for security reasons.
EDIT: I agree we definitely need something like UPnP, or maybe even UPnP itself, but it's another adoption problem currently.
EDIT: I agree we definitely need something like UPnP, or maybe even UPnP itself, but it's another adoption problem currently.
UPnP needs management. I'd like to be able to set rules about what ports can be opened by UPnP, from where, by whom, with or without a notification in email/logs/alerts etc.
[deleted]
Pretty much every consumer router has UPnP enabled by default.
We love IPv6 at Tailscale! It's just not pervasive yet, so we do what we gotta do.
So basically that would mean a cloudflare for P2P, though maintaining data privacy at least.
It’s better than no P2P but IPv6 solves exhaustion and NAT without the performance hit or protocol limitations and with no extra third party intermediary in the way.
BTW this maintains data privacy but you can still tell a whole whole lot from metadata.
On the flip side it would prevent the kind of “griefing” with DDOS that happens every once in a while with self hosted and P2P things. It’s not that common unless you are engaging with certain communities but it is an inherent Internet architectural flaw that this kind of works around (at a cost).
It’s better than no P2P but IPv6 solves exhaustion and NAT without the performance hit or protocol limitations and with no extra third party intermediary in the way.
BTW this maintains data privacy but you can still tell a whole whole lot from metadata.
On the flip side it would prevent the kind of “griefing” with DDOS that happens every once in a while with self hosted and P2P things. It’s not that common unless you are engaging with certain communities but it is an inherent Internet architectural flaw that this kind of works around (at a cost).
I envision something more decentralized than Cloudflare[0]. I think you could have local companies in every major city that would own a block of IP addresses and provide tunneling services with SNI routing for people in the same region. They can also provide more expensive services like DDoS protection and caching for popular sites or even on-demand when your mom blog goes viral.
> It’s better than no P2P but IPv6 solves exhaustion and NAT without the performance hit or protocol limitations and with no extra third party intermediary in the way.
I just don't see ISPs ever implementing IPv6 without governments forcing them to. It enables p2p which increases upload bandwidth requirements and cuts into their bottom line. And even if we get IPv6 you still need the ability to open firewall ports in a way the average user can understand. Not hard technically but that's another standard that everyone is going to have to agree on and implement.
[0]: Which I know you can appreciate. "Decentralize until it hurts; centralize until it works" is still one of my mottoes.
> It’s better than no P2P but IPv6 solves exhaustion and NAT without the performance hit or protocol limitations and with no extra third party intermediary in the way.
I just don't see ISPs ever implementing IPv6 without governments forcing them to. It enables p2p which increases upload bandwidth requirements and cuts into their bottom line. And even if we get IPv6 you still need the ability to open firewall ports in a way the average user can understand. Not hard technically but that's another standard that everyone is going to have to agree on and implement.
[0]: Which I know you can appreciate. "Decentralize until it hurts; centralize until it works" is still one of my mottoes.
There is no ISP conspiracy to not implement IPv6.
The hard truth is that implementing IPv6 costs money and customers are not willing to pay for it.
The hard truth is that implementing IPv6 costs money and customers are not willing to pay for it.
Doesn't need to be a conspiracy, just misaligned incentives. That said, I do agree that customers aren't clamoring for upload bandwidth and p2p, because the software for selfhosting is still way too complicated and insecure for the average user to set up and run. It's a chicken/egg problem, and IMO the software needs to get better first (which is what I'm working on).
All of the home ISPs I've used in the past 10 years have IPv6. I know a few don't, including some surprising ones such as new FTTH, but they all say it's "coming."
Once you wire fiber upstream bandwidth doesn't matter that much. ISPs are directly peered into the core of the Internet and pay bulk peering bandwidth pricing not cloud bandwidth pricing. Cloud bandwidth pricing is completely insane, like 10000% markup or more in many cases, and the fact that they charge more for outbound is just a strategy to make data flow into their cloud but not out. Bandwidth is actually dirt cheap or companies like Cloudflare could never exist.
The main reason they drag their feet on IPv6 is that there's no strong forcing function and dual stack adds complexity. When they're on a deadline to ship they punt on it. They are starting to get complaints from gamers though. Gamers tend to be the top home users that drive early adoption of all kinds of things.
Edit: another funny thing is that most ISP/telecom stuff these days is IPv6 at the core. If they're not doing it at the edge for new stuff it means they've just got it off and are running IPv4 over IPv6 within their network most of the time. This is even more true for mobile networks, some of which are IPv6 only and the phone does 4to6.
The rollout is still happening... slloooooooowly... The Internet is huge and it takes forever to do a major upgrade like this. I wish they'd have just made IP 48 or 64 bit with an easier upgrade path, but that's water under the bridge now.
Once you wire fiber upstream bandwidth doesn't matter that much. ISPs are directly peered into the core of the Internet and pay bulk peering bandwidth pricing not cloud bandwidth pricing. Cloud bandwidth pricing is completely insane, like 10000% markup or more in many cases, and the fact that they charge more for outbound is just a strategy to make data flow into their cloud but not out. Bandwidth is actually dirt cheap or companies like Cloudflare could never exist.
The main reason they drag their feet on IPv6 is that there's no strong forcing function and dual stack adds complexity. When they're on a deadline to ship they punt on it. They are starting to get complaints from gamers though. Gamers tend to be the top home users that drive early adoption of all kinds of things.
Edit: another funny thing is that most ISP/telecom stuff these days is IPv6 at the core. If they're not doing it at the edge for new stuff it means they've just got it off and are running IPv4 over IPv6 within their network most of the time. This is even more true for mobile networks, some of which are IPv6 only and the phone does 4to6.
The rollout is still happening... slloooooooowly... The Internet is huge and it takes forever to do a major upgrade like this. I wish they'd have just made IP 48 or 64 bit with an easier upgrade path, but that's water under the bridge now.
This is hopeful. I agree there's a good chance we'll all be running on IPv6 eventually. I just don't see it happening in the next 10 years unless the gamers can get us there. Personally, I'm hoping to see a selfhosting revolution in the next 5 years, and I think that's going to happen over tunnels and overlay networks.
It'll happen over overlay networks for other reasons, like the Internet being a dark forest hellscape where anything public gets attacked.
Overlay networks are probably the future. IPv6 lets them be fully P2P and more decentralized.
Edit: one more piece of detail about upstream bandwidth at home. 30-40mbps/sec up is a DOCSIS cable system limit. That's the only reason for that really. Cable was never designed to be bidirectional and the stuff they do with modulation to get shared upstream is heroic. It's also related to why cablemodems tend to use a lot of power. They have to blast spread spectrum pretty loud to get it to the CO. Fiber will save energy.
Overlay networks are probably the future. IPv6 lets them be fully P2P and more decentralized.
Edit: one more piece of detail about upstream bandwidth at home. 30-40mbps/sec up is a DOCSIS cable system limit. That's the only reason for that really. Cable was never designed to be bidirectional and the stuff they do with modulation to get shared upstream is heroic. It's also related to why cablemodems tend to use a lot of power. They have to blast spread spectrum pretty loud to get it to the CO. Fiber will save energy.
None of my ISPs ever had IPv6 support.
Have you used a smartphone? Most mobile networks are IPv6 enabled.
I just tried turning off wifi on my phone. After googling what is my ip and pinging the IPv6 address from another IPv6 device, it doesn't work. Whether it's a firewall/NAT/whatever is irrelevant. IPv6 as deployed does not provide p2p.
PS - typing the IPv6 address was super annoying and error prone compared to IPv4.
PS - typing the IPv6 address was super annoying and error prone compared to IPv4.
Your mobile network is probably still V6 at the core. They're either giving you V4 at the endpoint or your phone is hiding V6 from you. Android or iOS? Apple stuff is V6 native now. Android's gonna be mixed.
Depends on the carrier network though. I am on Spectrum (Verizon network) in Ohio and get V6 with CGN for V4. My wired ISP provides dual stack.
Depends on the carrier network though. I am on Spectrum (Verizon network) in Ohio and get V6 with CGN for V4. My wired ISP provides dual stack.
Can you ping directly to your phone from another device, or access a webserver on it? That would be awesome.
Never tried but I somehow doubt it. Standard issue UDP hole punching absolutely does work though.
You still usually need hole punching with IPv6 if there's any kind of firewall in the way, but unlike IPv4 with NAT it's virtually 100% successful. Even if IPv6 NAT is deployed there's usually a 1:1 internal/external IP mapping making hole punching 100% successful.
You still usually need hole punching with IPv6 if there's any kind of firewall in the way, but unlike IPv4 with NAT it's virtually 100% successful. Even if IPv6 NAT is deployed there's usually a 1:1 internal/external IP mapping making hole punching 100% successful.
Phone data traffic is proxied or NATted for qos and other purposes, even with IPv6.
It works better outbound than the old model though. I use iSH to get a Linux shell and with a mini Bluetooth keyboard I work on some hobby projects on the train from my iPhone.
It works better outbound than the old model though. I use iSH to get a Linux shell and with a mini Bluetooth keyboard I work on some hobby projects on the train from my iPhone.
Agreed, this is awesome! I've been using Cloudflare Tunnel for local dev, but the fact that it seems to be coupled to their CDN product with no way to permanently turn off the CDN functionality has caused quite a few headaches lately (though it's possible to turn off temporarily using "Development Mode").
Would love to give this a try, though from the post it's not clear if we could use our own custom domains instead of the provided ts.net ones? This is a necessity for my use case where I need to be able to handle wildcard subdomains.
Would love to give this a try, though from the post it's not clear if we could use our own custom domains instead of the provided ts.net ones? This is a necessity for my use case where I need to be able to handle wildcard subdomains.
Where do you see Cloudflare Tunnel T&C? Their help documentation seems to promote Tunnel/Access apps in every possible scenario:
> Our connector, cloudflared, was designed to be lightweight and flexible enough to be effectively deployed on Raspberry Pi, your laptop or a server running your data center. Tunnel does not programmatically enforce any throughput limitations.
> If you are hosting a Tunnel in GCP, AWS, or Azure you can view our deployment guides which are more prescriptive in assigning minimum system requirements.
https://developers.cloudflare.com/cloudflare-one/connections...
> Our connector, cloudflared, was designed to be lightweight and flexible enough to be effectively deployed on Raspberry Pi, your laptop or a server running your data center. Tunnel does not programmatically enforce any throughput limitations.
> If you are hosting a Tunnel in GCP, AWS, or Azure you can view our deployment guides which are more prescriptive in assigning minimum system requirements.
https://developers.cloudflare.com/cloudflare-one/connections...
Yeah it's actually a bit difficult to find on google: https://www.cloudflare.com/terms/#28-limitation-on-serving-n...
looool so I’m literally working on something like funnel (built on their tsnet package) as I type except for generic TCP/UDP listeners.
This explains so much of what I’ve seen added to their codebase recently
This explains so much of what I’ve seen added to their codebase recently
Where do they say you can't host anything besides HTML sites? Their docs even showcase various use cases for Tunnels besides that
Tailscale and the people building it continue to blow me away. The ingenuity, reliability, polish, and speed of feature delivery are unparalleled in software.
I'm eager to get rid of needing DDNS and open ports just for web hooks. And I can "flatten" my stack by cutting out a reverse proxy / weird port forwarding stuff.
I'm eager to get rid of needing DDNS and open ports just for web hooks. And I can "flatten" my stack by cutting out a reverse proxy / weird port forwarding stuff.
Though, strictly speaking, all of that was already possible with ip6
Sure. I don't think tailscale does anything that's impossible through other means (cue comments about how anyone can recreate Dropbox with an FTP server, svn, and a fuse file system). IMO whats great about it is that it's easy to set up and is incredibly low maintenance (at least they way I use it).
Further, and to their credit theres a lot of great tech in there.
Just the other day I stumbled on DERP [1] their wireguard-over-tcp (over their node network) implementation which they fall back to if NAT traversal fails. While sure, this is partly ipv4 problem, it recently helped me connect with friends behind government firewalls, presumably because the packets aren't recognized yet.
But that sort of automated connectivity during nat traversal failure through a global network of edges isn't something you can easily setup yourself (if you care).
[1] github.com/tailscale/tailscale/tree/main/derp
Just the other day I stumbled on DERP [1] their wireguard-over-tcp (over their node network) implementation which they fall back to if NAT traversal fails. While sure, this is partly ipv4 problem, it recently helped me connect with friends behind government firewalls, presumably because the packets aren't recognized yet.
But that sort of automated connectivity during nat traversal failure through a global network of edges isn't something you can easily setup yourself (if you care).
[1] github.com/tailscale/tailscale/tree/main/derp
It's about 40% possible with IPv6: https://www.google.com/intl/en/ipv6/statistics.html
And 40% * 40% = 16% if you're doing P2P.
IPv6 is an option, but not the one true answer (yet?). It helps sometimes.
For Tailscale, IPv6 helps about 7% of the time to bust a NAT connection.
IPv6 is an option, but not the one true answer (yet?). It helps sometimes.
For Tailscale, IPv6 helps about 7% of the time to bust a NAT connection.
Sad. Where's that other 16-7=9% go? Firewalls? Or do Tailscale's users have even lower adoption of IPv6?
The 7% is how often it ends up helping after all the traditional IPv4 traversal tricks.
We race all the options and see which works & is fastest. It's likely it's more like 16% or more (I don't have that number handy) in practice but 7% is just how often it would've not worked at all and had to go to DERP relays if it weren't for IPv6 being an option.
We race all the options and see which works & is fastest. It's likely it's more like 16% or more (I don't have that number handy) in practice but 7% is just how often it would've not worked at all and had to go to DERP relays if it weren't for IPv6 being an option.
My ISP in a major US city straight ip does not provide IPv6
Neither did mine (Verizon Fios in NYC) until a few weeks ago. The rollout is very slow, but I’m confident someday you’ll have it.
My ISP in the Bay Area also straight up does not provide IPv6, you'd think this would be the center of adoption.
Possible if you have IPv6.
I've been using tailscale in my home setup for a while and really appreciate the simplicity. It has just worked in my experience. Before taking the leap for tailscale I was semi-struggling with a vault + wireguard + consul-template approach which was pretty cool and fun to setup but a bit unnerving to be unsure if I got anything wrong and the chances of me being exposed.
This looks like yet another feature that fits my use case and reduces my security burden. Though learning a few things from this post the first being that I should have replaced my use of haproxy with rinetd ages ago. The other about Certificate Transparency logging. Still going through the wiki pages to understand how that works, but would it really log an event such as Tailscale terminating the request, dumping the data, and re-encrypting them before sending us the request? Or is it possible for a bad actor to hide the logging?
This looks like yet another feature that fits my use case and reduces my security burden. Though learning a few things from this post the first being that I should have replaced my use of haproxy with rinetd ages ago. The other about Certificate Transparency logging. Still going through the wiki pages to understand how that works, but would it really log an event such as Tailscale terminating the request, dumping the data, and re-encrypting them before sending us the request? Or is it possible for a bad actor to hide the logging?
I went all-in on Tailscale couple of years ago but slowly (and painfully) moving away from it.
It's a fantastic service but with a big flaw: its iOS app eats battery like crazy. I didn't know about it until I accidentally saw it one day: IIRC, it had consumed 20-25% battery averaged out over 10 days. (I used to keep it running in the background all the time, only to route DNS requests to pihole on a home server.) When I googled, it seems like a known problem on their forums for a long time.
So, beware if you are an iOS user.
It's a fantastic service but with a big flaw: its iOS app eats battery like crazy. I didn't know about it until I accidentally saw it one day: IIRC, it had consumed 20-25% battery averaged out over 10 days. (I used to keep it running in the background all the time, only to route DNS requests to pihole on a home server.) When I googled, it seems like a known problem on their forums for a long time.
So, beware if you are an iOS user.
At first it felt ‘magical’ being able to reach self-hosted services from my phone regardless of my location, but I quickly noticed the battery drain as well. I believe it has to do with an always-on ‘VPN’ and I don’t expect any improvements soon.
I’ve decided that Tailscale works perfect for all my computers (e.g., Raspberry Pi, Synology NAS, laptop and VPS), but not for my mobile devices. To mitigate this I use cloudflared on my VPS to route internet traffic over tailscale to any internal services that I often use on my phone.
Cloudflared has good options for securing a tunnel by using MFA methods, for example Google authentication.
For the rare occasion that I need to access something else I can always temporary join the Tailscale network from my phone.
I’ve decided that Tailscale works perfect for all my computers (e.g., Raspberry Pi, Synology NAS, laptop and VPS), but not for my mobile devices. To mitigate this I use cloudflared on my VPS to route internet traffic over tailscale to any internal services that I often use on my phone.
Cloudflared has good options for securing a tunnel by using MFA methods, for example Google authentication.
For the rare occasion that I need to access something else I can always temporary join the Tailscale network from my phone.
It is not caused by an always-on VPN, but by Tailscale. Having e.g. plain Wireguard enabled 24/7 doesn't cause the battery drain or the other issues Tailscale on iOS has.
Unfortunately, Wireguard on iOS doesn't work very well with dyndns, as it doesn't re-resolve dns and thus silently loses the connection when public home IPs change.
Unfortunately, Wireguard on iOS doesn't work very well with dyndns, as it doesn't re-resolve dns and thus silently loses the connection when public home IPs change.
What are you hosting from your phone? Personally, I think upcycled phones plugged into USB drives are the future of selfhosting, but the software's not there yet.
I’ve had this same issue. I just toggle Tailscale off now most of the time, and only turn it on when I really need it on my phone.
Shame though, cause I was also wanting to use it to funnel DNS. I’ve somewhat given up there. I hope they fix their app.
Shame though, cause I was also wanting to use it to funnel DNS. I’ve somewhat given up there. I hope they fix their app.
It also eats a lot of data, I recently had around 3gb eaten in a day just for maintaining the connection. On a metered mobile connection with 6gb/month a tad too much.
I‘d really like to use it, but in this state it’s really unusable for me.
I‘d really like to use it, but in this state it’s really unusable for me.
Same, it's really a shame as tailsclae is great but it uses so much battery on my ios devices I cant keep it active.
> Tailscale terminating the request, dumping ...
For that they need a certificate. They have two options of obtaining that:
a) They request one from a CA. This will be logged in Certificate Transparency logs, and thus you could detect it by comparing the certs logged with the ones your local machine generated
b) they could have their software upload the certificate from your machine. That would need effort to detect (deeply inspecting the software and/or its traffic), but if a whiff of such a "feature" were to be found by anyone it couldn't really be explained away. (and aren't their clients app open-source? then at least it'd be reduced to source inspection and compiling yourself, which makes hiding stuff harder)
For that they need a certificate. They have two options of obtaining that:
a) They request one from a CA. This will be logged in Certificate Transparency logs, and thus you could detect it by comparing the certs logged with the ones your local machine generated
b) they could have their software upload the certificate from your machine. That would need effort to detect (deeply inspecting the software and/or its traffic), but if a whiff of such a "feature" were to be found by anyone it couldn't really be explained away. (and aren't their clients app open-source? then at least it'd be reduced to source inspection and compiling yourself, which makes hiding stuff harder)
> and aren't their clients app open-source?
Only for Linux.
(On macOS I think the core CLI part is open source as well, but that's not what most people use I think.)
Only for Linux.
(On macOS I think the core CLI part is open source as well, but that's not what most people use I think.)
(Tailscalar here)
Most of the Tailscale client’s functionality is implemented as a daemon called tailscaled which is in the OSS repo.
It’s the GUI front ends for Windows, MacOS and iOS that are not.
Most of the Tailscale client’s functionality is implemented as a daemon called tailscaled which is in the OSS repo.
It’s the GUI front ends for Windows, MacOS and iOS that are not.
Any specific reason to why not? These are very simple GUI apps, I imagine there’s not much custom code apart from your usual view code written there.
Thanks, you're right yeah, I've oversimplified things a bit.
Re: macOS and the Network Entitlements shenanigans: if I understand correctly, it is possible to just run tailscaled unsigned [1] via /dev/utun instead of Apple's APIs. Would it be possible to get this into the GUI so that if you want, you can compile it from source and don't have to do the Apple dance?
[1]: https://github.com/tailscale/tailscale/wiki/Tailscaled-on-ma...
Re: macOS and the Network Entitlements shenanigans: if I understand correctly, it is possible to just run tailscaled unsigned [1] via /dev/utun instead of Apple's APIs. Would it be possible to get this into the GUI so that if you want, you can compile it from source and don't have to do the Apple dance?
[1]: https://github.com/tailscale/tailscale/wiki/Tailscaled-on-ma...
As an exercise, I've implemented a basic (and very hacky) UI for tailscale(1) as an xbar [1] plugin: https://gist.github.com/notpushkin/aa36c2d34e3e7180aa66ed2a5...
[1]: https://xbarapp.com/
tailscaled isn't particularly stable on my machine though, so I guess I'll roll back to the closed source version. However, this could be a starting point for a Linux client!
[1]: https://xbarapp.com/
tailscaled isn't particularly stable on my machine though, so I guess I'll roll back to the closed source version. However, this could be a starting point for a Linux client!
If I CNAME my domain to my assigned ts.net then I'm guessing funnel won't work because of the SNI lookup will it? Is that on the radar? Right now I'm using cloudflared but if I can get rid of it in favor of this that would be one less daemon to worry about. Wouldn't be able to do esni though. sooo, how about a vanity .ts.net I get to choose?
It's very nice that it doesn't do TLS termination, but it seems to rely on SNI. That's cool, but it probably precludes SNI encryption in the future. Is there a plan around this? Maybe in the IPv6 world, it becomes a non-issue... But I wonder what comes first: the push for ESNI everywhere, or actually substantial IPv6 adoption.
(Edit; though come to think of it, in practice, if the IP address each host resolved to was unique, it wouldn't really matter very much from a security/privacy standpoint, so I guess it's probably not important...)
(Edit; though come to think of it, in practice, if the IP address each host resolved to was unique, it wouldn't really matter very much from a security/privacy standpoint, so I guess it's probably not important...)
Author here. This shouldn't preclude doing us Encrypted ClientHello in the future. We control the DNS for *.ts.net so we can publish our public key for browsers/etc to encrypt the ClientHello to, if I'm remembering the latest encrypted SNI spec(s)?
Ahh, yeah; disregard me, totally can. Cool!
Is there any updates on being able to use the IOS app for self hosted tailscale? Also what is the status of fully self hosted tailscale in general?
I just don't trust my VPN to be managed by a 3rd party like this. I'm willing to pay money even (though I don't have much) for hobby use - but I don't like the possibility of exposing network devices like this. To be honest I'm a bit surprised seemingly everyone else is.
I just don't trust my VPN to be managed by a 3rd party like this. I'm willing to pay money even (though I don't have much) for hobby use - but I don't like the possibility of exposing network devices like this. To be honest I'm a bit surprised seemingly everyone else is.
Not everyone, we just don't talk about it much. headscale is plenty popular — that's not "everyone" already.
https://github.com/juanfont/headscale
In addition to your points, we over here also have our own reasons for self-hosting everything (for example, to protect ourselves from being cancelled at any moment for being forced into a citizenship you didn't ask for by being born at the wrong place).
https://github.com/juanfont/headscale
In addition to your points, we over here also have our own reasons for self-hosting everything (for example, to protect ourselves from being cancelled at any moment for being forced into a citizenship you didn't ask for by being born at the wrong place).
[deleted]
All depends on your threat model.
I try to escape Tailscale, but they keep trying to suck me back in.
Tailscale crew: I know y'all read HN, so I say to you: keep up the good work and innovation!
Tailscale crew: I know y'all read HN, so I say to you: keep up the good work and innovation!
I was making a service that's half public hosted, and half on tsnet https://tailscale.com/blog/tsnet-virtual-private-services/ server the other day, and this is exactly what I was looking for.
Having an app that can setup its own completely secure networking no matter where it's run is game changing, as soon as I get into the alpha, the Cloudflare tunnel it's on right now is going down!
Having an app that can setup its own completely secure networking no matter where it's run is game changing, as soon as I get into the alpha, the Cloudflare tunnel it's on right now is going down!
I'm surprised they don't allow exit nodes to function as funnel servers.
Seems to me this would save them the hassle of dealing with the bandwidth.
Seems to me this would save them the hassle of dealing with the bandwidth.
Exit nodes are usually still behind your firewall and have no open incoming ports. If you're willing to reconfigure your firewall to open incoming ports, you probably didn’t need Funnel in the first place.
As soon as Tailscale provides option for Wireguard preshared keys, I will use it. I need Tailscale out of my network.
Any plan?
Self hosting Tailscale will then not be needed, since users don’t need to trust Tailscale anymore.
Any plan?
Self hosting Tailscale will then not be needed, since users don’t need to trust Tailscale anymore.
What do you mean by "trust", what's your threat model? Tailscale does way, way more than just facilitate key exchange. If tailscale.com goes down or rogue, you're still in a pickle even with PSKs; just because there's a Wireguard under the hood, doesn't mean you can swap an API endpoint and continue as if nothing happened.
Even with self-provided PSKs, you're going for an (IMHO) pretty poor trade-off; keys, certificates, etc should be regularly rotated, that's a chore that's best left automated. At that point, why not just set up Wireguard yourself?
If you have legitimate concerns, you should be using Headscale[1] (or even plain Wireguard) from day 1. Otherwise - personally I find the current threat model very reasonable, it's in no way worse than trusting any other VPN provider, and they're keeping a pretty big chunk of their code base open for auditing.
[1]: https://github.com/juanfont/headscale
Even with self-provided PSKs, you're going for an (IMHO) pretty poor trade-off; keys, certificates, etc should be regularly rotated, that's a chore that's best left automated. At that point, why not just set up Wireguard yourself?
If you have legitimate concerns, you should be using Headscale[1] (or even plain Wireguard) from day 1. Otherwise - personally I find the current threat model very reasonable, it's in no way worse than trusting any other VPN provider, and they're keeping a pretty big chunk of their code base open for auditing.
[1]: https://github.com/juanfont/headscale
Tailscale is really, really doing a good job of taking all of the different secure remote networking tasks that have always been possible but self-managed and tedious, and wrapping it all in an automated, friendly interface.
Every time they come out with a new product, I read about it and think "Wow, that's really useful. That would be such a pain for me to roll by hand."
Everything they do was already possible with open source tooling, but they make it accessible. It reminds me of when Dropbox first came out.
Every time they come out with a new product, I read about it and think "Wow, that's really useful. That would be such a pain for me to roll by hand."
Everything they do was already possible with open source tooling, but they make it accessible. It reminds me of when Dropbox first came out.
This means selfhosters don't need anything other than a domain name and a local machine, right?
Technically is it very different from Cloudflare Tunnels?
Technically is it very different from Cloudflare Tunnels?
You actually can't use your own domain yet, but looks like there's a good chance they add that based on @bradfitz's comments.
I really want to like Tailscale but I couldn't easily find a way for it to work on a jumpbox running Ubuntu 14.04 that I don't have root access to.
Anyone have a way to install the client on a non-rooted box? I couldn't find anything in the docs about the assumption that it requires root or not, other than it being implied by their install steps using system package managers.
Anyone have a way to install the client on a non-rooted box? I couldn't find anything in the docs about the assumption that it requires root or not, other than it being implied by their install steps using system package managers.
You can grab static binary tarballs on https://pkgs.tailscale.com and then run tailscale in userspace mode: https://tailscale.com/kb/1112/userspace-networking/.
Nice, thank you! I got it to work.
Something else interesting they're doing is their tsnet package, which lets you join your process to the tailnet and bind tcp listeners/connect to TCP services via their tailnet IP or subnet.
I'm writing some stuff using this at the moment, but I also just saw https://github.com/tailscale/golink which does the same thing: a single binary that runs a link shortener that joins itself to your tailnet.
tl;dr: don't run your service on a machine then join that to tailnet, directly bind your service to an in-memory tailnet client
I'm writing some stuff using this at the moment, but I also just saw https://github.com/tailscale/golink which does the same thing: a single binary that runs a link shortener that joins itself to your tailnet.
tl;dr: don't run your service on a machine then join that to tailnet, directly bind your service to an in-memory tailnet client
I wasn't aware of tsnet. That's super cool.
Its very cool, some thoughts:
* They have support in there to get an API client that auths using your nodekey - not sure what endpoints it can hit but makes for some interesting cases like updating ACLs maybe
* You can use it as an exit node/subnet router too, but it requires some hacking
* Equally there UDP support lurking in their library you can wire up too
This is yet another amazing cherry-on-top of an amazing product. I switched Internet providers a couple months ago and was horrified to find that I was now behind a CGNAT. I went looking for a solution to reach my home lab on the go and found Tailscale. Tailscale solved that issue - and I actually had the epiphany that if I couldn't reach my home network without it then nobody else could either. So, maybe the CGNAT is actually a big security benefit in that way - but I digress.
I originally was thinking of it like a network-level VPN but realised if I installed it on everything individually it would give me DNS and HTTPS certs for all the machines in my home lab - that work from anywhere as long as my laptop was connected to Tailscale. That is something I always wanted to do with let's encrypt but never got around to. And now this!
It has really inspired my imagination. I've been running labs teaching 5-15 people k8s and k8s security out of AWS but this means I might be able to just run a bunch of VMs in my home lab all with Tailscale loaded and point people easily at them all. Maybe with code-server (VS code in a browser) on them to give them a browser-based terminal. And that is just one possible usecase...
Thank you Tailscale people - it is such a great product that has exceeded all my expectations!
I originally was thinking of it like a network-level VPN but realised if I installed it on everything individually it would give me DNS and HTTPS certs for all the machines in my home lab - that work from anywhere as long as my laptop was connected to Tailscale. That is something I always wanted to do with let's encrypt but never got around to. And now this!
It has really inspired my imagination. I've been running labs teaching 5-15 people k8s and k8s security out of AWS but this means I might be able to just run a bunch of VMs in my home lab all with Tailscale loaded and point people easily at them all. Maybe with code-server (VS code in a browser) on them to give them a browser-based terminal. And that is just one possible usecase...
Thank you Tailscale people - it is such a great product that has exceeded all my expectations!
>Maybe you need to receive a webhook from GitHub
There are also free options, e.g. ngrok [0] And open source options, e.g. openziti [1]
Doing webhooks and dark webhooks for quite some time. Always good to have more options - what does Funnel do differently than those?
[0] https://blog.ngrok.com/posts/getting-started-with-webhooks [1] https://openziti.io/my-intern-assignment-call-a-dark-webhook...
There are also free options, e.g. ngrok [0] And open source options, e.g. openziti [1]
Doing webhooks and dark webhooks for quite some time. Always good to have more options - what does Funnel do differently than those?
[0] https://blog.ngrok.com/posts/getting-started-with-webhooks [1] https://openziti.io/my-intern-assignment-call-a-dark-webhook...
What's a "dark webhook"?
Also, funny they should mention Github, as they literally just added webhook tunneling to the Github CLI a few days ago.
Also, funny they should mention Github, as they literally just added webhook tunneling to the Github CLI a few days ago.
A "dark webhook" in this case just means sending data from a public server/service like a GitHub action (or even an AWS Lambda) to a server that doesn't have a port open on the internet.
For example, I get a message to my Mattermost client everytime someone pushes/commits/etc. All those messages are sent to the Mattermost server over a webhook that is configured on an overlay network (in our case, using OpenZiti). There's no firewall rule allowing the traffic to the Mattermost server, it's "dark" to the internet.
For example, I get a message to my Mattermost client everytime someone pushes/commits/etc. All those messages are sent to the Mattermost server over a webhook that is configured on an overlay network (in our case, using OpenZiti). There's no firewall rule allowing the traffic to the Mattermost server, it's "dark" to the internet.
I assumed it would be something about the "dark web", never heard the term used for services that are behind a firewall. TIL.
Looks like a nice competition for cloudflare tunnels and ngrok.
Sounds promising! I recently got gigabit fiber through Sonic, who does not offer static IP addresses. I did read the article but it is pretty deep in to some stuff I am not that familiar with. Can anyone clarify, if I own some domain name, can I host something on my raspberry pi or whatever and use funnel with my domain so that someone can visit my domain and get to that hosted thing? And how would this compare to dynamic DNS approaches? Thanks!
No, you can't use your own domain, this specifically works with the ts.net subdomains. You could use it to host your service on "node.tailnet.ts.net", if you're ok with that naming. Otherwise, you'll need to set up a VPS with tailscale on it, and your own domain, and have it proxy similar to how Funnel works.
I assume there are going to be some egress charges for Funnel. Unlike normal tailscale, Funnel has a high bandwidth component to it for hosting high bandwidth services.
I assume there are going to be some egress charges for Funnel. Unlike normal tailscale, Funnel has a high bandwidth component to it for hosting high bandwidth services.
Author here.
We might do BYODomain later. It was easier to launch with only *.ts.net.
If you're using this for things like webhooks, the URL doesn't matter much.
We might do BYODomain later. It was easier to launch with only *.ts.net.
If you're using this for things like webhooks, the URL doesn't matter much.
That's a good point. I have a super simple status page I have wanted to make that would be externally accessible. I don't care what the URL is for that one. I guess this would be a great use for that! That one is behind a Starlink terminal so again, no static IP available there.
Anything stopping us from just creating a CNAME to our tailnet domain and registering certs for it instead of whatever.ts.net? This seems like it should work in my head...
Our Funnel ingress servers won't proxy any TCP connection that doesn't have a *.ts.net SNI name currently.
But BYODomain is something that'd be fun to add.
But BYODomain is something that'd be fun to add.
BYODomain would be great. This would give me a secure & reliable to host public services out of my homelab.
It would be great if Tailscale adds this, but there are lots of services that provide this functionality if you need it today, including Cloudflare Tunnel.
Cloudflare's CNAME flattening with proxy enabled would do the trick. The ingress sees a request to the CNAME target so SNI works as usual.
From how I understood the article, they don't do TLS termination but they do SNI snooping to figure out how to route it? So if they don't have all of the infrastructure in place to map the SNI for your CNAME to your Tailscale network, that wouldn't work?
The next step is being able to send a redirect to the client's tailscale with the public key of the destination node, so it can establish an anonymous connection directly with the node running the service, using some sort of Funnel ACL (default deny).
What about supporting UDP protocols?
Also, I've been told that it's currently bandwidth limited, with the future holding maybe variable bandwidth limits and bandwidth charges. So a dynamic DNS pointing at your gigabit home connection is likely going to be a better solution than funnel.
Got it. I thought maybe that would be the case but I wanted to check. Thanks!
I wonder why that's the case. If you own a DNS name, you can set NS record to point to magic-blah.tailscale.net, so they'll have a chance to geo-locate you and return IP address of the closest VM.
Tailscale is on fire.
I am watching it very closely and considering to set it up for my small team.
I am watching it very closely and considering to set it up for my small team.
I'd still love for them to support some other form of auth, Google or Microsoft auth is an incredible drag as a gatekeeper to their product.
We want other forms too. More will come.
They had an interesting conversation about this: https://twitter.com/bradfitz/status/1248458084705431555
We left them because of this. Long overdue move away from Gmail Gsuite resulted in TS costs for our dozen user team at least doubling; the overhead involved in managing the overlay network acls was also getting out of hand too.
I'm fine with companies making profit off of protocols, as long as their code is open source like https://github.com/firezone/firezone or https://github.com/zerotier/ZeroTierOne Tailscale seems great now, but its risky to trust their closed source for this type of service.
That's why headscale exist, its even sponsored by Tailscale!
This looks like cloudflare tunnel without the MITM attack!.
I'm interested to see the limits they put on this, I dont think its going to be as limitless as Cloudflared.
I'm interested to see the limits they put on this, I dont think its going to be as limitless as Cloudflared.
Also without the CDN (which I'm not sure how you'd do without MITM), but this is definitely comparable to Cloudflare Tunnel.
Yup, not everyone needs a CDN.
This speaks like greek to me and I'm a software engineer.
Don't get why this incredibly niche company is boosted like crazy on HN.
Don't get why this incredibly niche company is boosted like crazy on HN.
Another great feature from Tailscale!
Ever since I started using Tailscale a year or two ago, I haven't had to think much about networking for my self-hosted servers at home. It all _just works_. Tailscale is a great example of software solving a real problem in a user friendly way.
Ever since I started using Tailscale a year or two ago, I haven't had to think much about networking for my self-hosted servers at home. It all _just works_. Tailscale is a great example of software solving a real problem in a user friendly way.
Related product from Cloudflare: https://developers.cloudflare.com/cloudflare-one/connections...
Does this mean I can expose home assistant online without worrying too much about security?
Are you trying to share home assistant with everyone on the internet? If yes, then yes.
You probably don't want that, though, so vanilla Tailscale would let only you securely access your home assistant server from anywhere, as long as you install the Tailscale VPN app.
You probably don't want that, though, so vanilla Tailscale would let only you securely access your home assistant server from anywhere, as long as you install the Tailscale VPN app.
This.
You can anyways access Jome Assistant over tailscale without all this.
I think there is even a Tailscale addon for HA.
You can anyways access Jome Assistant over tailscale without all this.
I think there is even a Tailscale addon for HA.
If I understand correctly, this still won’t let me achieve my dream of hosting my personal email on my home computer, because smtp connections typically start out as plaintext and then negotiate up to TLS within the protocol itself.
One nice way this could be improved is to add support for a wildcard dns record (e.g. *.host.tailnet.ts.net) so you are not limited to a single domain per host.
[deleted]
genuine question -- why would I use this?
In addition to the "show your dev work to the CEO" use case, tunnels (ahem, "funnels") like this are useful when you're building functionality that requires pointing webhooks at your devlocal environment.
e.g., if you're building an integration with any of the myriad of SaaS tools that fire webhooks, you can test in devlocal and have a URL of whatever.tunnel.com.
There are tools like ngrok and localtunnel that exist to do just this. I'm looking forward to replacing those with TS Funnels.
e.g., if you're building an integration with any of the myriad of SaaS tools that fire webhooks, you can test in devlocal and have a URL of whatever.tunnel.com.
There are tools like ngrok and localtunnel that exist to do just this. I'm looking forward to replacing those with TS Funnels.
that's an excellent use-case, thanks. I didn't think of local machines when they mentioned webhooks in the article.
you could self host a website.
Or more realistically, if you are in web dev and wanted to show your work on your local machine - say when the CEO wants to 'check in and see how its going', you can just send them a link on slack and they can play with what your developing on.
Or more realistically, if you are in web dev and wanted to show your work on your local machine - say when the CEO wants to 'check in and see how its going', you can just send them a link on slack and they can play with what your developing on.
why do I need a tailnet to self host?
can't the CEO just use the Tailscale network to access it privately?
I just don't personally see a use case -- if I need someone to access the content, the box it is on is already easy to publicly access. if it's not, the only people who need to see it are on the Tailscale network
edit: I think I'm starting to see it. it's not for long term installations. I just feel like, why not just open the box to the internet at that point.
it makes more sense for the edge case(s) that might address friction with adoption. interim solutions, or temporary connections
edit2: I can also see how this might be useful for people living under an oppressive government
can't the CEO just use the Tailscale network to access it privately?
I just don't personally see a use case -- if I need someone to access the content, the box it is on is already easy to publicly access. if it's not, the only people who need to see it are on the Tailscale network
edit: I think I'm starting to see it. it's not for long term installations. I just feel like, why not just open the box to the internet at that point.
it makes more sense for the edge case(s) that might address friction with adoption. interim solutions, or temporary connections
edit2: I can also see how this might be useful for people living under an oppressive government
> can't the CEO just use the Tailscale network to access it privately
How many CEOs you know gonna install a VPN client on their workstation to see your stuff?
How many CEOs you know gonna install a VPN client on their workstation to see your stuff?
IMO it will be much more useful when they add custom domains so you can host things like public websites.
Do they want you to host a public website? AFAICT all the inbound traffic to Funnel has to go through servers they operate, and historically Tailscale has tried to minimize the traffic they handle that way.
They explicitly mention selfhosting services like Mastodon in the article, so have high hopes that they will support use cases like this moving forward.
the more I sit with it the more I can see different ways it might be valuable. even if it's just to simplify setup. the use cases just didn't really jump out to me this time, even as a happy Tailscale user
if there's anyone from tailscale is currently lurking this post:
1. How much traffic cost would you expect to get into your DERP instances when this service will be available globally?
2. How much bandwidth would you prepare just for proxying these nodes into public network?
3. How do you think some users might abuse this service in the future?
1. How much traffic cost would you expect to get into your DERP instances when this service will be available globally?
2. How much bandwidth would you prepare just for proxying these nodes into public network?
3. How do you think some users might abuse this service in the future?
It looks like they're bracing for a lot of traffic or abuse:
> Limitations
> - DNS names are restricted to that of your tailnet’s domain name.
> - The ports you can specify to expose your servers on are currently to 443, 8443 and 10000.
> - Traffic over Funnel is subject to bandwidth limits. They are not currently configurable.
I was thinking this would be cool to run some live video stuff on, but maybe that's too much bandwidth for now :)
> Limitations
> - DNS names are restricted to that of your tailnet’s domain name.
> - The ports you can specify to expose your servers on are currently to 443, 8443 and 10000.
> - Traffic over Funnel is subject to bandwidth limits. They are not currently configurable.
I was thinking this would be cool to run some live video stuff on, but maybe that's too much bandwidth for now :)
I'd love to learn what the bandwidth limits are.
This is the 'logistics' level questioning. "Amateurs talk strategy; professionals talk logistics"
Now I'm like. OK tailscale, give me custom domains and I'm sold. Where are you @bradfitz!
I love tailscale, but never understood why zerotier wasn't more popular
As someone who's currently using ZT (both personally and at work), and evaluating switching over to TS...
ZT is absolutely brilliant, but it lacks polish in a few places, that sometimes turn out to be critical. I could probably do a side-by-side comparison table, and ZT would still win in roughly 50% of the cases, but the places where it's losing are causing tiny bits of friction.
ZT flow rules are approximately just as powerful as TS ACLs, but TS has an integrated editor that does formatting, validation, inserts hints and snippets for you, etc. TS ACLs also have test rules that allow you to create assertions, about what must (or must not) have access to what, increasing my confidence when making bigger changes.
TS allows you to tag assets, making complex ACLs easier to reason about.
TS has MagicDNS; with ZT we had to hack something together using their API and a bit of Terraform, and it needs to be rerun every time a node joins/leaves. I could probably write a tiny custom authoritative DNS resolver that talks to ZT API, but TS has it out of the box.
We've effectively soft-bricked a ZT node behind an NAT during a routine dist-upgrade, because dpkg stopped to ask a question, in between the old ZT client version going down, and the new one coming back up. That costed us having to go on site in person to service the device (luckily just that one, and not the whole fleet - but we should've picked a canary node with secondary means of access, lessons learned).
And to be fair, TS is also far from perfect: it's currently allowing one node to participate in only one tailnet, and switching tailnets requires re-authentication in the web browser. This is incredibly annoying in any BYOD scenario, if you want to have separate personal and work tailnets. ZT is infinitely more flexible here: any device can just join or leave networks at will, and it's up to the network admin to authorize it (once).
The list goes on, I really like both tools but the small differences keep adding up in TS' favor.
ZT is absolutely brilliant, but it lacks polish in a few places, that sometimes turn out to be critical. I could probably do a side-by-side comparison table, and ZT would still win in roughly 50% of the cases, but the places where it's losing are causing tiny bits of friction.
ZT flow rules are approximately just as powerful as TS ACLs, but TS has an integrated editor that does formatting, validation, inserts hints and snippets for you, etc. TS ACLs also have test rules that allow you to create assertions, about what must (or must not) have access to what, increasing my confidence when making bigger changes.
TS allows you to tag assets, making complex ACLs easier to reason about.
TS has MagicDNS; with ZT we had to hack something together using their API and a bit of Terraform, and it needs to be rerun every time a node joins/leaves. I could probably write a tiny custom authoritative DNS resolver that talks to ZT API, but TS has it out of the box.
We've effectively soft-bricked a ZT node behind an NAT during a routine dist-upgrade, because dpkg stopped to ask a question, in between the old ZT client version going down, and the new one coming back up. That costed us having to go on site in person to service the device (luckily just that one, and not the whole fleet - but we should've picked a canary node with secondary means of access, lessons learned).
And to be fair, TS is also far from perfect: it's currently allowing one node to participate in only one tailnet, and switching tailnets requires re-authentication in the web browser. This is incredibly annoying in any BYOD scenario, if you want to have separate personal and work tailnets. ZT is infinitely more flexible here: any device can just join or leave networks at will, and it's up to the network admin to authorize it (once).
The list goes on, I really like both tools but the small differences keep adding up in TS' favor.
Isn't the performance also a difference? From what I understand, Tailscale uses wireguard, and ZT uses some other L2 tech. I haven't had the chance to personally compare, but it seems like that could be an order of magnitude difference in bandwidth between the two options.
It's worth noting that Tailscale runs WireGuard in userspace, which negates many (all?) of the performance benefits. I wonder if it will ever be possible for nonroot users to create WireGuard devices. They're just so useful.
Out of curiosity, what kinds of performance benefits are kernelspace-exclusive, in terms of VPN apps? I've seen arguments go both ways for different applications, with full usermode TCP/IP stacks, unikernels, even running apps directly on the NIC (snabb switch); historically there were also efforts like khttpd that ultimately failed.
I don't know much about what where specific gains come from. Generally avoiding copies and syscalls go a long way. I suspect in many cases WireGuard performance isn't going to be your bottleneck, but in those cases you're still reducing power consumption.
We're neither latency- nor bandwidth-sensitive, and both services are overall quite reliable, so I haven't actually paid much attention to that aspect. But there are plenty of war stories of people using ZT or TS to do absolutely bonkers stuff, like zero-downtime migrations between cloud providers, with a write-heavy DB in there.
I wholeheartedly recommend doing your own benchmarks! Everyone's workload will be slightly different, ultimately you should pick what works best for you.
I wholeheartedly recommend doing your own benchmarks! Everyone's workload will be slightly different, ultimately you should pick what works best for you.
I'll definitely have to do my own benchmarks! It's been weird how infrequently VPN tech is benchmarked. It's not easy to dig up hard numbers on bandwidth.
Yea this has been exactly my experience as well.
TS uses WG, so that might save so engineering time as well, and they really focus on creating usable features.
TS uses WG, so that might save so engineering time as well, and they really focus on creating usable features.
Regarding DNS, in my small private network I use Avahi and nss-mdns with ZT.
https://youtube.com/channel/UCjEFU_JKD2MRVNHFIk2HXHg
I need viral my YouTube channel subscriber
I love all the comments in the parenthesis.
this is cool and all, love me Tailscale for sure.
For this particular feature I like my own home rolled solution where I automated the process of spinning up a tiny ec2 server with an nginx proxy to a reverse ssh tunnel that goes back to my local machine. It gets a letsencrypt cert and modifies the route53 dns. All managed with a cli command and config file.
The other benefit is that it is completely unthrottled, which is particularly useful if your debugging some stupidly large react/vue website.
Im working on a feature that will enable basic-auth in front of it also, so at least a password would be required to send traffic to your local machine, if you wanted. Good for the "share your work" sort of scenarios.
tl;dr if you want any-subdomain.your-domain.com -> localhost:port, and you use AWS, try https://github.com/nelsonenzo/tolocal
For this particular feature I like my own home rolled solution where I automated the process of spinning up a tiny ec2 server with an nginx proxy to a reverse ssh tunnel that goes back to my local machine. It gets a letsencrypt cert and modifies the route53 dns. All managed with a cli command and config file.
The other benefit is that it is completely unthrottled, which is particularly useful if your debugging some stupidly large react/vue website.
Im working on a feature that will enable basic-auth in front of it also, so at least a password would be required to send traffic to your local machine, if you wanted. Good for the "share your work" sort of scenarios.
tl;dr if you want any-subdomain.your-domain.com -> localhost:port, and you use AWS, try https://github.com/nelsonenzo/tolocal
If you're having fun, don't let me stop you, but there are tons of open source projects to simplify this process: https://github.com/anderspitman/awesome-tunneling
Cool list, thanks for sharing.
Unfortunately none of those solutions are self hosted AND automated. They all seem to either use their own ifra, which will be slow & throttled, or require setting up a server and manually editing DNS.
I may try to get my own project added to that list though, so thanks for sharing!
Unfortunately none of those solutions are self hosted AND automated. They all seem to either use their own ifra, which will be slow & throttled, or require setting up a server and manually editing DNS.
I may try to get my own project added to that list though, so thanks for sharing!
We've done a lot of work on "self-hosted AND automated"
inletsctl - automates a VM with the inlets tunnel server preinstalled, including with HTTPS termination with Let's Encrypt, or pure TCP pass-through
inlets-operator - the same for Kubernetes Load Balancer services
Feel free to take a look at https://inlets.dev/
We talk a lot about the community adoption here in the first half -https://inlets.dev/blog/2022/11/16/service-provider-uplinks....
(I'm the original founder of inlets)
inletsctl - automates a VM with the inlets tunnel server preinstalled, including with HTTPS termination with Let's Encrypt, or pure TCP pass-through
inlets-operator - the same for Kubernetes Load Balancer services
Feel free to take a look at https://inlets.dev/
We talk a lot about the community adoption here in the first half -https://inlets.dev/blog/2022/11/16/service-provider-uplinks....
(I'm the original founder of inlets)
Well, yeah - For a minimum of $20/month just for the personal license!?! and THEN I need to still pay for my own infrastructure, AND run all the setup, etc.
mine is free and as easy as 1,2,3:
npm i -g tolocal
tolocal config -> answer the 3-4 questions about domain, vpc, etc.
tolocal apply. -> tunnel will come up to my own custom domain.
mine is free and as easy as 1,2,3:
npm i -g tolocal
tolocal config -> answer the 3-4 questions about domain, vpc, etc.
tolocal apply. -> tunnel will come up to my own custom domain.
[deleted]
So this is just a Wireguard wrapper with a shiny UI? Why is this so hyped?
Because it’s not the basic Wireguard part itself that’s hard, it’s the synchronized keys, NAT busting, ACLs, and other things on top of it that are. Tailscale has made it incredibly easy to deploy and use confidently and that’s why people are happy.
So offloading a critical part of your infrastructure to a $5/mo service is a good idea now?
Given the immense trust I have for the names behind Tailscale, sure. I don’t run my own data centers, either, so it is a sound business decision to offload this too.
To a novice, how else would you do it?
Ie i can self host most of this, but wouldn't i be hosting it on literally a $5mo VPS with a static IP to work around my homes dynamic IP?
Ie i can self host most of this, but wouldn't i be hosting it on literally a $5mo VPS with a static IP to work around my homes dynamic IP?
...yes?
You're already offloading critical parts of your infrastructure anyway.
You're already offloading critical parts of your infrastructure anyway.
welcome to 2010
Your comment has strong "what does Dropbox do that curlftpfs doesn't?" energy.
curlftpfs offers more with less bloat?
You discount enormously the value of good UI and UX.
Yes, a good UI is product, and people are prepared to pay for that.
Yes, a good UI is product, and people are prepared to pay for that.
For exactly the same reason that Dropbox was just "rsync with a shiny UI" and was very popular.
It's less about the UI and more that Tailscale takes care of setting up wireguard connections between every machine that needs them, along with the authentication and access control. All of which ends up with a simple network between your devices that doesn't have to worry about physical location and intervening network infrastructure.
It's less about the UI and more that Tailscale takes care of setting up wireguard connections between every machine that needs them, along with the authentication and access control. All of which ends up with a simple network between your devices that doesn't have to worry about physical location and intervening network infrastructure.
Usually people are pretty critical/cynical of sending sensitive data to a closed source third party server, no matter how strong their claims of 'being the good guys' are (eg see Telegram).
But somehow we're all meant to be happy giving full control of our entire network to a commercial company running a closed source command and control server?