Once every two restarts of the fail2ban service, if one checks the logs, the iptables-allports action fails, and thus fail2ban becomes useless. The service still appears as being up. I am using the iptables-allports action for ssh and ssh-ddos in my iptables configuration, so i'm unsure as to whether this issue only appears when two rules use iptables-allports. Reproducible: Always Steps to Reproduce: 1. /etc/init.d/fail2ban restart 2. check logs/iptables -L output, if the action succeeded do a /etc/init.d/fail2ban restart again 3. iptables-allports action fails to start but the service is considered up by the init system Actual Results: iptables is useless if the action startup failed since the fail2ban-sevice iptables chain isn't added Expected Results: the action starts and adds the relevant iptables chains
Created attachment 267401 [details, diff] patch aginst /etc/fail2ban/actions.d/iptables-allports Adding a sleep to the action startup seems to fix the problem for me
I forgot to add this happens with the latest fail2ban in portage tree: net-analyzer/fail2ban-0.8.4-r2
Created attachment 268173 [details, diff] /etc/fail2ban/actions.d/iptables-allports.conf patch that detects when the chain allready exists This patch both fixes the behaviour where if the iptables-allports rule is enabled in multiple jails, one of the jails fails to start sometimes. Also, makes it so that if the chain has allready been added it doesn't add a second referece to it.
Created attachment 268207 [details, diff] iptables action for fail2ban using locking This patch works much better, the real problem is that fail2ban seems to start actions in parallel, so if two jails use the same action it well get run twice. Sometimes i guess this can be good, but not in the case of iptables rules, as it adds two references to the same chain, which means netfilter will have to pass through the chain twice for each packet. This patch makes use of the flock locking utility for the shell, so the same action isn't executed in parallel, and it also makes sure two references are not added to the same rule. This can probably be used in other rules aswell.
This should be fixed in 0.8.6