Thanks, @Ilia … That’s the sense I am getting. I was headed down the wrong path by statements such as this one:
FirewallD is an IPv6 compatible firewall mechanism used in recent Linux distributions (RedHat/Fedora/CentOS) replacing good old iptables.
I now understand that statement is misleading at best.
So I do have iptables installed. That confusion continued as I searched for a solution to my issue:
- the bootup/shutdown list doesn’t list
iptables but does list firewalld
- The way this is all being used, in particularly by fail2ban in Webmin, firewall-cmd doesn’t see firewall details on the surface. (ACTUALLY, they are all there now! The needed commands are a bit obscure – see below.)
Here’s my new understanding of the reality:
- FirewallD (and firewall-cmd) is not a firewall at all. It is a UI for a backend firewall, either the older iptables or newer nftables packet filters, and other associated bits.
- iptables refers to two entirely separate things (managed by the netfilter.org project)
- a kernel packet filtering technology (being replaced by the nftables packet filter)
- the
iptables firewall definition command utility (nft is the equivalent for nftables architecture)
- Because the actual packet filters are built into the kernel, there’s no visible iptables or nftables process.
So in simple terms:
- FirewallD is a front end that currently uses iptables as its backend.
- Here are some handy commands for viewing and managing fail2ban firewall info.
- NOTE: firewall rules and IPset tables are only created once there is something to be banned.
- NOTE: “direct” rules do not display in the Webmin GUI. Yet that’s how fail2ban functions. Perhaps someday this can be added…
# firewall-cmd --direct --get-all-rules
# ipset list -t //list all IP sets: names and entry counts
# ipset list // list all IP addresses as well
And for diagnosing and detecting any issues, here’s how to temporarily log banned packets (without logging ALL drops. You don’t wanna do that 
) … There’s probably a way to do this with firewall-cmd but I haven’t deciphered it yet…
// Create a chain to log, then reject with appropriate packet for tcp and all others
// NOTE if you forget "-p tcp" the new nf_iptables backend gives a useless error message. I wasted too much time finding that ;)
iptables -N LOG_Reject
iptables -A LOG_Reject -j LOG --log-prefix "f2b reject " --log-level 6
iptables -A LOG_Reject -p tcp -j REJECT -reject-with tcp-reset
iptables -A LOG_Reject -j REJECT
And now, to replace a rule with a logging rule
// List the direct firewall rules, incl rule line number
iptables --line-numbers -vnL INPUT_direct
// An example: to log all hits on the postfix_sasl IPset...
// It's rule #4 in the list we displayed above
// Safest careful way: append a new rule, then delete the old
iptables -A INPUT_direct -m multiport -p tcp --destination-port 25,465,587,143,993,110,995 -m set --match-set f2b-postfix-sasl src -j LOG_Reject
// (Now list again and ensure the new rule is what you want)
// Now delete the old
iptables -D INPUT_direct 4
(After all that, it appears I may have found a bug in fail2ban. It does block for a little while but the bantime specified is kinda-sorta ignored.)
