debian firewalld reload issue
by nooobeee from LinuxQuestions.org on (#5BW94)
I have a vanilla debian 10 setup with nginx. I installed firewalld which went fine. I added the HTTP and HTTPS rules using:
Code:firewall-cmd --add-service={http,https} --permanent --zone=publicHowever when I attempt to reload, I run into an error:
Code:sudo firewall-cmd --reload
Error: COMMAND_FAILED: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.2 (nf_tables):
line 4: RULE_REPLACE failed (No such file or directory): rule in chain INPUT
line 4: RULE_REPLACE failed (No such file or directory): rule in chain OUTPUTDoing some digging, it seems there may be a bug.
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=914694
Most of this is, honestly, above my head. But I found a nugget in there so I tried the IndividualCalls=yes attribute and restarting the service because it seemed this may have been a workaround but that didn't seem to work for me:
Code:> > Setting InvividualCalls=yes in /etc/firewalld/firewalld.conf will be
> > more verbose and help in debugging the cause.
>
> Fun, this actually *fixes* the problem:
That makes it smell like an iptables-restore issue in the nftables
backed version of iptables. It would be great if we could reproduce
without firewalld using iptables-restore.apt indicates my firewalld is currently 1.8.2-4.
Has anyone else run into this? Any suggestions or thoughts would be appreciated.
Code:firewall-cmd --add-service={http,https} --permanent --zone=publicHowever when I attempt to reload, I run into an error:
Code:sudo firewall-cmd --reload
Error: COMMAND_FAILED: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.2 (nf_tables):
line 4: RULE_REPLACE failed (No such file or directory): rule in chain INPUT
line 4: RULE_REPLACE failed (No such file or directory): rule in chain OUTPUTDoing some digging, it seems there may be a bug.
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=914694
Most of this is, honestly, above my head. But I found a nugget in there so I tried the IndividualCalls=yes attribute and restarting the service because it seemed this may have been a workaround but that didn't seem to work for me:
Code:> > Setting InvividualCalls=yes in /etc/firewalld/firewalld.conf will be
> > more verbose and help in debugging the cause.
>
> Fun, this actually *fixes* the problem:
That makes it smell like an iptables-restore issue in the nftables
backed version of iptables. It would be great if we could reproduce
without firewalld using iptables-restore.apt indicates my firewalld is currently 1.8.2-4.
Has anyone else run into this? Any suggestions or thoughts would be appreciated.