Bug 1379110

Here is the workaround command I've been using as the entries show up in the log, but it kind of defeats the purpose of fail2ban if I have to manually check the log and issue block commands:

firewall-cmd --zone=home --add-rich-rule='rule family="ipv4" source address="116.31.116.16" drop

I believe I have found the problem...

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

This is the default rule being created... it isn't blocking traffic.

To get it to work I needed to change "REJECT --reject-with icmp-port-unreachable" to "DROP"

However, to do this, I had to manually change the firewallcmd-ipset.conf file 
<blocktype> variable to the fixed value DROP as follows:

actionstart = ipset create fail2ban-<name> hash:ip timeout <bantime>
              firewall-cmd --direct --add-rule ipv4 filter <chain> 0 -p <protocol> -m multiport --dports <port> -m set --match-set fail2ban-<name> src -j <blocktype>

actionstop = firewall-cmd --direct --remove-rule ipv4 filter <chain> 0 -p <protocol> -m multiport --dports <port> -m set --match-set fail2ban-<name> src -j <blocktype>
             ipset flush fail2ban-<name>
             ipset destroy fail2ban-<name>

to

actionstart = ipset create fail2ban-<name> hash:ip timeout <bantime>
              firewall-cmd --direct --add-rule ipv4 filter <chain> 0 -p <protocol> -m multiport --dports <port> -m set --match-set fail2ban-<name> src -j DROP

actionstop = firewall-cmd --direct --remove-rule ipv4 filter <chain> 0 -p <protocol> -m multiport --dports <port> -m set --match-set fail2ban-<name> src -j DROP
             ipset flush fail2ban-<name>
             ipset destroy fail2ban-<name>


If I read the documentation correction, I should be able to simple create a file
iptables-blocktype.local which will override the <blocktype> defaults...

[DEFAULT]

blocktype = DROP

It doesn't work...

I found where apparently the file should be:

iptables-common.local now instead of iptables-blocktype.local

I created it as follows:

[Init]

blocktype = DROP


So that works around the issue, but we probably shouldn't have a command that doesn't work as the default - unless I'm missing something...

Well, I still have it working but the whole DROP vs REJECT reason for failure was a red herring - although the exercise allowed me to figure out how to change the default via iptables-common.local

What I found was at times when fail2ban is shutdown, for whatever reason the ipfilter rule:  firewall-cmd --direct --get-all-rules isn't deleted - and apparently this somehow causes the ban functionality to not work when fail2ban is restarted.  

I found that if I manually delete the rule when this happens before restarting fail2ban that circumvents the issue.  I did notice there is a new release of fail2ban while going through all of this... maybe that fixes the issue.  I haven't been able to figure out causes the issue.

Sorry for all the comments, thought I'd add one last one for people who may encounter this issue so they don't have to drudge through all my blather above:

If you notice that things aren't being banned correctly, first shutdown fail2ban

systemctl stop fail2ban.service

Then, check to see if there are any "--match-set fail2ban-sshd" rules:

firewall-cmd --direct --get-all-rules

There shouldn't be... if you notice that there are, get rid of them by:
copying the rule:  starts with:  ipv4 filter ... 

issue the command:  
firewall-cmd --permanent --direct --remove-rule <paste line copied here>

Now you should be able to start fail2ban:  
systemctl start fail2ban.service

if you reissue the:
filewall-cmd --direct --get-all-rules

you'll notice that the "--match-set fail2ban-sshd" rule has been recreated.

Whenever you shutdown fail2ban, this rule should be deleted.  At times, and I haven't figured out why... it isn't - and it appears this causes an issue with things being banned.  At least that is what I have observed.

The other thing I learned (as mentioned above) is that if you want to change the default behavior of the ban from REJECT to DROP you need to create the

iptables-common.local

file as mentioned in comment #3.

You'll find references on the web and in some of the actual files in fail2ban  to "iptables-blocktype.local" - this doesn't work.  Not sure if it used to be called that and they changed their mind or it has some other function now.  In any event... it doesn't work to change the default behavior... for that, use iptables-common.local

FWIW - I can't reproduce this on rawhide with 0.9.5, so I'm hoping it will be fixed with the update.

fail2ban-0.9.5-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7db83f651b

Just left feedback on bodhi... appears to have fixed the issue.  Thanks!

fail2ban-0.9.5-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.