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.

"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 Programma

Je homelab heeft een voordeur. Als je zoals de meeste zelf-hosters bent, is die voordeur een poortdoorschakeling 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 kapot ging, 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 door 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 blootgestelde ingress-poorten. Direct bereikbare origin-servers. Beheerinterfaces 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.

Waarom de ZimaCube 2

Dit soort architectuur vereist een specifieke set hardwarekenmerken. 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 bridge-netwerken verstikken het systeem niet. Het platform is hiervoor gebouwd.

Op dit punt 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 Thuis 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 routering, SSL-terminatie en ACL's
Docker bridge-netwerken 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.

Docker-netwerksegmentatie: Edge ≠ Intern

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

docker network create \

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

edge

Het edge-netwerk bevat 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 service een aanvaller toegang tot alles.

De ZimaCube 2 verwerkt deze segmentatie netjes. Meerdere bridge-netwerken zorgen niet voor prestatieverlies op het platform, en de NVMe-opslag zorgt ervoor dat container-start 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 setup 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-hostname-validatie.

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 wordt gerouteerd 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.

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 originele 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 adminpaneel.

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

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

🔄 In een containeromgeving wordt het originele client-IP op meerdere stappen 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 diensten
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 diensten tegelijkertijd te draaien
Uitbreidbaarheid betekent dat je later een dedicated NIC of accelerator-kaart kunt toevoegen als je netwerkbehoeften groeien

De ZimaCube 2 host niet alleen deze diensten. 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 rand- versus intern verkeer
End-to-end TLS — versleuteld van client tot oorsprong, nergens platte tekst
Verborgen oorsprong — 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 realisatie van dit project: moderne self-hosting vereist steeds vaker dezelfde ingress-, netwerk- en trust-boundary-denkwijze als productie-infrastructuur. En de hardware moet bijblijven — stil, betrouwbaar, verbonden en altijd aan.

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 creëert 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 om de juiste Origin Server Name te gebruiken 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 consumenten-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 fysiek niveau is iets wat je niet kunt bereiken met hardware met één enkele NIC.