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.

Hoe ik de ZimaCube 2 heb omgevormd tot een zero-trust ingress-controller voor mijn hele homelab

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How I Turned the ZimaCube 2 Into a Zero-Trust Ingress Controller for My Entire Homelab - Zima Store Online

💡

Community Spotlight: Michael Luckenbill, ZimaCube 2 Pioneer Programma

Je homelab heeft een voordeur. Als je zoals de meeste zelf-hosters bent, is die voordeur een port forward op je router — en die staat wagenwijd open.

Ik heb weken besteed aan het herbouwen van de mijne. Het resultaat: een productieklare ingress-laag die volledig draait op een ZimaCube 2. Geen open poorten op mijn router. Geen publiekelijk bereikbare origin-servers. End-to-end TLS op elke verbinding. Alles stilletjes naast mijn tv.

Hier is precies hoe ik het heb gebouwd, wat er onderweg misging, en waarom de ZimaCube 2 de perfecte platform voor de klus bleek te zijn.

Het probleem met traditionele homelab ingress

Veel homelabs zien er nog steeds zo uit:

Poort 443 doorgestuurd op de router → wijst naar een reverse proxy
Poort 80 doorgestuurd → verwijst naar 443
Services zijn direct bereikbaar als je het IP-adres weet
De origin-infrastructuur is één poortscan verwijderd van ontdekking

Dit veroorzaakt echte problemen. Openbare ingress-poorten. Direct bereikbare origin-servers. Beheerdersinterfaces die reageren vóór authenticatie. Zelfs met HTTPS blijft de infrastructuur zichtbaar — en zichtbaarheid nodigt uit tot verkenning.

Ik wilde een heel ander model. Iets dichter bij hoe moderne cloudinfrastructuur ingress afhandelt: alleen uitgaand vertrouwen, geen inkomende blootstelling, en versleutelde tunnels die de oorsprong verbergen.

Traditioneel Homelab Architectuurdiagram dat de port forwarding workflow toont: Internet, router, reverse proxy en Docker-containers

Waarom de ZimaCube 2

Dit soort architectuur vraagt om een specifieke set hardware-eigenschappen. Niet ruwe kracht — betrouwbaarheid, flexibiliteit en stilte.

De ZimaCube 2 voldeed aan alle eisen:

Altijd Aan: Stil 24/7 gebruik.
De ingress-laag moet continu draaien — het thermisch ontwerp van de ZC2 zorgt ervoor dat dit gebeurt zonder de kamer te domineren.

Dubbele 2.5GbE: Eén interface voor het edge-netwerk, één voor intern. Verkeerssegmentatie begint op de fysieke laag, niet alleen in Docker.

Docker Native: NVMe-opslag voor snelle container I/O. Meerdere brugnetwerken verstikken het systeem niet. Het platform is hiervoor gebouwd.

Op dit moment is de ZimaCube 2 effectief vier dingen in één apparaat geworden: een Docker-host, een reverse proxy-platform, een ingress-laag en een gecentraliseerd infrastructuurapparaat. Voor modern zelf-hosting is die combinatie uiterst praktisch.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

De nieuwe architectuur

In plaats van poorten op mijn router te openen, werkt het nieuwe ontwerp zo:

Cloudflare Tunnel maakt alleen uitgaande versleutelde verbindingen met de Cloudflare-edge
Nginx Proxy Manager verzorgt routing, SSL-terminatie en ACL’s
Docker-bridgenetwerken segmenteren edge-verkeer van interne workloads
Geen inkomende NAT-regels — de router heeft geen idee dat er iets wordt geserveerd

🔒 De origin-infrastructuur is volledig verborgen. Cloudflare zit voor al het publieke verkeer. De ZimaCube 2 maakt alleen uitgaande verbindingen. Niets luistert op een publieke poort.

Dit voelde meteen meer als moderne cloud-ingressarchitectuur dan traditionele port-forwarded self-hosting.

Definitief veilig homelab architectuurdiagram draaiend op ZimaCube 2 met Cloudflare Tunnel, Nginx Proxy Manager en end-to-end TLS-encryptie

Docker-netwerksegmentatie: Edge ≠ Intern

Een van de belangrijkste veranderingen was het scheiden van verkeer met Docker-bridgenetwerken.

docker network create \

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

edge

Het edge-netwerk draagt precies twee containers: Cloudflare Tunnel en Nginx Proxy Manager. Dat is alles. Applicaties draaien op aparte interne Docker-netwerken — volledig geïsoleerd van de ingress-laag.

🎁 Niet elke container moet direct aan het internet gekoppeld zijn. Als je Plex-server, Vaultwarden-instance of CI/CD-runner een netwerk deelt met je reverse proxy, geeft één gecompromitteerde dienst een aanvaller toegang tot alles.

De ZimaCube 2 verzorgt deze segmentatie netjes. Meerdere brugnetwerken zorgen niet voor prestatieverlies op het platform, en de NVMe-opslag zorgt ervoor dat het opstarten van containers en netwerk-I/O snel blijven, zelfs als de netwerktopologie complexer wordt.

Het TLS-probleem dat me bijna brak

Dit bleek de meest interessante technische les van het hele project te zijn.

De installatie leek in het begin eenvoudig. HTTP tussen Cloudflare Tunnel en Nginx Proxy Manager werkte direct:

http://reverse-proxy → ✅ Werkt

Dus schakelde ik HTTPS in.

https://reverse-proxy → ❌ Fout

Het certificaat was geldig. De vervaldatum was in orde. De vertrouwensketen klopte. Alles leek correct — en toch weigerde HTTPS verbinding te maken.

Het echte probleem was TLS-hostnamevalidatie.

Het certificaat was uitgegeven voor mijn publieke domeinen (example.com, app.example.com). Maar Cloudflare Tunnel maakte intern verbinding met reverse-proxy — een Docker-hostnaam die niet overeenkwam met iets op het certificaat. De mismatch in hostname zorgde ervoor dat TLS-validatie stilzwijgend faalde.

💡 TLS-validatie gaat niet alleen over certificaatvertrouwen en vervaldatum. Het valideert ook de identiteit van de hostname en SNI-verwachtingen. Als de naam in de URL niet overeenkomt met de naam op het certificaat, mislukt de verbinding — zelfs als alles verder perfect is.

De oplossing: configureer Cloudflare Tunnel met Origin Server Name: example.com terwijl het intern nog steeds naar https://reverse-proxy:443. Dat zorgde voor versleuteld transport, correcte hostname-validatie en volledige TLS-verificatie — zonder beveiligingscontroles uit te schakelen.

Dit is het soort les dat je alleen leert door te bouwen.

Cloudflare SSL/TLS overzicht beheerpaneel met Full strict encryptiemodus, diagram van browser-naar-origin server verkeer encryptie

ACL’s en de les over infrastructuurverkeerspaden

Een operationele les die ik snel leerde: reverse proxies zien vaak Docker bridge IP’s, tunnel IP’s en interne proxy IP’s in plaats van het oorspronkelijke client-IP.

Ik leerde dit op de harde manier toen ik per ongeluk mezelf buitensloot van Nginx Proxy Manager.

Ik stelde een ACL in om alleen mijn LAN-subnet (192.168.x.x/24) toe te staan. De logica leek logisch — alleen apparaten op mijn thuisnetwerk mochten toegang hebben tot het beheerpaneel.

NPM zag het verkeer eigenlijk vanuit het Docker bridge-netwerk. Niet vanaf mijn LAN. De toegangscontrole blokkeerde alles, inclusief mijzelf.

Het toevoegen van het Docker-subnet aan de toegestane lijst loste het probleem direct op. Maar het was een duidelijke herinnering dat infrastructuurverkeerspaden vaak anders zijn dan we op papier aannemen.

🔄 In een gecontaineriseerde omgeving wordt het oorspronkelijke client-IP op meerdere punten herschreven: Cloudflare edge → tunnel → Docker bridge → reverse proxy. Elke stap verandert het bronadres. Je firewallregels moeten rekening houden met het daadwerkelijke verkeerspad, niet met het pad dat je denkt.

Waarom deze architectuur belangrijk is op de ZimaCube 2

Er is een reden waarom deze stack zo goed werkt op de ZC2 specifiek:

Dubbele 2.5GbE betekent dat de ingress-laag dedicated bandbreedte heeft — je interne netwerkverkeer concurreert niet met internetgerichte services
NVMe-opslag zorgt voor snelle container-netwerken — bridge-netwerkdoorvoer wordt niet beperkt door trage schijf-I/O
Stille altijd-aan werking betekent dat de ingress-laag 24/7 draait in een leefruimte — niet in een kelderrack
Docker-native platform met genoeg ruimte om de tunnel, reverse proxy, ACL-engine en al je services tegelijk te draaien
Uitbreidbaarheid betekent dat je later een dedicated NIC of accelerator-kaart kunt toevoegen als je netwerkbehoeften groeien

De ZimaCube 2 host deze services niet alleen. Het is het juiste platform voor hen.

De definitieve stack

Wat er nu draait op de ZimaCube 2:

Cloudflare Tunnel — alleen uitgaande versleutelde verbindingen, geen open poorten
Nginx Proxy Manager — reverse proxy, SSL, ACL’s
Docker bridge-netwerken — gesegmenteerd edge- versus intern verkeer
End-to-end TLS — versleuteld van client tot origin, nergens platte tekst
Verborgen origin — er reageert niets op een openbaar IP

Het is nog steeds een homelab. Maar het operationele model lijkt nu veel meer op moderne ingress-engineering dan op traditionele port-forwarded self-hosting.

De grootste ontdekking van dit project: moderne self-hosting vereist steeds vaker dezelfde ingress-, netwerk- en trust-boundary-denkwijze als in productie-infrastructuur. En de hardware moet bijblijven — stil, betrouwbaar, verbonden en altijd aan.

Diagram van moderne homelab ingress-architectuur die het outbound-only Cloudflare tunnelontwerp vergelijkt met een risicovolle traditionele port forwarding-opstelling

De ZimaCube 2 levert precies dat.

Bouw je eigen zero-trust homelab met ZimaCube 2 →

Veelgestelde vragen

Wat is een Cloudflare Tunnel en waarom zou ik die gebruiken op mijn ZimaCube 2?

Een Cloudflare Tunnel maakt een uitgaande, versleutelde verbinding van je ZimaCube 2 naar het Cloudflare edge-netwerk. In plaats van poorten op je router te openen (waardoor je infrastructuur aan het internet wordt blootgesteld), verloopt al het verkeer via deze versleutelde tunnel. Je origin server — de ZimaCube 2 — blijft volledig verborgen voor het publiek.

Moet ik poorten op mijn router openen voor deze setup?

Nee. Dat is juist het punt. Cloudflare Tunnel maakt alleen uitgaande verbindingen. Je router heeft geen enkele port-forwardregel nodig. Dit elimineert de meest voorkomende aanvalsvector in homelab-netwerken.

Kan de ZimaCube 2 een reverse proxy en al mijn diensten tegelijk draaien?

Ja. Michael ZC2 draait Cloudflare Tunnel, Nginx Proxy Manager en meer dan 10 Docker-containers tegelijkertijd — en dat alles terwijl hij stil en koel blijft. De dubbele 2.5GbE-poorten en NVMe-opslag zorgen ervoor dat netwerk- en container-I/O geen bottlenecks worden.

Waarom is Docker-netwerksegmentatie belangrijk?

Als elke container hetzelfde netwerk deelt, geeft één gecompromitteerde dienst een aanvaller toegang tot alles. Door alleen Cloudflare Tunnel en Nginx Proxy Manager op een "edge"-netwerk te plaatsen (en applicaties op aparte interne netwerken te houden), creëer je een gecontroleerde grens tussen publiek verkeer en je privéservices.

Wat was het probleem met de TLS-hostnaam mismatch?

Toen Cloudflare Tunnel intern verbonden was met Nginx Proxy Manager via een Docker-hostnaam zoals reverse-proxy, kwam het TLS-certificaat — dat was uitgegeven voor een publieke domeinnaam zoals example.com — niet overeen. De oplossing was om Cloudflare Tunnel te configureren met de juiste Origin Server Name terwijl het nog steeds naar de interne Docker-hostnaam werd gerouteerd. Dit behield volledige encryptie zonder validatie uit te schakelen.

Hoe verhoudt de netwerkhardware van de ZimaCube 2 zich tot een standaard NAS voor dit gebruik?

De meeste consumentgerichte NAS-apparaten worden geleverd met een enkele gigabit Ethernet-poort. De ZimaCube 2 heeft dubbele 2.5GbE — wat betekent dat je één interface kunt toewijzen aan edge-verkeer (Cloudflare + reverse proxy) en de andere aan interne diensten. Deze scheiding op het fysieke laagniveau is iets wat je niet kunt bereiken met hardware met één NIC.