I've just noticed ipset could not restore state after reboot, error messages produced by fail2ban alerted me about the problem. Upon inspection it turns out iptables save produces a file in "plain" format, while restore expects it to be in "save" format. Reproducible: Always
As a workaround I've changed the ipset init file to reflect this observation: # diff -urNp /usr/portage/net-firewall/ipset/files/ipset.initd-r5 /etc/init.d/ipset --- /usr/portage/net-firewall/ipset/files/ipset.initd-r5 2023-06-17 20:10:26.000000000 +0200 +++ /etc/init.d/ipset 2024-02-11 09:42:45.062922827 +0100 @@ -100,6 +100,6 @@ reload() { save() { ebegin "Saving ipset session" checkpath --file --mode 0600 "${IPSET_SAVE}" - ipset save > "${IPSET_SAVE}" + ipset -output save list > "${IPSET_SAVE}" eend $? } I'm not sure about the exact time and reason ipset started behaving like this. I could successfully recover after processing a previous saved state file.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0baf77a9399a23c01de5dccbdbd9b5a39994b9b6 commit 0baf77a9399a23c01de5dccbdbd9b5a39994b9b6 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2024-02-13 23:17:29 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2024-02-13 23:17:29 +0000 net-firewall/ipset: Fix saving rules, thanks to Attila Tóth Closes: https://bugs.gentoo.org/924417 Signed-off-by: Mike Pagano <mpagano@gentoo.org> net-firewall/ipset/files/ipset.initd-r6 | 105 ++++++++++++++++++++++++++++++++ net-firewall/ipset/ipset-7.20.ebuild | 2 +- 2 files changed, 106 insertions(+), 1 deletion(-)
