> Narrowlink and Tailscale are two open source solutions with different architectures that enable secure remote access and connectivity across networks.
A nitpick, but ironically I think they're being generous to Tailscale there. Tailscale isn't really "open source" - or at least not without heavy qualification. I'm not an open source zealot by any means but that line just seems a little misleading.
The clients are partially open source [0], but the server isn't at all.
There is an open-source implementation of the Tailscale server called Headscale, but Headscale is not Tailscale. This distinction is important because a significant part of the value proposition of Tailscale compared to other overlay/mesh networks is their very well designed web UI which makes managing their Wireguard based networks very user friendly. Headscale has no UI (edit: there are some third-party "unofficial" Headscale UIs [2]).
In fact the Headscale repo still says explicitly "This project is not associated with Tailscale Inc." [1] even though I understand that it is (unofficially?) supported by Tailscale these days.
> I understand that [Headscale] is (unofficially?) supported by Tailscale these days
I'm not sure if it clears the bar of official, but it seems to be not-unofficial. They were planning on open-sourcing a coordination server once they cleaned the code up, but then decided that there was no point in doing so due to Headscale. On top of that, one of the primary maintainers of Headscale works at Tailscale now.
Sounds like someone may have thought the code for Headscale "coordination" server was higher quality than the code for Tailscale "coordination" server. If the later needed to be "cleaned up". Maybe there were things in that code Tailscale did not want the public to see.
Funny how Wireguard's original pitch was that it was smaller and simpler than OpenVPN or other alternatives. Now people are commercialising some complex GUI on top of it. More "features" on a steady basis. Some of them might be closed source but pay no mind. "Worse is better".
There's absolutely nothing stopping you from just using WireGuard if you want to. I don't understand the mentality of complaining about a completely separate entity offering extra features just because you don't personally have a need/want for them.
I don't get the issue with having a tight secure underlying vpn protocol, and others building on top of it to improve deployment and setup/management side of it.
Agreed. I don't think people recognize how much of a pain cert management/orchestration can be, and Tailscale's value adds like MagicDNS and managing/creating SSH keys for logging into servers are significant QoL improvements. Sure, you can do that stuff on your own, but I simply don't want to.
I do run my own Wireguard VPN at home. It’s not terrible for a few clients with a set home dyndns or static IP.
It has basically taught me how the small building blocks for Wireguard work. And how for anything remotely more difficult or multi-user I’d absolutely want something more robust handling the orchestration and management of the network. It is very hard to get right and can be very complicated to keep everything in sync. There is definitely value to what Tailscale, et al deliver.
I’m happy that I can run a simple version myself, but only after doing that can you really appreciate where the dragons be.
I don’t really think your comment is a fair take. While it very well may be “actually what happened”, there are a lot of other reasons to hire from and foster your community rather than try to compete with them. It’s possible Headscale just does a better job at capturing a clean boundary between a public open source tool and a proprietary backend and Tailscale might have just liked what they saw, said well this is essentially how we’d do it, and made the smart decision to put the person on payroll instead of taking advantage of the community.
Furthermore IDK what your gripe is about management tools popping up on top of Wireguard. That’s what Jason wanted, for one. The downstream application use cases are kept out of the secure and simple core. Two just use vanilla Wireguard if you don’t need Tailscale. Are you an OpenVPN shill?
The client is completely open source on open source operating systems. The repository you linked to is 100% of the client for Linux, and there's another repository for Android.
As a bonus you can run the open source client on closed source OSs, i.e. macOS, WSL2.
We never open sourced our coordination server because Headscale beat us to it.
> We never open sourced our coordination server because Headscale beat us to it.
From what I understand, Headscale has not all the capabilities of Tailscale’s server.
Excerpt from Headscale’s README:
> Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailnet, suitable for a personal use, or a small open-source organisation.
Sure, and that seems very reasonable? If you're running your own coordination server, stand one up for each tailnet you want to run. Different software has different operating requirements, and headscale is building to requirements that are better suited to someone running their own.
E.g. our internal coordination server has a bunch of goop in it for talking to a couple of AWS services we use. No-one wants that.
Personally I just feel better recommending something to people if I know the service is 100% open source. I don’t care if the code includes stuff “no one wants”. I’m a talescale user and I love it, but I do feel a bit weird using and recommending a service with important bits that are proprietary. At the same time, part of why I like the service is that it’s dead simple to use. I imagine headscale takes more effort to set up and use. So I use the proprietary client, and just kinda feel weird about it. If it were open source I wouldn’t have those reservations.
Having recently put some work to essentially sell headscale-as-a-service (to clients that for various reasons wouldn't want to pay tailscale anyway even if they found the service great), about only issues between tailscale and headscale are that headscale got a bit of cruft regarding internal models that are currently being worked on, and for practical purposes it shows up in a bit harder time handling ACLs and no tailnet-peering support.
It strikes me that if you had to build a service platform, then that shows me there is a difference in the systems from a user perspective. I am a very technical user but I do NOT want to spend my time configuring network stuff, that's the whole reason I use tailscale. The fact that headscale is self hosted immediately creates barriers that tailscale does not have. I already host several web servers and it a huge pain that I want to do less of. (Everything is fine on digitalocean until some update does something weird and I have to spend a few days debugging it).
It's a networking service. Inherently, there are things you will be able to orchestrate easier from a centralized perspective than a self-hosted one.
You're correct to nit-pick the difference between Headscale and Tailscale as software products, but I think this is splitting hairs. There are perfectly valid reasons why both are different. Given Tailscale's featureset as a product, it's not reasonable to expect it's self-hosted alternative to be a pushbutton replacement.
> Given Tailscale's featureset as a product, it's not reasonable to expect it's self-hosted alternative to be a pushbutton replacement.
Yeah, exactly. That’s why I started this thread by disagreeing with the tailscale employee who said “we don’t need to open source tailscale because headscale already exists.”
Headscale and tailscale are not the same. I want to use tailscale, and I would love it if tailscale was open source! If truly the only reason they’re not open sourcing tailscale is that headscale exists, they’re kind of missing that existing tailscale customers will not all see headscale as a replacement but might still prefer open source.
I don't think it is possible to Open Source the entirety of Tailscale, is what I'm saying. Their product is deeply intertwined with system providers, autoscalers and load balancers.
There's a world in which they "open source" Tailscale in the form of a massive K8s spec, which costs ~$400/day to operate for a single user. But... nobody would really use it. If Headscale offers most of the features with much less overhead/configuration, it's a perfectly fair (even respectable) recommendation to make. Replacing what Tailscale actually does is not entirely what most Tailscale users want.
If you are the sort of Business Grade™ user who needs access to this tech, Headscale is BSD-licensed and you can make your own solution with little effort. Or you could pay Tailscale for an enterprise license and skip this whole headache from the start.
If you look at Tailscale as a wrapper for Wireguard that sells subnet address space instead of software, it makes a lot more sense. There isn't much for them to open source, really. It's like shaking your fist at Mullvad for not releasing their Terraform scripts and bootstrapping code.
I believe the best approach is to have a completely open source core product which its own API. You can then have a propriatery multi-tenant platform (incl. hosting, mngt, patching, support, 3rd party integrations etc) which interacts with the open source API. This provides the best of both worlds.
fwiw, I work for a company with both an open source and proprietary product and this is how we do it.
> The client is completely open source on open source operating systems.
IOW it's by and large the GUI part that is not open source. Personally I prefer to run it as a system LaunchDaemon than a user LaunchAgent anyway.
> We never open sourced our coordination server because Headscale beat us to it.
I seem to recall reading that another reason was that there was intent to open source it but it made little sense as far as running it because its code was written for (and coupled to) Tailscale's heavy duty infra. So Headscale beat Tailscale to it by providing not just code but code that could work on much wider contexts.
the GUI part is also open source (I went looking recently in hope of adding support for `tailscale switch` on android). It's just in surprisingly weird toolkits :)
Their clients consist of a daemon and, optionally, a GUI. The daemon is open source. The Android and Linux GUIs are open source but the Windows, iOS, and macOS GUIs aren't.
> We never open sourced our coordination server because Headscale beat us to it.
Can you elaborate? This sentence makes no sense to me. Headscale is not tailscale, so they didn't "beat you to it", they just released a competiting product.
They’ve been really good about promoting and supporting headscale. I feel like this comment from Bradfitz gives a nice little insight into the reality of open sourcing code.
I'm a big open source advocate and would be heavily critical if the Linux and Android clients weren't open source, but I don't see how a person can complain about tailscale being closed source on an operating system like Macos or iphone or Windows, when the entire platform practically is closed. Such person clearly does not have a problem or concern about using proprietary and closed systems. I think tailscales position here makes a lot of sense, and if it bothers somebody because they see the tremendous value in open source, I hope it would cause them to consider their platform of choice.
Tailscale hired the guy who wrote Headscale, for him to work on software, so they're sponsoring the programmer who's working it, but it's not "Tailscale" software, and they have no warranty, express or implied, because it's not theirs. It's its own project.
> significant part of the value proposition of Tailscale is their very well designed web UI which makes managing their Wireguard based networks very user friendly.
I think this is an opinion. I don't use the tags/rules, and I literally only use their website to complete the oauth flow to auth a new client. Headscale is a perfectly functional replacement of Tailscale for me.
I interviewed there and asked about this and they said their coordination server and (and other UI features UI) are almost completely about satisfying very demanding enterprise customers, with one of the major concerns being the performance particularly of applying ACL rules across huge complex networks.
They said there would be a lot of code cleanup to open source the coordination server, and it's not been completely ruled out but Headscale is such a nice alternative for those that care about an open source coordination server that it doesn't seem to be a big motivation.
> For companies or organizations whose policies are not compatible with the AGPL-3.0 license, we offer a separate business license. To inquire about the business license or discuss licensing options, please contact us at opensource@narrowlink.com.
One's not usable in any corporate context, especially one that's so low level in the network stack. The doc post is a content marketing post (in this case, for SEO hacking specifically) disguised as a technical comparison, so they clearly have monetisation in mind.
It isn't usable if your goal is to take the open source project and turn it into a component of your own commercial product that is for sale and is closed-source.
But I think more than half of the people in this thread have the opposite opinion (that if it isn't open source, it isn't usable) and I tend to agree with that.
it's also isn't usable if you're going to need to modify it, even if something trivial like patches to work on your internal historically complicated stack, then due to legal bugs in AGPL you might find yourself never compliant with the license.
Hey me too and I fully agree! Nebula is super underrated in this market space. I use Nebula to connect my primary datacenter rack with a bunch of dedicated servers and VMs all together on an overlay network. This makes it easy for me to add Nomad client nodes quickly in different parts of the world and everything just works.
I actually use https://defined.net for a managed Nebula experience and it makes everything super easy to get going and the team is super helpful with the few issues that I have run into. The free tier is super generous with up to 100 hosts for free and you don't need a credit card to get started. I highly recommend checking it out.
You're right! I didn't realize article posted by parent was 3 years old (it only mentions iOS client being in development). Their website mentions Android client!
Nebula is fantastic, absolute love it. We use it in production. Cert management can be a bit of a pain on a large scale but there's an excellent Terraform provider [0] that can help. Coupled with the Terraform ansible provider and a little bit of scripting you can automate anything related to cert provisioning and renewal.
The Nebula creators actually started their own company after leaving Slack focusing on handling your mentioned pain points with cert management and orchestration: defined.net
For people for which the SaaSiness of Tailscale would be the main deciding factor, it is important to note that this article completely fails to mention Headscale, a BSD-licenced tailscale-compatible coordination server under active development
We tried switching to Headscale recently...it was not a pleasant experience. I'm sure with more time in the oven, it will eventually become a comparable replacement, but I wouldn't be relying on it for anything production oriented.
Just for a counterpoint: I've been running headscale for 11 months, with just over 100 tailscale nodes, and it's been pretty good. There was one version upgrade that completely exploded memory use (it originally was running on a 1 or 2GB VM, with the upgrade I had to switch to 16GB to avoid thrashing), but that was fairly quickly resolved.
I would say it's been a pleasant experience, headscale and the headscale devs have been fantastic.
However, I would also agree with the statement that I wouldn't use it in production. In particular: I was hoping to use it as an overlay network for basically all traffic, between production machines and to user workstations. For the overlay network, my biggest fear there is that when headscale goes down, the entire network pretty much immediately stops responding. The usual case for this is when I make an ACL update and make an error, the entire overlay is down until I get the ACL fixed.
For replacing our OpenVPN, headscale+tailscale is going to be a clear win.
For the overlay network, I probably should go with Nebula. Headscale has these things over Nebula: Easier user onboarding (users can just login, no key exchange required), tailscale was able to route around some network problems we saw in Comcast (though it sounds like Nebula has experimental ability to do that now), and headscale has vastly better ACLs. Tailscale's are even better. Another downside of tailscale is that you can only connect to one tailnet at a time, so you can't have a "work" and "home" tailnet and be connected to both -- you have to switch.
Nebula has the benefit that there is no coordination server, so no worries about that going down. Even in the case of the Defined Networking SaaS, an outage of the control plane would just interfere with the ability to manage the network, until keys start expiring your network will continue to work.
ZeroTier also is very good, I'd classify it as closer to Tailscale, but it does have the ability to connect to multiple networks. ZeroTier in many ways is very slick, but I ended up removing it from my list of options because of a bad interactions with their sales team. It's ACLs are pretty obtuse though.
Oh, another slight minus of tailscale is it's manipulation of the system firewall rules, so if you have other firewall manipulation, in particular if you manage large rulesets via iptables-restore from a rules file, tailscale can lose it's rules. On the plus side "tailscale status" will report "health" issues in that case to point you in the right direction.
It was last year, so it's not in recent memory, but most of the problem was around instability. We ran into some frequent issues where we would begin troubleshooting, assuming it was something on the application end, only to find out that the issue was happening in the network. We eventually figured out that the Headscale network was randomly dropping in and out. I'm sure with a lot more time we could have identified the root cause, but unfortunately, we had a deadline and just paid Tailscale (and haven't had any issues since).
Like I said, I'm sure it's coming along fine, it's not just something that we were able to set and forget like with the Tailscale experience.
We have definitely improved a lot the stability and test coverage in the last year. Really, really a lot. Still a bit to go, but overall there have been many changes :)
But indeed we are not meant to replace the full frictionless experience of Tailscale SaaS.
Nebula is another option along these lines. https://nebula.defined.net/docs/ I've been using it for the better part of a year and am very happy with it. It is able to make point-to-point network connections in many situations, avoiding the out-and-back cost of VPN ingress/egress points that are far away from source and dest.
Not sure if I'm just bad at reading Rust code, but it looks like the end-to-end encryption is implemented by pre-sharing a symmetric key, and communicating a 24 byte xChacha20Poly1305 nonce over the wire as websockets are established. This key and nonce are subsequently used to encrypt and decrypt messages sent between the two parties. It looks like the encrypt and decrypt functions are called as new websocket traffic is read or written to the stream.
If true, this means that every message sent via this means uses an identical keystream to encrypt all messages, and thus results in a loss of confidentiality of all messages. Am I missing something?
(Disclaimer: not related to the referenced narrowlink code, but the sentiment of the parent post)
I which stuff like libsodium would be both more widely available and more widely used.
And with "stuff" I don't mean the internal core primitives but the slightly more higher level helper which often try (in the limits of C) limit miss use and have reasonable good documentation.
Because while by now most people have understood that inventing/putting together their own low level crypto primitives is a bad idea, people using existing low level primitives to invent their own "mid level" primitives still happen more often then healthy in the industry.
I've tried Tailscale, Headscale, Nebula, Netmaker, OpenZiti, wg-easy, and a few other niche overlay network and VPN tools. Each time I still end up using Firezone [1] when I need a simple wrapper over Wireguard.
Yeahhh, I tried to convey that with "and a few other niche overlay network and VPN tools" to imply that the list contained both kinds of thing, but couldn't think of a better way to phrase it.
This article is classic SEO fluff right? The Q&A style answering exactly the type of questions that people comparing the two would write into google search.
What makes it "fluff" to you? My definition of "fluff" is that it doesn't answer my question, and that I walk away from it with no idea what the product even is. This is mostly concrete and I can tell you roughly what Narrowlink is and isn't after reading their (misspelled) page.
Something like:
"Introducing NarrowLink, the world's most advanced and secure VPN solution! With our cutting-edge technology, you'll experience unparalleled speed, reliability, and security. Our military-grade encryption ensures that your data stays private and safe from prying eyes. Enjoy unlimited access to all your favorite content, no matter where you are in the world. Say goodbye to restrictions and hello to a new era of internet freedom. Join millions of satisfied customers and take control of your online experience with NarrowLink today!"
It's SEO spam. You might find it helpful, but that doesn't detract from the obvious nature that, for better or worse, it's design to rank in google and capture clicks.
I don't consider it spam due to its non-spam, grade A prime rib beef content, in actually saying what it does. But if you must, https://xkcd.com/810/ then
I found it useful - we have been considering tailscale for part of our post-VPN strategy, and as tailscale markets successfully there, the direct comparison helps. That they were fair about the OSS & centralization comparisons without explicitly punching up was also great for trust building - good job whoever wrote that.
If you want a search term for more info about it, this kind of article specifically falls under "content marketing", in this case it's a high-converting type called a "versus page".
It’s a little verbose but I’m in favor of people writing these sort of comparisons, and a Q&A format is fine. People writing more FAQ’s seems like a mostly positive side effect of SEO, if they’re accurate.
Hey, I am the creator of Narrowlink. I certainly find your comment valid, and using WireGuard over HTTPS most of the time provides better network performance. However, in very specific cases, Narrowlink demonstrates superior performance.
1- When your devices' routes are not optimal, and utilizing a CDN can enhance the connection due to smart routing. For instance, I have a server in Poland (while I live in Canada) where the direct connection is slower than connecting via Narrowlink behind the CDN (The gateway behind the CDN).
2- And in rare cases, Tailscale cannot establish a peer-to-peer connection, opting to use DERP servers and their own servers (no longer strictly P2P as seen here: https://tailscale.com/kb/1232/derp-servers/). In such cases, Narrowlink may provide faster connectivity.
3- When you start your Tailscale client, it needs to perform NAT discovery. If a symmetric NAT exists, it takes time to connect due to network flooding for UDP hole punching, while Narrowlink can respond on demand (see the section "The benefits of birthdays" on https://tailscale.com/blog/how-nat-traversal-works/).
It's also important to note, alongside the protocol, the software implementation is crucial. Narrowlink is written purely in Rust, while Tailscale has been created by orchestrating existing tools and uses the Go and C++ programming languages. I suggest you try Narrowlink and experience its computational performance.
I believe Tailscale is an amazing VPN solution, but its protocol, infrastructure, and complexities might not be the best fit for self-hosted platforms. In contrast, Narrowlink is a Proxy solution (currently not a VPN) that is very simple to set up.
Please note that narrowlink only encapsulate the TCP payload's not its headers.
I recently released Narrowlink (just two days ago), and it is in the early stages of its journey. I have various plans for this project, including a web interface, integration of the QUIC protocol, and more. I just need the support of the community and more time to enhance it.
Do you have an overview anywhere of the protocol you're using to encapsulate TCP in HTTP? Why did you go with HTTP instead of WebSockets? Does Narrowlink support UDP?
Narrowlink uses the HTTP/S (WebSocket) protocol as transport;
it encapsulates and decapsulates TCP and UDP connections on top of it.
This means both UDP/TCP tunneling methods are available out of the box.
For example, the following screenshot shows a UDP tunnel for DNS purposes and its encapsulated traffic as TLS (HTTPS+WebSocket=WSS).
https://i.ibb.co/wcHB8g2/udp.png
Tailsacle also has a series of performance optimization and wireguard testing blog posts; considering some of their late offload additions, and even though they use userspace wg, I find it hard to believe they are nowhere in the same perf ballpark, but I could be entirely wrong here...
They should move to using QUIC which is the protocol backing HTTP/3. QUIC incorporates TLS1.3 and has an extension for UDP style unreliable datagrams (https://datatracker.ietf.org/doc/rfc9221/). It would be the perfect way to bring SSL/TSL/HTTPS VPNs onto a modern performant protocol while keeping the simplicity in of the https based VPN. It would still have the advantage of looking like https traffic, while have the performance characteristics of UDP based VPN protocol.
And we all know apples and oranges are incompatible in every single way. Even their physical dimensions or prices can't be meaningfully compared!
Seriously though: both of those products aim to provide secure tunnelling/network connectivity. They do it differently, which leads to different trade-offs including, among other things, at which level the OS network stack is intercepted. All of those things can be meaningfully compared (e.g., "do I need my favourite application Z to explicitly support and be configured to use a HTTP/SOCKS-proxy or will it 'just work'™?" — Tor and OpenVPN give two different answers).
Both of those products provide that functionality on paper, but they are widely different products with widely different audiences.
I think their respective "Get Started" buttons show it best: Tailscale tries to get you connected to your team and to download the client as fast and easy as possible (= it's a product for everyone in the company), while Narrowlink throws you to a lengthy explainer page that no non-technical user will bother with.
Of course you can compare apples to oranges, but if you know that a huge amount of the population is allergic to citrus fruit, it's just a waste of time to compare their dimensions or prices.
It's not arbitrarily chosen, and I wouldn't call it a criterion. I am arguing that they are different products for so different audiences, that all other criteria don't really matter.
> both of those products aim to provide secure tunnelling/network connectivity
You are talking about technical capabilities, but that still doesn't make them similar products. Figma and Miro are not similar products, just because they both provide an infinite canvas and team collaboration capabilities.
> if you know that a huge amount of the population is allergic to citrus fruit
"But guys, what about lemo—", "John, you know we all except you are alergic to citrus, don't you?", "Oh, sorry, completely forgot, let's move on".
???
I don't understand what point you're even trying to argue. If some misguided manager would come to you and ask your opinion in him chosing between Miro and Figma, presumably you'll ask him a bit about his needs and then reply with something like "Well, while technically Miro would suit you better, what you actually need is Trello" instead of, I don't know, saying "they're not simialr products, no point in comparing them" then turning your back and leaving. Right?
That's an entirely reasonable scenario IMO even if it involves meaningfully (i.e. "yep, one of those is definitely more suiting than another") comparing Trello to Figma.
Image someone drew up a comparison of Miro and Figma which listed a lot of facts that they could be compared on, but left out the parts where one is about designing and the other is about diagramming.
Now, you would like to point out that the collection of facts omits some crucial points, which likely makes the comparison useless. What would you say in that instance? In the english language, the most common idiom that has emerged for that is "that's comparing apples to oranges".
That's what the GP original comment pointed out (I assume). You replied to it, ignoring that point and not really engaging with it, and trying to dismantle the concept of "apples to oranges" as a whole.
Yeah, I think trying to take the idiom too literally reveals a lot of holes, comparing apples to oranges is a legitimate thing to do in the context of what fruit to eat, for example.
Nitpicking that particular but doesn't negate the overall meaning behind the idiom. Lots of things can be compared, but the comparison provides dubious value at best. Sure I can compare having sticky notes on a fridge to Jira, but then I'd be comparing apples to oranges.
comparing apples to oranges is legitimately a good analogy here, just not in the idiomatic way people usually mean it.
apples and oranges are pretty comprable. they are different things, but serve the same purpose and are often used interchangeably. it's perfectly reasonable to compare those two things.
Yeah, the usual way this analogy is meant to be understood always pissed me off. Of course you can compare them: apples are better for making an apple pie than oranges; apples are cheaper and less squishy during transportation; oranges have more vitamin C; apples have more bio-available iron; oranges (subjectively) are tastier and less sour; etc.
> Narrowlink uses a centralized gateway to which clients and agents connect over HTTP/S protocols. The gateway handles routing and connections between agents behind firewalls/NAT and clients.
> Tailscale uses a centralized configuration management system to define devices, access control policies, etc. Traffic is routed through the Tailscale cloud services to facilitate connections between devices.
To clarify: Traffic _may_ be routed through Tailscale cloud services but the centralized Tailscale service is used primarily to coordinate configuration and only secondary as tunnel. If it goes down, the existing tailnet will keep functioning. In contrast, the Narrowlink gateway is an inherent central point-of-failure which all traffic needs to be routed through.
From a quick look this looks like one of the major deciding factors between the two. Would be great to hear if there are any intentions to make a future version of Narrowlink address this downside and make it into an actual mesh network.
Interesting. I thought recognized the logo, apparently seems to be a commercial support offering of https://github.com/slackhq/nebula and they support the "nebula" iOS app. I had been using for nebula/defined in the past.
I started reading through the Narrowlink URL, but the frequency of typos was frustrating enough the I came right back to HackerNews to read the comments and synopsis of what the kerfuffle is about.
Thanks for the pointer to headscale - will take a look ;)
That happens if you are using the free version on Ngrok. You could also check out zrok.io, its an open source alternative I work on. We also have a free SaaS version for easy usage.
The real game changer (but may not be relevant you) is zrok is being abled to use the OpenZiti SDKs so that you can embed zrok functions directly into an application. We have built the Go one so far, but all others will be done in due course.
> However, tailscale focuses on access different devices to each other, while Narrowlink focuses on access to the services trough on the agent as a proxy.
The downside of that is its instability. I enjoy it as a product - I was using it almost two years ago and it was good enough to set up a small scale mesh network at that point - but they basically were issuing breaking releases every month or two. Maybe now that they have a cloud offering it has stabilized.
Sounds like in Narrowlink as a proxy passes through all traffic as it's not peer-to-peer? As a home lab with it deployed on a VPS the bandwidth rates/caps could be significant. Granted residential lSP can run into caps as well.
I am trying to use tailscale for personal project as mesh overlay network, but it is annoying. When you create images in packer, you need to remove state, otherwise nodes would fight over the same IP when created from the same snapshot. AuthKey expiration for infra is 90 making this another secret that you need to manually rotate. When running "tailscale up" with --ssh it hangs ssh connection making Ansible scripts brittle. For non-tech use, the android app is pretty useless. Taildrop is weird, I would like to have NFS over tailnet that you can easily share with others.
It seems that everyone wants to build VPN solution to sell to enterprises. There is probably more profit than building opensource mesh overlay :(
Given all that, I think that narrowlink architecture is flawed and worse than tailscale. Narrowlink gateway is both single point of failure and performance bottleneck (looks a bit like Cisco AnyConnect). Wireguard is very nice and modern protocol, narrowlink would need to implement own custom alternative over https. It would be interesting to see how both perform in very large topologies.
... because network sharing is easy if you can trust the network? Easy re-use of existing network tools is literally the usecase for these networks in the first place?
Yes, but auth key is only valid for 90 days. If you put your Auth key in secrets, and you want to add new machine via CI/CD you need to rotate key every 90 days.
What this tells me is that I really want something like Tailscale but written in Rust and not requiring a third-party, closed source server for authentication. (yes I know about headscale)
There are but they are all done by companies with an interest and therefore other parties cry foul that their product was not setup to give best performance. fwiw, I work on the OpenZiti project which may interest you too as the overlay is a smart routing mesh network (think concepts of MPLS as SW) including ability to have multiple nodes with E2E latency being used to shift paths.
From my read of the article it's mainly from the peer to peer nature of the setup. With Tailscale and wireguard you know where traffic is coming from and where it is going as it's not going through a central gateway.
You also can find out it's VPN data as it isn't tunnled over https or using any other masking methodology.
I belive you wouldn't find anything out about the data inside the wireguard tunnel just the wireguard tunnel metadata.
"Narrowlink and Tailscale are two open-source solutions with different architectures that enable secure remote access and connectivity across networks."
The opening statement of this document is misleading and indicative that the author isn't really aware of what is open source and what isn't. A more appropriate comparison should be between headscale and narrowlink.
A nitpick, but ironically I think they're being generous to Tailscale there. Tailscale isn't really "open source" - or at least not without heavy qualification. I'm not an open source zealot by any means but that line just seems a little misleading.
The clients are partially open source [0], but the server isn't at all.
There is an open-source implementation of the Tailscale server called Headscale, but Headscale is not Tailscale. This distinction is important because a significant part of the value proposition of Tailscale compared to other overlay/mesh networks is their very well designed web UI which makes managing their Wireguard based networks very user friendly. Headscale has no UI (edit: there are some third-party "unofficial" Headscale UIs [2]).
In fact the Headscale repo still says explicitly "This project is not associated with Tailscale Inc." [1] even though I understand that it is (unofficially?) supported by Tailscale these days.
[0] https://github.com/tailscale/tailscale
[1] https://github.com/juanfont/headscale
[2] https://github.com/juanfont/headscale/blob/main/docs/web-ui....