I noticed that whenever I upgrade systemd that my iptables and ip6tables rules are gone from: /var/lib/iptables/rules-save and /var/lib/ip6tables/rules-save when using iptables-store.service, iptables-restore.service, ip6tables-store.service and ip6tables-restore.service and that everything defaults to ACCEPT. I'm reporting this as I'm considering this a slight security risk, as I've configured iptables on various systems and after a upgrade all of my firewall rules were gone. Reproducible: Always Steps to Reproduce: 1.Install Gentoo using systemd 2.Configure iptables 3.Store the iptables settings using the iptables-store.service, iptables-restore.service, ip6tables-store.service and ip6tables-restore.service to make the rules load at boot 4. Perform an upgrade of systemd 5. Reboot and check the specified locations Actual Results: The files: /var/lib/iptables/rules-save and /var/lib/ip6tables/rules-save are empty Expected Results: The files: /var/lib/iptables/rules-save and /var/lib/ip6tables/rules-save filled with the former iptables rules I selected critical as I wasn't sure whether it's considered a security risk. If it's supposed to be normal, then revert the change please.
This is likely some local issue; if this were a common problem, we would have heard about it by now.
What version(s) of iptables and systemd have you encountered this with?
A few points to add: I've encountered this on 3 of my machines so far from which 2 are desktops (1 running Gnome and 1 running KDE) and 1 is a server (with no xorg-server or wayland installed). All of them running systemd with iptables configured in the same way. I've encountered the issue with former upgrades, but thought it was a one time bug and didn't know what package could've caused it, so ignored it and just imported my ruleset back and was up and running. I've been able to narrow it down to the systemd package, because this issue occurred again after upgrading my laptop. After that I decided to upgrade the packages selectively (one by one) and after upgrading just systemd (without upgrading other packages) on both of the other systems and performing a reboot, my iptables ruleset was gone. Currently I'm using net-firewall/iptables-1.6.1-r3 and sys-apps/systemd-244.3 on all 3 of these machines.
(In reply to nvaert1986 from comment #0) > I noticed that whenever I upgrade systemd that my iptables and ip6tables > rules are gone from: /var/lib/iptables/rules-save [...] (In reply to nvaert1986 from comment #3) > I've encountered this on 3 of my machines so far from which 2 are desktops > (1 running Gnome and 1 running KDE) and 1 is a server (with no xorg-server > or wayland installed). All of them running systemd with iptables configured > in the same way. FWIW not seeing this bug here (found it looking for something else and it looked like something I better check), but there /is/ a critical difference in my config. I have the -restore service enabled, but not -store. See below. First, as I don't see the results of this posted to the bug yet, let's confirm whether a systemd upgrade/remerge actually changes the runtime config. Running iptables-save without a file parameter will output the currently active runtime config to the terminal and not affect your saved config, so try that immediately before and after upgrading/remerging systemd. (Don't /post/ the config, just whether it's good before and bad after.) That'll let us know whether the actual runtime config is affected and whether it's likely to be the systemd upgrade doing it if so, and we can go from there. As to the difference in my config, here, I have iptables-restore enabled, but *NOT* iptables-store. If I make any changes that I want to be permanent, I run the appropriate command to save them manually (running iptables-save pointed at the appropriate file, but manually running the -store service should do it as well). While that means I don't store updated activity figures and thus start over at each reboot, it also prevents accidentally storing a bad runtime config, regardless of what made it bad. If you need those updated activity figures, or if you dynamically create and possibly delete rules with something like fail2ban and want them saved, that's not going to work for you, but if there's no real reason to risk automatically rewriting a known good config with one that /could/ be bad, why do so? Maybe that's helpful on at least some of your systems, even if you need to keep the -store rules enabled on others. YMMV. > I've encountered the issue with former upgrades, but thought it was a one > time bug and didn't know what package could've caused it Been there. Know the feeling. =:^(
Yesterday I upgraded to systemd-245.5 (I only upgraded systemd) and the issue occurred again. I resolved it again, by restoring the rules, which I backed-up into another file and it worked flawlessly again after that.
This issue hasn't occurred for me for almost a year (with several systemd upgrades). I think this can be considered resolved / obsolete.
