Help needed with self-hosted NetBird: Traefik port conflicts and stuck wildcard certificates via Cloudflare

Community Support Self-Hosted
1

Hi everyone,

I am currently trying to migrate my entire self-hosted infrastructure from Nginx to NetBird, but I am stuck with the initial configuration regarding routing, port conflicts, and SSL certificate issuance.

My domain is registered with Cloudflare, where both my root domain (example.de) and the NetBird management subdomain (netbird.example.de) point directly to my public home IP via A records with the Cloudflare proxy disabled. I also have a wildcard CNAME for *.netbird.example.de pointing to the management subdomain. On my local router, ports 80, 443, and the STUN port 3478 are forwarded to my main server. This single server runs multiple Docker containers on various ports and is supposed to host the NetBird Management instance, the Routing Peer, and the Proxy all at once. I used the official advanced setup script with the built-in Traefik instance to deploy it.

To route my local services through NetBird, I set up a reverse proxy cluster on this same server. However, since the NetBird-integrated Traefik instance already occupies ports 80 and 443, I ran into an immediate port conflict. To bypass this, I changed my proxy cluster ports to 280 and 2443. While the cluster is recognized and the custom domains are validated, I hit a wall when adding actual services. Whenever I try to add a service under a subdomain, such as app1.example.de, the status gets permanently stuck on “issuing Certificate” and the service never becomes reachable. I assume this happens because the standard HTTP-01 validation fails due to the non-standard ports or because it is trying to publicly validate an internal routing setup.

Ultimately, I want all my subdomains to be strictly private and only accessible when a client is connected via the NetBird VPN app, with only a few rare public exceptions. Furthermore, I want all these subdomains to share a single wildcard certificate (*.example.de) instead of getting individual certificates, because I do not want my internal service names to appear in public Certificate Transparency logs.

I would really appreciate some help on how to resolve the port conflict between the integrated Traefik and my local proxy, how to configure the host or NetBird setup to use a Cloudflare DNS-01 challenge for the wildcard certificate, and whether I need to adjust any specific settings or API tokens on the Cloudflare side to make this work.

Thanks in advance for your help!

2

Correct me if I am reading this wrong, but it sounds like you setup a second proxy on your management server?

If so, that is probably where the port clash comes from. A second proxy should be on a separate VM or VPS.

All you need to do is add the NB_PROXY_PRIVATE=true line into the proxy.env file for the main proxy. That is what I did and it works well - both private and publicly exposed services work (and private services stay private).

(Don’t forget to also update netbird.grpc rule as directed here. Scroll down to the “Upgrading a self hosted deployment” section)

3

I managed to get it working eventually, but it wasn’t the right solution for my particular use case.

My goal was to control exactly which users could access specific resources. While this is possible with NetBird, I experienced occasional crashes of both the Management Server and the Relay. Because of that, I decided to switch to a different approach.

Now, each user has their own unique mTLS client certificate installed on their device, and access control is handled directly through NGINX rules instead of NetBird policies. It took some effort to set everything up, but it now works exactly the way I wanted.

Adding new users is straightforward as well, since I built a small web frontend for certificate management and automatic NGINX configuration generation.

NetBird is still a fantastic piece of software, and I can definitely see why many people use it successfully. However, for my specific requirements, it wasn’t stable enough and added more complexity than I wanted to maintain. I’m sure it will be an excellent solution for many other use cases.

4

That sounds like an interesting solution. Glad you found something that works for you.

Thanks for sharing it.