NetBird - WireGuard based VPN
-
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 -
@DanTheMan Cool, perhaps you can contribute a guide for the community?
One notable thing is that Netbird uses Rosenpass.eu, allegedly post quantum secure set of algorithms that works with Wireguard.
@robi rosenpass is on by default now
-
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...
@stevespaw my aidevops.sh harness has all the skills needed for Cloudron app packaging, now. I used that and Opus 5.5 to package this, and other community apps.
Worth a try if you want to package RustDesk & ManageEngine. It's prob a few hours work, and with ssh to a cloudron instance can do all the testing for you, too.
-
@james do i get an
APP DEVbadge of honour yet?Hello @marcusquinn
do i get an APP DEV badge of honour yet?
You have 3x community apps, if you'd like the badge I'll add you.
-
Hello @marcusquinn
do i get an APP DEV badge of honour yet?
You have 3x community apps, if you'd like the badge I'll add you.
@james how many apps do you want?
Jeez, just seen my post count, here. You got a badge for
SUPER FANtoo?
Web Design & Development: https://www.evergreen.je
Technology & Apps: https://www.marcusquinn.com -
@james how many apps do you want?
Jeez, just seen my post count, here. You got a badge for
SUPER FANtoo?Hello @marcusquinn
You got a badge for SUPER FAN too?
Not yet, but maybe we could add such a thing.
I know that Discourse has some gamification for topics read, created hearts given and received and more.
There even is a gamification in Discourse if you finish the tutorial of how to write topics you get a certificate and a badge. -
Hello @marcusquinn
You got a badge for SUPER FAN too?
Not yet, but maybe we could add such a thing.
I know that Discourse has some gamification for topics read, created hearts given and received and more.
There even is a gamification in Discourse if you finish the tutorial of how to write topics you get a certificate and a badge.@james ahah, gold
for you my friend -
@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.
@andreasdueren Claude Opus 5.5 says:
Did @andreasdueren just outsmart Opus?
-
Hello @marcusquinn
do i get an APP DEV badge of honour yet?
You have 3x community apps, if you'd like the badge I'll add you.
You have 3x community apps, if you'd like the badge I'll add you.
Wait, don't get me wrong, I think @marcusquinn is great, but the AppDev badge existed before Community Apps did, and until this moment I think had been reserved for people who initially packaged apps that are now in the official app store.
Given @staff's understandable desire to distinguish between official and community apps (the latter of which are of varying quality) IMHO it should probably be reserved for that.
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