What is a Cloudflare Tunnel and why would I use it on my ZimaCube 2?

A Cloudflare Tunnel creates an outbound-only encrypted connection from your ZimaCube 2 to Cloudflare edge network. Instead of opening ports on your router (which exposes your infrastructure to the internet), all traffic flows through this encrypted tunnel. Your origin server — the ZimaCube 2 — remains completely hidden from public view.

Do I need to open any ports on my router for this setup?

No. That is the point. Cloudflare Tunnel only makes outbound connections. Your router does not need a single port forward rule. This eliminates the most common attack vector in [homelab networking](https://shop.zimaspace.com/blogs/zima-campaign-hub/ultimate-homelab-hardware-guide-self-hosting "Building a Homelab: Top Hardware Picks for Beginners to Pros").

Can the ZimaCube 2 handle running a reverse proxy and all my services at the same time?

Yes. Michael ZC2 runs Cloudflare Tunnel, Nginx Proxy Manager, and 10+ Docker containers simultaneously — all while maintaining quiet, cool operation. The dual 2.5GbE ports and NVMe storage ensure networking and container I/O do not become bottlenecks.

Why does Docker network segmentation matter?

If every container shares the same network, one compromised service gives an attacker a path to everything else. By placing only Cloudflare Tunnel and Nginx Proxy Manager on an "edge" network (and keeping applications on separate internal networks), you create a controlled boundary between public-facing traffic and your private services.

What was the TLS hostname mismatch issue?

When Cloudflare Tunnel connected to Nginx Proxy Manager internally using a Docker hostname like reverse-proxy, the TLS certificate — which was issued for a public domain like example.com — did not match. The fix was configuring Cloudflare Tunnel to use the correct Origin Server Name while still routing to the internal Docker hostname. This preserved full encryption without disabling validation.

How does the ZimaCube 2 networking hardware compare to a standard NAS for this use case?

Most consumer NAS devices ship with a single gigabit Ethernet port. The ZimaCube 2 has dual 2.5GbE — which means you can dedicate one interface to edge traffic (Cloudflare + reverse proxy) and the other to internal services. This physical-layer separation is something you cannot achieve on single-NIC hardware.

Wie ich den ZimaCube 2 in einen Zero-Trust-Ingress-Controller für mein gesamtes Homelab verwandelt habe

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

"Dual monitor home lab workstation showing Lucky in Prod blog page, mini server tower, keyboard and coding setup on office desk

💡

Community Spotlight: Michael Luckenbill, ZimaCube 2 Pioneer Program

Dein Homelab hat eine Haustür. Wenn du wie die meisten Self-Hoster bist, ist diese Haustür eine Portweiterleitung an deinem Router – und sie steht weit offen.

Ich habe Wochen damit verbracht, meinen neu aufzubauen. Das Ergebnis: eine produktionsreife Ingress-Schicht, die vollständig auf einem ZimaCube 2 läuft. Keine offenen Ports am Router. Keine öffentlich erreichbaren Ursprungsserver. Ende-zu-Ende-TLS bei jeder Verbindung. Und das alles steht leise neben meinem Fernseher.

So habe ich es genau gebaut, was unterwegs kaputtging und warum der ZimaCube 2 sich als perfekte Plattform für die Aufgabe erwies.

Das Problem mit traditionellem Homelab-Ingress

Viele Homelabs sehen immer noch so aus:

Port 443 am Router weitergeleitet → zeigt auf einen Reverse Proxy
Port 80 weitergeleitet → leitet zu 443 um
Dienste sind direkt erreichbar, wenn man die IP kennt
Die Ursprungsinfrastruktur ist nur einen Portscan von der Entdeckung entfernt

Das schafft echte Probleme. Öffentlich zugängliche Ingress-Ports. Direkt erreichbare Ursprungsserver. Admin-Oberflächen, die vor der Authentifizierung antworten. Selbst mit HTTPS bleibt die Infrastruktur sichtbar – und Sichtbarkeit lädt zur Aufklärung ein.

Ich wollte ein ganz anderes Modell. Etwas, das näher an der modernen Cloud-Infrastruktur für Ingress ist: nur ausgehendes Vertrauen, keine eingehende Exposition und verschlüsselte Tunnel, die den Ursprung verbergen.

Warum der ZimaCube 2

Diese Art von Architektur verlangt eine spezifische Hardwareausstattung. Nicht rohe Leistung – Zuverlässigkeit, Flexibilität und Stille.

Der ZimaCube 2 erfüllte alle Anforderungen:

Immer an: Leiser 24/7-Betrieb.
Die Ingress-Schicht muss kontinuierlich laufen – das thermische Design des ZC2 sorgt dafür, dass sie das tut, ohne den Raum zu dominieren.

Duale 2,5GbE: Ein Interface für das Edge-Netzwerk, eines für intern. Die Verkehrssegmentierung beginnt auf der physischen Ebene, nicht nur in Docker.

Docker Native: NVMe-Speicher für schnelle Container-I/O. Mehrere Bridge-Netzwerke überlasten das System nicht. Die Plattform wurde dafür gebaut.

An diesem Punkt ist der ZimaCube 2 effektiv vier Dinge in einer Maschine: ein Docker-Host, eine Reverse-Proxy-Plattform, eine Ingress-Schicht und ein zentrales Infrastrukturgerät. Für modernes Self-Hosting ist diese Kombination äußerst praktisch.

Featured

ZimaCube 2 Persönliche Cloud Heim-NAS

ZimaCube2

Die neue Architektur

Anstatt Ports an meinem Router zu öffnen, funktioniert das neue Design so:

Cloudflare Tunnel erstellt ausgehende, verschlüsselte Verbindungen zum Cloudflare-Edge
Nginx Proxy Manager übernimmt Routing, SSL-Terminierung und ACLs
Docker-Bridge-Netzwerke segmentieren den Edge-Verkehr von internen Workloads
Keine eingehenden NAT-Regeln — der Router hat keine Ahnung, dass etwas bereitgestellt wird

🔒 Die Origin-Infrastruktur ist komplett verborgen. Cloudflare sitzt vor dem gesamten öffentlichen Traffic. Der ZimaCube 2 stellt nur ausgehende Verbindungen her. Es hört nichts an einem öffentlichen Port.

Das fühlte sich sofort moderner an als traditionelles Self-Hosting mit Portweiterleitung.

Docker-Netzwerksegmentierung: Edge ≠ Intern

Eine der wichtigsten Änderungen war die Trennung des Verkehrs durch Docker-Bridge-Netzwerke.

docker network create \

--subnet 172.x.x.x/24 \

edge

Das Edge-Netzwerk enthält genau zwei Container: Cloudflare Tunnel und Nginx Proxy Manager. Das war’s. Anwendungen laufen auf separaten internen Docker-Netzwerken — vollständig isoliert von der Ingress-Schicht.

🎁 Nicht jeder Container sollte direkt ans Internet angebunden sein. Wenn Ihr Plex-Server, Vaultwarden-Instanz oder CI/CD-Runner ein Netzwerk mit Ihrem Reverse-Proxy teilt, erhält ein kompromittierter Dienst Zugang zu allem anderen.

Der ZimaCube 2 handhabt diese Segmentierung sauber. Mehrere Bridge-Netzwerke verursachen keine Leistungseinbußen auf der Plattform, und der NVMe-Speicher sorgt dafür, dass Container-Start und Netzwerk-I/O auch bei komplexerer Netzwerktopologie schnell bleiben.

Das TLS-Problem, das mich fast zum Scheitern brachte

Das war die interessanteste technische Lektion im gesamten Projekt.

Die Einrichtung schien zunächst unkompliziert. HTTP zwischen Cloudflare Tunnel und Nginx Proxy Manager funktionierte sofort:

http://reverse-proxy → ✅ Funktioniert

Also aktivierte ich HTTPS.

https://reverse-proxy → ❌ Fehler

Das Zertifikat war gültig. Das Ablaufdatum stimmte. Die Vertrauenskette war in Ordnung. Alles sah korrekt aus — und dennoch verweigerte HTTPS die Verbindung.

Das eigentliche Problem war die TLS-Hostname-Validierung.

Das Zertifikat wurde für meine öffentlichen Domains ausgestellt (example.com, app.example.com). Aber Cloudflare Tunnel verband sich intern mit dem Reverse-Proxy — einem Docker-Hostnamen, der im Zertifikat nicht vorkam. Die Nichtübereinstimmung des Hostnamens führte dazu, dass die TLS-Validierung stillschweigend fehlschlug.

💡 TLS-Validierung betrifft nicht nur das Vertrauen in das Zertifikat und dessen Ablaufdatum. Sie überprüft auch die Identität des Hostnamens und die SNI-Erwartungen. Wenn der Name in der URL nicht mit dem Namen im Zertifikat übereinstimmt, schlägt die Verbindung fehl — selbst wenn sonst alles perfekt ist.

Die Lösung: Konfigurieren Sie Cloudflare Tunnel mit Origin Server Name: example.com, während die interne Weiterleitung weiterhin erfolgt an https://reverse-proxy:443. Das bewahrte verschlüsselten Transport, ordnungsgemäße Hostnamen-Validierung und vollständige TLS-Überprüfung — ohne Sicherheitsprüfungen zu deaktivieren.

Das ist die Art von Lektion, die man nur durch Bauen lernt.

ACLs und die Lektion über Infrastruktur-Verkehrswege

Eine betriebliche Lektion, die ich sehr schnell lernte: Reverse Proxies sehen oft Docker-Bridge-IPs, Tunnel-IPs und interne Proxy-IPs statt der ursprünglichen Client-IP.

Das lernte ich auf die harte Tour, als ich mich versehentlich aus dem Nginx Proxy Manager aussperrte.

Ich konfigurierte eine ACL, die nur mein LAN-Subnetz (192.168.x.x/24) zulässt. Die Logik schien sinnvoll — nur Geräte in meinem Heimnetzwerk sollten auf das Admin-Panel zugreifen.

NPM sah tatsächlich Traffic vom Docker-Bridge-Netzwerk. Nicht von meinem LAN. Die Zugriffskontrolle blockierte alles, auch mich.

Das Hinzufügen des Docker-Subnetzes zur Allow-Liste löste das Problem sofort. Aber es war eine sehr reale Erinnerung daran, dass Infrastruktur-Verkehrswege oft anders sind als auf dem Papier angenommen.

🔄 In einer containerisierten Umgebung wird die ursprüngliche Client-IP an mehreren Stationen umgeschrieben: Cloudflare Edge → Tunnel → Docker Bridge → Reverse Proxy. Jede Station ändert die Quelladresse. Deine Firewall-Regeln müssen den tatsächlichen Verkehrsweg berücksichtigen, nicht den, den du dir vorstellst.

Warum diese Architektur auf dem ZimaCube 2 wichtig ist

Es gibt einen Grund, warum dieser Stack speziell auf dem ZC2 so gut funktioniert:

Duale 2,5GbE bedeutet, dass die Ingress-Schicht dedizierte Bandbreite hat — dein interner Netzwerkverkehr konkurriert nicht mit internetseitigen Diensten
NVMe-Speicher sorgt für schnelles Container-Netzwerk — Bridge-Netzwerk-Durchsatz wird nicht durch langsame Festplatten-I/O gebremst
Leiser Dauerbetrieb bedeutet, dass die Ingress-Schicht rund um die Uhr in einem Wohnraum läuft — nicht in einem Keller-Rack
Docker-native Plattform mit genug Kapazität, um Tunnel, Reverse Proxy, ACL-Engine und alle deine Dienste gleichzeitig zu betreiben
Erweiterbarkeit bedeutet, dass du später eine dedizierte Netzwerkkarte oder Beschleunigerkarte hinzufügen kannst, wenn dein Netzwerkbedarf wächst

Der ZimaCube 2 hostet diese Dienste nicht nur. Er ist die richtige Plattform für sie.

Der finale Stack

Was jetzt auf dem ZimaCube 2 läuft:

Cloudflare Tunnel — nur ausgehende verschlüsselte Verbindungen, keine offenen Ports
Nginx Proxy Manager — Reverse Proxy, SSL, ACLs
Docker-Bridge-Netzwerke — segmentierter Edge- vs. interner Traffic
End-to-End TLS — verschlüsselt vom Client bis zum Ursprung, nirgendwo Klartext
Versteckter Ursprung — keine Antwort auf einer öffentlichen IP

Es ist immer noch ein Homelab. Aber das Betriebsmodell ähnelt jetzt moderner Ingress-Architektur viel mehr als traditionellem portweitergeleitetem Self-Hosting.

Die wichtigste Erkenntnis aus diesem Projekt: Modernes Self-Hosting erfordert zunehmend dieselben Überlegungen zu Ingress, Netzwerk und Vertrauensgrenzen wie Produktionsinfrastrukturen. Und die Hardware muss mithalten – leise, zuverlässig, vernetzt und immer einsatzbereit.

Der ZimaCube 2 liefert genau das.

Bauen Sie Ihr eigenes Zero-Trust-Homelab mit dem ZimaCube 2 →

Häufig gestellte Fragen

Was ist ein Cloudflare Tunnel und warum sollte ich ihn auf meinem ZimaCube 2 verwenden?

Ein Cloudflare Tunnel stellt eine ausschließlich ausgehende, verschlüsselte Verbindung von Ihrem ZimaCube 2 zum Cloudflare-Edge-Netzwerk her. Anstatt Ports an Ihrem Router zu öffnen (was Ihre Infrastruktur dem Internet aussetzt), fließt der gesamte Traffic durch diesen verschlüsselten Tunnel. Ihr Origin-Server – der ZimaCube 2 – bleibt vollständig vor der Öffentlichkeit verborgen.

Muss ich für diese Einrichtung Ports an meinem Router öffnen?

Nein. Genau das ist der Sinn. Cloudflare Tunnel stellt nur ausgehende Verbindungen her. Ihr Router benötigt keine einzige Portweiterleitungsregel. Das beseitigt den häufigsten Angriffsvektor im Homelab-Netzwerk.

Kann der ZimaCube 2 gleichzeitig einen Reverse Proxy und alle meine Dienste betreiben?

Ja. Michael ZC2 betreibt Cloudflare Tunnel, Nginx Proxy Manager und über 10 Docker-Container gleichzeitig – und das bei leisem, kühlem Betrieb. Die zwei 2,5GbE-Ports und der NVMe-Speicher sorgen dafür, dass Netzwerk- und Container-I/O keine Engpässe verursachen.

Warum ist die Segmentierung des Docker-Netzwerks wichtig?

Wenn alle Container dasselbe Netzwerk teilen, erhält ein kompromittierter Dienst einem Angreifer Zugang zu allem anderen. Indem Sie nur Cloudflare Tunnel und Nginx Proxy Manager in einem „Edge“-Netzwerk platzieren (und Anwendungen in separaten internen Netzwerken halten), schaffen Sie eine kontrollierte Grenze zwischen öffentlich zugänglichem Traffic und Ihren privaten Diensten.

Was war das Problem mit der TLS-Hostname-Übereinstimmung?

Als Cloudflare Tunnel intern über einen Docker-Hostnamen wie reverse-proxy mit Nginx Proxy Manager verbunden wurde, stimmte das TLS-Zertifikat – das für eine öffentliche Domain wie example.com ausgestellt wurde – nicht überein. Die Lösung bestand darin, Cloudflare Tunnel so zu konfigurieren, dass der korrekte Origin Server Name verwendet wird, während der interne Docker-Hostname weiterhin geroutet wird. So blieb die vollständige Verschlüsselung erhalten, ohne die Validierung zu deaktivieren.

Wie schneidet die Netzwerktechnik des ZimaCube 2 im Vergleich zu einem Standard-NAS für diesen Anwendungsfall ab?

Die meisten Consumer-NAS-Geräte werden mit einem einzelnen Gigabit-Ethernet-Anschluss geliefert. Der ZimaCube 2 verfügt über zwei 2,5GbE-Anschlüsse – das bedeutet, Sie können eine Schnittstelle für Edge-Traffic (Cloudflare + Reverse Proxy) und die andere für interne Dienste reservieren. Diese Trennung auf physikalischer Ebene ist mit Hardware mit nur einer Netzwerkkarte nicht möglich.