The firewall governs what is forwarded, and never closes ssh #23

2026-09-14T13:27:24Z

jschoubben commented

2026-09-14 13:27:24 +00:00

Fixes both halves of issue 047, which run in opposite directions.

Forwarded traffic. There was no forward chain, on the reasoning that dropping there stops every container the runtime explicitly allowed. The first half of that is true. The conclusion was not: a published port is redirected and then forwarded, so it never reaches the input chain, and a firewall with no forward chain is silent about exactly the ports most worth protecting.

The way through is the one the system being replaced has been using on these machines for months: deny by default there, then allow the runtime's own networks explicitly, so containers keep working while everything else has to be asked for. A forwarded rule matches what the client originally asked for rather than where the packet is going, because the destination has already been rewritten by the time the chain sees it.

ssh. Now a floor that nothing derives. Every other line in the chain comes from what is assigned to the node, which is the whole point of the mechanism — but a mesh part-way through adopting a machine has been assigned almost nothing, so what it computed was a chain that shut the port used to fix it. The session loading the rules survives on conntrack until it drops, and then the machine is reached from a rescue console. Open from the mesh always; open from outside on a machine that faces outward, because that is the way in on the day the private network is what broke.

Rehearsed on three lab machines, same probes before and after:

	undeclared host port	docker port, declared mesh-only
from inside the mesh	blocked	reachable
from outside the mesh	blocked	blocked

Before this, the bottom-right cell was reachable.

The test asserting there was no forward chain is replaced by ones asserting the chain exists, denies by default, and still lets the runtime's networks through — which is the thing the old decision was protecting and which had to survive.

Fixes both halves of issue 047, which run in opposite directions. **Forwarded traffic.** There was no forward chain, on the reasoning that dropping there stops every container the runtime explicitly allowed. The first half of that is true. The conclusion was not: a published port is redirected and then *forwarded*, so it never reaches the input chain, and a firewall with no forward chain is silent about exactly the ports most worth protecting. The way through is the one the system being replaced has been using on these machines for months: deny by default there, then allow the runtime's own networks explicitly, so containers keep working while everything else has to be asked for. A forwarded rule matches what the client originally asked for rather than where the packet is going, because the destination has already been rewritten by the time the chain sees it. **ssh.** Now a floor that nothing derives. Every other line in the chain comes from what is assigned to the node, which is the whole point of the mechanism — but a mesh part-way through adopting a machine has been assigned almost nothing, so what it computed was a chain that shut the port used to fix it. The session loading the rules survives on conntrack until it drops, and then the machine is reached from a rescue console. Open from the mesh always; open from outside on a machine that faces outward, because that is the way in on the day the private network is what broke. **Rehearsed on three lab machines**, same probes before and after: | | undeclared host port | docker port, declared mesh-only | |---|---|---| | from inside the mesh | blocked | reachable | | from outside the mesh | blocked | blocked | Before this, the bottom-right cell was reachable. The test asserting there was no forward chain is replaced by ones asserting the chain exists, denies by default, and still lets the runtime's networks through — which is the thing the old decision was protecting and which had to survive.

jschoubben added 1 commit 2026-09-14 13:27:25 +00:00

The firewall governs what is forwarded, and never closes ssh c8d8211385

Two faults, opposite directions, both in issue 047.

There was no forward chain, on the reasoning that dropping there stops every
container the runtime allowed. The first half is true; the conclusion was not. A
published port is redirected and then forwarded, so it never reaches the input
chain — the firewall was silent about the ports most worth protecting. The way
through is the one the system being replaced already used: deny by default, then
allow the runtime's own networks explicitly. A forwarded rule matches what the
client originally asked for, because the destination has been rewritten by the
time the chain sees it.

And ssh is now a floor nothing derives. Every other line comes from what is
assigned, which is the point — but a mesh part-way through adopting a machine
has been assigned almost nothing, so what it computed was a chain that shut the
port used to fix it. From the mesh always; from outside on a machine that faces
outward, because that is the way in when the private network is what broke.

Rehearsed on three machines: a docker-published port declared mesh-only is now
reachable from inside the mesh and refused from outside. Before, it was
reachable from both.

jschoubben merged commit 844dd09434 into main

2026-09-14 13:27:35 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#23