NetBird Reverse Proxy: Interne Services sicher ins Internet exponieren


NetBird hat mit dem Reverse Proxy ein Feature veröffentlicht, das Self-Hosted-Setups grundlegend verändert: Interne Services lassen sich jetzt direkt über das WireGuard-Mesh-Netzwerk ins Internet exponieren – ohne Port-Forwarding, ohne Firewall-Regeln, mit automatischem TLS und optionaler Authentifizierung.
Enterprise VPN Flatrate: Wir bieten Managed NetBird zum Festpreis – unbegrenzte User & Geräte, gehostet in Deutschland. 14 Tage kostenlos testen →
Inhaltsverzeichnis
- Was ist der NetBird Reverse Proxy?
- Wie funktioniert es?
- Authentifizierung: SSO, Passwort und PIN
- Self-Hosted Setup
- Service erstellen: Step-by-Step
- Path-Based Routing und Multi-Target
- NetBird Reverse Proxy vs. Alternativen
- Use Cases
- Einschränkungen (Beta)
- Unsere Leistungen
- Weiterführende Guides
Was ist der NetBird Reverse Proxy?
Der NetBird Reverse Proxy exponiert interne Services, die auf Peers oder hinter Network Resources laufen, ins öffentliche Internet. NetBird übernimmt dabei:
- TLS-Terminierung mit automatischen Let's-Encrypt-Zertifikaten oder eigenen Zertifikaten
- Optionale Authentifizierung per SSO (OIDC), Passwort oder PIN
- Traffic-Routing durch verschlüsselte WireGuard-Tunnel zum Ziel-Service
Der Ziel-Service benötigt keine öffentliche IP-Adresse und keine offenen Ports. Er muss lediglich innerhalb des NetBird-Netzwerks erreichbar sein.
Status: Das Feature ist aktuell in der Beta und nur für Self-Hosted-Deployments verfügbar. Cloud-Support folgt (Dokumentation).
Wie funktioniert es?
Der Ablauf bei einer eingehenden Anfrage:
- Service erstellen → NetBird provisioniert eine öffentliche Domain mit TLS-Zertifikat
- HTTPS-Request an die Domain → TLS-Terminierung am NetBird Proxy Cluster
- WireGuard-Tunnel → Der Request wird durch den verschlüsselten Tunnel zum Ziel-Peer weitergeleitet
- Response folgt denselben Weg zurück
Kernkonzepte
| Konzept | Beschreibung |
|---|---|
| Service | Konfigurationseinheit: mappt eine öffentliche Domain auf interne Targets |
| Target | Ziel innerhalb des NetBird-Netzwerks: Peer, Host (IP), Domain oder Subnet |
| Domain | Öffentliche URL – automatisch generiert (Cluster) oder eigene Custom Domain |
Jeder Service kann mehrere Targets für Path-basiertes Routing haben. Targets unterstützen HTTP und HTTPS als Backend-Protokoll.
Authentifizierung: SSO, Passwort und PIN
Jeder Service kann mit einer oder mehreren Authentifizierungsmethoden geschützt werden:
| Methode | Beschreibung |
|---|---|
| SSO (Single Sign-On) | Authentifizierung über den konfigurierten Identity Provider (OIDC). Optional auf bestimmte Gruppen einschränkbar. |
| Passwort | Schutz mit einem gemeinsamen Passwort |
| PIN-Code | Schutz mit einem numerischen Code |
| Keine Authentifizierung | Service ist öffentlich zugänglich (Warnung im Dashboard) |
Mehrere Methoden können gleichzeitig aktiviert werden – Nutzer wählen beim Zugriff ihre bevorzugte Methode.
Für Unternehmen mit bestehender IdP-Integration (Keycloak, Azure AD, Okta, Google Workspace) ist SSO die naheliegende Wahl: Mitarbeiter authentifizieren sich mit ihren bestehenden Credentials, Gruppen-basierte Einschränkungen steuern den Zugriff granular.
Self-Hosted Setup
Self-Hosted-Deployments benötigen eine separate Proxy-Instanz (netbirdio/netbird-proxy), die sich per gRPC mit dem Management Server verbindet.
Voraussetzungen
- Traefik als Reverse Proxy (TLS Passthrough erforderlich – andere Proxies wie Nginx oder Caddy unterstützen dies nicht in der benötigten Form)
- Mindestens ein verbundener Peer oder ein konfiguriertes Network mit Resources
- NetBird-Account mit 'Services' Permission ('Network Admin' oder höher)
Schnellstart
Wer NetBird ab v0.65.0 mit dem offiziellen Setup-Script (getting-started.sh) und der Traefik-Option deployt hat, hat den Proxy-Container bereits im Docker-Compose-Stack. Direkt zum Service-Erstellen springen.
Für bestehende Deployments gibt es einen Migration Guide, der den Prozess beschreibt: Access Token generieren, Proxy-Container mit Traefik-Labels hinzufügen, Wildcard-DNS einrichten.
TLS-Zertifikate
Der Proxy unterstützt zwei Modi:
ACME (Let's Encrypt):
NB_PROXY_ACME_CERTIFICATES=true
NB_PROXY_ACME_CHALLENGE_TYPE=tls-alpn-01 # oder http-01
Statische Zertifikate (Wildcard oder Corporate CA):
NB_PROXY_CERTIFICATE_FILE=tls.crt
NB_PROXY_CERTIFICATE_KEY_FILE=tls.key
NB_PROXY_CERTIFICATE_DIRECTORY=./certs
Statische Zertifikate unterstützen Hot-Reload – bei Dateiänderungen aktualisiert der Proxy automatisch, ohne Neustart.
High Availability
Mehrere Proxy-Instanzen mit demselben NB_PROXY_DOMAIN-Wert bilden einen Cluster. Fällt eine Instanz aus, übernehmen die verbleibenden den Traffic. Jede Instanz registriert sich unabhängig beim Management Server.
Service erstellen: Step-by-Step
Schritt 1: Service anlegen
Im NetBird Dashboard unter Reverse Proxy → Services → Add Service.
Schritt 2: Details konfigurieren
- Subdomain wählen (z.B.
grafana) - Base Domain auswählen (Cluster-Domain oder Custom Domain)
- Target hinzufügen: Typ (Peer, Host, Domain, Subnet), Protokoll (HTTP/HTTPS), Port
- Optional: Path für Path-basiertes Routing
Schritt 3: Authentifizierung
Im Tab „Authentication":
- SSO aktivieren und optional auf Gruppen einschränken
- Passwort und/oder PIN setzen
- Oder alle deaktiviert lassen für öffentlichen Zugriff
Schritt 4: Erweiterte Einstellungen
Im Tab „Settings":
- Pass Host Header – Original-Host-Header an Backend weiterleiten (nützlich wenn die Anwendung die öffentliche Domain kennen muss)
- Rewrite Redirects – Location-Header in Backend-Responses umschreiben, um interne URLs zu ersetzen
Schritt 5: Service erstellen
Nach dem Erstellen durchläuft der Service folgende Status:
| Status | Bedeutung |
|---|---|
pending |
Service wird provisioniert |
certificate_pending |
TLS-Zertifikat wird ausgestellt |
active |
Service ist live |
tunnel_not_created |
WireGuard-Tunnel zum Target steht noch nicht |
certificate_failed |
Zertifikat-Ausstellung fehlgeschlagen |
Path-Based Routing und Multi-Target
Ein Service kann mehrere Targets mit unterschiedlichen Pfad-Präfixen haben:
| Pfad | Target | Beschreibung |
|---|---|---|
/ |
Peer A (Port 3000) | Haupt-Webanwendung |
/api |
Peer B (Port 8080) | API-Service |
/docs |
Resource C (Port 80) | Dokumentation |
Das konsolidiert mehrere interne Services unter einer Domain – weniger Domains, weniger Zertifikate, eine zentrale Authentifizierung.
Zusätzlich bietet die Integration mit Networks einen „Expose Service"-Button direkt auf Ressourcen in der Networks-Ansicht. Ein Klick öffnet den Service-Dialog mit vorausgefülltem Target.
NetBird Reverse Proxy vs. Alternativen
| Aspekt | NetBird RP | Cloudflare Tunnel | ngrok | Pangolin | Nginx/Traefik |
|---|---|---|---|---|---|
| Self-Hosted | Ja | Nein | Nein | Ja | Ja |
| Automatisches TLS | Ja | Ja | Ja | Ja | Manuell/ACME |
| SSO/Auth built-in | Ja (OIDC) | Ja (Access) | Ja (Edge) | Basic Auth | Nein |
| WireGuard-Tunnel | Ja | Nein | Nein | Ja | Nein |
| Mesh-VPN integriert | Ja | Nein | Nein | Nein | Nein |
| Port-Forwarding nötig | Nein | Nein | Nein | Nein | Ja |
| Open Source | Ja | Nein | Nein | Ja | Ja |
| Datenhoheit | 100% | Cloudflare-Infra | ngrok-Infra | 100% | 100% |
Der entscheidende Vorteil von NetBird: Reverse Proxy und Mesh-VPN kommen aus einer Plattform. Wer NetBird bereits für den sicheren Netzwerk-Zugang nutzt, bekommt den Reverse Proxy ohne zusätzliche Infrastruktur dazu. Bei Cloudflare Tunnel oder ngrok fließt der Traffic über externe Server – bei NetBird bleibt alles auf eigener Infrastruktur.
Use Cases
Interne Dashboards publizieren
Grafana-, ThingsBoard- oder Monitoring-Dashboards für Kunden oder Partner zugänglich machen – mit SSO-Schutz und ohne VPN-Client auf der Gegenseite.
Staging-Umgebungen teilen
Entwickler-Previews oder QA-Umgebungen per PIN oder Passwort teilen, ohne VPN-Zugang einrichten zu müssen.
IoT-Plattformen exponieren
IoT-Dashboards und APIs, die auf internen Servern laufen, sicher ins Internet bringen – relevant für Plattformen wie merkaio, die Kunden-Zugang zu Sensordaten bieten.
Webhooks empfangen
Interne Services können Webhooks von GitHub, Stripe oder anderen Diensten empfangen, ohne eine öffentliche IP zu benötigen.
Temporäre Demo-Zugriffe
Mit PIN oder Passwort lassen sich zeitlich begrenzte Zugriffe auf interne Anwendungen einrichten – ideal für Demos oder Proof-of-Concepts.
Einschränkungen (Beta)
Das Feature befindet sich in der Beta-Phase mit folgenden Einschränkungen:
- Nur Self-Hosted: Cloud-Support ist angekündigt, aber noch nicht verfügbar
- Traefik erforderlich: Andere Reverse Proxies (Nginx, Caddy, HAProxy) werden nicht unterstützt, da TLS Passthrough benötigt wird
- Kein Pre-Shared Key / Rosenpass: Netzwerke, die auf diese Features angewiesen sind, können den Reverse Proxy aktuell nicht nutzen
Unsere Leistungen
Als erfahrener NetBird-Partner unterstützen wir beim Setup und Betrieb:
Managed NetBird inkl. Reverse Proxy
- Self-Hosted-Deployment auf Hetzner oder eigener Infrastruktur
- Reverse Proxy Konfiguration mit Custom Domains und SSO
- Integration mit bestehendem Identity Provider (Keycloak, Azure AD, Okta)
VPN-Flatrate
Managed NetBird zum Festpreis – unbegrenzte User und Geräte, kein Per-Seat-Pricing. Gehostet auf deutschen Servern.
→ VPN-Flatrate: 14 Tage kostenlos testen
Weiterführende Guides
- NetBird Reverse Proxy Dokumentation
- NetBird Installation auf Hetzner Cloud
- NetBird vs. Tailscale: Self-Hosted vs. Cloud
- NetBird vs. ZeroTier: WireGuard statt proprietär
- NetBird vs. Twingate: Self-Hosted oder Cloud-ZTNA?
- → VPN Hub: Alle Business-VPN Vergleiche
- → Expertise: NetBird
- → Enterprise VPN Flatrate
Häufig gestellte Fragen
Antworten auf wichtige Fragen zu diesem Thema
Der NetBird Reverse Proxy ist ein neues Feature, das interne Services über das WireGuard-Mesh-Netzwerk ins Internet exponiert. NetBird übernimmt TLS-Terminierung, optionale Authentifizierung (SSO, Passwort, PIN) und routet eingehenden Traffic durch verschlüsselte WireGuard-Tunnel zum Ziel-Service – ohne offene Ports oder Firewall-Änderungen.
Nein. Der Ziel-Service benötigt weder eine öffentliche IP-Adresse noch offene Ports. Der Traffic wird über den bestehenden WireGuard-Tunnel geroutet, den der NetBird-Agent aufbaut. Nur die Proxy-Instanz selbst benötigt Port 443 (und optional 80 für ACME HTTP-01).
Der Reverse Proxy unterstützt SSO (Single Sign-On über OIDC mit optionaler Gruppen-Einschränkung), Passwort-Schutz und PIN-Code. Mehrere Methoden können gleichzeitig aktiviert werden. Ohne Authentifizierung wird eine Warnung angezeigt.
Aktuell ist der Reverse Proxy nur für Self-Hosted-Deployments verfügbar (Beta). Cloud-Support ist angekündigt und wird in einer zukünftigen Version nachgereicht.
Ja. Neben den automatisch generierten Cluster-Domains (subdomain.proxy-domain) können eigene Domains per CNAME-Record auf die Proxy-Cluster-Adresse konfiguriert werden. Alle Domain-Typen erhalten automatische TLS-Zertifikate.
Der NetBird Reverse Proxy ist vollständig self-hosted und Open Source – alle Daten bleiben auf eigener Infrastruktur. Cloudflare Tunnel routet Traffic über Cloudflare-Server. NetBird bietet zusätzlich ein integriertes WireGuard-Mesh-VPN, sodass Reverse Proxy und Netzwerk-Zugang aus einer Plattform kommen.

Geschrieben von
Timo Wevelsiep
Co-Founder & CEO
Co-Founder von WZ-IT. Spezialisiert auf Cloud-Infrastruktur, Open-Source-Plattformen und Managed Services für KMUs und Enterprise-Kunden weltweit.
LinkedInLassen Sie uns über Ihre Idee sprechen
Ob konkrete IT-Herausforderung oder einfach eine Idee – wir freuen uns auf den Austausch. In einem kurzen Gespräch prüfen wir gemeinsam, ob und wie Ihr Projekt zu WZ-IT passt.


Timo Wevelsiep & Robin Zins
Geschäftsführer




