I am getting this on a somewhat regular basis in my logs:
Sep 30 06:52:50 jik2 fail2ban.actions: WARNING [ssh-iptables] Ban 60.190.176.116
Sep 30 06:52:50 jik2 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q fail2ban-SSH returned 100
Sep 30 06:52:50 jik2 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
Sep 30 06:52:50 jik2 fail2ban.actions.action: ERROR iptables -D INPUT -p tcp --dport ssh -j fail2ban-SSH#012iptables -F fail2ban-SSH#012iptables -X fail2ban-SSH returned 100
Sep 30 07:02:51 jik2 fail2ban.actions: WARNING [ssh-iptables] Unban 60.190.176.116
I'm not certain, but I think it might happen only the first time fail2ban tries to ban somebody after it starts up.
I have fail2ban 0.8.4.
I have the same problem sometimes. It seems if you have a lot of jails (I have 6), there is a race condition of some kind between fail2ban and iptables that causes the
iptables -I INPUT... -j fail2ban-<name>
to fail because it executes before the
iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
have fully completed. I have worked around this with the following in /etc/fail2ban/action.d/iptables-allports.local (iptables-allports is the only action I use)
[Definition]
# add a sleep to try to avoid apparent race in iptables
#
actionstart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
sleep 1
iptables -I INPUT -p <protocol> -j fail2ban-<name>
In the previous comment, the lines following "actionstart =" should be indented (my leading spaces were stripped).
Also, see the patch at
https://sourceforge.net/tracker/?func=detail&aid=2857096&group_id=121032&atid=689046
which I believe addresses this
Fixed sleep in all jails would not resolve the issue reliably: you have to use variable duration for sleep.
If you have bash for your shell -- add
sleep ${RANDOM:0:1}.${RANDOM: -1:1}
at the beginning of actionstart/actionstop
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554162 for more information