Description of problem:
I had to create a custom jail which temporary blocks access to one particular port for IPv4 and IPv6. A trigger with an IPv4 address creates 2 rules (one for IPv4 and one for IPv6) as configured, but if the trigger IP address is IPv6, this fails.

The dual IP protocol block is necessary to block requests e.g. from 6to4 address of same client.


Version-Release number of selected component (if applicable):
fail2ban-0.11.2-1.el8.noarch


How reproducible:
always


Steps to Reproduce:
1. create a custom jail like:

[apache-jail-special]
enabled   = true
port      = 8080
logpath   = /path/to/apache-log
maxretry  = 1
bantime   = 15m
bantime.increment = false
action    = firewallcmd-rich-rules[name=apache-jail-special-ipv6,actiontype=<multiport>,rich-blocktype=drop,protocol=tcp,port=8080,family=ipv6,ip=::/0]
            firewallcmd-rich-rules[name=apache-jail-special-ipv4,actiontype=<multiport>,rich-blocktype=drop,protocol=tcp,port=8080,family=ipv4,ip=0.0.0.0/0]


2. trigger jail e.g. using curl with an IPv6 address


Actual results:

2021-09-06 19:18:43,403 fail2ban.utils          [2066307]: ERROR   7ff6936acdc0 -- exec: ports="$(echo '8080' | sed s/:/-/g)"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv6' source address='0.0.0.0/0' port port='$p' protocol='tcp' drop"; done
2021-09-06 19:18:43,403 fail2ban.utils          [2066307]: ERROR   7ff6936acdc0 -- stderr: 'Error: INVALID_ADDR: 0.0.0.0/0'
2021-09-06 19:18:43,403 fail2ban.utils          [2066307]: ERROR   7ff6936acdc0 -- returned 105
2021-09-06 19:18:43,404 fail2ban.actions        [2066307]: ERROR   Failed to execute ban jail 'PB-apache-useragent-java' action 'firewallcmd-rich-rules-apache-useragent-java-ipv4' info 'ActionInfo({'ip': '2002:***', 'family': 'inet6', 'fid': <function Actions.ActionInfo.<lambda> at 0x7ff69366f9d8>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7ff6936700d0>})': Error banning 2002:***



Expected results:

Working well as triggered with IPv4 address - and that is the reason why I don't understand where the root cause of this issue is located...because I would assume that in case of IPv4 the IPv6 error would thrown...but this is not the case.


Additional info:

same config triggered with IPv4 address is resulting in

table inet firewalld {
        chain filter_IN_public_deny {
                ip6 saddr ::/0 tcp dport 8080 ct state { new, untracked } drop
                ip saddr 0.0.0.0/0 tcp dport 8080 ct state { new, untracked } drop
}


Also note that it is not depending on the order, whether IPv6 rule will be created in advance before IPv4 rule.