Something is flusing iptables after some hours of fail2ban reload

Question

Several days ago I asked this question Confuse about fail2ban behavior with firewallD in Centos 7
It is a large text with several comments.
It seems something starts flushing iptables after some hours of fail2ban restart I don't get what it is.
A couple of months ago I moved a few Virtual Hosts from a dedicated server I used for more than 10 years to a Contabo VPS. All goes fine but fail2ban jail. Prisoners escape. :)
My move was from Centos 6 to Centos 7 Webmin/Virtualmin LAMP fail2ban; leaving /etc/sysconfig/iptables, now using firewalld. As said, after some hours of fail2ban restart, and after some successfully banned IPs, as @sebres suggested, something is flushing iptables because of the symptom "after effects" like

2019-12-05 16:55:20,856 fail2ban.action [1514]: ERROR iptables -w -n -L INPUT | grep -q 'f2b-proftpd[ \t]' -- stdout: ''

and "already banned" notices.
None of the changes I tried in default configurations changed that.
At the end I deleted the Webmin module to manage fail2ban and reinstalled the service.
Renamed /etc/fail2ban to keep backup configurations.

rpm -qa | grep -i fail2ban

then

yum remove fail2ban-server     
yum remove fail2ban-firewalld      
yum install fail2ban-firewalld  (also installs -server)
yum install fail2ban-systemd

then copied old jail.local to new /etc/fail2ban directory

[DEFAULT]
banaction = iptables-multiport
banaction_allports = iptables-allports

[sshd]
enabled = true
port = ssh
maxretry = 4
bantime = 7200

[ssh-ddos]
enabled = true
port = ssh,sftp
filter = sshd-ddos

[webmin-auth]
enabled = true
port = 10000

[proftpd]
enabled = true
bantime = -1

[postfix]
enabled = true
bantime = -1

[dovecot]
enabled = true
bantime = -1

[postfix-sasl]
enabled = true
bantime = -1

I also checked cron jobs to see if something can be flushing iptables in any way.
At this time I have running, periodically, a script to manually reject those "already banned" IPs once.

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='xxx.xxx.xxx.xxx' reject"

So my question is how to know what is flusing iptables.

UPADATE 1
After update to stable V 0.10 fail2ban release it seemed problems gone but after 5 days they started again.
Previously, after v0.9 restart, problems started after few hours.

UPADATE 2
Running fail2ban-client -d I got "Found no accessible config files for 'filter.d/sshd-ddos'". That's because I kept the old ssh-ddos config in jail.conf.
So, a subquestion is if I'm right simply making this change (at least no errors in fail2ban-client -d

#filter  = sshd-ddos
filter  = sshd
mode = agressive (as suggested by @sebres)

Here's the output of fail2ban-client -d

"No, the after effect is there because something is flushing rules, not vice versa"

I understand that, I'm not that fluent in English speaking, I meant that that was a symptom that something happens so the effect.

"So which banning action do you use really?"

Sorry my poor knowledge on this matter. Is that what is included in [Default] part of jail.local?

"(for example can you exclude some service implemented by Contabo installed or integrated in your VPS, that doing that?"

I asked them some time ago but their answer was "...we are providing our customers with the basic installations..." nothing that technical. They have several VPS services and I don't see other people complaining about that.

UPDATE 3

The first jail.local (from fresh Webmin/Virtualmin install) actions were

action = firewallcmd-ipset[]
action_ = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

I changed by

banaction = iptables-multiport                 
banaction_allports = iptables-allports     

some time ago.
Now I went back with firewallcmd-ipset as [DEFAULT] and this is the fail2ban-client -d output.
I'll check fail2ban.log. .... After few hours, problems again.

About firewallD Webmin has a section with defined zones/rules and tools to manage them instead of having to write commands in shell. Nothing more.

Answer 1

I cannot imagine fail2ban blame here, but to exclude it (or some action of fail2ban is broken on your side), we should take a look into your configuration...
So provide your whole (unmodified) configuration dump:

fail2ban-client -d

or at least dump of all actions of all jails:

fail2ban-client -d | grep 'action'

now using firewalld

I see pretty sure iptables in your config and the log excerpt (error message). So which banning action do you use really?

something is flushing iptables because of "after effects" like ...

No, the after effect is there because something is flushing rules, not vice versa. This can be for example some "firewall" script which you apply to configure iptables (ports, default reject rules, etc), restart of some service due to dependency (restarting or reloading iptables), some script mistakenly implementing knocking, and many others.
I don't think it'd be simple to find it, if you don't have it under your control (for example can you exclude some service implemented by Contabo installed or integrated in your VPS, that doing that?).

UPDATE 1:

I don't see any error in your excerpt... to remove f2b-proftpd (or flush input chain) it should contain:

• either <iptables> -D INPUT ... -j f2b-proftpd
• or even <iptables> -F INPUT somewhere in actions parameters, excepting actionstop (which is intended stop by shutdown or restart case only).

But it is only available in actionstop as expected:

all entries containing removal from INPUT chain (actionstop only):
  <iptables> -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
  <iptables> -D INPUT -p tcp -m multiport --dports 10000 -j f2b-webmin-auth
  <iptables> -D INPUT -p tcp -m multiport --dports ftp,ftp-data,ftps,ftps-data -j f2b-proftpd
  <iptables> -D INPUT -p tcp -m multiport --dports smtp,465,submission -j f2b-postfix
  <iptables> -D INPUT -p tcp -m multiport --dports pop3,pop3s,imap,imaps,submission,465,sieve -j f2b-dovecot
  <iptables> -D INPUT -p tcp -m multiport --dports smtp,465,submission,imap,imaps,pop3,pop3s -j f2b-postfix-sasl
  <iptables> -D INPUT -p tcp -m multiport --dports ssh,sftp -j f2b-ssh-ddos

Thus we could exclude the blame of fail2ban.
Just you said "now using firewalld" - where? In your config dump I see iptables-multiport only:

['set', 'sshd', 'addaction', 'iptables-multiport']
['set', 'webmin-auth', 'addaction', 'iptables-multiport']
['set', 'proftpd', 'addaction', 'iptables-multiport']
['set', 'postfix', 'addaction', 'iptables-multiport']
['set', 'dovecot', 'addaction', 'iptables-multiport']
['set', 'postfix-sasl', 'addaction', 'iptables-multiport']
['set', 'ssh-ddos', 'addaction', 'iptables-multiport'],

So for example if firewald would rewrite INPUT chain of iptables (removes fail2ban entries), you would catch exactly this issue.

Thus better find out which major netfilter your system use and use it as banaction (or avoid rewriting of fail2ban rules e. g. by adding it to fail2ban dependencies, etc).