None of iptables persistent methods working

I need

iptables -P FORWARD ACCEPT

soon after boot. Which does work manually.

None of the possible automated methods is working.
Not working: Execute after network goes up via e.g. /etc/network/if-up.d/iptables
Not working: iptables-persistent (https://www.thomas-krenn.com/en/wiki/Saving_Iptables_Firewall_Rules_Permanently)
Not working: /etc/init (https://askubuntu.com/questions/814/how-to-run-scripts-on-start-up)
Not working: rc.local (https://linuxtechlab.com/executing-commands-scripts-at-reboot/)
Not working: crontab (https://linuxtechlab.com/executing-commands-scripts-at-reboot/)

Satanic…

How to get this working.
I am using Docker, and Docker is adjusting iptables, but executing a command can’t be that hard right?

Saturnus

  1. Did you try to set it manually and check back if it got applied: iptables -P FORWARD ACCEPT; iptables -L FORWARD
  2. If Docker configures iptables, did you verify that it does not either overwrite previous rules or it must be set somehow from within Docker to be effektive there? Sorry I am not too experienced with Docker :wink:.
  3. To debug, disable Docker autostart (echo ‘- docker’ >> /DietPi/dietpi/.dietpi-services_include_exclude), use /etc/network/if-up.d/iptables (makes most sense IMO), assure that it has a proper shebang: #!/bin/dash will work best for this simple command.
  4. Check if run-parts would even run the script: run-parts --test /etc/network/if-up.d
  5. Check if the result is as expected: run-parts -v /etc/network/if-up.d
  6. Check if ifup triggers it similarly: ifdown eth0; sleep 1; ifup eth0 (Replace “eth0” with the correct interface)
  7. Do a reboot, check if interface is brought up as expected and iptables rules state applied: ip a; iptables -L FORWARD
  8. Then compare result with Docker enabled: sed -i ‘/- docker/d’ /DietPi/dietpi/.dietpi-services_include_exclude

Thank you for the reply. I will look at this a bit later as more urgent IT and other matters appeared these days.

I’m having a lot of trouble adapting to the changes Buster has made to begin the transition from iptables to nftables - the most difficult to deal with is that I can no longer use iptables-save and iptables-restore. I am wondering if the problems you are having are somehow connected to the problems I’m having.

iptables-save seems to work just as it always has, but iptables-restore is very different.

The following problem is reproducible for me:

  1. Install DietPi (I’m using an Odroid C2 with DietPi v6.31.2)
  2. apt install iptables
  3. iptables -A INPUT -p tcp -j ACCEPT
  4. iptables-save > my_rules
  5. iptables-restore <my_rules

This reproducibly yields:
iptables-restore v1.8.2 (nf_tables):
line 2: TABLE_FLUSH failed (Device or resource busy): table filter
and the default iptables rules remain entirely unchanged.

I have not figured out how to sidestep the device busy error, despite a fair amount of searching on the net.

I was attempting to configure this system to restore iptables rules on startup. I have a script that calls iptables-restore in /etc/network/if-pre-up.d. When I run systemctl status networking.service after my system boots, I see this:

(I’m using my original iptables rules, not the simple example above)
Jul 29 18:15:50 DietPi systemd[1]: Starting Raise network interfaces…
Jul 29 18:15:50 DietPi ifup[378]: iptables-restore v1.8.2 (nf_tables):
Jul 29 18:15:50 DietPi ifup[378]: line 3: CHAIN_UPDATE failed (No such file or directory): chain INPUT
Jul 29 18:15:50 DietPi ifup[378]: line 4: CHAIN_UPDATE failed (No such file or directory): chain FORWARD
Jul 29 18:15:50 DietPi ifup[378]: line 5: CHAIN_UPDATE failed (No such file or directory): chain OUTPUT
Jul 29 18:15:50 DietPi ifup[378]: iptables-restore v1.8.2 (nf_tables):
Jul 29 18:15:50 DietPi ifup[378]: line 3: CHAIN_UPDATE failed (No such file or directory): chain INPUT
Jul 29 18:15:50 DietPi ifup[378]: line 4: CHAIN_UPDATE failed (No such file or directory): chain FORWARD
Jul 29 18:15:50 DietPi ifup[378]: line 5: CHAIN_UPDATE failed (No such file or directory): chain OUTPUT
Jul 29 18:15:50 DietPi systemd[1]: Started Raise network interfaces.

and none of my rules have been restored.

From attempting to learn how nftables works, I realize that it is up to me to define and hook the base tables, but I’m surprised that iptables-save is not also aware that this is an nftables requirement. This makes it difficult to figure out how to create a system that can boot without manual assistance and function as my router.

Maybe you need to use the iptables-legacy-save|restore instead?

Not sure if this has anything to do with iptables/nftables switch. From all I found is that both work exactly the same applying such regular rules.

Did you try to use if-up.d instead? Would make sense to me that you cannot apply a rule before even the loopback interface has been initialised. Note that this applies to bringing up lo as well.

We btw use up iptables-restore < rules directly inside /etc/network/interfaces to be applied when only the specific interface of matter is brought up, which excludes the loopback interface then and avoids applying the same rules multiple times.

Also I could not reproduce the error on VirtualBox Buster:

2020-07-31 20:02:12 root@VM-Buster:~# iptables -A INPUT -p tcp -j ACCEPT
2020-07-31 20:06:04 root@VM-Buster:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
2020-07-31 20:06:11 root@VM-Buster:~# iptables-save > my_rules
2020-07-31 20:06:20 root@VM-Buster:~# iptables-restore < my_rules
2020-07-31 20:06:23 root@VM-Buster:~# readlink -f $(which iptables-restore)
/usr/sbin/xtables-nft-multi
2020-07-31 20:07:28 root@VM-Buster:~# iptables --flush
2020-07-31 20:08:52 root@VM-Buster:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
2020-07-31 20:08:58 root@VM-Buster:~# iptables-restore < my_rules
2020-07-31 20:09:04 root@VM-Buster:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

:thinking:

Once again, my problems are largely self-inflicted. I was following the process I have become accustomed to, and hadn’t heard about the shift from xtables to nftables. Because I had tried a number of ways of getting around my problem, I have gone back to a clean installation, and discovered that trendy’s suggestion to use iptables-legacy-save/restore is correct. But now I also find that I now have to consistently call iptables-legacy to use my existing rule set. I am very conservative about changing rules in my firewall, because (as should be obvious) I’n not the brightest, and I don’t want to cause unintended side-effects. So I am going to take some time now to work out how I should attempt to transition to nftables syntax.

Even though I was very careful to only install iptables (I looked in the package listing, and did not find a distinction between iptables and iptables-legacy in the package listing) - by now, I’m aware that I definitely do not want to mix nftables and iptables. But I find that iptables shows me a set of rules that are entirely distinct from the list iptables-legacy shows me. It was quite a surprise to see that in some sense the iptables package allows both legacy iptables and modern nftables rules to operate on the same network traffic.

I am sorry to have wasted anyone’s time while I am in the process of becoming enlightened. The tools work as they are intended to work, but it is relatively easy to misuse them in this current hybrid state. There is no problem with the tools themselves.

Btw the commands iptables, iptables-save etc are symlinks to what has been chosen via “alternatives” system, which by default are the modern nftables commands for obvious reason (performance, security). You can change those alternatives to make the above commands use the legacy system, e.g. update-alternatives --config iptables

I’m still wondering if using /etc/network/if-up.d/ or the up command in /etc/network/interfaces would not work as well with nftables. However, differences are minimal on a small/home server without huge traffic.

Thanks for additional information to allow me to adapt my new system to my old reflexes. Also, I was not aware the using the “up” command in interfaces would allow me to get my rules in place before packets begin to arrive.

In order to avoid duplicating rules, my existing script flushes all the tables and begins again. And yes, this produces the danger of a mistake early in the script leaving me without a functional firewall. Atomic application of rules is a great improvement.

When I get things back to the point where I’m ready to go “live”, I will definitely spend some time with both “up” in interfaces, and if-up.d to see what seems best.

Thanks!