ZimaOS' own remote access was being dropped by ZFW
ZimaOS ships znet / Zima Net — IceWhale's built-in remote-access mesh, an embedded EasyTier — and it owns the interface tun0. ZFW bypassed every other mesh (tailscale0, ZeroTier's zt+, WireGuard's wg+) but not that one, so every inbound packet arriving through Zima Net hit the catch-all DROP.
Measured on a ZimaCube:
ZFW-IN-DROP IN=tun0 SRC=10.126.126.243 DST=10.126.126.1 PROTO=TCP DPT=9527
125 dropped SYNs in a single connection attempt. The desktop client hung on "connecting" indefinitely while tun0's tx counter sat at 668 bytes for days. Adding the bypass moved it within two seconds.
Fixed: tun0 is now in the bypass list of all four emitted chains — ZFW-IN, ZFW-IN6, DOCKER-USER and its IPv6 counterpart. The first fix, applied by hand, covered only ZFW-IN and was therefore incomplete; the test now asserts all four chain outputs so a partial addition cannot pass again.
Who is affected — measured, not assumed
Zima Net is not new in v1.7.1-beta1. The official ZimaOS 1.7.0 bundle, downloaded and verified against the published checksums.txt (0c990f24…0df570), already contains:
| Path in the stock 1.7.0 rootfs | |
|---|---|
usr/bin/znet |
the binary |
usr/lib/systemd/system/znet.service |
the unit |
usr/lib/systemd/system-preset/80-znet.preset |
contains enable znet.service — on by default |
etc/systemd/system/multi-user.target.wants/znet.service |
symlink already baked into the image |
usr/share/zimanet/VERSION |
0.1.0-2.6.4 |
usr/share/casaos/modules/zimanet.json |
registered as a ZimaOS module |
So every stock ZimaOS 1.7.0 host running ZFW ≤ 1.0.23 is dropping Zima Net traffic, not only 1.7.1-beta1 hosts. IceWhale's release notes mention Zima Net in neither version — absence from a changelog is not absence from the image. Older ZimaOS releases were not checked; the claim is deliberately "since at least 1.7.0".
That it is IceWhale's own component rather than a third-party leftover is measured too: 161 easytier strings in the shipped binary, plus hardcoded IceWhale roots (planet.net.icewhale.io, root.remote-eu-central-1a.icewhale.io and three further regions).
How to tell whether this is your problem
On the host: ip -br link | grep tun — if tun0 exists with an address in 10.126.126.0/24, Zima Net is running. In the ZFW UI, the Events tab shows the drops, with the source IP and destination port.
Note for VPN users generally
The wg+ auto-allow only applies when WireGuard terminates on the ZimaOS host. If your VPN terminates on your router (a Freebox, a UniFi gateway, a Fritz!Box), clients arrive on the LAN interface with a source address from the VPN subnet, and the starter rules — which are pinned to the LAN CIDR ZFW detected at install time — will not match them. Add an allow rule with that VPN subnet as its source, in the right zone.
Verification
gofmt/go vet/go test clean; CI green on all five jobs. The shipped amd64 payload unpacked from zfw-amd64.raw carries the version string 1.0.24 (and no other 1.0.2x) and the tun0 bypass on both the ACCEPT and RETURN chains. The README.md inside the tarball leads with the v1.0.24 block. Tarball checksums in mod-store/zfw.yaml come from dist/*.sha256 of this exact build.
amd64 b6fcfad24cd9ad31a6656d9817c7007b3c0dcd24c378c7256a6ad08f211665c2
arm64 9a5f117471d84659b41ee71fb91824b285a9290a46cc331a9ba06764be531520