Description of problem: Noted after upgrade from FC26 to FC27. When starting fail2ban.service, it seems to cause firewalld to look for the iptables-restore script. This script is not installed on the system. How reproducible: systemctl restart fail2ban.service Watch systemd journal for the following: Dec 12 09:38:09 host.com fail2ban-server[6031]: Server ready Dec 12 09:38:09 host.com firewalld[1162]: WARNING: '/usr/sbin/iptables-restore --wait=2 -n' failed: Dec 12 09:38:09 host.com firewalld[1162]: ERROR: COMMAND_FAILED Dec 12 09:38:15 host.com firewalld[1162]: WARNING: '/usr/sbin/iptables-restore --wait=2 -n' failed: Dec 12 09:38:15 host.com firewalld[1162]: ERROR: COMMAND_FAILED Dec 12 09:38:16 host.com firewalld[1162]: WARNING: '/usr/sbin/iptables-restore --wait=2 -n' failed: Dec 12 09:38:16 host.com firewalld[1162]: ERROR: COMMAND_FAILED Fail2ban shows 3 IPs that should be banned but they are not actually rejected by the firewall: fail2ban> status sshd Status for the jail: sshd |- Filter | |- Currently failed: 14 | |- Total failed: 1518 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd `- Actions |- Currently banned: 3 |- Total banned: 3 `- Banned IP list: 121.18.238.125 192.129.227.186 218.65.30.251 ipset -L Name: f2b-sshd Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem 65536 timeout 86400 Size in memory: 88 References: 0 Number of entries: 0 Members: Above ipset not seen in output of iptables -L -v
Correction. The iptables-restore script IS installed, but is failing on a --wait parameter which seems to not be supported. The issue has been verified to be related to the presence of /etc/firewalld/direct.xml: http://www.firewalld.org/documentation/man-pages/firewalld.direct.html Removing direct.xml and restarting seems to have fixed my issue. This seems to be related to an reported by unresolved issue in 1370682.
This seems more of a firewalld issue than a fail2ban one. Unless someone can provide evidence that fail2ban is calling a firewalld command incorrectly.
After applying the fix from 1525134 this did not occur at next restart.
Thanks. *** This bug has been marked as a duplicate of bug 1525134 ***