NetBird - FOSS noconf Mesh VPN using Wireguard, alternative to ZeroTier, Tailscale, OmniEdge, Netmaker etc

[timconsidine]

@sponch ah, sorry, misunderstood, my mistake.
I've only used Netbird previously as a peer registration solution.

I see the Reverse Proxy in the left sidebar of the management app.
But I don't think it is enabled or working despite saying 'Create Service'.

NetBird Reverse Proxy feature 
This is a separate NetBird feature for exposing services behind peers to the public internet through NetBird, with auth/TLS rules. NetBird documents it as requiring:

- a NetBird reverse-proxy component/cluster
- Traefik with TLS passthrough in front of it

NetBird says self-hosted deployments must use Traefik for this feature because TLS passthrough is required
[source: NetBird Reverse Proxy docs].

I will have to look into whether this is possible. It might not be on Cloudron, so if it is important for your use case, a more traditional VPS docker plus Traefik might be needed.

[sponch]

hi @timconsidine, thanks. I've already got that extra VPS with proxy running - just could save some bugs a month if could replace it with a cloudron version of netbird

[timconsidine]

"Cloudron does not currently expose the kind of per-app TLS passthrough on 443 that NetBird Reverse Proxy needs."

It's a cool feature, though, so I'm going to have a think about a workaround.

EDIT #1 : The only Netbird-like alternative supporting this Reverse Proxy functionality is Tunnet, according to my research. But it is much younger than Netbird.

EDIT #2 : Because Cloudron platform (not base image) owns 443, unless/until there is more traffic pass-through from the platform nginx, I don't think Netbird Reverse Proxy is deliverable on Cloudron. Don't hold your breathe !

[robi]

@timconsidine maybe something the team can address for v10+.

[timconsidine]

@robi I think there is an existing feature request for more TLS passthrough while preserving core platform function. Don't know where it is or whether in mind. More likely a v11, but Christmas is always a nice time for surprise presents

[marcusquinn]

AI's reply. Not tested, but seems good:

@timconsidine @sponch thanks for investigating and documenting the transport issue.

I’ve now published v2.0.16, which adopts the dedicated native-client transport model:

• Dashboard, API and OIDC remain on normal Cloudron HTTPS/443.
• NetBird management, signal and relay traffic use a dedicated TLS/HTTP2 TCP port.
• The default external port is 33073, but use whichever TCP port is configured in Cloudron.

Client example:

sudo netbird up
--management-url https://netbird.example.com:33073
--setup-key YOUR_SETUP_KEY

The selected TCP port must be reachable through the server firewall. NetBird’s own configurable UDP STUN port is also retained. I did not use Cloudron’s TURN addon because its relay credential model is incompatible with NetBird’s built-in relay.

Internally, the native listener maps to container port 33074, because current NetBird releases reserve 33073 for their legacy gRPC listener.

Reverse Proxy clusters are still not included. That feature requires raw TLS passthrough on public port 443, which Cloudron does not currently provide per app. The dedicated client port fixes peer registration but does not remove that separate platform constraint.

Release: https://github.com/marcusquinn/cloudron-netbird-app/releases/tag/v2.0.16
Community app: https://ca.cloudron.io/app/netbird

Local runtime tests passed first-run setup, TLS validation, HTTP/2 negotiation, restart and persistence checks. I still need confirmation from a real Cloudron installation, so please let me know whether a native client now registers successfully.

[timconsidine]

@marcusquinn thank you !
Will test tomorrow.

[timconsidine]

Sorry @marcusquinn, gone down multiple rabbit-holes on other projects, so not fully tested yet, but looks to me like your solution will work.

I've been researching the NetBird reverse proxy feature, which currently isn't viable behind Cloudron's nginx. Given Cloudron team's workload, TLS passthrough is unlikely soon (unless they say otherwise).

But it looks like there might be a path with no Cloudron modifications:

• Get a 2nd public IP on the same VPS (usually cheap — less than a separate VPS)
• iptables DNAT: redirect IP2:443 → 127.0.0.1:8443
• Expose 8443 via tcpPorts in the NetBird app manifest — this bypasses Cloudron's nginx entirely (raw TCP, no TLS termination)
• Run netbird-proxy as an additional supervisord process inside the existing NetBird app; it connects to the management server at localhost
• DNS: netbird.domain.tld → IP1 (Cloudron), netbirdRP.domain.tld + *.netbirdRP.domain.tld → IP2 (DNAT to proxy)
• Survives Cloudron upgrades and restarts — iptables rules are kernel-level

This might be a solution for @sponch (and everyone).

Untested — I don't have a 2nd IP (yet !). But it would be a simple addition: no changes to Cloudron, minimal changes to the NetBird app.

[marcusquinn]

@timconsidine clever, i like the thinking! investigating...

[marcusquinn]

An update on the NetBird Cloudron package—the single-VPS reverse-proxy candidate is now merged and available to build from source:
https://github.com/marcusquinn/cloudron-netbird-app

• One Cloudron app packages NetBird management, dashboard, embedded login, native client transport and relay/STUN. Ordinary private mesh access does not need a second IP or the optional public proxy.
• The 2.1.0 candidate adds the optional NetBird reverse proxy inside that same app. This exposes selected HTTP services on mesh peers through public HTTPS, without requiring visitors to install NetBird.
• The single-VPS setup requires a second public IPv4 and documented root-admin host configuration. No second VPS or replacement of Cloudron’s managed nginx is required. This is an opt-in administrator-managed integration, not a built-in Cloudron feature.
• A controlled live deployment has exercised native peer registration, public ACME TLS, traffic to a remote WireGuard peer, header authentication and forwarded-IP spoof rejection.
• The latest integrated source passes local build/runtime checks covering initial setup, restart persistence, unprivileged services, native-port browser redirects and native OAuth continuity. Host-ingress tests include port-collision rejection and fail-closed checks.
• Setup, rollback and qualification documentation are included. The proxy is disabled by default, and its public ingress does not automatically inherit Cloudron’s normal HTTP protections.
• This is ready for experienced source-build testers, not a production-certification or App Store announcement. Full restore, renewal, reboot/platform upgrade and broader isolation/load qualification remain open. Optional Cloudron SSO onboarding is a separate follow-up.
• Feedback on fresh installations, desktop/mobile clients, custom ports and the documented single-VPS setup would be useful. Please use an isolated test environment and retain recovery access before changing host networking.
  Implementation and verification details:
  https://github.com/marcusquinn/cloudron-netbird-app/pull/141

[timconsidine]

@marcusquinn wow, that's massive ! Congratulations and thank you.

Sadly I have some boring admin days before I can test this out. But I look forward to doing so.

[marcusquinn]

@timconsidine credit to you for the idea, sir!

in my quick tests it seemed to work fine, serving a page from a mac mini.

there should be enough .md info in the package to help any AI understand it all to help with setup and testing

as always, aidevops.sh has subagents for cloudron app packaging, netbird setup and use, etc

[marcusquinn]

@timconsidine and the approach might open up similar being possible for other cloudron apps needing tls passthrough

[marcusquinn]

@braginini take a look at the latest version of the cloudron-netbird-app package — might help you get more people trying and adopting it (and hopefully nullifying all the tailscale-only options i see, that i was aggrieved enough with to work on this

fan of your work, very impressive ux!

[marcusquinn]

cloudron SSO should be working now, available for testing in the latest release

and got a new session working on syncing users with app visibility permissions, and seeing if we can integrate this with the new cloudron vpn protection features as a potentially easier way to give users vpn gated access to private wan apps

[marcusquinn]

@girish cloudron-netbird-app seems to be working nicely, now

any chance of making it a recognised app option for the vpn-protection features now in cloudron?

https://github.com/marcusquinn/cloudron-netbird-app/issues/149

[marcusquinn]

updated the screenshots in the original post to better show what it is now

great ux and community version capabilities imho