ZFW är en communityutvecklad värdbrandvägg för ZimaOS, inte en inbyggd IceWhale-funktion. Den installeras som ett systemtillägg på värdnivå, visas som en panel i instrumentpanelen och försöker lösa en verklig brist i ZimaOS: inbyggda tjänster och Docker-publicerade portar kan nås från det lokala nätverket om inte en annan brandvägg eller uppströmsnätverksenhet begränsar dem.
Källinlägget började med ZFW v1.0.10, men den versionen är inte längre rätt referens för en aktuell installation. ZFW fortsatte att förändras snabbt i takt med att ZimaOS självt ändrades. Den aktuella uppströmsversionen är v1.0.25, och projektet har redan åtgärdat kompatibilitetsproblem som rör ZimaOS 1.6.2:s nf_tables backend, sessions-tokenförändringar i ZimaOS 1.7.x, IPv6-exponering av Docker och Zima Net-trafik på tun0.
ZFW är communityprogramvara, inte en IceWhale-brandvägg
Lintux utvecklade och underhåller ZFW oberoende. Källtråden innehåller omfattande communitytestning, inklusive användare som bekräftade att regler sparas, portar blockeras, återställning fungerar och senare kompatibilitetsfixar har genomförts, men inget tillkännagivande från IceWhale gör ZFW till en officiell brandvägg för ZimaOS.
Den skillnaden är viktig eftersom ZFW manipulerar värdens nätverksstack direkt. En felaktig eller inkompatibel regel kan blockera SSH, webbgränssnittet, Docker-appar eller fjärråtkomst.
ZFW skiljer värdtjänster från Docker-publicerade portar
ZFW:s arkitektur tar hänsyn till att Docker-trafik skiljer sig från vanlig INPUT-trafik till värden:
- inbyggda ZimaOS-/värdtjänster styrs genom regler av INPUT-typ;
- Docker-publicerade portar filtreras genom
DOCKER-USER; - IPv6 har motsvarande kedjor och beteende.
Det här är mer korrekt än en brandväggsguide som bara kontrollerar INPUT och antar att Docker följer samma väg.
Säker tillämpning är den viktigaste säkerhetsfunktionen
Källan införde en återställning med dödmansknapp efter 120 sekunder. När en regeluppsättning tillämpas måste användaren bekräfta den innan tiden löper ut. Om reglerna råkar låsa ute användaren återställs brandväggen automatiskt.
Det är särskilt värdefullt på en huvudlös NAS, eftersom ett misstag i brandväggskonfigurationen annars kan leda till att man måste återställa systemet lokalt med skärm och tangentbord.
Tråden blottlade en verklig lucka i standardinställningen för ZimaOS-terminalen
En användare rapporterade att ZFW blockerade TCP-port 7681, den standardmässiga terminalporten för ttyd. Lintux förklarade att den ursprungliga startvitlistan innehöll portar som SSH, HTTP/HTTPS, SMB och flera ZimaOS-tjänster, men inte 7681.
Det här är en användbar påminnelse: inventera de tjänster du faktiskt är beroende av innan du aktiverar en standardregel som nekar all trafik. En brandvägg kan fungera korrekt och ändå blockera en tjänst som standardprofilen missade.
ZimaOS 1.6.2 ändrade iptables-backend
En av de viktigaste uppdateringarna i källtråden kom efter att ZimaOS 1.6.2 ändrade Dockers effektiva iptables-sökväg till nf_tables backend-servern. Äldre ZFW-versioner kunde skriva regler i den oanvända äldre tabellen medan panelen fortfarande såg ut att fungera korrekt.
De senare versionerna lade till backendidentifiering och ytterligare validering av Docker-regler. Därför bör gamla installationsanvisningar för ZFW aldrig låsas fast som en permanent metod.
Tråden upptäckte och korrigerade ett verkligt fel som gjorde att Docker-trafik kunde släppas igenom
Under testningen av v1.0.16 upptäckte en användare att DOCKER-USER kunde sluta med en enkel RETURN utan de förväntade reglerna för standardmässigt nekande. Lintux bekräftade att detta var en verklig, oväntad väg där allt tilläts och ändrade logiken för portinventeringen.
Senare installerade samma användare om v1.0.19, tillämpade brandväggen igen och verifierade att de förväntade portspecifika reglerna och UDP-hanteringen fanns på plats.
IPv6 krävde flera omgångar med korrigeringar i verkliga miljöer
Källtråden dokumenterar fall där IPv6-skyddet var aktivt men rapporterades felaktigt, samt andra fall där Docker-publicerade IPv6-portar blockerades oväntat. Detta var inte teoretiska problem; användare publicerade aktiva utdata från kedjorna och underhållaren återskapade och korrigerade specifika sökvägar.
För en hemanslutning med IPv6-stöd bör du testa åtkomst från ett riktigt externt IPv6-nätverk i stället för att anta att ett IPv4-test från LAN-nätverket bevisar att samma policy gäller.
Aktuella ZFW var också tvungen att anpassas till fjärråtkomst via Zima Net
En senare version från upstream visade att ZimaOS inbyggda trafik för fjärråtkomst via Zima Net på tun0 kunde släppas av äldre ZFW-versioner. ZFW v1.0.24 lade till den nödvändiga förbikopplingshanteringen i alla berörda kedjor.
Detta är ytterligare ett skäl att uppdatera både ZimaOS och ZFW tillsammans samt verifiera fjärråtkomst efter en brandväggsuppgradering.
Använd den aktuella ZFW-versionen, inte v1.0.10
I september 2026 anger upstream att ZFW v1.0.25 är den senaste versionen. Granska de aktuella ZFW-versionerna och kompatibilitetshistoriken innan du installerar eller uppdaterar.
Verifiera den aktiva brandväggen, inte bara den gröna panelen i instrumentpanelen
Testa följande efter att ZFW har aktiverats:
- SSH och webbgränssnittet från LAN-nätverket;
- ZimaOS-terminalen;
- viktiga Docker-publicerade portar;
- Tailscale/ZeroTier/Zima Net om det används;
- IPv6 utifrån LAN-nätverket när det är relevant;
- beständighet efter omstart.
Källhistoriken visar varför ett gränssnitt som ser ut att fungera korrekt inte bör vara det enda beviset på att reglerna har nått den aktiva backend-servern.
Vanliga frågor om ZFW
Är ZFW en officiell brandvägg från IceWhale?
Nej. Det är en communitybaserad brandväggsmodul för värdsystemet som integreras djupt med ZimaOS.
Bör nuvarande användare installera v1.0.10 från originalinlägget?
Nej. Projektet har fått många kompatibilitets- och säkerhetskorrigeringar sedan den versionen.
Varför använder ZFW DOCKER-USER?
Docker-publicerad trafik kan kringgå vanlig INPUT-filtrering på värden, så ZFW använder Dockers dedikerade filtreringsväg för containerportar.
