cannot use interface managed by NetworkManager (NM) #374
Comments
0.6.0 defaults to nftables unless you've changed FirewallBackend. Check the output of |
|
@erig0 , I had it explicitly configured to use iptables: I does configure iptables, but only for the zones that firewalld considers active (vms). |
|
Can I provide any more info? Keeping downgrading to 0.5.3 is not a very nice solution, specially when you use a rolling release (OpenSUSE Tumbleweed). |
|
Your output is confusing. On the top you provide information for So in the end, what is the output of What kind of rules do you expect to see in the public zone? Can you provide the |
|
@hdhoang , you are right. I mixed some interface names. That's why "firewall-cmd --get-zone-of-interface=eno0" was not returning a zone. I do not have eno0. I retested all commands and edited the original text. Still, the problem persists. So, basic, the problem is that eno1, managed by NetworkManager, is not assigned to firewalld public zone and public zone rules are not added as there is no interface using it. |
|
Some follow-up. I got this logs in journald after either firewalld or NetworkManager is restarted: Some part of firewalld thinks POST_public chain exists. So, part of it know NetworkManager connections. |
|
@luizluca, Thanks for reporting this. I hit this myself and after quite a bit of debugging found it to be an issue with firewalld's transaction mechanism. I'm in the process of finalizing a fix. |
|
@erig0 , I'm sorry but it did not fix the problem. I applied the patch on 0.6.2 and I still get nothing about default zone in iptables. |
|
BTW, would it be possible to reopen this issue? I cannot do it. |
Just like FirewallZoneTransaction.execute() that was spawned from a FirewallTransaction must call FirewallTransaction.exectue() we should also make sure the same is done for clear(). Otherwise we can end up with a partially cleared transaction. This gets really hairy if the FirewallTransaction contains many instances of FirewallZoneTransaction which is common during startup with non-default configuration. Fixes: #374 (cherry picked from commit 2e53fab)
|
I did some more debug. The issue is not NetworkManager. There is two problems. First, I never got the relevant error message. Running manually, I got this pretty traceback: Further, I get the iptables error, because public zone was not created: The firewall systemd service file sends stdout and stderr to null. I don't know who must change (firewalld error output or systemd service file) but that kind of error (a backtrace) should definitely get into journalctl logs. Now, back to the original problem. Poor NM is innocent here. firewalld fails to use rich rules matching ipsets: I can reproduce it even with very simple rules and empty ipset: |
|
Thanks for the reproducer. The rich rule error is the root cause. I will investigate. |
|
This is due to python's special treatment of variables/functions with two leading underscores. Previously this function was only called within the same source file. Can you try this patch? diff --git a/src/firewall/core/fw_zone.py b/src/firewall/core/fw_zone.py
index 2d7943930e3e..ca90f7fba0d4 100644
--- a/src/firewall/core/fw_zone.py
+++ b/src/firewall/core/fw_zone.py
@@ -1519,7 +1519,7 @@ class FirewallZone(object):
def __ipset_type(self, name):
return self._fw.ipset.get_type(name)
- def __ipset_match_flags(self, name, flag):
+ def _ipset_match_flags(self, name, flag):
return ",".join([flag] * self._fw.ipset.get_dimension(name))
def _check_ipset_applied(self, name):
diff --git a/src/firewall/core/ipXtables.py b/src/firewall/core/ipXtables.py
index 66af2a26eb2b..02a518d2938d 100644
--- a/src/firewall/core/ipXtables.py
+++ b/src/firewall/core/ipXtables.py
@@ -852,7 +852,7 @@ class ip4tables(object):
rule_fragment += [ "-m", "set" ]
if rich_source.invert:
rule_fragment.append("!")
- flags = self._fw.zone.__ipset_match_flags(rich_source.ipset, "src")
+ flags = self._fw.zone._ipset_match_flags(rich_source.ipset, "src")
rule_fragment += [ "--match-set", rich_source.ipset, flags ]
return rule_fragment |
|
I did some more digging. This dirt patch: Shows that calling FirewallZone methods prefixed with two "_" will, in fact, prefix that call with an extra "_ip4tables". So, either renaming "__ipset_match_flags" to remove the two "_" prefix or creating a new "_ip4tables" prefixed one will workaround the problem. I'm really really no python expert but this looks like some black magic metaprogramming going on here. Or, would it be a normal python 3.6 thing? Or even a python bug? Update: escaped some '_' because of markdown syntax |
Pretty much. If it is prefixed with two underscores python will prepend the class name. |
It works! Now, the only problem is the fact that backtrace are being ignored by default. |
Usually the exception is caught and a warning/error is logged. The backtrace is only logged if debug is enabled. |
That didn't happen. I only saw ip6?tables-restore errors: Even on debug, I only saw the backtrace at DEBUG1: and no ERROR: msg. |
Hello,
Since firewalld upgraded to 0.6.x, I cannot use NetworkManager interfaces with firewalld. I'm explicitily using iptables.
Everything looks ok, but:
In the end, I have no iptables rules for public zone.
It works if I downgrade to firewalld-0.5.3:
I'm testing with these OpenSUSE Tumbleweed packages:
Do I need to update NM to a specific version? Or change any settings to make it work? My NM connection settings explicitly set zone to public.
The text was updated successfully, but these errors were encountered: