Fail2ban service on Debian 12 exhibits inconsistent startup behavior

System Details:

  • OS: Debian 12 (Bookworm)
  • Control Panel: Virtualmin
  • Firewall: firewalld

Observed Behavior:
After a fresh installation of Virtualmin on Debian 12, the fail2ban service behaves inconsistently upon system or service restarts.

Steps to Reproduce:

  1. Install Virtualmin on a clean Debian 12 server with the default component selection.
  2. Restart the fail2ban service from the command line using systemctl restart fail2ban.
  3. Check the firewall ruleset for sshd-specific fail2ban chains using nft list ruleset | grep 'f2b-sshd'.

Observed Result:
In most cases, the f2b-sshd chain is not present in the firewall rules after a command-line restart. The service appears to be running, but the necessary firewall rules for the SSH jail are not applied.

Contrasting Behavior:
If, after the service fails to apply rules, I navigate to the fail2ban module in the Webmin UI (Webmin > Networking > Fail2Ban Intrusion Detector), open any configuration file, make no changes, and click the “Save” button, the f2b-sshd rules are immediately and correctly applied to the firewall.

Summary:
Restarting the fail2ban service via systemctl does not reliably result in the application of its firewall rules. However, triggering a configuration reload via the Webmin UI consistently resolves the issue and applies the rules as expected. This suggests an inconsistency between the two methods of reloading the service.

So maybe a difference between ‘service’ and ‘systemctl’?