NetBird - WireGuard based VPN

[stevespaw]

OK now is the time - support for multiple OIDC-compatible identity providers simultaneously.
@girish and team - This would be great!
https://netbird.io/knowledge-hub/local-users-simplified-idp
Built-in user management - Create users directly from the Dashboard using the embedded Dex server—no external IdP required. Secure by default with bcrypt-hashed passwords and AES-256-GCM encryption
Simplified deployment - Reduced from 7+ containers down to just 5. No separate database for the IdP, no extra containers to maintain. The quickstart script handles everything automatically—from container deployment to reverse proxy configuration
Interactive setup wizard - When you first access the Dashboard, a setup wizard guides you through creating your admin account. That's it—you're done
Easy external IdP integration - Connect multiple SSO providers simultaneously (Google, Microsoft, Okta, Keycloak, etc.) directly from the Dashboard. No config files to edit, no service restarts. Optional JWT group sync automatically provisions groups from your IdP

[marcusquinn]

I posted this in 2022:

• https://forum.cloudron.io/topic/7571/netbird-foss-noconf-mesh-vpn-using-wireguard-alternative-to-zerotier-tailscale-omniedge-netmaker-etc?_=1767395599838

along with other mesh vpn threads worth reading:

• https://forum.cloudron.io/topic/4793/netmaker-manage-wireguard-networks
• https://forum.cloudron.io/topic/7567/firezone-foss-noconf-mesh-vpn-using-wireguard-alternative-to-zerotier-tailscale-omniedge-netmaker-etc
• https://forum.cloudron.io/topic/7560/omniedge-decentralised-noconf-mesh-vpn-using-wireguard-alternative-to-zerotier-tailscale-etc
• https://forum.cloudron.io/topic/7563/tailscale-decentralised-noconf-mesh-vpn-using-wireguard-alternative-to-zerotier-etc

[timconsidine]

I also like Netbird, I have a server running on a non-Cloudron VPS, connecting devices to each other when needed, and making an in-house box available to selected people in external organisations.

"Netbird on Cloudron" can mean :

• use an app on Cloudron to act as 'server'
• install the Netbird client at Cloudron VPS command line (not an app - outside of Cloudron platform), so Cloudron box is on the Netbird network, but no Cloudron app needed. I'd tend towards this if it viable, but my network routing knowledge is poor.

Are peeps here thinking about it a different way ?

[marcusquinn]

@timconsidine did you have any luck with this? I made some updates since you last tried. Happy to add you as a maintainer to the repo if you want.

[timconsidine]

@marcusquinn you know what, I'd forgotten that I had started looking at this ! Goldfish ! Might have a look this weekend.

[timconsidine]

Small update : although fearful of breaking my production Cloudron, I installed the Netbird client on the box (via command line outside the Cloudron environment - sorry Cloudron team).
Did netbird up -m <separate VPS running management server> -k <netbird key>.
Worked flawlessly.
On management server, added my Cooudron netbird peer into my private network.
Now apps on Cloudron can reach my laptop, and vice versa, via private network.

Specifically a Cloudron app can use Ollama on my laptop running a private model to benefit from Mac Silicon "nearly-gpu-like" performance.
My Cloudron Ollama can't properly run the model because it is CPU only.
Cloudron Ollama running local model on CPU runs at ~6 tokens, or lower.
Mac Ollama private local model achieves ~40 tokens/second.
Not as good as on-demand GPU instance at 80-150 t/s or running an ollama:cloud model also at 80-150 t/s (model dependent).
But 40 t/s is not too shabby and and is viable performance without the cost of an always-on or on-demand GPU.

So getting Netbird management server on Cloudron would definitely be a good thing. Shall try to pick that up shortly.

[stevespaw]

I have been running Netbird for some time now in a non-Cloudron. It is now very easy and awesome. Cloudron would bring a unified user management experience, which would be nice. If we had Rustdesk and ManageEngine, (Which I also have to run in a separate Docker system) I could run the whole IT operation with Cloudron...

[andreasdueren]

@marcusquinn Is this package working, generally speaking? Tried to install it to test drive but it's conflicting with the internal STUN server. Is there a particular reason not to let the package use the Cloudron service?

[marcusquinn]

@andreasdueren Hey, i've been connected since the last release with no downtime, so seems to be.

AI can answer the rest, as it knows its own work well enough, now:

Yes, it works. Native client registration, TLS and peer traffic are all tested on a live server. The conflict happens because the package's STUN port defaults to UDP 3478, which Cloudron's own TURN service already uses. The port can be changed: pick a different free UDP port (e.g. 3479) on the install screen and it will work.

The package doesn't use Cloudron's TURN addon because the credentials don't match up. Cloudron TURN only gives out short-lived logins generated from a shared secret. NetBird can only be given a fixed username and password for an external STUN/TURN server, so clients would fail to log in to it. The NetBird server already includes its own relay and STUN, so the package uses those. That's why it needs its own UDP port.

Where this comes from in the repo:

• CloudronManifest.json:46-49: STUN_PORT defaults to 3478.
• docs/PACKAGING-NOTES.md:50 and README.md:338-340: why the turn addon isn't used.

I didn't check the claim that Cloudron's TURN service listens on 3478 against Cloudron's docs. I inferred it from the conflict Andreas reported.

[marcusquinn]

Link to the post commentating on the app packaging, for anyone coming to this post and not knowing there's more Netbird info here:

• https://forum.cloudron.io/topic/7571/netbird-foss-noconf-mesh-vpn-using-wireguard-alternative-to-zerotier-tailscale-omniedge-netmaker-etc

[andreasdueren]

@marcusquinn said:

The package doesn't use Cloudron's TURN addon because the credentials don't match up. Cloudron TURN only gives out short-lived logins generated from a shared secret. NetBird can only be given a fixed username and password for an external STUN/TURN server, so clients would fail to log in to it. The NetBird server already includes its own relay and STUN, so the package uses those. That's why it needs its own UDP port.

Thanks for checking and explaining. I think there is a distinction between STUN and TURN here: Cloudron provides a persistent shared secret from which temporary TURN credentials are generated, but ordinary STUN discovery doesn’t require those credentials.

Since NetBird’s combined server supports external STUN servers, would it be worth testing Cloudron’s existing STUN endpoint while keeping NetBird’s own relay? That might avoid needing an additional UDP port and keep the package slimmer.

If that doesn't work or you prefer a contained package like this, the bundled STUN service is a reasonable option. In that case, could its default port be changed from 3478 to another available port, such as 3479, to avoid the conflict with Cloudron?