firewall-cmd says no firewall zones are active. Why?

Question

On Debian 9, I installed firewalld (version 0.4.4.2-1).

sudo firewall-cmd --get-active-zones shows no output. And echo $? shows the exit status was 0 (EXIT_SUCCESS). Why?

I have a network interface eth0, which is shown by ip link (as well as the loopback interface lo).

---

I should say my firewall configuration appears to be mostly working. FWIW, I have changed the default zone from public to MyZone, defined as follows:

$ sudo cat /etc/firewalld/zones/MyZone.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>My Zone</short>
  <service name="ssh"/>
  <service name="https"/>
  <!-- ... --> 
</zone>

If I try to connect using another computer, I am allowed to access the SSH and HTTPS services. And if I run ncat -l -p 8000 on the server, and try to connect with ncat my-server 8000, the connection is correctly blocked. (Ncat: No route to host. And tcpdump shows an ICMP unreachable reply is generated, type "admin prohibited").

Why is firewall-cmd --get-active-zones not showing MyZone as active?

$ sudo firewall-cmd --state                                                                                                         
running
$ sudo firewall-cmd --get-active-zones
$ echo $?
0
$ sudo firewall-cmd --get-default-zone
MyZone
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:43:01:c0:ab brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.8/24 brd 172.16.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd5e:fcf3:b885:0:250:43ff:fe01:c0ab/64 scope global mngtmpaddr dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::250:43ff:fe01:c0ab/64 scope link
       valid_lft forever preferred_lft forever

firewalld.service does not log any warnings.

$ sudo systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-01-30 13:17:31 GMT; 56min ago
     Docs: man:firewalld(1)
 Main PID: 509 (firewalld)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/firewalld.service
           └─509 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid

Jan 30 13:17:21 brick systemd[1]: Starting firewalld - dynamic firewall daemon...
Jan 30 13:17:31 brick systemd[1]: Started firewalld - dynamic firewall daemon.

---

I see that firewalld prefers to be used with NetworkManager. I am not running NetworkManager at the moment, and it sounds like this is a bit fragile.

https://firewalld.org/documentation/concepts.html

If NetworkManager is not used, there are some limitations... If firewalld gets started after the network is already up, the connections and manually created interfaces are not bound to a zone.

However, I have rebooted at least once since installing firewalld. I checked the systemd service. firewalld.service is started Before=network-pre.target. networking.service is started After=network-pre.target. I have confirmed that firewalld is started before networking.service:

$ sudo journalctl -b -u networking -u firewalld
-- Logs begin at Sat 2019-01-26 04:15:01 GMT, end at Wed 2019-01-30 14:15:33 GMT. --
Jan 30 13:17:21 brick systemd[1]: Starting firewalld - dynamic firewall daemon...
Jan 30 13:17:31 brick systemd[1]: Started firewalld - dynamic firewall daemon.
Jan 30 13:17:31 brick systemd[1]: Starting Raise network interfaces...
Jan 30 13:17:37 brick systemd[1]: Started Raise network interfaces.

I have not manually restarted networking or run ifdown / ifup, and I am not running ifplugd. The kernel logs (below) say that the ethernet link has been up, and IPv6 has been running, continuously since boot.

$ sudo dmesg|grep eth0
[    4.082350] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:01:c0:ab
[   47.577570] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   49.981569] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[   49.991543] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

I am not even using DHCP. The configuration for eth0 in /etc/network/interfaces is

auto eth0
iface eth0 inet static
    address 172.16.1.8
    netmask 255.255.255.0
    gateway 172.16.1.1
    dns-nameservers 172.16.1.1

Answer 1

firewalld does not depend on NetworkManager, but the use is recommended.

They're not kidding.

In the absence of NetworkManager, the web page document goes on to say you are required to duplicate / maintain consistency between configuration in two different places.

Additionally, the first of the two places is the ifcfg network configuration system, which does not exist on Debian. By implication, NetworkManager is required on Debian :-).

(Synthesizing various information, it becomes clear that the duplicate configuration in /etc/firewalld/, is only required in case you manually start firewalld after the network interface has been started. This includes if you restart firewalld, although you would normally prefer not to restart firewalld.)

On the one hand, it is probably fair to expect the specific "mostly working" behaviour which was observed in the question. Based on other documentation and further observations, you could reasonably expect the default zone to be applied to your interface(s).

On Debian without NetworkManager, assigning an interface to a different zone will likely appear to work on the running system, but fail to work when you reboot.

You might want to have more than "reasonable expectations" for your firewall. It is more reassuring if you can use the "recommended" configuration, which probably gets better testing when firewalld is changed, and not have to rely on such confusing behaviour.

And I remain confused by the implications of this, including for Red Hat systems. It is extremely confusing that firewall-cmd --permanent --add-interface=... can literally shows the result "success", when it has failed to save the zone configuration correctly!

---

Here is the relevant quote in man firewalld:

If NetworkManager is not in use and firewalld gets started after the network is already up, the connections and manually created interfaces are not bound to the zone specified in the ifcfg file. The interfaces will automatically be handled by the default zone. firewalld will also not get notified about network device renames. All this also applies to interfaces that are not controlled by NetworkManager if NM_CONTROLLED=no is set.

You can add these interfaces to a zone with

firewall-cmd [--permanent] --zone=zone --add-interface=interface

If there is a /etc/sysconfig/network-scripts/ifcfg-interface file, firewalld tries to change the ZONE=zone setting in this file.

If firewalld gets reloaded, it will restore the interface bindings that were in place before reloading to keep interface bindings stable in the case of NetworkManager uncontrolled interfaces. This mechanism is not possible in the case of a firewalld service restart.

It is essential to keep the ZONE= setting in the ifcfg file consistent to the binding in firewalld in the case of NetworkManager uncontrolled interfaces.

As an experiment, I tried the command mentioned:

$ sudo firewall-cmd --zone=MyZone --add-interface=eth0
$ sudo firewall-cmd --get-active-zones
MyZone:
  interfaces: eth0

This behaviour is what you would expect from the documentation if my network interface had been started after firewalld. However my network interface was not started after firewalld.

The man page makes it sound like firewalld relies on getting callbacks from ifcfg when it starts a network interface. However ifcfg is the network system for Red Hat; it is not installed on my Debian system. It seems the Debian firewalld package does not provide any equivalent. So we degrade to "the interfaces will automatically be handled by the default zone".

I ran sudo iptables-save to look at the iptables (IPv4-only) rules generated by firewalld. If I have not manually run firewall-cmd --add-interface..., then there is no mention of eth0. But if I read correctly, the rules handle such packets using the default zone's rules, as a fallback.

Answer 2

If you did not put any config files in either the /usr/lib/firewalld/zones or/etc/firewalld/zones you don't have any configured zones. All you would have is a generic firewall. Still effective depending on the rules you have, just no way to switch from public to private or any other zone you may have configured and have the rules change automatically.

Also if you used a GUI to configure the firewall, just check those directories to make sure the settings that you set actually were put in place.

If you manually put the config files there or the GUI settings manager successfully put the files for the zones you configured in place, then I have no idea.

firewalld is a firewall management tool for Linux operating systems. It provides firewall features by acting as a front-end for the Linux kernel's netfilter framework via the iptables command, acting as an alternative to the iptables service

Check: iptables -S, what is there? If there are rules listed it is a generic firewall! You don't need firewalld to have a firewall you could just manually edit the iptables.

Then install iptables-persistent, and then save your rules after each edit with netfilter-persistent save

Default policy on most systems is (PUBLIC):

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Then you can elaborate with rules in the form of chains.

• Syntax:

  iptables -A INPUT/FORWARD/OUTPUT <interface> <port type> <state> <port> <what to do if match>
  

Example: (allow all incoming SSH on default port not good practice for security)

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT