I noticed this on Fedora as well and wasn't particularly happy about the use of legacy iptables but wasn't sure what to change to. I'll take a look but from what you say it sounds like it would be best to change all the releases to this method (Fedora & EPEL).

Just verified it seems to work well. While I'm at it, is there any reason not to update the EPEL branches to the latest version?

At this point, probably not.

Performing builds now. As the config files are marked "noreplace" existing edited 00-firewalld.conf files will not be overwritten.

FEDORA-2020-30b046478a has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-30b046478a

FEDORA-EPEL-2020-f5c952ab51 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f5c952ab51

FEDORA-2020-caae9d7741 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-caae9d7741

FEDORA-2020-41b4fce889 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-41b4fce889

FEDORA-EPEL-2020-f5c952ab51 has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f5c952ab51

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-30b046478a has been pushed to the Fedora 30 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-30b046478a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-30b046478a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-caae9d7741 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-caae9d7741`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-caae9d7741

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-41b4fce889 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-41b4fce889`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-41b4fce889

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-30b046478a has been pushed to the Fedora 30 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-caae9d7741 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

With recidive jail and bantime = -1 (for permanent) I get these errors:

2020-04-30 11:29:55,293 fail2ban.utils          [937290]: ERROR   7f14bda4e690 -- exec: ports="0:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='103.4.165.137' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done
2020-04-30 11:29:55,294 fail2ban.utils          [937290]: ERROR   7f14bda4e690 -- stderr: 'Error: INVALID_PORT: 0:65535'
2020-04-30 11:29:55,294 fail2ban.utils          [937290]: ERROR   7f14bda4e690 -- returned 102
2020-04-30 11:29:55,295 fail2ban.actions        [937290]: ERROR   Failed to execute ban jail 'recidive' action 'firewallcmd-rich-rules' info 'ActionInfo({'ip': '103.4.165.137', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x7f14bda5af80>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7f14bda53680>})': Error banning 103.4.165.137
2020-04-30 11:29:55,295 fail2ban.actions        [937290]: NOTICE  [recidive] Restore Ban 103.79.141.109
2020-04-30 11:29:55,755 fail2ban.utils          [937290]: ERROR   7f14bda4e690 -- exec: ports="0:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='103.79.141.109' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done
2020-04-30 11:29:55,756 fail2ban.utils          [937290]: ERROR   7f14bda4e690 -- stderr: 'Error: INVALID_PORT: 0:65535'
2020-04-30 11:29:55,757 fail2ban.utils          [937290]: ERROR   7f14bda4e690 -- returned 102

Can we get this logged as a new bug? I hate that the changed caused a new problem but ipset wasn't working well at all. 

Are you using allports? (noticing the ports="0:65535")

It doesn't look like the "$p" is being expanded.

(In reply to Richard Shaw from comment #16)
> Can we get this logged as a new bug? I hate that the changed caused a new
> problem but ipset wasn't working well at all. 

I can do that. There are several threads about this at Fail2ban's GitHub. 

> Are you using allports? (noticing the ports="0:65535")

No I'm using banaction = firewallcmd-rich-rules in [DEFAULT]

For pam-generic jail I do have:
port     = all

Ok, this may be simpler than I thought. It's choking on the 0:65535 but would accept 0-65535, so I just need to see how that's being generated.

in the main jail.conf (or setup a jail.local) change:

# Ports to be banned
# Usually should be overridden in a particular jail
port = 0:65535

to 

# Ports to be banned
# Usually should be overridden in a particular jail
port = 0-65535

(In reply to Richard Shaw from comment #19)
> in the main jail.conf (or setup a jail.local) change:
> 
> # Ports to be banned
> # Usually should be overridden in a particular jail
> port = 0:65535
> 
> to 
> 
> # Ports to be banned
> # Usually should be overridden in a particular jail
> port = 0-65535

OK I have that for tbe pam-generic jail now and it works.

However recidive jail is never triggered. 

I've tried various combinations of the below (# is a comment) and no bans

[recidive]
enabled  = true
filter   = recidive
action = %(action_mwl)s
banaction = %(banaction_allports)s
#action   = iptables-allports[name=recidive]
#           sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log*]
#bantime  = 7776000   ; 3 months
bantime   =  -1 ; permanent ban
#action = %(banaction)s[name=%(__name__)s, bantime=0, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
findtime = 86400   ; 1 day
logpath  = /var/log/fail2ban.log
           /var/log/fail2ban.log-*[!.gz]
#action   = firewallcmd-ipset[name=recidive]
#banaction = firewallcmd-ipset[bantime=0]
maxretry = 4

No errors from this either:
fail2ban-client status recidive
Status for the jail: recidive
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- Journal matches:  _SYSTEMD_UNIT=fail2ban.service PRIORITY=5
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

FEDORA-2020-41b4fce889 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2020-f5c952ab51 has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.

I am still seeing the error even with the latest update fail2ban-server-0.11.1-6.fc32.noarch

In particular, jail.conf still has 

port = 1:65535

I found that overriding this in a local sshd jail still produced these errors:

2020-05-31 22:46:36,481 fail2ban.utils          [254236]: ERROR   7f45e6ad2cf0 -- exec: ports="1:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='85.209.0.100' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done
2020-05-31 22:46:36,481 fail2ban.utils          [254236]: ERROR   7f45e6ad2cf0 -- stderr: 'Error: INVALID_PORT: 1:65535'
2020-05-31 22:46:36,481 fail2ban.utils          [254236]: ERROR   7f45e6ad2cf0 -- returned 102
2020-05-31 22:46:36,481 fail2ban.actions        [254236]: ERROR   Failed to execute ban jail 'sshd' action 'firewallcmd-rich-rules' info 'ActionInfo({'ip': '<remote ip>', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x7f45e623ee50>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7f45e623f550>})': Error banning <remote ip>

sshd.local:

[sshd]
enabled = true
port = ssh
action = firewallcmd-rich-rules
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400
findtime = 86400

Also tried adding:

[DEFAULT]
port = 1-65535

to the top of sshd.local

This had no apparent effect.

(In reply to Adam Huffman from comment #23)
> I am still seeing the error even with the latest update
> fail2ban-server-0.11.1-6.fc32.noarch
> 
> In particular, jail.conf still has 
> 
> port = 1:65535
> 
> I found that overriding this in a local sshd jail still produced these
> errors:
> 
> 2020-05-31 22:46:36,481 fail2ban.utils          [254236]: ERROR  
> 7f45e6ad2cf0 -- exec: ports="1:65535"; for p in $(echo $ports | tr ", " "
> "); do firewall-cmd --add-rich-rule="rule family='ipv4' source
> address='85.209.0.100' port port='$p' protocol='tcp' reject
> type='icmp-port-unreachable'"; done
> 2020-05-31 22:46:36,481 fail2ban.utils          [254236]: ERROR  
> 7f45e6ad2cf0 -- stderr: 'Error: INVALID_PORT: 1:65535'
> 2020-05-31 22:46:36,481 fail2ban.utils          [254236]: ERROR  
> 7f45e6ad2cf0 -- returned 102
> 2020-05-31 22:46:36,481 fail2ban.actions        [254236]: ERROR   Failed to
> execute ban jail 'sshd' action 'firewallcmd-rich-rules' info
> 'ActionInfo({'ip': '<remote ip>', 'family': 'inet4', 'fid': <function
> Actions.ActionInfo.<lambda> at 0x7f45e623ee50>, 'raw-ticket': <function
> Actions.ActionInfo.<lambda> at 0x7f45e623f550>})': Error banning <remote ip>
> 
> sshd.local:
> 
> [sshd]
> enabled = true
> port = ssh
> action = firewallcmd-rich-rules
> logpath = %(sshd_log)s
> maxretry = 3
> bantime = 86400
> findtime = 86400
> 
> Also tried adding:
> 
> [DEFAULT]
> port = 1-65535
> 
> to the top of sshd.local
> 
> This had no apparent effect.

Yep because action.d/firewallcmd-common.conf also has port = 1:65535.

So either remove it from that file or override it in the respective service, so in your case in [sshd].

I don't get how this got bifurcated upstream. Why not be consistent with the port convention?

(In reply to RobbieTheK from comment #24)
> I don't get how this got bifurcated upstream. Why not be consistent with the
> port convention?

Because it's not about fail2ban, but the backend. Iptables supports the ":" separator, but nftables (the default in f32), only supports "-". I need to patch the package but I only recently took over maintenance of fail2ban on Fedora.

Thought I should mention that I see these warnings:

Jun 04 16:06:37 nuc.localdomain firewalld[85158]: WARNING: NOT_ENABLED: 'rule family="ipv4" source address="<remote IP>" port port="1-65535" protocol="tcp" reject type="icmp-port-unreachable"' not in 'FedoraServer'

Did you switch zones at some point? I know firewalld segregates a lot of stuff based on the zone it's in. I'm honestly not familiar enough with the interaction between firewalld zones and fail2ban to guess.