NetBird - WireGuard based VPN
-
Coming from Zerotier _ I any really digging Netbird - Super easy setup and now have "networks" which we had on Zerotier. Running on their host now, but would love to have our own server on Cloudron. This is much more powerful than the basic wireguard in the VPN app. Please?
@stevespaw Agreed!
-
-
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 -
I posted this in 2022:
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
-
S stevespaw referenced this topic on
-
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 ?
Indie app dev, scratching my itches : communityapps.appx.uk, portfolio at myca.appx.uk
-
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 ?
@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.
Web Design & Development: https://www.evergreen.je
Technology & Apps: https://www.marcusquinn.com -
@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.
@marcusquinn you know what, I'd forgotten that I had started looking at this ! Goldfish ! Might have a look this weekend.
-
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).
Didnetbird 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.
-
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...
-
@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.
@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 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?
@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:50andREADME.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.
Web Design & Development: https://www.evergreen.je
Technology & Apps: https://www.marcusquinn.com -
Link to the post commentating on the app packaging, for anyone coming to this post and not knowing there's more Netbird info here:
-
@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:50andREADME.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.
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
STUNandTURNhere: Cloudron provides a persistent shared secret from which temporaryTURNcredentials are generated, but ordinarySTUNdiscovery doesn’t require those credentials.Since NetBird’s combined server supports external
STUNservers, would it be worth testing Cloudron’s existingSTUNendpoint while keeping NetBird’s own relay? That might avoid needing an additionalUDPport and keep the package slimmer.If that doesn't work or you prefer a contained package like this, the bundled
STUNservice is a reasonable option. In that case, could its default port be changed from3478to another available port, such as3479, to avoid the conflict with Cloudron? -
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
STUNandTURNhere: Cloudron provides a persistent shared secret from which temporaryTURNcredentials are generated, but ordinarySTUNdiscovery doesn’t require those credentials.Since NetBird’s combined server supports external
STUNservers, would it be worth testing Cloudron’s existingSTUNendpoint while keeping NetBird’s own relay? That might avoid needing an additionalUDPport and keep the package slimmer.If that doesn't work or you prefer a contained package like this, the bundled
STUNservice is a reasonable option. In that case, could its default port be changed from3478to another available port, such as3479, to avoid the conflict with Cloudron?@andreasdueren You're right, thanks for spotting.
I tested it on a live install: with
server.stunspointing at Cloudron'sSTUN(CLOUDRON_TURN_SERVER:CLOUDRON_TURN_PORT).NetBird switches off its own
STUN, clients report Cloudron'sSTUNas available, peers connect, and NetBird's own relay keeps running.The new release uses Cloudron's
STUNby default, so new installs won't need an extra UDP port or clash on3478.LMK if it works for you.
Web Design & Development: https://www.evergreen.je
Technology & Apps: https://www.marcusquinn.com -
@andreasdueren You're right, thanks for spotting.
I tested it on a live install: with
server.stunspointing at Cloudron'sSTUN(CLOUDRON_TURN_SERVER:CLOUDRON_TURN_PORT).NetBird switches off its own
STUN, clients report Cloudron'sSTUNas available, peers connect, and NetBird's own relay keeps running.The new release uses Cloudron's
STUNby default, so new installs won't need an extra UDP port or clash on3478.LMK if it works for you.
@marcusquinn Seems to work, is there a way to set up the package to preconfigured OIDC with Cloudron? Currently it requires manual setup.
-
@marcusquinn Seems to work, is there a way to set up the package to preconfigured OIDC with Cloudron? Currently it requires manual setup.
@andreasdueren investigating...
-
@marcusquinn Seems to work, is there a way to set up the package to preconfigured OIDC with Cloudron? Currently it requires manual setup.
@andreasdueren courtesy of AI — opus does all my r&d now):
Glad it works! It isn't fully automatic, by design:
- NetBird keeps external login providers in its database and only accepts new ones through its API from a logged-in owner. The combined server's config.yaml (v0.80.0) has no option to predefine an OIDC provider. Doing it at startup would mean storing an owner API token inside the app, and it could overwrite an existing provider or spread the client secret around.
- If you ticked Cloudron SSO at install, it's about a minute of work: Settings > Identity Providers > Add > Generic OIDC, name it Cloudron, and paste the values from cloudron exec --app <app> -- printenv CLOUDRON_OIDC_ISSUER (then CLOUDRON_OIDC_CLIENT_ID and CLOUDRON_OIDC_CLIENT_SECRET). Keep the built-in email login working as your recovery login.
- To script it, or to add Cloudron login to an install without SSO, scripts/cloudron-sso.py in the repo does it with short-lived tokens; see docs/SSO-SWITCH.md. A login client added that way doesn't follow the app's Cloudron access list, so the script requires NetBird's new-user approval to be switched on.
If NetBird adds login providers to config.yaml, I'll switch the package to that.
And some more improvements from testing in a new release:
The monitoring guide now covers the proxy backend over IPv6 as well as IPv4 (PR #183, merged). This was a docs-only change, so no new package was published and your app stays on 2.4.3.
What changed in docs/MONITORING.md:- A new IPv6 row for the inverted <closed> check on the proxy backend port.
- A note that Docker publishes app ports over IPv6 too, so on an IPv6 server you need the check for both IPv4 and IPv6.
- The API example now includes the IPv6 native-port and IPv6 backend checks.
- A note that updown rejects a URL that is already registered, so running the example again is safe. I saw this happen when I re-ran my own script.
The docs and package tests passed, and CI passed.
You already have both IPv6 checks running for your server, and both are up.
Web Design & Development: https://www.evergreen.je
Technology & Apps: https://www.marcusquinn.com -
@andreasdueren courtesy of AI — opus does all my r&d now):
Glad it works! It isn't fully automatic, by design:
- NetBird keeps external login providers in its database and only accepts new ones through its API from a logged-in owner. The combined server's config.yaml (v0.80.0) has no option to predefine an OIDC provider. Doing it at startup would mean storing an owner API token inside the app, and it could overwrite an existing provider or spread the client secret around.
- If you ticked Cloudron SSO at install, it's about a minute of work: Settings > Identity Providers > Add > Generic OIDC, name it Cloudron, and paste the values from cloudron exec --app <app> -- printenv CLOUDRON_OIDC_ISSUER (then CLOUDRON_OIDC_CLIENT_ID and CLOUDRON_OIDC_CLIENT_SECRET). Keep the built-in email login working as your recovery login.
- To script it, or to add Cloudron login to an install without SSO, scripts/cloudron-sso.py in the repo does it with short-lived tokens; see docs/SSO-SWITCH.md. A login client added that way doesn't follow the app's Cloudron access list, so the script requires NetBird's new-user approval to be switched on.
If NetBird adds login providers to config.yaml, I'll switch the package to that.
And some more improvements from testing in a new release:
The monitoring guide now covers the proxy backend over IPv6 as well as IPv4 (PR #183, merged). This was a docs-only change, so no new package was published and your app stays on 2.4.3.
What changed in docs/MONITORING.md:- A new IPv6 row for the inverted <closed> check on the proxy backend port.
- A note that Docker publishes app ports over IPv6 too, so on an IPv6 server you need the check for both IPv4 and IPv6.
- The API example now includes the IPv6 native-port and IPv6 backend checks.
- A note that updown rejects a URL that is already registered, so running the example again is safe. I saw this happen when I re-ran my own script.
The docs and package tests passed, and CI passed.
You already have both IPv6 checks running for your server, and both are up.
@marcusquinn Looking into this, I found NetBird’s automated setup documentation, which looks like it could offer an alternative for fresh installs.
With
NB_SETUP_PAT_ENABLED=true, the initialPOST/api/setuprequest can create the local owner and return a short-lived PAT. A setup script could then use that token to callPOST/api/identity-providers, passing Cloudron’sCLOUDRON_OIDC_ISSUER,CLOUDRON_OIDC_CLIENT_IDandCLOUDRON_OIDC_CLIENT_SECRETas a genericOIDCprovider.The provider configuration would remain in NetBird’s database, so the bootstrap token could be revoked afterward rather than kept inside the app. The local owner login could remain available for recovery.
Would that be worth considering for automatic SSO configuration when the Cloudron SSO checkbox is selected?
-
@marcusquinn Looking into this, I found NetBird’s automated setup documentation, which looks like it could offer an alternative for fresh installs.
With
NB_SETUP_PAT_ENABLED=true, the initialPOST/api/setuprequest can create the local owner and return a short-lived PAT. A setup script could then use that token to callPOST/api/identity-providers, passing Cloudron’sCLOUDRON_OIDC_ISSUER,CLOUDRON_OIDC_CLIENT_IDandCLOUDRON_OIDC_CLIENT_SECRETas a genericOIDCprovider.The provider configuration would remain in NetBird’s database, so the bootstrap token could be revoked afterward rather than kept inside the app. The local owner login could remain available for recovery.
Would that be worth considering for automatic SSO configuration when the Cloudron SSO checkbox is selected?
@andreasdueren Claude Opus 5.5 says:
Thanks Andreas, great suggestion. It's in NetBird package 2.6.0.
When the app is installed with Cloudron SSO ticked, the owner's first /setup goes through a small loopback helper. It adds create_pat: true, pat_expire_in: 1 (the dashboard doesn't send these) and uses the token once:
- turns on new-user approval;
- adds a Cloudron OIDC provider from the addon credentials, unless one already exists;
- deletes the token, checks it no longer works, and removes it from the response to the browser.
Nothing runs at startup, and the token and secret are never logged. The local owner login stays as the recovery login. If registration fails, setup still succeeds and the log points to the manual steps. Cloudron users wait for approval before they get access.
I've tested the fallback path (unreachable issuer, token cleanup). I haven't yet tested a successful registration on a real fresh SSO install, so reports are welcome.
The dashboard's Add Peer command now also includes --enable-rosenpass --rosenpass-permissive by default.
Web Design & Development: https://www.evergreen.je
Technology & Apps: https://www.marcusquinn.com -
M marcusquinn referenced this topic
-
@andreasdueren Claude Opus 5.5 says:
Thanks Andreas, great suggestion. It's in NetBird package 2.6.0.
When the app is installed with Cloudron SSO ticked, the owner's first /setup goes through a small loopback helper. It adds create_pat: true, pat_expire_in: 1 (the dashboard doesn't send these) and uses the token once:
- turns on new-user approval;
- adds a Cloudron OIDC provider from the addon credentials, unless one already exists;
- deletes the token, checks it no longer works, and removes it from the response to the browser.
Nothing runs at startup, and the token and secret are never logged. The local owner login stays as the recovery login. If registration fails, setup still succeeds and the log points to the manual steps. Cloudron users wait for approval before they get access.
I've tested the fallback path (unreachable issuer, token cleanup). I haven't yet tested a successful registration on a real fresh SSO install, so reports are welcome.
The dashboard's Add Peer command now also includes --enable-rosenpass --rosenpass-permissive by default.
@james do i get an
APP DEVbadge of honour yet?
Web Design & Development: https://www.evergreen.je
Technology & Apps: https://www.marcusquinn.com
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login