Closed hexchain closed 4 years ago
This sounds like NM is not notifying firewalld of the zone assignment after firewalld restarts. In cd97204a06f32, we made a change to proactively ask NM about assignments during a reload - this explains why the reload case works. I suppose we could do the same on a cold start().
@thom311, if firewalld restarts will NM re-send the interface to zone assignments when it comes back? i.e. call dbus method changeZoneOfInterface()
I don't know what changeZoneOfInterface()
is. NM only calls 3 possible D-Bus methods: addInterface()
, changeZone()
, removeInterface()
.
Anyway, so NM watches the D-Bus name owner of firewalld, and when firewalld reappears, it will should changeZone()
on the interfaces where a Zone should be configured. So, yes, this could be NM's doing. Enable level=TRACE
logging of NM and grep for firewall:
to see whether that is indeed happening...
Actually, the interface managed by NM gets its zone assigned correctly. It's the unmanaged interface that is ignored by firewalld.
~ % sudo systemctl start firewalld.service
~ % firewall-cmd --get-active-zones # note that ztxxxx did not show up here
home
interfaces: wlp58s0
~ % firewall-cmd --reload
success
~ % firewall-cmd --get-active-zones
home
interfaces: wlp58s0
internal
interfaces: ztxxxx
Sorry for the vagueness.
@hexchain, can you post you internal.xml
and any firewalld warning/errors from the logs during a restart.
@erig0 Sure.
internal.xml
:
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Internal</short>
<description>For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted.</description>
<interface name="ztxxxx"/>
</zone>
firewall-cmd --reload
It looks like something failed during startup, but not during the subsequent reload.
@hexchain, Can you do it again with max debug, --debug=9
?
Also, what is your OS and nftables version? There was a bug in nftables that would cause rule handles to be omitted from the reply. It affects nftables <0.9.3. Many distributions ship 0.9.2 with fixes from the master branch. See https://github.com/firewalld/firewalld/issues/540#issuecomment-553407681.
https://paste.xinu.at/c9iQ/ Here is the startup log with --debug=9
, followed by a reload (see timestamp).
I'm using Arch Linux, nftables 0.8.2 without any patches (packaging script here).
Just built an nftables
package with the 4 patch mentioned in https://github.com/firewalld/firewalld/issues/540#issuecomment-553407681 and the problem was gone.
Thanks for the tip!
Just built an
nftables
package with the 4 patch mentioned in #540 (comment) and the problem was gone.
Great. Closing this report then.
@hexchain, please consider added those patches to the Arch nftables package. Or wait on nftables 0.9.3 which should be out soon.
Arch Linux, firewalld 0.8.0-1, networkmanager 1.20.8-1.
I'm using NM to control Wi-Fi interfaces, and other interfaces, such as ZeroTier, are ignored and unmanaged, as set in
/etc/NetworkManager/NetworkManager.conf
.If for example the ZT interface is assigned to "internal" in firewalld both at runtime and permanently, it is written to
/etc/firewalld/internal.xml
, and the zone is active:But after restarting firewalld, the ZT interface is not assigned to "internal" zone anymore, and the zone is no longer active, until
firewall-cmd --reload
.