I still think that the level of Tailscale’s logging is excessive to the point of it having an ulterior motive, but the article does make an attempt at allaying privacy concerns. Interesting read, thanks for sharing.
At least they’re being honest about it. They’re literally telling you not to use their service if you want to be anonymous.
Creating a Tailscale account requires having Apple, Google, and Microsoft accounts. Who would expect anonymity from Tailscale under these conditions?
Seriously? Only 3 options? No way to use email and password?
There’s some other options but a password isn’t one of them, all external accounts.
I feel like most people do not actually benefit from the easy mesh networking Tailscale provides, and could just use a simple central WireGuard server, either on a VPS or at home. I’ve mainly switched back to this setup (well, sort of) and it’s been no problem.
If you actually do need an easy mesh VPN, Netbird might be solid as a self-hosted alternative. I never got a chance to really use it but I know other people who do.
Tailscale is probably “best” if your needs are too complex for WireGuard, and you’re not savvy enough to install Netbird, but between both things that seems like a pretty small percentage of people…
Speaking of not being an anonymity service, I stumbled across this ticket on Tailscale’s GitHub. It’s been open for 3 months with no response:
When “Use Tailscale DNS settings” is checked in macOS, Tailscale additionally records all your system’s DNS queries. This means that when this box is checked, on machines where it is installed, Tailscale will collect metadata about your laptop’s routine web browsing, such as when you visit Google.com, and when your server retrieves updates from Ubuntu, your AWS account ID, your EKS endpoints, and other private hash information that appears in domain names. This is your “Internet browsing metadata”.
Yeah I’ve been reading more and more here on Tailscale and I’d like to switch.
My use case is accessing my NAS files from outside my country securely and privately. What would be the easiest alternative?
Edit: from my research, it would be Headscale or Netbird.
I think that the best they can provide are passkeys even as of today
I’m currently exactly in that situation, currently considering giving a try to Netbird because:
- having a Wireguard-only setup will require me to have an external VPS or expose my LAN to the Internet
- or give all my anonymity to Tailscale
- or limit it somewhat by using Headscale (but the setup is not the most friendly/stable)
Turns out, Netbird looks like a better solution overall because it’s fully FOSS and not a hacky community backend-compatible solution.
But maybe I missed out a basic feature of WG that would allow me to skip opening any kind of ports on my router? A buddy told me to maybe do some port knocking but that idea doesn’t sound too exciting tbh.
Is there a way to have a native access to my LAN from outside my home ala Tailscale with only WG? ![]()
Haha yes, I’m coming exactly from your previous post here
I self-host netbird and don’t have any ports open on my LAN because I host it on a VPS (costs $1/mo). Port knocking was excessive for my setup, but my VPS is running fail2ban + ufw + I moved my sshd away from port 22 towards something more obscure port.
IIRC, if you aren’t a self-hoster, you can use netbird’s cloud version for free and avoid opening any ports a la Tailscale
I am not a security sysadmin and do not believe that I can harden a VPS enough to the point of making it bullet proof, and no I do not consider fail2ban + ufw + obscuration to be a safe enough solution.
Hence, an entry point outside of my LAN is a no-go. No system exposed to the Internet is trustworthy IMO especially if you need to trust the VPS provider.
But I can probably manage to selfhost it myself without too much issue. Mostly wanted to know which one to pick: Headscale or Netbird. It was trickier than expected to make the first one work out properly because of all the Docker networking (still new to it).
But was also curious to know if WG only could solve my problem because I started to reach the end of my networking knowledge. ![]()
I think you might have a misunderstanding on a few things. Traditional VPNs are like a post office: mail/traffic passes through someone else’s purview and you pray that no one snoops… OTOH, the control plane (aka the docker container running netbird/headscale) simply tells the devices how to find each other and gets out of the way so that devices can to talk to each other directly
Here’s an analogy:
You and a friend both want to meet up at a crowded festival
- You both call the festival info booth
- The booth worker tells you: “Your friend is at the north entrance”
- The booth worker tells your friend: “They’re at the south entrance”
- You both walk toward each other, meet up and talk about secret stuff, Because you are talking directly to each other instead of the booth, it doesn’t really matter.
- If a third friend wanted to join, you reach out to the booth again and to get their coordinates
In this analogy:
You = your LAN
The Booth worker = the Control Plane
Your friend(s) = devices connected to a network other than your LAN
Since the booth doesn’t hear what you talk about, where the booth is located is irrelevant as long as its in a location where both you and your friend can reach it. Speaking of which…
If you are/were hosting a control plane on your LAN, it is almost certainly exposing your LAN to the internet. This is because by default, Docker punches holes through firewalls. This has been a case for over a decade and while most see it as a bug, Docker sees it as a feature
To reiterate, the whole purpose of the VPS is so that you do not have to open any ports on your LAN which is safer than your current setup if it is unintentionally exposing ports on your LAN. If you want to truly avoid exposed ports, the control plane needs to be somewhere already public (like a VPS), or you need something like Cloudflare Tunnel to proxy it.
Speaking of pure WG setup: Isn’t opening an UDP port on your WAN-LAN router the much lesser evil, than need to configure a public Netbird VPS? Latter needs to consider hardening of many services like SSH, Netbird coordiation server, and also should incorporate mentioned fail2ban and other security features, which probably is overwhelming for most users - I’ll count myself to that set. WG doesn’t even respond to port scanning requests from inet or connection attempts with invalid credentials.
Hence I’d be curious: Why did you chose Netbird+VPS over plain WG server in LAN, UDP port forwarding + DDNS (if needed for dynamic IPs) here from security perspective?
Good question. I had to reevaluate my priors. To be frank, I was of the impression that opening any ports on LAN = bad. Now I understsand that this is true theoretically but not meaningfully re: UDP/WG ports.
Re: my personal security/privacy choices:
- I was using Tailscale but wanted a similar experience but w/ privacy in mind. WG is more secure/private than tailscale, but would’ve been a step backwards feature-wise so it was essentially a non-starter. Headscale was an option but I don’t like how dependent/intertwined it seems to be with tailscale.
- For features present in both Netbird and WG, Netbird’s modern GUI interface makes advanced features easier to implement: I can easily create rules to limit network access (ie if you have multiple VLANs for different threat models.. maybe the IoT devices are on a different VLAN than the guest wifi/work laptop which is on a different VLAN than your personal server. You can limit/edit device’s access to different networks on the fly). Also, perhaps overkill for the average user, but you can also do things like auto expire keys shared w/ guests/used temporarily or set posture checks.
- Using netbird + VPS means I can use an exit node to obscure my web traffic from my ISP (Comcast) and obscure my IP address generally.
- As a backup option, I can use any browser on anyone’s computer to access my networks securely w/o compromising my security
- (Almost exclusively theoretical point ahead) If WG is compromised, your entire LAN is compromised. With my current setup, it would require an exploit of my VPS + 2FA + Control Plane +Home Peer private keys, all at the same time.
If I knew nothing about either option but had a better grasp of UDP ports at the time, I likely would’ve went with Wireguard since I typically prefer the minimalist solution. It is likely overkill for people that just want to get things up and running quickly + securely. With that said, netbird exceeds Wireguard in terms of security (albeit more nuanced than only looking at an “external hackers” threat), usability and features (current and prospective).
Thanks for the elaborate answer @anon92357554 . Some of those features sound cool, and I probably will give it a try in future.
But I disagree with the point, that NetBird is more secure than plain WireGuard.
The security risk I am seeing with NetBird is: Its control server is regarded as trust root for all peers and even LAN access, while at the same time being a public-facing VPS.
- In general a public-facing linux server requires effort and knowledge to harden against malicious actors, which probably excludes many users.
- NetBird management service opens quite a few ports, like TCP/443 and multiple UDP ports, in addition to SSH and other needed administration ports for VPS.
- Compare that to lightweight WireGuard protocol, which opens a single UDP port, automatically protects against DDOS and port scanning attacks by not responding to invalid packets, provides implicit access control by declaring allowed remote peer public keys and
AllowedIPs. WG server might optionally be added to specific VLAN for better segmentation.
With public VPS, I think it always makes sense to include “external hackers” in the threat model. Worst-case scenario is a full compromise of that Linux system, which would allow an attacker to alter NetBird management service configuration (let’s call control server C for brevity):
Cadds malicious peerMto its managed devicesCdiscovers existent routing peerR(node, that advertises and allows access to your internal home LAN subnet)CletsMcommunicate withR.RfetchesM’s added public key fromC.Mhas network access to all LAN devices and can decrypt traffic sent byR.Calso might invalidate public keys of other existent peers, so that NetBird client agents are instructed to re-fetch these. It then might do some sort of MITM attack.- The only way to prevent this MITM attack in my view is to use WireGuard
PreSharedKeyproeprty, which is a shared secret between two peers. It allows additional authentication between peers (like 2FA) and allows to put less trust into control server. But this kinda would undermine convenience of NetBird’s auto-configuration again.
(Please take that with a grain of salt, I am not a NetBird user yet)
Even if that scenario sounds a bit hypothetical, it is leveraged by the fact, that you need to trust an additional party (NetBird control server), which is not the case with plain WireGuard. Of course, if a peer gets compromised either with NetBird or plain WG, it naturally also has access to your LAN.
The other disadvantage I am seeing is need for separate NetBird client agent app. E.g. this prevents WG connection to be used in combination with Rethink DNS for Android. For Android specifivally I dislike, there is no official F-Droid version, the Google Play client seems to have tracker integrated and demands adservices permissions.
If your ISP uses CGNAT though, some kind of relay proxy / NetBird seems to be obligatory.
Touche. I was thinking of a hacker attempting to gain access and attempting to gain access via the protected dashboard, not via the (theoretically) exposed management server.
With that said, to clarify, when I said:
I was not insinuating that we shouldn’t care about external threats. I was operating under the assumption that both wireguard or netbird (+ VPS) are properly configured, so the odds of a stranger forcing their way into either setup is trivial.
With that in mind, netbird, as a zero-trust network architecture also accounts for internal threats, reducing its attack surface in a meaningful way that is not as feasible w/ WG.