Bug 871996 – net-analyzer/fail2ban systemd iptables-restore.service failed sometimes when fail2ban set ipset to ban IPs

• Product: Gentoo Linux
• Status: UNCONFIRMED ---

[Description Ryan Tsien 2022-09-20 07:02:25 UTC]

systemd environment

When I setup fail2ban to set ipset to ban IPs, a f2b-sshd ipset will be created when fail2ban start and it'll be deleted when fail2ban stop.

However the iptables-store service store the f2b-sshd ipset record, after reboot, the iptables-restore service wants to restore this record (but has not been created by fail2ban yet), so iptables-restore service fails.

May require additional ordering on shutdown to ensure iptables-store is called after fail2ban.

Reproducible: Sometimes

[Comment 1 Sam James 2023-01-26 01:25:53 UTC]

Created attachment 849209 [details, diff]
fail2ban.service.in-fix-ordering-iptables.patch

Does this work?

[Comment 2 Ryan Tsien 2023-01-26 07:51:05 UTC]

(In reply to Sam James from comment #1)
> Created attachment 849209 [details, diff] [details, diff]
> fail2ban.service.in-fix-ordering-iptables.patch
> 
> Does this work?

Thanks for your patch!

It's not a suitable time for testing due to the server is running, I'm not sure whether the 'After=' configure works on a 'shutdown.target' only service with a 'multi-user.target' service or not.

But due to the new 'Before=' configure, the fail2ban service will always be started before the ip[6]tables-restore service, and the f2b-<xxx> ipset will always be created first, so no matter whether the fail2ban service is stopped before the ip[6]tables-store service, there will be no problem.

[Comment 3 Mike Fisher 2024-02-08 19:11:23 UTC]

I ran into this today myself.  Apologies in advance as I'm still learning the ins and outs of systemd here...

I tried applying the suggested changes in the patch to the default fail2ban.service unit, but it ran into circular ordering upon startup so it would drop iptables-restore or fail2ban to break that cycle.

However, rather than trying to start fail2ban before iptables, it seems to work better to start iptables first (and stop fail2ban first upon shutdown).  Essentially swap around the "Before=" and "After=".

In /etc/systemd/system/fail2ban.service.d/override.conf (via systemctl edit 
fail2ban.service):
----
[Unit]
Before=iptables-store.service ip6tables-store.service
After=iptables-restore.service ip6tables-restore.service
----

That seems to have done the trick.  Several reboots were repeatedly successful.

With this ordering, upon shutdown fail2ban stops, removing the iptables rule it inserted at the front of the INPUT chain, then iptables-store saves the remaining rules.  Upon startup iptables-restore repopulates the bulk of the rules, then fail2ban starts and inserts itself back in the front of the chain after it creates the ipset.