Tailscale vs. Narrowlink
narrowlink.com
narrowlink.com
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....
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.
For the record I think Headscale is an impressive project.
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.
https://github.com/gurucomputing/headscale-ui
Granted, that's also not tailscale.
I take your point, but they're technically not Headscale either!
Yes there are a few third-party UIs for Headscale but now we are 3 times removed from Tailscale :)
In other words, disingenuous advertising.
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.
To me the AGPL thing feels like all or nothing.
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.
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".
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.
There are a ton of things you do in closed source “only my small team touches it” vs open source.
Even if it’s just comments, notes files and stuff like that. For example I often leave project notes in comments and address people etc.
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?
> This project is not associated with Tailscale Inc.
:)
I am pretty sure they would have eventually published a control server.
We just happened to be quicker (and come up with a great name, IMHO).
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.
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.
(emphasis mine)
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.
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.
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.
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.
fwiw, I work for a company with both an open source and proprietary product and this is how we do 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.
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.
As you would have read a few paragraphs further on in TFA they describe the situation with much more clarity:
"Tailscale uses the open source WireGuard protocol, and its client apps are open source, but the coordination services are proprietary."
[1] https://slack.engineering/introducing-nebula-the-open-source...
EDIT: my bad, they have an Android client
https://play.google.com/store/apps/details?id=net.defined.mo...
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.
I don't know why it seems to be so far below the radar in these comparisons / conversations. Perhaps the Tailscale marketing is just that good :)
[0] https://registry.terraform.io/providers/TelkomIndonesia/nebu...
The interface is a bit clunky but the service (both agent and control plane) are rock solid for me.
What issues did you face? :)
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.
But indeed we are not meant to replace the full frictionless experience of Tailscale SaaS.
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.
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?
https://github.com/narrowlink/narrowlink/blob/abf35e38567b88...
https://github.com/narrowlink/narrowlink/blob/abf35e38567b88...
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.
E.g. crypto_secretstream_xchacha20poly1305* from https://doc.libsodium.org/secret-key_cryptography /secretstream
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.
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!"
would be fluff.
You included what the product actually is in the first sentence so I can tell you are still lacking some real marketing obfuscation skills
And as any marketing article it's also SEO optimized, I mean it would be strange if not. But it's core point is still marketing not SEO.
I would guess there are two possible (non exclusive) reasons:
- people ask all the time how this is different from Tailscale
- they want to take advantage of Tailsacle publicity (and AFIK succeeded)
>Narrowlink uses a centralized gateway that clients and agents connect to over HTTP/S protocols
Tunneling TCP over TCP will undoubtedly result in poor network performance. This is why WireGuard is UDP-only.
And on the other hand, HTTP/S is often using UDP for the transport now
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.
Sorry for so many questions
I also invite you to continue the discussion on the github https://github.com/narrowlink/narrowlink/discussions
You are most welcome
I think they are comparing apple to orange here.
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.
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).
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.
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.
"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.
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.
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.
> 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.
Thanks for the pointer to headscale - will take a look ;)
I recently tried to use ngrok as a daemon to my local server but it constantly kept closing the connection, and it seems to be a common issue.
But I might check out zrok.io anyways, can I run it in a container aswell?
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.
You can easily do the same thing with Tailscale: https://tailscale.com/kb/1019/subnets/.
I assume the services trough is somewhat of a poor man's service bus
In general, that page is a lot clearer about the product than the linked one.
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.
Anything stopping you there? Other than NFS being NFS?
CIFS/Samba or WebDAV should work fine?
Unfortunately they still don't have an iOS client (which e.g. Tailscale and ZeroTier has).
No central point of failure, I think.
mhm. single-handedly, though.
Especially since you can self-host headscale...
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.
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.