FirewallD Rich Rules Module -- full UI for complex firewall rules

Developers
1

I develop for Volantic Systems and built a Webmin module for managing firewalld rich rules. The existing FirewallD module handles zones, services, and basic port rules, but rich rules (the rule family=… syntax in firewall-cmd) have
no GUI. This module fills that gap.

What it does:

  • Create, edit, clone, test, and bulk-manage rich rules across all zones
  • Full coverage of the rich rule spec: all 9 element types, source/destination with NOT variants, MAC, ipset, all reject types, logging (syslog + nflog), audit, rate limits, priority, port forwarding
  • Live preview showing exact firewall-cmd syntax as you build the rule
  • “Test Rule” button validates against the runtime without persisting
  • Auto-categorizes rules by origin (admin vs. fail2ban)
  • Tabbed browsing, filtering, and search
  • 40-test integration suite with a failsafe watchdog

Works with Webmin 2.0+ and any Linux distribution running FirewallD 0.3.0+. Uses the standard Webmin module API (ui_table, ui_columns, ui_form, etc.) and the Authentic theme throughout.

Repo: GitHub - VolanticSystems/webmin-rich-rules: Webmin rich rules · GitHub

Feedback welcome. Happy to adapt it if there’s interest in including it upstream.

2

Hello,

Thanks for sharing this!

I was planning to add rich rules in the UI using the Webmin FirewallD module, but we decided to switch to the new Webmin Nftables module for production.

3

Thanks Ilia, I appreciate the response and understand the direction toward nftables.

One thought, though: part of the reason Red Hat created firewalld in the first place was to abstract the underlying packet filter (whether iptables or nftables) into concepts like zones, services, and rich rules that are manageable without memorizing kernel-level syntax. Firewalld already sits on top of nftables on modern systems, so it’s not really a competing technology; it’s an abstraction layer over it.

From a UI perspective, that abstraction is what makes a clean GUI possible. Zones map to dropdowns, services map to checkboxes, rich rules map to structured forms. Raw nftables (tables, chains, hooks, verdict maps, priorities) is much harder to represent in a usable interface. The few attempts I’ve seen on GitHub either handle only basic rules and/or were abandoned.

Firewalld is actively maintained by Red Hat, is the default on RHEL, AlmaLinux, Rocky, and Fedora, and isn’t going anywhere. This module fills a specific gap: rich rules had no Webmin UI. I intend to keep maintaining it as the firewalld ecosystem evolves.

If it’s not a fit for bundling, would you consider listing it as a recommended third-party module?

Either way, happy to help if there’s anything useful here for the nftables effort.

1 Like
4

Well, there is a difference between Webmin and Webmin bundled with Virtualmin. Firewalld bundled with Virtualmin may go away but this remains perfectly valid for Webmin regardless doesn’t it?

5

as long as you don’t use it with debian/ubuntu systems that use init for network control, I’ve fallen foul of this one so I no longer use Firewalld in favour of something I coded myself which currently uses iptables as a back end but over the last week or so I have started to develop a nftables version so for one I would not find this module useful however users that RHEL (assuming that Firewalld doesn’t clash with init) may find this useful

6

I’ve come to the conclusion that most people find the abstractions in firewalld more confusing than the “kernel-level syntax” of iptables or nftables (though I don’t think that’s an accurate description of those tools…nftables is a user tool with intentionally human-readable syntax).

I’m certainly not opposed to expanding the firewalld module feature set, but I don’t think this really fits as a thing we could just drop in. We wouldn’t want to add a whole other module just for rich rules, we’d want to just expand the existing module with a few tweaks to support more types of rules, etc. And, it’s a lot of code to review. We’re not, like, religiously opposed to LLM-generated code in Webmin (the new nftables module was partly written by Claude, though all three of us have touched the code as well), but reviewing and modifying AI-generated code is extra challenging, as it is verbose and often mis-aligned with human desires without a lot of care.

Ours isn’t abandoned. :wink:

It ships with Webmin, and will be supported for years to come.

We’re not removing the firewalld module and certainly won’t stop folks from using it in the future with Virtualmin. But, from my time spent supporting firewalld, I’ve come to regret choosing it for Virtualmin. People find it really confusing. And, now that I’m not immersed in it as I was when initially developing the Virtualmin installer support and such, I also find it confusing. It doesn’t fit my mental model of how firewalls work, while nftables does.

We don’t really recommend stuff. I mean, we bake our recommendations into the installer, and try to stay out of the way for folks who want to do things differently. We’re not opposed to you announcing the module (and new versions in the future) in the Thirdy-Party News category, though.

For bundling, it would need to be an extension of the current firewalld module, rather than a whole new module, and it’d need to come in via a series of small-ish PRs to Webmin that a human could easily review. Since we’re not going to be using firewalld for Virtualmin going forward, the module itself probably will be somewhat neglected (it’s a Webmin core module, so it’ll continue to be fully maintained, but it’s probably not getting new features from us), and we’d have no problem with someone else contributing new features or bugfixes to that module, as long as they’re in a form we can easily review and test.

1 Like
7

Thanks for the feedback, Joe. A few thoughts.

On the abstraction question, I’d suggest perhaps a wider perspective. Rich rules cover a lot more than basic port filtering. The full scope includes source and destination IP/network restrictions, port forwarding (DNAT), masquerading (SNAT), logging with configurable prefixes and levels, rate limiting, ICMP type filtering, mark/set operations, accept/reject/drop with specific ICMP reject types, protocol matching beyond TCP/UDP, and time-based rules.

Several of these are cumbersome to express in raw nftables and benefit from the structured abstraction firewalld provides. The nftables module as of 2.640 handles port-based allow/deny, which is a good start, but it’s a different scope.

To jimr1’s point about Debian/Ubuntu: fair concern. The module does depend on firewalld, which is standard on RHEL, AlmaLinux, Rocky, and Fedora but not default on Debian-based systems. It’s targeted at that ecosystem.

And ID10T makes a good observation that Webmin and Virtualmin serve different audiences; standalone Webmin users on RHEL-family systems are the natural fit here.

Either way, I’m glad the nftables module exists for people who want to work at that layer. For those of us running firewalld in production on RHEL-based systems, the rich rules module fills a gap that’s there today.

My own use case is practical: restrict SSH to my specific networks so the rest of the planet can’t connect, lock down database ports to known IPs, and open access on the fly when I find myself at a remote location. Rich rules handle that cleanly through the zone/service/source model, and the module puts it all in a UI where I can manage it without remembering syntax.

And you’re right, I used Claude to develop it. It was one of those things I’d been meaning to do for a long time, and the tooling made it practical to finally build. I intend to maintain it going forward. Perhaps others will find it interesting as well.

3 Likes
8

I always applaud anyone who can create a quality GUI to help with configuration. A decent GUI can add more intuitive advantages to any system.

1 Like