I chose Firewalld not because I love it, but because it’s good enough and common across all distributions. We can install it on any systemd based distribution and know it’ll work the same across all of them.
It isn’t mandatory; you can use whatever firewall you prefer, and Webmin even has a module for a few of them (iptables, CSF, etc.), but we needed something that was simple, reliable, and consistent across all of the distributions we support. Firewalld isn’t a CentOS/RHEL/Fedora thing. It is its own open source project, independent of any distribution or vendor, which was also really important in my decision-making process. ufw is an Ubuntu project. We don’t really do that kind of distro specific thing; we use the conventions of the distro for config files, but we don’t use distro-specific programs, as it would lock users into that distribution (the lock-in probably isn’t a big problem with regard to a firewall, but still a concern).
I’m also not a fan of firewall generation tools that abstract away the specific rules…firewalld is borderline, but it’s basically a thin wrapper over iptables that uses D-Bus rather than a monolith that spits out firewalls based on a configuration file. It’s working directly on the firewall rules, which is a subtle distinction, but matters to me. So, ufw has two strikes against it (it is distro-specific, and it is a rules generator rather than a tool for working directly with the firewall).
So, for folks who want something simple that Just Works out of the box and looks the same on any supported distribution, FirewallD is great. It does the thing, provides some abstraction of some complex topics, and will smooth over migration pain in the transition to nftables in the future (which I keep hoping will start happening any day now, because nftables is sweet). I was torn about using firewalld vs. iptables and was leaning strongly toward iptables until a user kinda pushed back and wanted firewalld and so I did some more research and found there are some good arguments for choosing firewalld.
And, yes, to be clear: If you are using firewalld to manage your firewall you would not use any other tools to manage the firewall.
Firewalld “owns” the firewall on the system, and all management should be done using the firewalld commands or the Webmin firewalld module. If you don’t want to use the firewalld tools, you need to disable the firewalld service, and switch to the service you do want to use and recreate your rules. There is a
virtualmin config-system command that will initialize an iptables firewall, and can also setup fail2ban to use iptables (though switching after installation hasn’t been tested…you’ll want to check the configs it generates and make sure it’s actually working).
Something like (assuming firewalld has been stopped and disabled, and fail2ban has, as well):
# virtualmin config-system --include Firewall Fail2ban
The Firewalld versions of those config-system plugins are
I have vague feelings that while the iptables firewall will work without any poking after doing this, the fail2ban config will probably need a little bit of human attention…since iptables would be a blank slate while fail2ban would already have some config from the initial installation configuration, and for now the config-system command assumes a fresh install of the services it configures (I’m working on rollback functionality for Virtualmin 7, so you can undo what the installer changes, but it’s not in there yet).
But, really, unless you have specific firewall needs, just use the defaults and add whatever extra rules you need using the firewalld module. Most servers don’t need and aren’t well-served by complicated firewalls. They just tend to confuse your future self with unnecessary complexity. A world-facing server has a different security profile and process than a private network with client systems and maybe a DMZ or similar (where firewalls serve an important purpose and may need to be quite complex).
If I can impart any wisdom here, it’s this: If you’re worrying about what firewall is running beyond needing to know which tools to use to manage it, you’re probably spending too much time/effort on the firewall. It probably isn’t doing anything useful for the security of your server and your time would be better spent making sure you’re up to date, you’ve disabled services you don’t need/use, you’ve got strong passwords, and your custom applications are constructed with care. Firewalls on servers are generally not very useful, except for dealing with specific problems (fail2ban automates handling one kind of specific problem, and you can also address things like DoS attacks at the firewall level), but you can’t prevent an exploit of an unpatched service with a firewall without turning off access to the service (in which case, turning off the service would be even more effective).