On 4/7/26 4:29 AM, Łukasz Michalski wrote:
Other than that, there should not be any extra migration step for the
backend itself. The main thing to check is whether pacman leaves your
saved rules as .pacsave files when switching packages. Please check:
- /etc/iptables/iptables.rules.pacsave
- /etc/iptables/ip6tables.rules.pacsave
In my case docker stopped to work after this change. I had my own
nftables firewall and fail2ban configured, and after iptables started to
use nft backend docker returns errors when trying to configure its own
iptables rules.
I switched to experimental support for nftables in docker and everything
seems to work as expected for now.
Thanks Lukasz,
For me new iptables to iptables-legacy switch went fine, but there is
one caveat I encountered installing iptables-legacy worth noting.
Knowing the change was coming between 1:1.8.11-2 and 1:1.8.11-4 and
seeing 1:1.8.11-4 in core, I went ahead and installed iptables-legacy
before doing a system update to ensure I stayed on the legacy backend.
When the current iptables is removed and iptables-legacy installed
your iptables.rules will be saved as iptables.rules.pacsave -- but in
the install process the service is restarted with a new empty/default
iptables.rules file. This will cause the loss of any in-memory rules
from services like fail2ban, etc. Specifically after restoring the
.pacsave and reloading iptables, the fail2ban entries were gone.
You can capture the current state of your rules by saving the rules
right before you install iptables-legacy with:
# iptables-save -f /etc/iptables/iptables.rules
And then restore from the .pacsave after install of iptables-legacy
and restart. Doing so will save whatever time it takes for fail2ban to
re-sync with iptables-legacy.
I just let it re-sync itself, and it did after a period of time. I'm
not sure how long it took, but by a couple hours later the listing of
rules with, e.g. 'iptables -nvL --line-numbers' again contained the
fail2ban entries.
--
David C. Rankin, J.D.,P.E.
