Dear Maintainer,

using "protocol = all" in the [default] part of jail.local throws an error in
fail2ban.log like this when attempting to ban:

2016-01-12 23:29:33,345 fail2ban.actions.action[10712]: ERROR   iptables -n -L
INPUT | grep -q 'fail2ban-ssh[ \t]' returned 100
2016-01-12 23:29:33,345 fail2ban.actions.action[10712]: ERROR   Invariant check
failed. Trying to restore a sane environment
2016-01-12 23:29:33,351 fail2ban.actions.action[10712]: ERROR   iptables -n -L
INPUT | grep -q 'fail2ban-ssh[ \t]' returned 100
2016-01-12 23:29:33,351 fail2ban.actions.action[10712]: CRITICAL Unable to
restore environment

According to github a similar issue has been fixed in 2012:
https://github.com/fail2ban/fail2ban/issues/75

Hi,

While looking for a first Debian contribution, I picked this report, filed in 2016 against fail2ban 0.8.13-1.

I was not able to reproduce the problem against the version currently in unstable (1.1.0-11). Looking at config/action.d/iptables.conf, the "protocol" option is now processed through a generic loop that splits the value on commas and issues one `-p <proto>` iptables rule per value:

    _ipt_for_proto-iter = for proto in $(echo '<protocol>' | sed 's/,/ /g'); do

With `protocol = all` (no comma present), the loop runs once with $proto = all, producing a plain `-p all` rule, which iptables accepts natively. I confirmed this manually on a current system:

    $ sudo iptables -N f2b-test
    $ sudo iptables -A f2b-test -j RETURN
    $ sudo iptables -I INPUT -p all -j f2b-test
    $ sudo iptables -n -L INPUT | grep f2b-test
    f2b-test  all  --  0.0.0.0/0            0.0.0.0/0

The chain is created and the rule is accepted without error, so the ctionstart/actioncheck sequence described in the original report no longer fails.

The changelog doesn't reference this bug number, so my guess is this was fixed as a side effect of the later work adding support for comma-separated protocol lists (protocol = tcp,udp), rather than intentionally for this report.

I'm new to Debian packaging, so I'll leave the actual closing to the maintainers in case there's an edge case I'm missing (e.g. a firewall backend other than plain iptables, or an older/newer iptables version with different behaviour for "-p all"). Happy to dig further if useful.

Thanks,
Germano Castanho

Hi,


I still see this bug with the version currently in stable (1.1.0-8). As
1.1.0-11 is also in testing, I downloaded that to see whether the bug is
still in there, and the installation immediately triggered the bug,
because the install triggers a 'systemctl fail2ban stop' and 'systemctl
fail2ban start', and the 'systemctl fail2ban start' starts restoring all
bans, which triggers the error (for every ban). Hope this helps to
further debug the error, it certainly still is there.


Please let me know if you need more.