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

241–250 of 299 posts

Re: Netbird – Open Source Zero Trust Networking

#241

Post by Uptrenda »

Uptrenda wrote: post #221

Going to mention my own project which aims to be 100% open source, free, and relies almost only on public infrastructure: https://github.com/robertsdotpm/p2pd Basically, I'm building a framework for building NAT traversal plugins. Software like ngrok and P2P VPNs can then be built on top of it. Examples of plugins for the library include direct connect, reverse connect (connect back to you), TCP hole punching, and UP…

By the way I forgot to add: if anyone needs a list of public STUN, TURN, MQTT, or NTP servers I wrote a monitor for them last year and added a bunch of servers. This is basically the infrastructure I use for my P2P library. The public API is here: http://ovh1.p2pd.net:8000/servers or if you want to host it: https://github.com/robertsdotpm/dogdorm

Re: Netbird – Open Source Zero Trust Networking

#242

Post by metmac »

geoctl wrote: post #105
CubsFan1060 wrote: post #96

Earlier quoted context omitted.

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?

Thank you, I haven't accepted any contributions so far primarily because of this reason but things might change in the future. As mentioned in the README and docs, Octelium is designed specifically for self-hosting so the commercial side of the project is simply confined to commercial AGPLv3-alternative licensing, support, and other very enterprise-y/customized features such as SCIM, SIEM to specific providers, etc..…

Do you foresee this changing anytime soon? Would love to contribute but also I think community adoption and contribution would go along way in terms of businesses less worried about single points of failure.

It’s hard balance to strike for sure. And it’s getting weirder by the day with agents.

Re: Netbird – Open Source Zero Trust Networking

#244

Post by h4kunamata »

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/

According to its own documentation: https://headscale.net/stable/setup/requirements/

So instead of opening a port on my firewall for WireGuard, I must have these ports public exposed:

* tcp/80

* tcp/443

* udp/3478

* tcp/50443

I don't know about you but that seems the most insane approach. Even if HTTP-01 challenge is not used, you are still exposing 3 ports instead of 1 random-high port like 55555 for example.

Yeah yeah, you can use rever-proxy but still, you are exposing way more ports and services to the internet than just one port for WireGuard itself.

Re: Netbird – Open Source Zero Trust Networking

#245

Post by catlifeonmars »

h4kunamata wrote: post #244
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/

According to its own documentation: https://headscale.net/stable/setup/requirements/ So instead of opening a port on my firewall for WireGuard, I must have these ports public exposed: * tcp/80 * tcp/443 * udp/3478 * tcp/50443 I don't know about you but that seems the most insane approach. Even if HTTP-01 challenge is not used, you are still exposing 3 ports instead of 1 random-high port like 55555 for example. Yeah y…

Read the docs more closely.

- TCP/80 is only required to answer let’s encrypt challenges for certificate issuance

- UDP is only required to enable DERP.

These are both optional.

It’s not surprising that there are additional ports required on top of Wireguard. 443 is likely for key distribution and management. If you don’t want PKI then you don’t need headscale; you can always distribute the keys yourself and just run plain wireguard

Re: Netbird – Open Source Zero Trust Networking

#246

Post by teruakohatu »

SebastianKra wrote: post #231
smashed wrote: post #156

Earlier quoted context omitted.

We tried netbird but could not get the client to register to a self hosted server. It ignored the setting or failed. Good chance it was user error on our part. Most of their documentation is very unclear about what is a cloud offering feature and what is possible using self-hosting. There are features not available on the community edition and you have to be very careful reading their doc. Just putting it out there s…

We also had a bunch of problems. The DNS resolution didn't work, and support was unable to figure out the reason. A coworker reported domain access breaking when he went to office 1, but fixed itself when he went to office 2. For a while, when you logged in with the wrong account, it was near impossible to replace it. This on is fixed now, but the entire thing still feels very much like paying for beta software.

I have endless DNS problems with Tailscale. So I am guessing it’s a hard problem.

Re: Netbird – Open Source Zero Trust Networking

#247

Post by ImpostorKeanu »

h4kunamata wrote: post #244
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/

According to its own documentation: https://headscale.net/stable/setup/requirements/ So instead of opening a port on my firewall for WireGuard, I must have these ports public exposed: * tcp/80 * tcp/443 * udp/3478 * tcp/50443 I don't know about you but that seems the most insane approach. Even if HTTP-01 challenge is not used, you are still exposing 3 ports instead of 1 random-high port like 55555 for example. Yeah y…

80/443 is all that's necessary for Headscale as a control server.

UDP/3478 is STUN for the embedded DERP. I recommend hosting a distinct DERP server, thus decoupling the control and data planes. DERPer is open source from Tailscale.

50443 is for GRPC. I'd not expose that, even if it is protected by authentication (and tested).

Re: Netbird – Open Source Zero Trust Networking

#249

Post by braginini »

smashed wrote: post #156
regisso wrote: post #64

I recommend it the NetBird team is transparent and easy to reach. I switched from Tailscale a while ago (2y), went fully self-hosted, and upgrades across versions have been smooth, which tells me they care about the self-hosted, not just their cloud offering.

We tried netbird but could not get the client to register to a self hosted server. It ignored the setting or failed. Good chance it was user error on our part. Most of their documentation is very unclear about what is a cloud offering feature and what is possible using self-hosting. There are features not available on the community edition and you have to be very careful reading their doc. Just putting it out there s…

There is a dedicated page explaining the difference between selfhosted and cloud versions: https://docs.netbird.io/selfhosted/self-hosted-vs-cloud-netb...

You can also use profiles and set management URL in the settings through the UI. You can even switch between self hosted and cloud versions: https://docs.netbird.io/client/profiles

Re: Netbird – Open Source Zero Trust Networking

#250

Post by abcd_f »

sunshine-o wrote: post #180
abcd_f wrote: post #63

Earlier quoted context omitted.

You can conceal that open port with some form of port knocking. Though this does reinforce your "easy" point. Also, if it's an UDP port, then using a protocol that expects first client packet to be pre-authenticated and not emitting any response otherwise gets you pretty damn close to having this port closed.

Thanks for the suggestion ! I looked into it but it seems that port knocking and Single Packet AuthZ literally open the firewall and expose the port when used. Meaning it is great to reveal the SSH port when needed, do your business quickly and close it back when you are done. But my guess is those overlay networks need to port available all the time, so...

Port knocking should open up the port for the IP that sent the knock. Not for everyone.
Post reply on HN