Join Log in
Score:2
avatar Server

iptables flushed on firewalld reload

br flag
Nicolas Goudry

I’m running on Rocky Linux (RHEL8 based) and am kind of struggling with firewalld and iptables. Well, not really iptables anyway… Let me explain.

I setup a K8S cluster on VMWare ESXi with six virtual machines, all the same. I need to have firewalld running, given this environment. I’m using Weave CNI, which is using iptables in order to create its networking rules.

Here are my initial findings:

  • on weave docker containers and VM hosts, iptables with nf_tables backend is used
    • this is confirmed by iptables -V output which gives me iptables v1.8.4 (nf_tables)
  • firewalld is setup to use nftables as its backend (FirewallBackend)
  • iptables service doesn’t exists (Unit iptables.service could not be found.)
  • nftables service is loaded, but inactive
  • firewalld service is running
  • if I start nftables service, firewalld service is stopped, and vice-versa

As of my understanding of firewalld, because it uses nftables, it shouldn’t flush iptables at all, as per their blog post about nftables backend.

When weave sets its iptables rules (for routing and network policies), I can see them either with iptables-save or nft list ruleset. This means that even if weave is using iptables to set its rules, they are in fact set into nftables.

Now, my problem is that if I reload firewalld (with firewall-cmd --reload or systemctl reload firewalld.service) after weave set its rules, all rules are flushed! I can confirm that with iptables-save or nft list ruleset.

May it be related to using iptables commands instead of nft? Even if iptables uses nf_tables backend?

Please note that this problem is partially addressed by weave, because they monitor rules to see if a special (empty) chain WEAVE-CANARY still exists. If it’s not there, they recreate routing routes, but nothing is done for network policy rules. This is currently a feature request.

What are the possible solutions? I thought about hooking into firewalld service to add ExecStopPre and ExecReloadPre to save other rules than firewalld’s one into /etc/sysconfig/nftables.conf (or another file, included from there), but it’s sort of hackish and I’m not fond of this “solution”. Furthermore, I’m not even sure that this will work, given that nftables service is stopped.

Edit: I made some tests and behavior is really weird.

I added a rule with iptables: iptables -I INPUT 3 -s 10.1.1.9 -j DROP, then reloaded the firewall and the rule is not there anymore! I tried the same with nft: nft add rule ip filter INPUT ip saddr 10.1.1.9 drop, reloaded firewall and result is the same…

This is driving me crazy, firewalld shouldn’t touch other rule tables than its own, but this is not the case here!

421
0 + 0
A.B avatar
cl flag
A.B
If firewalld really uses nftables as backend, it should work only with the firewalld table: https://firewalld.org/2018/07/nftables-backend#only-flush-firewallds-rules . Is there a firewalld table?
0
Reply
A.B avatar
cl flag
A.B
See also this Q/A: https://serverfault.com/questions/1046179/rhel-centos-now-to-add-nftable-rules-to-firewalld-on-system-boot (note my remark about the nftables service flushing all).
1
Reply
br flag
Nicolas Goudry
@A.B Indeed, there is a firewalld table. And the FirewallBackend is set to nftables in firewalld config, as stated in my post. That’s why it’s driving me crazy ^^' Already saw and read the Q/A you pointed, but I don’t think that would fix the problem, because nftables service is not running at all (due to firewalld service running). Actually, the idea of hooking into firewalld service is greatly inspired from your answer. However, I tested to add some rules to /etc/sysconfig/nftables.conf and reload firewalld but I don’t see those rules, so it's not a working solution… I’m kind of stuck rn.
1
Reply
br flag
Nicolas Goudry
@A.B. For clarity, here are the tables i have rn: ip filter, ip6 filter, bridge filter, ip security, ip raw, ip mangle, ip nat, ip6 security, ip6 raw, ip6 mangle, ip6 nat, bridge nat, inet firewalld, ip firewalld, ip6 firewalld. Weave is adding its rules in the ip filter, ip mangle and ip nat. On firewall reload/restart, those tables get flushed.
0
Reply
A.B avatar
cl flag
A.B
Indeed on start/stop/reload of firewalld an nftables rule in an other table than compat iptables or firewalld is preserved, but iptables' rules are not. So the blog I linked to appears to be wrong.
0
Reply
A.B avatar
cl flag
A.B
Note that firewalld with nftables backend can still use iptables: with direct rules. So that might be the reason iptables is still flushed. Now to find where this is documented if it is...
0
Reply
br flag
Nicolas Goudry
Alas, it's the official firewalld blog... I think I'd better be filing an issue on their GitHub then! Thanks for the help btw :)
0
Reply
Score:2
avatar Server
br flag
Nicolas Goudry

Source: GitHub issue reply from a firewalld’s collaborator

There are a couple things going on here.

  • The nft variant of iptables will add rules to nftables in the known tables: filter, nat, raw, etc.
  • firewalld always flushes all iptables rules (e.g. iptables -F -t filter) which flushes all chains in the filter table. This corresponds to the known nftables table names mentioned above.

Firewalld's nftables backend only touches the firewalld table, but tables filter, nat, raw, etc. are touched indirectly via iptables-nft to support iptables direct rules. This behavior cannot be changed due to compatibility. Firewalld will not touch other nftables tables though, e.g. a table named foobar would not get flushed.

Unfortunately we can't do anything here. We either a) maintain compatibility and let the iptables named tables get flushed or b) drop iptables direct rule support. Option A is the most user friendly.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.