ZFW is een door de community gebouwde hostfirewall voor ZimaOS, geen ingebouwde functie van IceWhale. Het wordt geïnstalleerd als een systeemextensie op hostniveau, verschijnt als een dashboardtegel en probeert een echt probleem in ZimaOS op te lossen: native services en door Docker gepubliceerde poorten kunnen vanaf het LAN bereikbaar zijn, tenzij een andere firewall of netwerkapparaat stroomopwaarts dit beperkt.
De oorspronkelijke post begon bij ZFW v1.0.10, maar die versie is niet langer de juiste referentie voor een huidige installatie. ZFW bleef snel veranderen naarmate ook ZimaOS veranderde. De huidige upstreamrelease is v1.0.25 en het project heeft al compatibiliteitsproblemen opgelost rond de nf_tables backend, wijzigingen in sessietokens van ZimaOS 1.7.x, IPv6-blootstelling van Docker en Zima Net-verkeer op tun0.
ZFW is communitysoftware, geen IceWhale-firewall
Lintux heeft ZFW onafhankelijk ontwikkeld en onderhoudt het ook. De bronthread bevat uitgebreide tests door de community, waaronder gebruikers die bevestigden dat regels behouden blijven, poorten worden geblokkeerd, terugrollen werkt en latere compatibiliteitsproblemen zijn opgelost. Toch maakt geen enkele aankondiging van IceWhale van ZFW een officiële ZimaOS-firewall.
Dat onderscheid is belangrijk omdat ZFW de netwerkstack van de host rechtstreeks manipuleert. Een onjuiste of incompatibele regel kan SSH, de WebUI, Docker-apps of externe toegang blokkeren.
ZFW scheidt hostservices van door Docker gepubliceerde poorten
De architectuur van ZFW erkent dat Docker-verkeer verschilt van normaal INPUT-verkeer van de host:
- native ZimaOS-/hostservices worden beheerd via regels in INPUT-stijl;
- Door Docker gepubliceerde poorten worden gefilterd via
DOCKER-USER; - IPv6 heeft zijn eigen overeenkomstige ketens en gedrag.
Dit is nauwkeuriger dan een firewallhandleiding die alleen INPUT controleert en ervan uitgaat dat Docker dezelfde route volgt.
Veilig toepassen is de belangrijkste veiligheidsfunctie
De bron introduceerde een terugrolfunctie met een veiligheidsmechanisme van 120 seconden. Wanneer een regelset wordt toegepast, moet de gebruiker deze bevestigen voordat de timer afloopt. Als de regels de gebruiker per ongeluk buitensluiten, zet de firewall ze automatisch terug.
Dat is vooral waardevol op een headless NAS, omdat een firewallfout anders kan uitmonden in herstelwerk met een lokale monitor en een toetsenbord.
De thread bracht een echte lacune in de standaardtoegang aan het licht voor de ZimaOS-terminal
Een gebruiker meldde dat ZFW TCP-poort 7681 blokkeerde, de standaardterminalpoort van ttyd. Lintux legde uit dat de oorspronkelijke starterswhitelist poorten zoals SSH, HTTP/HTTPS, SMB en verschillende ZimaOS-services bevatte, maar niet 7681.
Dit is een nuttige herinnering: inventariseer de services waarop je daadwerkelijk vertrouwt voordat je een standaardbeleid voor alles weigeren inschakelt. Een firewall kan correct functioneren en toch een service blokkeren die het standaardprofiel over het hoofd zag.
ZimaOS 1.6.2 heeft de iptables-backend gewijzigd
Een van de belangrijkste updates in de brondiscussie kwam nadat ZimaOS 1.6.2 het effectieve iptables-pad van Docker had gewijzigd in het nf_tables backend. Oudere ZFW-builds konden regels naar de ongebruikte legacytabel schrijven terwijl de tegel er nog steeds gezond uitzag.
De latere releases voegden backenddetectie en aanvullende validatie van Docker-regels toe. Daarom mogen oude ZFW-installatie-instructies nooit als een permanent recept worden vastgelegd.
De discussie bracht een echte fail-open-situatie in Docker aan het licht en verhielp deze
Tijdens het testen van v1.0.16 ontdekte een gebruiker dat DOCKER-USER kon eindigen met een eenvoudige RETURN zonder de verwachte standaardregels voor weigeren. Lintux bevestigde dat dit een echte, onverwachte fail-open-route was en wijzigde de logica voor de poortinventarisatie.
Later installeerde dezelfde gebruiker v1.0.19 opnieuw, paste de firewall opnieuw toe en controleerde of de verwachte regels per poort en de UDP-verwerking aanwezig waren.
Voor IPv6 waren meerdere rondes met oplossingen uit de praktijk nodig
De brondiscussie documenteert gevallen waarin IPv6-bescherming actief was maar onjuist werd gemeld, en andere gevallen waarin door Docker gepubliceerde IPv6-poorten onverwacht werden geblokkeerd. Dit waren geen theoretische problemen; gebruikers plaatsten live-uitvoer van ketens en de maintainer reproduceerde en verhielp specifieke paden.
Test voor een IPv6-geschikte thuisverbinding de toegang vanaf een echt extern IPv6-netwerk, in plaats van aan te nemen dat een IPv4-LAN-test hetzelfde beleid bewijst.
De huidige ZFW-versie moest zich ook aanpassen aan externe toegang via Zima Net
Een latere upstream-release ontdekte dat het ingebouwde externe verkeer van ZimaOS voor Zima Net via tun0 kon door oudere ZFW-builds worden verwijderd. ZFW v1.0.24 voegde de noodzakelijke omzeilingsverwerking toe in de relevante ketens.
Dit is nog een reden om zowel ZimaOS als ZFW samen bij te werken en externe toegang na een firewallupgrade te verifiëren.
Gebruik de huidige ZFW-release, niet v1.0.10
Sinds september 2026 vermeldt upstream ZFW v1.0.25 als de nieuwste release. Bekijk de huidige ZFW-releases en compatibiliteitsgeschiedenis voordat u installeert of bijwerkt.
Controleer de actieve firewall, niet alleen het groene dashboardtegel
Test het volgende nadat u ZFW hebt ingeschakeld:
- SSH en de WebUI vanaf het LAN;
- de ZimaOS-terminal;
- belangrijke door Docker gepubliceerde poorten;
- Tailscale/ZeroTier/Zima Net, indien gebruikt;
- IPv6 van buiten het LAN, indien relevant;
- persistentie na opnieuw opstarten.
De bronhistorie laat zien waarom een ogenschijnlijk gezonde gebruikersinterface niet het enige bewijs mag zijn dat regels de actieve backend hebben bereikt.
Veelgestelde vragen over ZFW
Is ZFW een officiële firewall van IceWhale?
Nee. Het is een communitymodule voor de hostfirewall die diep met ZimaOS integreert.
Moeten huidige gebruikers v1.0.10 uit het oorspronkelijke bericht installeren?
Nee. Sinds die versie heeft het project veel compatibiliteits- en beveiligingsoplossingen ontvangen.
Waarom gebruikt ZFW DOCKER-USER?
Door Docker gepubliceerd verkeer kan de gewone INPUT-filtering van de host omzeilen. Daarom gebruikt ZFW het speciale filterpad van Docker voor containerpoorten.
