1.9 KiB
Diagnosis
2026-10-02.
Not the tunnel. The route from either home machine to the target is the tunnel, and traffic to the 17 ports travels it in both directions. A placement fault would have stopped every port.
Not the target's filter. The target opens the failing ports to every address of the mesh in its input chain and its forward chain, the hub reaches them directly, and the SYN for a failing port never arrived at the target to be judged.
The hub's forward chain. A relayed packet comes in on the tunnel and leaves on it, so the hub's
forward hook judges it. The chain the controller renders (AsNftables) has a default of drop, accepts
established traffic, and accepts what did not arrive on an outward link or the tunnel. That last rule is
for the machine's own containers reaching outward. After that come the rules for this machine's own
published ports, each matching the original destination port of the connection. None of them names
an outgoing interface or a destination. So a relayed packet to another machine's port 20000 matched the
hub's own rule for its own port 20000 and passed. One to port 8080, which the hub does not publish,
matched nothing and was dropped.
The fix. One rule: in on the tunnel and out on the tunnel is accepted. That is the mesh passing
through to another of its machines, which filters it against its own rules. It does not widen anything
on the hub. A packet for the hub itself is the input chain's, and one for the hub's own containers
leaves by a bridge, not the tunnel. Both still meet their rules. WireGuard only accepts a packet from a
peer whose address that peer is allowed to use, so in-on-the-tunnel means from a machine of the mesh.
A controller test asserts the rule in the forward chain only, never in the input chain, and absent on a
machine with no tunnel. It fails without the fix, and the rendered set loads with nft -c.