The firewall
Everything on this page is on the console's Options page, on the Firewall, Whitelist and Blacklist cards.
Which chain the bans go into
The most consequential setting in the product is the chain, and it is the one you have the least chance of checking by eye.
| Chain | Use it for |
|---|---|
| DOCKER-USER (default) | Services that are published container ports. That traffic is forwarded, and never passes INPUT |
| INPUT | A service listening on the host itself |
A jail pointed at INPUT on a host whose services are published container ports is perfect in
every visible way - the jail runs, the ban is recorded, the rule is written - and blocks nothing.
The reverse is just as silent: a jail protecting the host's own SSH, pointed at DOCKER-USER,
blocks nothing either. A NAS that runs Docker usually needs INPUT, because its jails protect the
NAS itself. When one host has both kinds, give a jail its own chain: see
A jail's own chain.
Chain, Ban action and Ban action, all ports are lists of what this host can use
(GET /firewall/choices), read when the page opens:
- Chain offers
INPUT,DOCKER-USERwhen Docker runs here, and the host's other chains. It leaves out fail2ban's own chains, Docker's other chains andOUTPUT, which no ban belongs in. - Ban action offers the iptables action, the iptables action with an ipset, and the nftables
action. One this host cannot use is shown greyed out with the reason: no working ipset (normal on
a NAS), or no
nftcommand, which the image does not carry. Choosing one sets Ban action, all ports to the same kind. - Your own actions: an action file you put in the
action.dfolder of the configuration volume (/config/action.d/<name>.conf) is offered in both lists under its name, and fail2ban reads it from the next save or restart. A file named like an action fail2ban ships is not used, and the log says so: name it differently, or change the shipped action with a<name>.localfile. - A saved value the list does not offer stays in the list, marked as the current setting, so a save never changes it behind your back.
When the firewall cannot be read at all, the three fields are plain text boxes and Diagnostics says why.
Auto-detect (GET /firewall/detect) looks at the host and fills in the ban actions and IPv6 to
suit it, with one sentence per decision so you can disagree with a reason. It leaves the chain and
Blocked packets as you set them, because those follow from what your jails protect, which the
firewall cannot tell; it only replaces a chain that does not exist on the host. It only fills in the
form; nothing is applied until you save.
Diagnostics (POST /firewall/diagnostics) lists the host's firewall tooling and proves a rule
can actually be written, which is the question the bans list cannot answer.
Blocked packets decides what a banned packet meets: a rejection, or nothing at all. It applies to
fail2ban's iptables-* actions; the nftables actions use their own vocabulary and are left alone.
The iptables backend
Most distributions' iptables is the nftables-backed one, which needs kernel modules that NAS and appliance kernels (Synology DSM, for example) do not ship. There every firewall call fails, while fail2ban still starts, runs its jails, counts failures and records its bans - so every page in the console looks right and nothing is blocked.
The container therefore picks a backend before the daemon starts: nft when a rule can be
written with it, legacy when it cannot. Set Fail2Ban__IptablesBackend to nft or legacy to decide it
yourself. The Firewall card reports which one is in use.
The whitelist and the blacklist
- Whitelist (never banned): addresses and ranges no jail ever bans. Loopback is always ignored on top of these, Never ban this host adds the host's own addresses, and Never ban private addresses (on by default) adds the private ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and fc00::/7.
- Never ban this host (on by default) covers every address on the server's network interfaces: its LAN address and the gateway of every container network on it, such as Docker's own bridge. Traffic the server sends to its own containers arrives from such a gateway, so without this the server could ban itself. It holds in every jail, including a jail that sets its own ignore list, and the addresses are checked again every minute, so a container network created later is covered within a minute. Only the gateway addresses are covered, never the container networks themselves: the containers can still be banned.
While Never ban private addresses is on, a failed login from your own network is detected and then ignored, so testing a jail from a PC on the LAN never produces a ban. Test from outside, or switch it off - and put the addresses you manage the host from on the whitelist first, or a few mistyped passwords lock you out.
- Blacklist (always banned): addresses and ranges banned permanently, whatever any jail has
seen. A permanent block is an ordinary ban in a reserved jail,
antelao-blocklist: it goes through the same action into the same chain, survives a restart, and appears on the bans list beside everything else. That jail cannot be edited directly, because the next options save rewrites it.
An address cannot be on both lists. fail2ban never bans an address it has been told to ignore, so the entry would look enforced and block nothing; the console and the API refuse the pair.
Repairing the rules
Rebuild the rules (POST /firewall/rebuild) has fail2ban write its chains again from what it is
currently enforcing, and removes any f2b- chain no running jail accounts for.
Those leftovers are what a replaced container leaves behind: with host networking the rules belong to the host and outlive the container that wrote them, so the chains can grow by a full set of rules per restart with nothing reporting it.
It also removes a running jail's old rule after the jail's port or chain changed. fail2ban removes only the rule it would write now, so the one with the old port stays behind, still sending that port's traffic into the jail's bans. The report lists these under Old rules removed.
It is a rebuild, not a reset:
- Every ban is written out again from the daemon's own database, and the report states the ban count before and after, so the result can be checked rather than trusted.
- Nothing outside the
f2b-prefix is ever touched, and a rule that cannot be read safely is reported and left alone. - It does not lift bans; that is the Bans page.
- It is not license-gated: it repairs what is already being enforced.