Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netbird – Open Source Zero Trust Networking

netbird.io

Post reply on HN
Print view View original

91–100 of 299 posts

Re: Netbird – Open Source Zero Trust Networking

#91

Post by geoctl »

nszceta wrote: post #86
geoctl wrote: post #70

(Shamless plug) I am also working on a similar FOSS, self-hosted project called Octelium https://github.com/octelium/octelium that you might find interesting if you are interested in this space. Octelium is, however, more of a generic/unified zero trust secure access platform that can operate as a remote access VPN, a ZTNA platform, API/AI/MCP gateway, a PaaS, an ngrok-alternative and a homelab infrastructure. It pro…

It took me too long to understand the difference between the two so I'll leave it here for others. Octelium operates on OSI Layer 7 and Tailscale operates on OSI Layer 3 and 4.

Well, yes, Octelium is technically a VPN from a layer-3 perspective since it uses WireGuard/QUIC tunneling, but the tunnel doesn't directly terminate to the destination like in VPNs but instead to an identity-aware proxy that does authentication and L7-aware authorization on a per-request basis with policy-as-code via CEL/OPA. From an architecture perspective, I assume it's closer to ZTNAs such as Cloudflare Access and Teleport than to traditional VPNs, even though it operates as one for the clien-based access mode. However, unlike VPNs, it does provide clientless/BeyondCorp access too as it's intended to operate as a more generic/unified access platform (e.g. API/AI/MCP gateway, ngrok-alternative, PaaS-like platform, etc.) rather than just a VPN.

Re: Netbird – Open Source Zero Trust Networking

#92

Post by CommanderData »

sunshine-o wrote: post #55

For someone who want to setup a private network between host/devices, I feel the dilemma is always: 1. Trust a third party like Tailscale by giving them the key to your kingdom, but everything is incredibly easy and secure. 2. Self-host but need at least one host with a fixed IP address and an open port on the Internet. What requires a set of security skills and constant monitoring. That includes headscale, selhosted…

When I look at these zero trust solutions need 80/443 for what seems some type of bootstrapping

Better it happens using the same approach wireguard takes (udp/stateless). Though I'm not sure if there's more than just bootstrap taking place, maybe constant routing updates etc

Re: Netbird – Open Source Zero Trust Networking

#93

Post by athrowaway3z »

markonen wrote: post #90
mittermayr wrote: post #47

I can only recommend giving headscale a try. It's free, works extremely well, and can be used with the official Tailscale clients. Was super easy to set up. https://headscale.net/stable/

Apparently they've deprecated Postgres support and now only recommend sqlite as the storage backend. I have nothing against sqlite but to me this looks like Tailscale actively signaling what they think the expected use of headscale is.

I dont understand what these two have to do with anything? The db-use is almost trivial, and SQLite can be embedded. Why would we want wasted effort and configuration complexity on supporting postgres?

Re: Netbird – Open Source Zero Trust Networking

#94

Post by matthewmacleod »

k_bx wrote: post #78
matthewmacleod wrote: post #42

Earlier quoted context omitted.

There is some confusion here because while you can disable node key expiration, you can’t disable auth key expiration. But that’s less of a problem than it seems - auth keys are only useful for adding new nodes, so long expiry times are probably not necessary outside of some specific use-cases. Edit: in fact from your original post it sounds like you’re trying to avoid re-issuing auth keys to embedded devices. You do…

I want my CI containers created per branch/PR to have their own Tailscale domain, so logging them in is useful via non-expiring key. Only good option I've seen previously is to notify every 90 days when key expires.

The best way to do that is using an OAuth client. These don't expire, and grant scoped access to the Tailscale API. You use this to generate access keys for the devices that need to authenticate to the network.

We use this for debugging access to CI builds, among other things – when a particular build parameter is set, then the CI build will use an OAuth key to request an ephemeral, single-use access key from the Tailscale API, then use that to create a node that engineers can SSH into.

Access keys ideally should be short-lived and single-use where possible. https://tailscale.com/kb/1215/oauth-clients#generating-long-... has details on this flow.

Re: Netbird – Open Source Zero Trust Networking

#95

Post by sigio »

I've head Netbird running for the last few months... In general it works quite well, but it would keep messing with my dns-resolving, and I couldn't find the setting to stop it inserting itself into my resolv.conf.

During the last few weeks I've removed netbird from all my systems (about 12), mostly because of issues on laptops where resolving or networking would break after they moved to a different network/location.

Re: Netbird – Open Source Zero Trust Networking

#96

Post by CubsFan1060 »

geoctl wrote: post #70

(Shamless plug) I am also working on a similar FOSS, self-hosted project called Octelium https://github.com/octelium/octelium that you might find interesting if you are interested in this space. Octelium is, however, more of a generic/unified zero trust secure access platform that can operate as a remote access VPN, a ZTNA platform, API/AI/MCP gateway, a PaaS, an ngrok-alternative and a homelab infrastructure. It pro…

I've been keeping my eye on this one, it's very interesting.

Feel free to ignore this, but, what's your long term plan here? I see you have Enterprise plans (especially that allow different licenses). From what I can tell you're the only contributor, but, I assume that if you accepted contributions there'd be a CLA?

Re: Netbird – Open Source Zero Trust Networking

#97

Post by ghrl »

markonen wrote: post #90
mittermayr wrote: post #47

I can only recommend giving headscale a try. It's free, works extremely well, and can be used with the official Tailscale clients. Was super easy to set up. https://headscale.net/stable/

Apparently they've deprecated Postgres support and now only recommend sqlite as the storage backend. I have nothing against sqlite but to me this looks like Tailscale actively signaling what they think the expected use of headscale is.

https://headscale.net/stable/about/faq/#scaling-how-many-cli...

> Scaling / How many clients does Headscale support? > It depends. As often stated, Headscale is not enterprise software and our focus is homelabbers and self-hosters. Of course, we do not prevent people from using it in a commercial/professional setting and often get questions about scaling. > Please note that when Headscale is developed, performance is not part of the consideration as the main audience is considered to be users with a modest amount of devices. We focus on correctness and feature parity with Tailscale SaaS over time. [...] > Headscale calculates a map of all nodes that need to talk to each other, creating this "world map" requires a lot of CPU time. When an event that requires changes to this map happens, the whole "world" is recalculated, and a new "world map" is created for every node in the network. [...] > Headscale will start to struggle when [there are] e.g. many nodes with frequent changes will cause the resource usage to remain constantly high. In the worst case scenario, the queue of nodes waiting for their map will grow to a point where Headscale never will be able to catch up, and nodes will never learn about the current state of the world.

I find that quite interesting and it is one of the reasons I've not really considered trying out Headscale myself.

Re: Netbird – Open Source Zero Trust Networking

#98

Post by matthewmacleod »

stingraycharles wrote: post #52
matthewmacleod wrote: post #41

Earlier quoted context omitted.

What would be your use-case for auth keys with long expiry times? Auth keys are only required for registering new nodes.

When managing your infrastructure as code, it’s quite common to deploy new instances for upgrades etc. Having these keys expire after 3 months is a big pain. Eg doing a routine update by rebuilding an AMI. I don’t understand how they can have such a strategy, and then not having any decent way to programmatically allocate new keys.

Yeah, that's a common workflow. It's easy to programatically allocate those keys using the OAuth workflow though – there's even a CLI utility to do it (https://tailscale.com/kb/1215/oauth-clients#get-authkey-util...)

This can all be automated using e.g. the Terraform Tailscale provider, which takes the OAuth id/secret and can then issue keys as needed for the infrastructure you are deploying.

Re: Netbird – Open Source Zero Trust Networking

#99

Post by sigio »

fc417fc802 wrote: post #61
sunshine-o wrote: post #56

Earlier quoted context omitted.

Makes a lot of sense. But self-hosting still require at least a public domain name [0], so here goes your privacy right? - [0] https://docs.netbird.io/selfhosted/selfhosted-quickstart#inf...

> The VM must be publicly accessible on TCP ports 80 and 443, and UDP port 3478. > A public domain name that resolves to the VM’s public IP address. Since it already uses DNS it's disappointing that it hardcodes ports instead of using SRV records. IMO anything that can use SRV records should. It makes for a more robust internet.

The number of products that actually use SRV records is surprisingly low (besides some mailservers and kerberos)

Re: Netbird – Open Source Zero Trust Networking

#100

Post by usagisushi »

m_santos wrote: post #71
usagisushi wrote: post #48

Netbird's flexibility with IdPs is really nice. I recently switched mine to Pocket ID. Overall, it's perfectly sufficient and lightweight for homelab use.

Thanks for your feedback. I have a question: What do you think about the number of containers in our quick start deployment? Was that a concern?

You’re from the dev team, right? Thanks for the amazing OSS!

Regarding the containers, AFAIK it's 5 for the core setup (dashboard/signal/management/relay/coturn) plus Traefik in my case. It feels like a bit much, but the services are almost stateless and not resource intensive even on my little VPS. The setup script (bash + envsubst) is so straightforward and thanks to good documentation, I’ve never found the setup confusing. (I use Renovate to keep things updated, but I’d love to know if there's a recommended update path.)

A couple of minor things I noticed: 1. the dashboard image isn't on ghcr.io. 2. the generated compose.yaml contains hardcoded values. It could be even better if it referenced values from a .env file instead.

By the way, are there any ways to support NetBird other than GitHub Sponsors?

Post reply on HN