IPTables causes conflict with Fail2Ban

Question

OS: Ubuntu Server 18.04

Fail2ban: v0.10.2

I am trying to understand a bug with my Fail2ban installation (I believe from my own making). I have a cron job that populates iptables with a predefined list using:

iptables -A INPUT -s <ip address> -j DROP
iptables -A INPUT -s <ip address> -j DROP
etc
etc

At the beginning of this script, it runs:

iptables -F INPUT to flush the INPUT chain. This cron job was present on the server before I installed Fail2ban to dynamically ban bad actors. However, I noticed I started getting a lot of notices stating that a particular IP was already banned. When I stopped the iptables cron job from running, this error disappeared, and has been runnning without any issues whatsoever.

My question is: What sort of conflict am I creating by running iptables -F INPUT while Fail2ban is still running? Shouldn't this command be fine since banned IPs are placed into their respective f2b-<jail> chain, or am I misunderstanding? If this iptables script needs to run, should I also do something with the Fail2ban database (purge, etc)?

Thank you.

Answer 1

fail2ban must also place rules in the INPUT chain to call the chains it defines for each individual jail. By removing those, you are causing those rules to not apply, and the IP addresses that should be banned still get through, and fail2ban warns you about this by saying they were already banned.

You should not have any reason to flush the INPUT chain like this. Instead your cron job should create its own user-defined chain, and only add to the INPUT chain a rule to call that user-defined chain. Better yet, you should use an ipset, which has better performance and also can be atomically swapped when you want to change it. (And for that same reason you should have fail2ban use ipsets as well.)