Score:0

How do I display the entire firewalld state?

cn flag

I'm trying to work out why a firewall is not behaving as I think I've asked it to behave, and thus trying to work out how to get firewalld to show its complete set of rules, in some format resembling an iptables configuration file. Or some other format – I don't much care – as long as it's as least as readable as an iptables or pf configuration (ie, this is a pretty low bar to clear!).

  • Commands like firewall-cmd --list-all ‘List everything added for or enabled in zone.’ But that just lists interfaces, services, and so on, with no further detail. I can't see a --list-all-no-really-everything option.
  • I thought I had found it when I read about the direct rules, but I see that that only applies to rules added as extra ‘direct’ rules, and isn't the trapdoor into the engine room that it first appeared.
  • I see the configuration files in /etc/firewalld and the defaults in /usr/lib/firewalld. But while this is promising at first glance, and beautifully commented, it doesn't seem to actually tell me much about the current state. Questions like this one are about exporting rules (for moving elsewhere), and suggests that this is all there is (I'm guessing that ports mentioned in services mentioned in the public zone are blocked for incoming...?).

My understanding (correct me if I'm wrong) is that firewalld has something iptables-like inside, which is doing all the actual work, and it has some sort of state which --reload can find and, well,... reload. That is the state which I'm hoping to find.

Perhaps I'm dim, but I find the overall level of indirection and helpfulness of firewall-cmd completely unintelligible. Yes, famously ‘every problem in computing science can be solved by adding another layer of indirection’, but sometimes this can be taken to extremes.

I may not have a firewall problem at all, but I can't work out enough about the firewall state to rule that out. Is there a case for switching to iptables (I wonder in desperation)? It's more fuss to set up, and easy to get things wrong, but at least I have some idea what's happening.

I'm very open to frame challenges, or to being told I'm barking up the wrong tree.

Score:1
cn flag
Bob

I would generally recommend to look at the actual firewall rule sets the Linux kernel is running, rather than trying to diagnose more complex firewall issues from "user-friendly" tools such as firewalld (or similarly UFW and others) and the abstraction layer it provides. Often once you understand the underlying issues you can easily resolve them in a matter supported by those tools.

Although some people like [sudo] iptables-save better for me the command [sudo] iptables -L -v -n is your best friend.
Often when discussing configurations it is useful to use the --line-numbers option as well to see number lines. Mentioning rule #X makes a discussion somewhat easier. Remember though that by default iptables only displays the FILTER table and you specify others with the -t [ nat | mangle | raw] switch.

When the nftables backend is used by firewalld, use nft list ruleset.

(For me firewalld is effectively yet another front-end to create rulesets that will be loaded into the Linux netfilter kernel modules. You can still manipulate those backends with their native and more low level tools such as iptables or the more modern nftables successor tools. The picture below shows what other backends firewalld can use and bring together.)

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

cn flag
Thank you! That's exactly what I was looking for. I see from `firewall.conf` that I'm using the `nftables` back-end, so I'm slightly confused that `iptables-save` produces output, or is that just designed to work with both back-ends? Also, where did that diagram come from? It looks like a document I should look at, at least briefly. I expect I'll continue to manipulate the RH firewall using `firewall-cmd`, but consult this output to check what change I've effected.
cn flag
Bob
If you look at the output of `iptables -V` you may see nftables compatibility. The image comes from https://firewalld.org/documentation/concepts.html
cn flag
perfect – thanks
Score:0
cn flag

The accepted answer is correct, I'd just like to add for others coming for this answer that firewall-cmd --list-all-zones gives a very good overview of all the zones and their rules (same output as --list-all, but for all zones at once).

i.e.

[root@sso-staging-01 ~]# firewall-cmd --list-all-zones
[root@sso-staging-01 ~]# firewall-cmd --list-all-zones
block
  target: %%REJECT%%
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

dmz (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 172.18.16.0/20
  services:
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

drop
  target: DROP
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

external
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh
  ports:
  protocols:
  forward: no
  masquerade: yes
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

home
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: cockpit dhcpv6-client mdns samba-client ssh
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

internal (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 172.15.232.0/23
  services: VRRP https
  ports: 6556/tcp 443/tcp
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

legacy (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 128.0.0.0/24
  services: https
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

nm-shared
  target: ACCEPT
  icmp-block-inversion: no
  interfaces:
  sources:
  services: dhcp dns ssh
  ports:
  protocols: icmp ipv6-icmp
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule priority="32767" reject

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: 
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

trusted (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces:
  sources: 172.10.1.0/24 172.10.3.0/24
  services: http https ssh
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

work (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 172.10.0.0/16
  services: http https
  ports: 80/tcp 443/tcp
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
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.