I wrote a firewall rule and nothing happens: the three level switch

You wrote the rule, you saved it, and nothing changed. Traffic still passes, or the thing you wanted blocked was not blocked. Not because the rule is wrong, but because the layer the rule sits in is switched off.

Three levels, all three at once

The firewall is not switched on in one place. It has three levels, and each has its own switch: the cluster level at the top, the node level in the middle, the machine's network interface at the bottom. A rule works only when the whole chain is on. A flawless rule written on the machine does nothing while the switch above it is off, and it gives no warning either.

So the diagnosis runs top down: is the top switch on, then the node, then the machine. Starting at the bottom costs time.

The second switch at the machine level

On the machine side the switch does not sit on the machine itself, it sits on the network interface. Turning the firewall on for the machine but not on the interface, or the reverse, still leaves the rule inert. Because these are two different places, it is often missed.

The direction question

Rules are written from the machine's point of view. Incoming and outgoing are not the same rule, and which side counts as "in" also depends on which level you are at. The most ordinary reason a rule never matches is that it was written for the wrong direction.

Order is a rule too

Rules are read top to bottom and the first match wins. A narrow deny rule written below a broad allow rule is never read. A rule list is not a set, it is a sequence.

The fear that stops everyone

Turning on the top switch frightens people, because the moment they do they might lose the panel and never turn it on again. That fear is not unfounded: the default behaviour, and whether your management access is protected by a rule, is what decides it here. The right order is to write the rule that keeps management access open first, and turn the switch on second. Done the other way round, someone who gets locked out once never touches that switch again, and the machine stays unprotected for years.

Knowing whether a rule is working

The most useful habit is to look at the log. If a rule matches it leaves a trace; if nothing appears, either the chain is off or the rule is not matching. Looking instead of guessing is what saves the most time here.

There are two firewalls, look at both

The virtual machine's own operating system may be running a firewall as well. A packet blocked inside the machine never shows up in the log on the server side. That is the most common answer to "everything is open on the server but I cannot connect".

What Atlas does

Atlas lists the node level rules on a single screen. Above the rule list sits a separate strip with the state of the chain: it says whether the rules are in effect right now. The list on its own says "a rule exists", not "the rule is working"; the strip says exactly that difference.

The option to turn the switch on from that strip was deliberately left out. If the top switch is turned on without a rule protecting management access, the panel can be lost; showing and switching are separate jobs.

Rules can be switched on and off individually, so you can test what a rule does without deleting it.