Tailscale is pretty useful
blog.6nok.org
blog.6nok.org
IMO the main outstanding questions/concerns are:
* Is the VPN model really the way to go? If someone gets their hands on one of your Tailscale nodes, they can access every service on your tailnet, which are likely running with reduced security since that's a huge part of the appeal. This is exactly the situation BeyondCorps/Zero Trust was created to avoid. Tunneling services[0] are more of a Zero Trust approach, but they can't match the seamlessness of Tailscale once a node is connected to the tailnet.
* Can it expand into the layman market? I wonder if the average person will ever be willing to install a VPN app on all their devices. On the flipside, I could see TS partnering with someone like Google to integrate TS tightly with Android and set up a private network between all your Google-signed-in devices.
* The relay system - DERP is nice, but it's primarily intended for signaling/fallback. It feels like CGNAT adoption is growing faster than IPv6 is, and I wouldn't be surprised if fewer and fewer p2p connections succeed over time[1]. DERP forces everything over a single TCP connection (HOL blocking), and I'm not sure it even has any flow control.
* Use in web browsers - They got a demo of this working, but it's pretty involved. You have to compile the entire Tailscale Golang library to WebAssembly which is a large artifact, and it's DERP-exclusive.
* Portability in general - Depending on WireGuard, as awesome as it is, is fairly limiting. You either need admin privileges to create the TUN device, or you need to run an entire TCP stack in userspace alongside your own WireGuard implementation. I'd be interested to see something like Tailscale implemented on top of WebTransport.
It basically works by tagging machines (especially those deployed with an API key) and grouping users. Then you set up rules which allow groups and tags can communicate with each other on specific ports. Since the default rule is DENY, you only need to specify rules for communication you actually want to allow.
For instance you would create a tag for `servers` and a group for `sre`. Then you setup an ACL rule like this to allow SRE to ssh into servers:
"action": "accept",
"src": ["group:sre"],
"dst": ["tag:server:22"]
The tailscale docs are really good. And the videos they have are a great starting point if you dont come from a networking background.
At the very least there's ACLs so you can tag devices and restrict access down to specific ports and protocols based on either user identity or device tag.
At my org we use tailscale much like a VPN, to give users access to a few internal web apps, and with ACLs those users can only hit the webserver on 443 and nothing else to that node. This way the web server itself has no ports exposed on the host, ufw deny all incoming.
I can't answer if the VPN model is really the way to go, long term - probably not, but for our use case Tailscale has been absolutely perfect, and we accepted the tradeoffs were worth it over a more "complete" zero-trust approach, and the complexities that come along with it.
What Tailscale doesn't solve is access to the data that web app serves if the user's machine is compromised, as tailscale is just determining "can the user hit the webserver on port 443?" and does nothing to evaluate the state of the user's host.
I guess that's all to say, I/we don't see Tailscale as a zero-trust solution, but more or less a more convenient VPN with easier to use ACLs. Cloudflare Tunnel and the likes are much better suited to implementing a zero trust approach.
I think there's still value though. A zero trust approach is the correct way for most organizations, but there's still a big niche for Tailscale especially for small-medium orgs and self-hosters/homelabbers.
This is the main reason I use a mesh vpn (though not tailscale)
Tailscale has some cybersecurity integrations to configure access depending on the device posture. For example, blocking access to a webserver if the device is out of date, or if malware is detected, or if the firewall is disabled, etc. But I don't use any of those integrations and can't speak to them.
The same posture API can be used to restrict access to devices in your inventory or to set up just-in-time access to a sensitive asset. For the latter, you can use a Slack app provided by Tailscale or integrate with an identity governance workflow to set a posture attribute with a limited TTL. Your tailscale policy just needs to condition the relevant access on the attribute.
I use Tailscale - so I can do remote tech support on my 81 year old mother’s computer
- So I can remote in to my desktop from anywhere with my mobile phone or iPad or Vision Pro or Steam Deck if I need a file or need to print something
- watching streaming media from my home network when I’m travelling (and avoiding VPN blocks because my home computer isn’t on a known VPN network)
And the best part is none of this required almost any configuration beyond (a) installing the software, (b) checking the “allow exit node” box on my home computer, (c) sharing my mom’s computer onto my tailnet.
It really is just useful with minimal fuss.
Perhaps the AI age makes everyone more data privacy conscious.
I've also long thought that eventually every household will eventually have a mini server for home automation and storing personal information. The rise of the cloud kinda slowed this down, but I don't think cloud and home server are mutually exclusive.
Maybe a NAS that comes with Jellyfin and Immich pre-installed? But that still leaves the problem of content...
Is it because lot of people are just using a VPN as a proxy replacement, watering down the original meaning of the word?
Yes. The question was about a “mainstream consumer”. While “mainstream” is always a moving target, today (in March 2025) that mainstream consumer believes that a VPN == NordVPN == ExpressVPN == what we call/know as a proxy.
NordVPN added some mesh features and you can CTRL-F this thread to find a confused person asking “how is tailscale different than Nord?”
What's app do you use to browse data on your desktop?
I use VPN (usually Tailscale, though I have the Proton subscription package that includes their VPN - mainly useful if for some reason my home internet is slow or out, otherwise I would just TS it) on all public WiFi. My work's remote access blocks logins from outside the US, so if I'm out of the country, my wife and I both need VPN to be able to log in.
Interestingly, while my work's network blocks Tailscale's initial authentication, it doesn't actually block the traffic. I can authenticate my iPad via cell phone tethering or just before I leave the house and it will work when I connect to their network. It's a personal device without any access to their internal network, and I'm using the guest network, so I'm not compromising security to actual work devices. But when I'm stuck up there and I want to stream a movie from my NAS at home, I can.
I still think VPN has a good usecase. It's great extra layer of defense and also a nice way to disclose access to devices at different locations.
I don't use tailscale as it's too commercial for me but I use another VPN mesh service. Of course you still need to secure your endpoints properly.
Maybe it's more enthusiast than layman, and I guess it's also not much of a market, but in the video arrrchival space it's pretty widespread, with people running e.g. Jellyfin behind Tailscale.
1. If you actually need strong security, you are likely to go with open source zero trust or their commercial versions.
2. If you don't need strong security, you will often view VPN an insurance policy (TS simplifies but is still more difficult than 'do nothing').
So you end up with a relatively narrow band of 'use cases' like NAT traversal; semi-privacy; access to private IP hosted services. Enough to sustain a venture funded company?
> set up a private network between all your ~~Google-signed-in~~ devices.
One big issue is Apple, who doesn't seem to respect DNS and VPNs, especially local network access... the other aspect is that it makes some ssh automation annoying because they will change things, such as getting the name of the current ssid (wtf?!). So I can't just make a conditional in my config to go through TS instead of local network based on that
Tailscale can do hairpinning, so you may find you don't need a conditional config.
Though part of my gripe is just not having this in general. I can want to work on a certain machine I don't open and if I'm on an internal network but if external I want to do a proxy jump. The ssid is the most obvious and consistent way to determine this, at least to me. Anyone got another idea?
I'm mostly concerned about whether the DERP protocol can scale in that way.
I suspect it'll be more complicated than a flat subscription, which is unfortunate. I think it'll be a combination of bytes and number of connections.
I run it on my router, providing access to the entire subnet, so it doesn't have to be all your devices.
And configuring a router also isn't something most people can/will do.
In addition to the ACLs mentioned by the sibling, a tailnet is not quite a plain-old VPN overlay network, in that each device on a tailnet gets assigned a predictable, durable LAN IP address based on the credentials that device is logged into Tailscale with.
Which means that, for at least the "personal" devices (laptops, phones, tablets), you can configure your servers on a tailnet to do something that's less finicky than full-on credential-based auth, but still more secure in practice than no auth: namely, host-based authentication — which should be a reasonable 1:1 proxy for user authentication (assuming the constraints from the previous paragraph.)
To put that in concrete terms: on a tailnet, a user's SSH credential for a given server can simply be the fact that the user is able to originate the connection from the expected LAN IP address of the user's workstation. Except that instead of that LAN + the user's workstation living in a physical building, they're both virtual, and the user's physical workstation (of the moment) must provide credentials to bind to the tailnet IP that allows it to present itself as the virtual workstation.
Of course the average person will be willing to install a VPN app: all it takes is a bit of internet censorship, blocking access to their favourite services, and some geofencing, where services limit access to them based on IP address.
Just ask people from China, Russia, Ukraine, Turkey, UK, Germany, etc.
When you use services like NordVPN, Mullvad, Surfshark, etc., you're just installing a VPN client, and you're basically just using them as a reverse proxy to hide your IP address (present it as coming from another country). That is the use case you are talking about.
Tailscale is very different. It is about setting up your own VPN so that you can access devices from your home or wherever from the Internet at large in a secure manner.
Tor exists and is far better at providing privacy.
Does that matter? It still shows willingness to install.
Just look at the US - tons of people now install a VPN app like Nord or Mullvad to get around state-level porn blocks. In other countries it's to get around other types of censorship. And to install those apps on something like a phone or laptop is trivially easy.
The use cases for installing Tailscale (I need a home network and I need to be able to access these devices from the Internet) is, I would guess, ~5% compared to the other VPN use case. I'm a software developer, and I don't need it.
Directly answering your concerns:
- Deny by default and least privilege model means getting access to a node does not give you access to all services on the overlay. This includes SDKs so that only embedded apps are authorised, the apps have no listening ports on underlay and are literally unattackable via conventional IP-based tooling, all conventional network threats are immediately useless.
- Its open source nature means its being adopted by companies to create more powerful ecosystems.
- The overlay, while looking similar to DERP, uses individual service encryption and routing with flow control and smart routing (I know people who get much much better performance as a result).
- Our SDK includes a 'clientless' endpoint for the browser called BrowZer - https://blog.openziti.io/introducing-openziti-browzer. All users need to do it log into their IdP and everything else is done automatically, without involvement from the user.
- We don't build on Wireguard, which provides much more flexibility.
What does it do better/worse, and are the use cases different?
Similarities: - Fully open source, using CAs as strong identities (rather than relying on SSO from third parties), completely self-hosted (with 3rd party SaaS options), and providing scalable, performant overlay networking.
Differences:
- OpenZiti is focused on connecting services based on zero trust principles. In contrast, Nebula focuses on connecting machines – e.g., you can authorize only a single port without needing to set up ACLs or firewall rules.
- OpenZiti does not require inbound ports or hole punching, it builds outbound only connections via an overlay which looks sort of similar to DERP (but better with app specific encryption, routing, flow control, smart routing etc). This overlay also removes need for complex FW rules, ACLs, public DNS, L4 loadbalancers, etc.
- As alluded to above, truly private, zero trust DNS entries with unique naming – if you wanted to call your service "my.secret.service", you can do that; it does not force you to have a valid Top Level Domain.
- OpenZiti includes SDKs (along with appliance or host based tunnels) to bring overlay networking and zero trust principles directly into your application.
- FOSS Nebula does not include "provisioning new clients with identities", as this person pointed out in our public forum - https://openziti.discourse.group/t/using-openziti-in-distrib...
What's your funding model? Are enterprises willing to sponsor the development?
I think Nebula has a lot of trust solely because it's made at/used by Slack. In a similar sense, why should enterprises trust OpenZiti? If services do not use e2ee (e.g. service mesh with TLS) but rely on OpenZiti, it places a lot of trust in OpenZiti. How has the code been audited? Why are you confident that it's cryptographic implementation is secure?
We are not rolling our own crypto, we use well vetted open source standards/implementations - https://openziti.io/docs/learn/core-concepts/security/connec.... If you don't trust that, you can easily roll your own - https://github.com/openziti/tlsuv/blob/main/README.md. I know people who do that. Yes, its been audited, and run my many large enterprises in security conscious use cases - e.g., 8 of the 10 largest banks, some of the largest defence contractors, leaders in ICS/OT automation as well as grid etc.
Yes, we support K8S in a lot of ways, both for tunnelling and deployement - https://openziti.io/docs/reference/tunnelers/kubernetes/. There are more native options being worked on incl. Admission Controller and Ingress Controller but I honestly don't know the exact status of either. If they interest you, feel free to ping me on philip.griffiths@netfoundry.io. I can get more info.
In my opinion, Kubernetes networking is flawed, in that service mesh authentication with mTLS has unnecessary overhead, Cilium network policies are clumsy using labels and work poorly with non-pod workloads (i.e. CIDR-based policies), multi-cluster is hacky, and external workloads are inconvenient to set up. So a simple plug-and-play solution that solves these problems would be great.
I agree with a lot of what you say. Tbh, this is also why we are advocates of app-embedded ZTNA. You get mTLS (and way, way more) out of the box, without the overhead, and its super easy to run your K8S or non-K8s workloads anywhere. No need for VPNs, inbound FW ports, complex ACLs, L4 loadbalancers, public DNS and more. It is thus much easier to build distributed systems which are secure by default from network attacks.
TL:DR, we believe service meshes introduce complexity with control plane synchronization, service discovery challenges, and network overlays. A Global Overlay removes Kubernetes service dependencies and shifting networking to a Zero Trust, software-defined global overlay which is much simpler, automated and secure.
Super curious to get your thoughts.
> In a similar sense, why should enterprises trust OpenZiti?
you don't have to. It's open source - so you go look at all the code and judge for yourself but perhaps better than that (well different anyway) is that OpenZiti allows you to use your own PKI for identities if youlike. With third-party CA support, you can make your own key/cert and deploy them to identities if you desire. https://openziti.io/docs/learn/core-concepts/pki/#third-part...
> If services do not use e2ee
with OpenZiti you basically get this by default between OpenZiti clients. (once offloaded from the OpenZiti overlay, it's up to the underlying transport protocol)
The routers that you deploy to make up the overlay still need inbound ports though, right? I thought that's what 10080 was doing.
- (1) need to bypass the mTLS requirement necessary to connect to the data plane (note, each hope is uses its own mTLS with its own, separate key).
- (2) have a strong identity that authorizes them to connect to the remote service in question (or bypass the authentication layer the controller provides through exploits; note again, each app uses separate and distinct E2EE, routing, and keys)
- (3) know what the remote service name is, allowing the data to target the correct service (not easy as OpenZiti has its own private DNS that does not need to comply to TLDs)
- (4) bypass whatever "application layer" security is also applied at the service (ssh, https, oauth, whatever)
- (5) know how to negotiate the end to end encrypted tunnel to the 'far' identity
So yes, if they can do all that, then they'd definitely be able to attack that remote service. Note, they only have access to 1 single service among hundreds, thousands, or potentially millions of services. Lateral movement is no possible. So the attacker would have to repeat each of the 5 steps for every service.
A colleague wrote this too, its from a slightly different angle but still very relevant - https://blog.openziti.io/no-listening-ports.
How does this choice affect performance and CPU utilization? Wireguard is known for providing good network performance with low resources.
I think the concept of making a simple SDK for embedding tunneling in apps is unique and very compelling.
However, for me to commit to a platform like that, the most important question is: if upstream changes their license, runs out of money, or just generally takes things in a direction I don't like, what are my options?
Ideally, the platform would be so simple that I can just fork it myself or with a small team without too much effort. The best way to create a platform like this is to build around simple, open protocols. I've never gotten the feeling OpenZiti is designed this way. I've never found any documentation on the network protocol. Your platform also offers many features I don't need, which makes it even higher risk to consider forking.
Note that I'm not trying to say you're doing something wrong. I'm not aware of any tunneling platform that provides this, which is why I'm currently building one myself (a successor to boringproxy).
I get the feeling OpenZiti is rather enterprise focused. And that makes sense, it's almost certainly where all the money is. I really hope you guys are able to prove the value of app-embedded tunneling.
But I'm looking for a very simple consumer product/platform.
- Agreed. OpenZiti is not trying to focus on indie hosts. It has the goal to completely transform how networking and connectivity are done, to make secure by default and a simple user experience the de facto standard.
- Our path to do this definitely depends on monetising enterprise rather than indiehosters. That said, you can build abstractions on OpenZiti, which are much more simple and focused on indie hosters. A good example is zrok (https://zrok.io/), which makes sharing super simple (publicly, privately, and more), and is built on OpenZiti. Likewise, it's FOSS and permissively licensed under Apache 2.0 while also having a free SaaS.
- Likewise, we truly do believe in the power of app-embedded to transform networking and connectivity, but I would note the majority of people (self-hosters and enterprises alike) today use it as a superior private connectivity platform rather than for the app-embedded. They may use the SDKs, or consider it in the future, but the main selling point is the power of the platform, making it dead simple to do private connectivity across networks while abstracting away a lot of complexity (no need for VPNs, SDWAN, inbound ports, complex ACLs, L4 load balancers, public DNS, etc).
Maintainer here so I'm gonna be biased with this hot take, but I really don't agree with this particular sentiment.
I would turn it around instead and say that most indie hosters are maybe not looking for the levels of protection a zero trust overlay network provides. That is a believable reason for me why it might be perceived as not a good fit. If you're not looking for the sort of security that OpenZiti affords the operator, it will certainly feel less of a fit than a classic VPN-like solution. It also focuses on a different paradigm wrt connectivity centered around individual services. That does mean the learning curve is absolutely steeper because it's not "just IP" and all our years of ip-based-know-how are useful, but not to make the most of the system. While one can use IP/L3/L4 just fine with OpenZiti, it's certainly not trying to be an IP-based VPN (like many of the other solutions are). That also might lead to feeling like it's not a great fit.
For the people who want the sort of security OpenZiti provides, however. It really is an easy-to-use (my bias showing) solution that plenty of indie hosters use already. :)
Not trying to sound too defensive here (a little is ok, right?) but I also appreciate the comments and feedback, thank you!
https://github.com/tailscale/ts-browser-ext
super experimental but really cool
1. Maintaining high availability
2. Dealing with patches/upgrades
But I'm also really curious how likely a self-hosted instance is to be an attack vector potentially more dangerous than using something like Tailscale.
In my experience as a poor sysadmin (as in, bad), you don't /need/ HA for Headscale because the clients are pretty resilient. I've had my instance go down for a little bit and it's fine. Stale and new connections aren't, obviously, but it will work well enough that you won't realize Headscale itself has gone down until a while after it did.
So while also implementing Tailnet locks and other security measures to constrict traffic flow, I'd also consider going a step further by only permitting server or resource access based on client certificate validation (in other words, a client that's missing a trusted certificate is rejected from even attempting to initiate AuthN); that way even if your Tailscale network is compromised somehow, untrusted clients and endpoints can't make inroads into your infrastructure as easily.
Is that a gigantic PITA to implement? Oh heck, you betcha it is, and I doubt 99% of folks need to go that far with their homelabs or home services. Still, that'd be my approach to zero trust - trusting Tailscale only so far as enabling virtual networking, but not blindly trusting traffic coming over that network at any point.
There is slacks nebula and other options that are completely self-hosted from the start.
Feels like such a weird hype around tailscale.
Tailscale is an excellent piece of software, provided it's implemented in a way to emphasize security, and not weaken it. In OPs case, being used as an accessibility aide to a system that couldn't be secured any other way while preserving external access (in their case due to CGNAT) was an excellent use of Tailscale.
I do think this simplicity is exactly what contributes to those weird and non-standard configurations.
This is why I am confident I will always have employment in IT. As I make things simpler for others to use, they in turn will find new and innovative ways of making my eyes bleed from cursed workflows that once again require professional intervention for simplicity, efficiency, and security.
Tailscale is based on Wire Guard, isn’t it? Now there’s a piece of software that truly made VPNs simple. I have a tunnel back into my LAN by way of an EC2 instance and all it took was two super simple config files on each machine.
Tailscale simplifies: authentication (including OIDC), authorization (via ACLs), DNS, NAT piercing. All of that is not obvious or easy for someone without deeper expertise.
Of course there are tons of alternatives even if you are behind CGNAT. Nebula is but one.
Imo they don't charge all that much relative to their value, depending on who you're asking.
You emphatically cannot trust vendors, suppliers, users, software, systems, or governments. Ergo, your infrastructure should be built with an appropriate risk assessment in mind, and have proper safeguards in place where feasible. That's just good OpSec.
This stuff was obvious and standard in the 80s-2000s. It’s only in the last 15-20 years that it became acceptable to get updates shoved down your throat.
Service providers can cut off your access any day.
Software providers cannot unless you’ve given them a live update channel direct to your env.
I use my own self-hosted Wireguard VPN server. I agree with a lot of what you were saying about client certificates etc. And I plan to eventually do that sort of thing on some of my services in my own Wireguard VPN too.
But in terms of Tailscale, if you are going to set up all kinds of client certificate things that will take a lot of time and effort, why not self-host Wireguard also?
Setting up a Wireguard server is super simple. The only couple of things that complicate it a tiny bit is opening up a port for it for inbound connections if you host it from your home connection rather than a rented server, and managing the Wireguard public keys that are allowed to connect.
But if you are going to do a whole client certificate setup on top anyway, the work of setting up your own Wireguard VPN is small in comparison.
Unless like OP your ISP has put CGNAT on you.
Already do! I tried Tailscale initially, but ultimately decided to put in the effort of a proper Wireguard setup. It's how my personal devices always get back to my home LAN, and then exit to the internet; it's also how I make sure every DNS lookup hits the Pi-Hole, for domain blocking wherever I am.
I emphatically recommend learning WireGuard (and to a lesser degree, VPN Concentration) when practical and possible. Until then, Tailscale is an excellent product.
I run Wireguard on a VPS and route public traffic with it over Wireguard to my home machine.
Are you saying my ISP must not be CGNAT or else it wouldn't work?
Tailscale addressed those issues.
It’s encrypted from client to VPS, then from VPS to home. The VPS sees the traffic inside of tunnel. That’s the first problem.
See earlier in the comment where I said:
> opening up a port for it for inbound connections if you host it from your home connection rather than a rented server
Although I can see how it might not be clear that in the end where I’m mentioning CGNAT I am still specifically talking about hosting the VPN server from your home connection.
That's not what Zero Trust means, at all.
That being said, the core concept of ZTA is that no user or device should be trusted by default. So yes, my statement is still generally correct even if it’s not how the term is often or commonly used.
This is where I'm the most curious on what Tailscale will do next. So far all their products seem to contrast at the IP level, but for enterprise use cases there's a real need for application level protections as well. Cloudflare Access is a great example of what I mean.
We took the opposite approach with NetFoundry. (1) We open sourced the code (https://openziti.io/), (2) we built in PKI with private keys generated at source and destination so that even if traversing NF hosted data plane, we CANNOT decrypt traffic, (3) mTLS everywhere, (4) ability to bring your own PKI, and more.
Can you clarify?
Even if an attacker such as the government runs the coordination and relay servers, and the IdP, they will not be able to decrypt any traffic in tailnet.
The secret keys remain on device, and traffic is end to end encrypted. There is no mechanism in the client agents to send out the secret keys. The coordination server receives the public keys and metadata.
Please clarify or revise your comment!
edit: okay, CGNAT
Not just CGNAT but not having _any_ external ports open can be a beautiful thing. I used to have an ssh port (not on the standard 22) and the amount of auth attempts back then was insane. I now have a full firewall zero open ports but, thanks to tailscale, I can still safely access my machines while not being at home with zero unauthorized attempts.
And since I am a security person, I use the tailscale lock feature so not even tailscale themselves can add nodes to my network. Even if they had a breach.
I am a very happy customer.
See xz vulnerability for more details. It’s about not trusting people with any of my ports/software (directly).
> I use the tailscale lock feature so not even tailscale themselves can add nodes to my network.
Also, it seems their infrastructure runs on AWS, not exactly confidence inspiring from a censorship/privacy risk standpoint.
I think tailscale also doesn't provide transient quantum resistance. Wireguard traffic can be made quantum resistant with a PSK. I fail to see why one would use Tailscale over just wireguard other than for "convenience" reasons which are almost never good reasons if security and privacy also matter. Please correct me if I'm wrong with anything, I'm happy to learn.
I do verify every node’s key. That’s kind of the point of tailscale lock unless I am missing something.
> Also, it seems their infrastructure runs on AWS, not exactly confidence inspiring from a censorship/privacy risk standpoint.
I don’t understand what censorship has to do with a personal home network?
Privacy on the other hand, is fair. For my usecase this is a home network I am not that concerned that they know what devices talk to what devices. Yes they know my ip address but that’s not valuable since it’s all defended by the tailnet lock.
> I fail to see why one would use Tailscale over just wireguard other than for "convenience" reasons which are almost never good reasons if security and privacy also matter. Please correct me if I'm wrong with anything, I'm happy to learn. Direct access to my network being limited behind tailscale with a requirement to be part of my tailscale network signature satisfies my requirements for no one else’s access to my network at all. And only if I am away from home does any of my traffic pass through a relay.
Tailscale has more device support than any wireguard apps than I know of. I don’t believe wireguard has Apple TV support, but tailscale does.
I am not the only member of my family either, including them in this network with the simplicity of tailscale’s apps is also important.
I mean, yeah, if you unfortunately have to deal with CGNAT, then you gotta do what you gotta do. But other than that, what's the issue with self-hosting Wireguard?
User simplicity. I am not the only one on my home network which I want to be able to access some parts of the things I build.
Device support. I appreciate that tailscale has gone out of their way to bring tailscale to even more devices than even wireguard supports. Namely apple tv, wireguard does support iOS but doesn't seem to currently support apple tv or maybe just my version of apple tv.
I do have enough trust in their client that's installed on my machine to believe that it's not actively malicious. I do trust that I can find my other devices, and trust tailscale to keep a list of them, and not randomly add other devices that I don't know, but I don't have perfect trust of that. All my internal services are still E2E encrypted over the Wireguard link; They run HTTPS with an internal cert authority. There's not ports open on them that shouldn't be, and while it's possible that one of them still gets popped, it's much less likely.
I basically just see Tailscale as an auth paradigm for managing wireguard keys.
Just hypothetically, what if an intelligence service records your encrypted traffic and also happened to get AWS to mitm your communication with the tailscale key distribution server?
Doesn't really matter if most of your traffic doesn't use their infrastructure if the most important parts of it do.
https://tailscale.com/compare/wireguard
My understanding is that (in theory) the only way this is possible is if the attacker introduces a new node and then connected to other nodes that are in the tailnet. What you're suggesting is that a single node that is connected to the other nodes gets compromised, but this isn't possible without already being able to compromise that specific node. Alternatively, if someone hacks Tailscale itself, the only way they could get access to any nodes would be to add their own node, but if you have alerting set up you would know and you could shut down the attacker.
Everything on my home network is set up as if it were public-facing.
That's Wireguard, I have the same, just Wireguard + VPS, everything I want available that is. I don't put every PC on my home network on the VPN, I could though, pretty easily.
By "as if it were public facing" I assume you mean locked down as much as possible using either router or host-based firewall rules?
Let me explain what I mean by low maintenance...
I was a very early containerization adopter and set up a company and also my home network using Docker around 10 years ago. I chose Docker because I thought it was reasonably polished and was the future of deployment. Even though the landscape keeps moving with changes in Kubernetes, Helm, Rancher and stuff like that, the actual Docker part hasn't changed in 10+ years so I haven't had to change my setup for a decade. Low maintenance for me is software that can be left mostly untouched (except for minor updates) for a long time and I judge that based on the project's future, which for me is partly judged from a project's polish.
Every time I tried WireGuard in the past, it didn't seem so polished. I don't want to waste time learning something that could go away. On the other hand, not only did Tailscale look pretty well set up, it was pretty much click and run which means that even if it were to fail, I would have not lost any time learning much about it.
So low maintenance for me is "get the most out of as little work as possible" and choosing Tailscale was the decision to achieve that. So given that I've been using Tailscale for 1.5 years with near 0 amount of configuration and so far, no real downtime, it is adequately low maintenance.
Instead, I have a VM running on a cloud provider that I SSH to from an OpenBSD box inside my home network. The SSH connection establishes a reverse SSH tunnel. This opens a port on the cloud VM to tunnel to my OpenBSD sshd port.
With the reverse proxy to my home OpenBSD box established, I can use the SSH jump box option, -J. I connect to the cloud VM and "jump" through the tunnel to the OpenBSD box at home. You can even specify multiple jumps if I need to connect to another machine in my home.
I can also set up a local tunnel through that jump for things like connecting to my Home Assistant server from my remote laptop or phone.
I only have to trust my cloud provider.
My use case for tailscale: have an SSH (or other) connection to my home server while working from home. Drive to a coffee shop, register on their network, and continue using the same connection. (Or hotspot, if I'm somewhere without Wifi.)
The IP address of my server does not change. When at home, the packets do not leave my home network. When out and about, they do.
It's magic to me. I set up a sophisticated (read: overkill) SSH tunneling setup previously, using Match rules in .ssh/config to autodetect the network I was on so that `ssh myserver` would always go via the correct route. But my connections were still interrupted broke when I switched, and I'm not good enough at networking to do any better.
(I guess this is what Wireguard is for? I could access my server via a fixed IP address on my machine that goes to a tun device, and that would send the packets to the actual server if nearby otherwise hand off to the carrier pigeons? Is that what the tailnet is doing? I don't understand how packets get intercepted by tailscaled, though I do see a tailscale0 device. Is that just a vanity license plate version of tun0? Why does `ip route show` give me only routes through my actual devices, then? Never mind, this isn't a helpdesk. I'm just getting old and stupid, I think.)
The tunnel is on localhost only. The VM has a static IPv4/IPv6 with DNS.
Connecting the SSH tunnel from my home is stable as well as connecting to the VM remotely.
I do appreciate Tailscale and Wireguard. I was more responding to the fact that I don't have to trust any provider here, other than the one keeping my VM running.
Also, there's tmux for preserving sessions.
Their golink project [2] is a good example (and useful itself), but I've used it to build "peer to peer" comms for one application, and to host an API and Svelte SPA to control some other things in a tailnet.
I pulled tsnet out of my go application and switched entirely to `tailscale serve` and just use the header that adds to auth my family into apps I write. I love it.
I had some issues with builds every once in a while, which is another reason I switched to using tailscale serve instead.
Tunnelling into my home machine I was able to access the account and transfer money I needed.
Sure a VPN might be able to do this too but it’s nice being able to exit via a connection you control.
I can also watch Plex movies without exposing ports.
Honestly I would suggest wireguard on your router before openvpn.
https://tailscale.com/kb/1097/install-opnsense
I'm not sure about the performance yet, however.
Without a laptop handy, I had to use my iPhone to set up a droplet running Ubuntu, then install vray onto it and configure it to run on port 443. vray uses "standard" SSL to tunnel connections, so to DPI it just looks like normal HTTPS traffic and I was able to pass traffic through the firewall when I needed to access something that was blocked. It makes me wonder if TailScale would also bypass their analysis, or if it would be blocked as well.
(I didn't abuse this to the detriment of the network, and I did pay for the "streaming package" on sea days when I had a lot of traffic to run)
I haven't actually tried this when my home service is down, because it's basically never down, but I can easily switch exit nodes when they are both running without hitting the authentication servers again.
I can understand the work network policy, someone could use Tailscale to leak data, but a residential ISP should not block it. I would rather bother their support for an incomplete service.
Tailscale doesn't really address connecting to strangers, though.
Also, it's old but not 90s old: https://swapped.cc/#!/hamachi released in 2004 actually.
This allowed us to play Warcraft II with random strangers: RTS games over the Internet... Felt like the future!
What Tailscale does is difficult to do with Wireguard: Easy VPN, SSO with MFA, key distribution, static private IP for each node, peer to peer direct connectivity, split tunneling, fine grained access control rules down to per port and application, Wireguard over TCP, NAT transversal for devices behind firewall, central management, sharing nodes with others, DNS, file sending, routing rules (with exit nodes, subnet routers, “via”), key rotation, …
Wireguard connects peer A to peer B, and its simplicity stops there.
I found Tailscale to be a very good tool, that I extensively use.
My only concern is: what happens if their infrastructure is compromised at some point, like Okta’s? Assuming I have tail lock enabled.
It's completely OSS, just like the Android & Linux clients.
My main gripe, though, is DNS. It’s great to be able to reach prod-db-1, prod-db-2, and prod-db-3, tag them as „db“ and create a rule to allow TCP on db:5432. however, it’s annoying that all of this is supported, but not the obvious extension - DNS records for the tags, so I can point apps to a group of servers belonging to the same tag.
db. IN A 100.64.123.1 # prod-db-1.
db. IN A 100.64.123.2 # prod-db-2.
db. IN A 100.64.123.3 # prod-db-3.
In a usual setup, the problem is that if a host goes down, clients will still try to reach it because it's still in the DNS record; but with Tailscale, the "DNS" is generated by the local Tailscale daemon on the fly, so you get a live view, and if this was implemented, it would be possible to only return available servers for tag queries.
Since people typically don’t believe me about this, here it is from someone who has done a lot of networking programming:
https://daniel.haxx.se/blog/2012/01/03/getaddrinfo-with-roun...
Thanks, I didn't know this!
"This Deployment is paused by the owner.
Your connection is working correctly.
Vercel is working correctly."
I'm terrified using a service like Vercel because I heard about the massive cost trap that can hit you hard and I don't know if there is any alternative for (easily & quickly) hosting NextJS apps.
* It's not reliant on port forwarding at your firewall
* It can get around bad ISP habits, like CGNAT or a lack of IPv6 (or IPv4)
* As the OP points out, it's broadly compatible with various forms of exit nodes
Straightforward and to-the-point. Great writeup.
The Tailscale k8s operator is also great.
I have a bluetooth gateway (Cassia X1000) in my workshop where I normally develop. I was at home doing some Android work at one point rather than at the workshop and needed to test some new Cassia functionality.
Tailscale exit node in the workshop.
Tailscale client on my linux dev laptop at home.
Started up the android emulator via Android Studio, connected to the Cassia via the app being debugged, debugged what I needed to, shipped it.
At the time it seemed like actual magic had happened.
Does Tailscale have features that set it apart now that other VPNs have gotten the private mesh thing down pretty well?
Also, ZeroTier is "open-source ish." They use the BSL license for most of their code (https://www.zerotier.com/blog/on-the-gpl-to-bsl-transition/) and I believe you can self-host (https://docs.zerotier.com/selfhost/)
My one objection to Nebula is that its Android app is proprietary, and your response is to plug the even more proprietary way to run it?
> Also, ZeroTier is "open-source ish."
So it's not FOSS.
Best of luck in your search! Maybe take a look at Tinc or Yggdrasil.
> The Business Source License (this document, or the “License”) is not an Open Source license.
I'm gonna take them at their word.
> Best of luck in your search! Maybe take a look at Tinc or Yggdrasil.
I did, but thanks:)
I also tried ZeroTier and was extremely unimpressed, although again that was a few years ago. The performance on single threaded systems was absolutely terrible, which suggests some deeply broken code and made it unusable with a cheap VPS. The paceof development was also pretty slow and the insistence on homebrew crypto was also not confidence inspiring compared to something that used a proven solution like Wireguard.
That said, I can totally see where a less DIY solution. VPNs fundamentally aren’t novel and there’s nothing wrong with Nord and similar products. (Although I don’t put any stock in the no logging claims)
It comes in handy from time to time. I run a "public" subsonic server but I don't have most of my own productions on it, but I can open VLC on android and go to a bookmarked share and play it all there.
Also stuff like NVR camera feeda I can look at over tailscale, too. No "cloud" storage needed.
I wish there was an easy reliable way to do this that didn't involve a for-profit; but until awful things happen I am fine using this for low-friction, trivial network access.
Recently, as I have been traveling through the Middle East and East Africa, I have also used Tailscale on my phone to protect myself on public wifis and to work around MitM attempts, see my other comment further up.
- ephemeral nodes are super useful for things like attaching a GitHub action runner or a fly.io instance to your tailnet
- Tailscale's ACL system has a ton of capabilities
- getting corporate buy-in is possible, vs trying to get a business to buy into Nord meshnet for actual workloads
Schedule A
Tailscale Entity
Existing customer accounts as of September 2, 2024 Tailscale Inc., a Canadian business corporation
New customer accounts on or after September 3, 2024 Tailscale US Inc., a Delaware corporation
Last week I noticed McDonalds guest wifi is blocking new connections over the tailscale control ports. It will pass wireguard mesh traffic for established sessions, but their firewall rules prevent you from establishing new ones.
I discovered the workaround purely by accident, when I took my laptop to work (which is unusual, it's a personal device not used for work but I needed to do some work on files that were on it). It was logged into my Tailscale when I last turned it on at the house and I discovered that it reconnected fine as long as it didn't have to do the authentication over the work network.
Pretty damn useful to connect to services in my internal network wherever I go. I have it set up on my router, so I don't need to install it on every single server in the house :D
I'm looking at setting up a VPN for my services at home and am considering ZeroTier or Nebula. Tailscale is out because I already have a tailnet and you can only have one (you have to switch networks if you have multiple).
I kind of regret not having used Nebula instead of Tailscale, because it gets rid of the control plane and it has less "magic" to it. Though Nebula seems to be moving much slower as far as improvements. I also checked out defined.net for nebula hosting, but at that time they were just starting to work on their API and I absolutely needed that because we have hosts that respin and join our net every night.
I wonder if they can figure out a way to distribute compute eventually via their network (not just clunky ssh): 'my' storage is already shared with 'my' nodes, why not 'my' compute? :)
Seems like a great company/business.
I still want to do it and we continue to brainstorm on the problem of state management and how to do it in an HA way, so you can run services where the compute bounces around some node in a set that's up and reachable on the tailnet but the state is durable and in sync between the nodes. It's a fun problem.
Anyway, a fun problem (or worse, a solution looking for a problem as I couldn't immediately think of a problem that would require it just yet. May be distributed training and such)
Cool to see a bradfitz reply though!
In a way I think all these solutions just keep enabling IPv4 to continue and that sucks. Does Tailscale offer anything in an IPv6 world? Are they another company with an interest in stopping IPv6 progress?
If you have more complex cases, the IPTables/Netfilter rules make it vastly more difficult to manage, particularly if you're running docker-compose (or anything using IPTables rules) on the same box and trying to troubleshoot the packets coming out of docker and going into tailscale.
And then trying to figure out what tailscale is doing with your packets is not great as well. They've also broken features I relied upon with a minor release.
Their nat traversal doesn't always work, as sometimes I get connected to a DERP server, so that limits the network speeds across the internet.
I blame CG-NAT quite a bit -- it's really why we can't have nice things these days -- and I get tailscale is trying to fix a bunch of that. But the reality is, I just want an interface just like eth0 or wl0, not an IT infrastructure to move my packets across.
Use jupyter notebook to fetch the stock and weather info and feed that into a local LLM and convert that to speech using opensource TTS.
I can open a stream manually through http://192.168.1.189:5004/auto/v600 while connected to tailscale (w/ my apple tv in-home as an exit node) on my laptop outside of the house, but when I open the HDHR/Channels apps, they can't detect the HDHR tuner itself.
Apparently this "just works" with openvpn, so I've been thinking about just switching back to that.
[0]: https://github.com/tailscale/tailscale/issues/1013
[1]: https://old.reddit.com/r/HDHR/comments/z8byns/watching_remot...
Tools for the job, should be our watchword ... phrase 8)
IPSEC is somewhat old school but very solid - if you can do opportunistic IPSEC via DNS etc it can be rather nifty. You can also use FRRRRRRRRRRRR to do it routed. IPSEC with BINAT can be used to avoid issues involving duplicate network addressing.
I default to IPSEC for site to site links.
OpenVPN is more TCP/IP related compared to IPSEC - that's very simplified. You can easily set an IP address for a client and other niceties.
OpenVPN is superb for massive client deployment. If you have a central CA and can deploy certs on all devices eg via MS AD CA then you can use a single config file for all clients, which is a doddle to deploy via GPO.
Tailscale is the new kid on the block. As with all new kids you need to examine what works for you and you could be one person or an entire multi national.
The real world is rather messy. For example your home/office/corp network will almost certainly have a MTU of 1500 bytes. When you hit the internets it gets really messy. Some British Telecom links (for example) will support mini jumbo frames and some won't and the real world continues to get more and more complicated.
https://github.com/freebsd/freebsd-ports/blob/ec981e26cd3128...
In case that wasn't helpful, maybe you have a more specific question
That said, what messed with me greatly was the fact that Tailscale seems to have an MTU of 1280 whereas Docker by default had 1500 which lead to inexplicably dropped overlay traffic with nonsensical log messages in my reverse proxy web server.
Basically, I had to delete docker_gwbridge and recreate it with some specific options: https://docs.docker.com/engine/swarm/networking/#customize-t...
It was quite the mess. I have no idea why Docker couldn’t just figure out that it needs the smaller MTU by itself, cause it listens for the Swarm on an interface that’s related to Tailscale and it can see what MTU that has.
Still, Tailscale in of itself is pretty nice.
Its due to some strangeness in general with tcpip layers that don't forward PMTU discovery ICMP messages. You'll see the same thing in some cell networks, and wireguard is particularly fragile here, because wireguard itself doesn't have a PMTU discovery mechanism.
Or, to be more exact, wireguard currently doesn't have a method to 'bubble up' a PMTU process to the inner wireguard interface from mtu-impacting events in its outer layer.
There's hacks like https://github.com/luizluca/wireguard-ipv6-pmtu/blob/main/wi... that try to handle this by monitoring outer route discovered MTUs and then applying them to wireguard routes.
In applications where I've had to deal with this (wireguard over cellmodem networks), I tool my network setup to poll whatever the cell network mtu happens to be and then set the wireguard MTU appropriately.
This gets really painful though if you think you wanna do something like run a network that really wants a >1280 MTU over tailscale. It's pretty much not doable, and it is, in fact, my biggest gripe with tailscale. Yes, its suboptimal for the 'whole-internet' usecase, but I really do want my wireguard links to be 9000 MTU.
Maybe wireguard will get that in the future, since it is an acknowledged problem. I bet someone in the conjunction of secure networking and HPC spaces could even justify paying the wireguard team to implement it.
I ran into a corporate network recently that blocked the Tailscale DERP servers.
My sense is that tailscale makes sense for a more locked-down service that is not accessible to the general public (although they do have a way to open up access to the world [4], it felt like more of a temporary thing than a permanent solution when I was looking into it).
And Cloudflare is more for exposing a service to the world, with support for a custom domain name, DDoS protection and other IP blocking feaures, etc. Cloudflare does have a "Zero Trust Network Access" product that I think might offer similar functionality to Tailscale, but honestly pretty hard to tell what it does from their website or how hard it would be to set up.
They both have free tiers that are pretty generous for "homelab" use cases. [2][3]
Does that sound pretty much correct? Are Tailscale and Cloudflare competitors with a lot of overlapping functionality? Or are they mostly distinct products serving different use cases/markets?
[1] https://developers.cloudflare.com/cloudflare-one/connections...
[2] https://tailscale.com/pricing
So, traffic is not end to end encrypted (Cloudflare man in the middles the traffic). That’s the reason we didn’t use it. Otherwise it’s a good service.
Tailscale is dead simple, even to create 'routers' that act more like a VPN appliance inside your network. It really does feel like something Apple would've come out with in their hayday: missing advanced features for power users, but is somehow able to deliver what feels like magic with minimal setup.
Yes, Cloudflare has tons of functionality you probably won't need and their dashboards can be several layers deep, but just setting up the tunnel with HTTPS and some basic security takes one evening at most.
That's my experience. I wish it was better.
On my iPhone, I've not even noticed any battery problems whilst running Tailscale 24/7. Are you running it with an exit node that funnels all traffic? I've just got it active for my nodes which might be why it's basically doing nothing.
Can't remember what the default install is - do you have "VPN On Demand" turned on? That should keep it mostly idle unless you're actually talking to one of your nodes, I think?
- My home PC, my laptop, and my phone are the participants.
- My home PC is connected to a GPU, and runs a colab runtime, SSHD, as well as a simple http file server in $HOME (actually, C:/Users/username, its windows)
- My laptop doesn't have an NVIDIA GPU, so it just runs SSHD and a file server.
- My phone serves nothing, but has an SSH client, and a http client obviously.
There is simple hostname based DNS setup by tailscale automatically, so I can just go to http://laptop:8000 to access all my files, or just ssh to username@computer
Accessing everything from everywhere is absolutely great. And this is all on their free tier.
Unrelated to tailscale, I use parsec for a similar solution for remote desktop, their "machine level user" feature allows me to initiate remote desktop from certain client devices directly.
Too smooth.
If your Internet provider and your mobile provider is the same company, they could put all your connected devices in the same IP block within the CGNAT IP range.
Now, not only you can access your device at home while away using your cellphone, you can also connect to your partner's phone with the same IP address at (or away from) home.
Some Internet providers in China very recently started providing this service, e.g. https://www.chiphell.com/thread-2666772-1-1.html (in Chinese). In addition to the convenience of accessing your home server while on the go, they also make the traffic within the CGNAT free.
I signed up for the tmo beta even though I am not a tmo subscriber. Now I have a cool thing to test, can I access my behind-starlink stuff from my cellphone?
> they also make the traffic within the CGNAT free
So.. both data caps and breaking the principle of net neutrality?
Imagine you can remote desktop connect to your parents' computer after their phone call.
The data cap is on your cell service (the US also has that). Net neutrality is debatable given the traffic is between my own devices so presumably no one gets hurt (think of accessing and streaming from your NAS at home).
Right, but not easier than static IP (or dyn dns), both of which require technical knowledge and procedure to set up. I really don’t see the great simplification here. Plus you’d still have firewalls and it’d stop working as soon as you (the client) leave your company’s garden (eg at work). To be fair, static IPs also wouldn’t work when your parents (the server) move their device.
> The data cap is on your cell service (the US also has that). Net neutrality is debatable given the traffic is between my own devices so presumably no one gets hurt (think of accessing and streaming from your NAS at home).
Fair enough. That I don’t mind. I really dislike configuring multiple devices for an ISP, that’s consumer lock in imo. The provider can simply implement hairpinning on their infrastructure and the traffic won’t leave their network anyway.
The only thing I need is to simply connect to the home network and I dont want to need to open and forward ports etc in routers and firewalls for it to work, just something simple plug and play and is secure.
At this mesh vpn is really good.
Fully compatible with Tailscale client binaries; it just replaces the control server.
That's tailscale, basically. Install on devices and they can magically talk to each other across the internet with no other configuration.
If you really want to, you can run headscale and manage the coordination plane yourself as well.
That could have benefits, for example, if you're concerned about a DDoS attack on that service taking your home internet out, you may be able to work around it like this. But it won't mitigate a gaping hole in the underlying service which you're still exposing.
It could also have drawbacks, like limited bandwidth and higher latency, which would make it highly unsuitable for something like a game server.
As long as you trust them this really give you a lot of security at a very low cost.
- Boom, everything works
- Internet? feels like local-net
This is just brilliant tech. Thank you so much for building this guys and the amazing effort that goes behind it everyday
I'm sick and tired of the way ISPs treat us. It's literally written into my lease what company I will pay for internet, and how much I will pay them. It is not, however, written in my lease how fast the connection will be. Not only am I unable to forward ports, I can't even change my own WiFi password! Sure, I could make a fuss and probably obtain access to my router, but it isn't worth the hassle.
But why is there a hassle to begin with? How in the hell is it in anyone's interest to keep me from configuring my own router? I can come up with plenty of authoritative bullshit answers to this question, but they are all authoritative bullshit. I think that's the real answer: we have systemically built our society to operate on authoritative bullshit. sigh
Tailscale is a usable workaround, but it shouldn't exist. It shouldn't need to exit. I just want to be able to host a server. Is that really so much to ask?
Your landlord (I'm guessing based on having seen it before) gets kickbacks from the ISP to force all tenants onto a specific (probably overpriced) Internet plan. The interest in keeping you from configuring your own router is in allowing the ISP's enshittifying further monetization tactics to proceed unopposed. The two big ones I've seen in this kind of setup are:
Using DNS enforced by the router to gather data and place ads on any 404 error.
Sharing their WiFi network that you lease with the ISP's other customers nearby.
If I moved into a house, I could get 1gbit symmetric from Google Fiber or UTOPIA at half the price. But that doesn't matter because I cannot remotely afford a mortgage.
The real problem is Monopoly. Not the market dominance kind: the no one gets to compete kind. We have it in real estate, where every piece of the market is overvalued so far that very few individual people can meaningfully participate. We have it with ISPs who get to literally own the last mile infrastructure, so their customers can't physically connect to a competitor.
You can't BYOD? I got a lot of info out of the install techs when my home fiber was installed, including the router password, because they saw my setup and said "whoa... this is not a normal person setup". I said no, it isn't, you want me to walk you through what I've got? They did.
I ended up putting their device to DMZ all traffic to my device and turning off its radios (I have multiple AP's with wired backend). Technically double NAT, but in the first step all ports were forwarded, so it didn't affect anything. It took me a while to have a weekend where my wife was gone and I could risk breaking things for a few hours, but after that I was able to remove their device entirely. Turns out it uses a VLAN on the outgoing connection, so I had to figure out how to set that up on my router.
I live in an apartment. The router was here before me.
I’m sure you have tried these, just spitballing about how I would try to deal with that…
My frustration is that it's difficult in the first place. I shouldn't need to call someone (and hope they both comprehend and help) just to configure a device inside my home. It's absurd, and everything that led us to this point deserves criticism.
But you can proxy traffic using a VPS really easily, which is basically the reverse of exit nodes.
I was a doubter a bit as to how it would work at a bigger org but so far rock solid, easy to setup and great user experience.
Or is there more to it that I’m missing?
When you set up wireguard you have to update every system’s config to add a new device, Tailscale does this for you. That’s the key thing.
Wireguard is a great VPN protocol, but what the basic protocol doesn't do is make it transparently easy to use in a wide variety of edge cases without having to reconfigure anything. If all I want is two devices to be able to talk to each other, at least one of which is in a fixed location where I have total control over the network, then yeah, raw Wireguard is probably a decent solution. If I want to do anything else, I need a management layer on top of Wireguard, and Tailscale is by far the best solution for that out there.
As a thought exercise, consider a home network where a laptop connects to a NAS to store media files. I take the laptop to some random destination and connect it to hotel WiFi, while someone else takes the NAS to a totally different hotel and connects it to the WiFi. With Tailscale, the laptop can immediately directly access the NAS without even having to change the mount point. Think about what it would take to set up similar functionality with raw Wireguard. I'm not saying this is a common scenario, or that you can't do the same thing manually. But the fact that such a setup would just work is pretty impressive.
It wasn't very intuitive to set up but it took less than an hour and it has worked flawlessly for years. Unraid definitely made it a bit easier. Seems Tailscale almost completely solves that complexity for the initial setup and each additional device.
I was even able to stream my games through the tunnel with a (decent enough) latency of 27ms with variance of 2ms.
Admittedly, I could buy a gaming laptop, but I don't want to carry a heavy laptop 4 times a month :P
I never understood this problem. I just create a Tor hidden service when I want to ssh into a machine behind a firewall.
Does anybody know of any good materials on the enterprise use cases and configs? e.g. blogs, screencasts, etc.
Samba transfers take a 15 megabyte per second hit over tailscale even with a fairly fast CPU on both ends (Ryzen 3600 and Ryzen 7900X3D) on my local network
https://old.reddit.com/r/mikrotik/comments/112mo4v/is_there_...
The overhead shouldn't be 15% but there could be some weird interaction with the link MTU for the VPN causing, e.g., smaller packets to be sent with more overhead.
These are on my local network, connected to my switch over 1gig Ethernet.
https://www.reddit.com/r/linux/comments/9bnowo/wireguard_ben... from 7 years ago is about trying to get it running at 10Gbps speeds.
Now I mount the NAS volumes to a host at the same location and sftp to it. It’s still dog slow at 30MB/s but that’s the NAS limitation.
Direct access to the NAS can also be achieved via Subnet Routers
expand plz
(Like If I wanted to crawl an area in germany, but needed an exit tracert that originated there - a tailscale droplet that could be connected to, perform [object] and openly pipe data back to master?
Fair enough if you're stuck behind a CGNAT though.
"Yes, WireGuard does support NAT traversal, though it doesn't handle it natively; it relies on techniques like UDP hole punching to establish connections between peers behind NATs."
That makes no sense to me, I have my peers talking to each other on the Wireguard VPN behind my ISP NAT. I do have one UDP port open on the VPS that they all talk to. Is that what you mean by, "Wireguard doesn't do NAT traversal on its own, which is, IMHO, the killer feature of Tailscale."?
If so, how does not having to open one UDP port which can't really be detected anyway, justify having all your traffic controlled by a third party through servers (I forget what Tailscale called them) you don't own?
as someone who does publicly expose services that have auth, why does CGNAT make exposing ports publicly bad?
Tailscale is a better idea.
Tailscale is great but direct is always better IMHO.
Luckily for me I have a regular ip4 address but if that ever changed I’d be out of luck unless my isp (quantum fibre) implemented a proper ipv6 solution.
I used to run a WireGuard server on a raspberry pi with ddns to update dns record on an as needed basis.
Eventually replaced it with my gateways built in WireGuard server which also has ddns enabled
The use cases described by the author are taken care of with a simple wg server. Sure you don’t get the distributed peer network of tailscale but I can live without that.
It’s incredible how shitty modern software is that a raspberry pi couldn’t run a basic VPN.
If any tailscale devs see this you should try to reproduce this issue and use it as an opportunity to clean up a bunch of dumb assumptions that likely hurt real users as well, just through less direct means like battery consumption and slower overall performance.
honestly, not sure what's all the hype. ssh under wg with sane user management and key distribution cover 110% of the TS use cases. and thebonly difficult part is the key distribution but that should be difficult by design otherwise you're doingnit wrong anyway. you can even resuse the ssh keys for the wg tunnel if you're smart about it.
https://nebula.defined.net/docs/
https://nebula.defined.net/docs/guides/quick-start/
...I believe 100% open source. You can basically hub between different devices (including iOS/Android) that are identified via certs. Recommended to have one or more public "lighthouses" so anything that can reach a lighthouse can reach any of your other servers (maybe kindof "syncthing for vpn/overlay-network?").
I've dorked around with it a little bit, but it's rare enough that I need access to my home network while out that I haven't doubled down on proper cert, key management, rotation, etc.
https://github.com/DefinedNet/mobile_nebula/issues/19#issuec...