Problem with Fail2Ban blocking after FirewallD restart

On a CentOS 7 system where FirewallD is employed as the system's host-based firewall, I use Fail2Ban to block brute-force break-in attempts by Secure Shell (SSH). When I issued a FirewallD command to view the firewall rules currently in effect, I saw one related to the Fail2Ban blocking service.

$ firewall-cmd --direct --get-all-rules
ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable
$

I added a new permanent rule with the command below:

# firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='116.31.116.0/26' reject"
success
#

To have the new permanent rule take effect immediately, I had to restart the FirewallD service to add the additional blocking rule to the rules currently in effect. When I did so, I found that the rule related to Fail2Ban was no longer appearing.

$ systemctl restart firewalld.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or units.
Authenticating as: root
Password:
==== AUTHENTICATION COMPLETE ===
$ firewall-cmd --direct --get-all-rules
$

The Fail2Ban process was still running as I could see when I checked with the pgrep and ps commands. I could see that the process ID (PID) for the process was 1716.

$ pgrep fail2ban -fl
1716 fail2ban-server
$ ps -e | grep fail2ban
 1716 ?        01:45:02 fail2ban-server
$

When I restarted the Fail2Ban service, I found the rule had been reapplied to the running configuration.

# systemctl restart fail2ban.service
# firewall-cmd --direct --get-all-rules
ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable
#