Configure a firewall with firewalld

firewalld is the default host firewall on Red Hat Enterprise Linux, Fedora, CentOS Stream, Rocky and AlmaLinux. It exposes a two-level declarative model, zones attached to interfaces and preconfigured services allowed per zone, on top of nftables (modern Linux) or iptables (older Linux). The promise: configure rich filtering without writing a rule chain, and reload on the fly without cutting established connections. This guide lays the foundations (zones, services, rich rules), handles the two classic pitfalls (runtime vs permanent, forgetting to allow SSH), and ends with a rollback plan.

What you will learn

• Install and enable firewalld, check its state
• Understand zones (public, internal, work…) and their role
• Tell runtime from permanent so you no longer lose your rules on reload
• Open services and ports per zone
• Write a rich rule for the cases services do not cover
• Log, troubleshoot and roll back cleanly

In what context?

firewalld is the default when you are in the Red Hat ecosystem (RHEL, Fedora, CentOS Stream, Rocky, AlmaLinux) or on a modern openSUSE. You will meet it almost every time on an RHCSA workstation, on a RHEL/Rocky cloud VM, and on any server managed by firewalld.service.

It is used:

• when you want a host firewall with zones (laptop moving between networks, multi-interface server)
• when you want to reload without cutting established TCP connections
• when you prefer to declare named services (http, ssh, samba…) rather than port numbers

On Debian/Ubuntu, the default is UFW, simpler and enough for a single-interface server. Do not mix the two on the same machine.

Prerequisites

• A RHEL, Fedora, CentOS Stream, Rocky or AlmaLinux server (or Debian/Ubuntu if you explicitly need firewalld)
• A user with sudo rights
• A key-based SSH session and a fallback access (cloud console, IPMI, serial) before any change

Lockout risk

Any drop default policy or any removal of the ssh service from an active zone can cut off your session. Keep a console access ready and test your rules in runtime mode before making them permanent.

Core concept: zones

firewalld attaches each network interface to a zone, and each zone carries its own rules. This is what lets a laptop be strict on public Wi-Fi and permissive on the home Wi-Fi by switching zones automatically.

The standard zones to know, with the open services read from /usr/lib/firewalld/zones/ on AlmaLinux 10:

Zone	Typical use	Default policy
drop	Hostile (unknown network, heavy scanning)	Inbound blocked without notification
block	Hostile with explicit rejection	Inbound blocked, ICMP reject
public	Internet, public Wi-Fi, frequent default	ssh, dhcpv6-client, cockpit allowed, the rest blocked
external	Internet egress with masquerade (NAT)	ssh allowed, masquerade enabled
work	Office LAN	ssh, dhcpv6-client, cockpit
home	Home LAN	ssh, mdns, samba-client, dhcpv6-client, cockpit
internal	Trusted LAN	Same as home
trusted	Everything allowed	No filtering

Swipe to see more

The cockpit service (port 9090) is an addition of the Red Hat distributions: on Debian 13 (firewalld 2.3.1), the same zones do not open it. Check the default zone and the active zones:

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

Runtime vs permanent, the main pitfall

firewalld maintains two configurations, and almost every surprise comes from mixing them up:

• Runtime: the rules currently applied. Lost at the next reload or reboot.
• Permanent: the rules saved in /etc/firewalld/. Applied after reload or reboot.

A command without --permanent touches only the runtime. A command with --permanent touches only the permanent configuration; you then need a firewall-cmd --reload for it to take effect. Measured on AlmaLinux 10: an --add-service=https without --permanent disappears at the next --reload.

Recommended workflow

1. Test first in runtime, without --permanent.
2. If it works, replay it with --permanent.
3. firewall-cmd --reload to apply the permanent version.

Quick alternative: firewall-cmd --runtime-to-permanent copies the current runtime state into the permanent configuration. Useful when you have chained several successful tests.

Install firewalld

firewalld is preinstalled on the Red Hat family, available but not installed on Debian and Ubuntu. In every case, the daemon is started and enabled at boot with systemd.

RHEL / Fedora / Rocky / Alma

firewalld is normally installed and enabled by default:

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld

Check:

sudo firewall-cmd --version
sudo firewall-cmd --state

firewall-cmd --state must answer running.

openSUSE

sudo zypper install firewalld
sudo systemctl enable --now firewalld

Debian / Ubuntu

Available in the official repositories, not installed by default. If UFW meets your needs, stick with UFW. If you need the zone model:

sudo apt update
sudo apt install -y firewalld
sudo systemctl enable --now firewalld

Disable UFW first to avoid any conflict:

sudo systemctl disable --now ufw

Arch Linux

sudo pacman -S firewalld
sudo systemctl enable --now firewalld

Allow SSH before anything else

This is the step never to skip. You must know the active zone of the administration interface before allowing SSH, otherwise you open the port in the wrong zone and cause a lockout at the first disconnection.

Find the active zone:

sudo firewall-cmd --get-active-zones
# Typical output:
# public
#   interfaces: eth0
# internal
#   interfaces: eth1

The interface carrying your SSH session (often eth0) is attached to a zone, here public. It is in that very zone that SSH must be allowed. For the commands of this section, replace public with your active zone.

Check that ssh is already in the zone (it is by default on RHEL/Fedora):

sudo firewall-cmd --zone=public --list-services

If ssh does not appear in the output:

# runtime
sudo firewall-cmd --zone=public --add-service=ssh

# permanent
sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --reload

If SSH listens on a non-standard port, open the raw port:

sudo firewall-cmd --zone=public --add-port=2222/tcp --permanent
sudo firewall-cmd --reload

Zones: read, assign, switch

Once SSH is secured, the commands below are used to inspect zones, attach an interface to one and create one for a dedicated segment.

List all available zones:

sudo firewall-cmd --get-zones

Show the details of a zone (services, ports, sources, interfaces):

sudo firewall-cmd --zone=public --list-all

Attach an interface to a zone (persistent):

sudo firewall-cmd --zone=internal --change-interface=eth1 --permanent
sudo firewall-cmd --reload

Set the default zone:

sudo firewall-cmd --set-default-zone=public

Create a custom zone, useful for a dedicated network segment:

sudo firewall-cmd --new-zone=administration --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=administration --add-source=10.10.10.0/24 --permanent
sudo firewall-cmd --zone=administration --add-service=ssh --permanent
sudo firewall-cmd --reload

Sources vs interfaces

A zone can match either by interface (everything arriving through eth0) or by source (everything coming from 10.10.10.0/24). The second is useful when several subnets share the same physical interface.

Open services and ports

firewalld ships more than 260 preconfigured services (263 counted on AlmaLinux 10), as XML files in /usr/lib/firewalld/services/. List them:

sudo firewall-cmd --get-services | tr ' ' '\n' | head

Allow a service

A firewalld service is a named set of ports and protocols, defined in /usr/lib/firewalld/services/. Opening it by name saves you from knowing its port numbers.

# runtime
sudo firewall-cmd --zone=public --add-service=https

# permanent + reload
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --reload

Open a raw port

Useful when no predefined service matches; the protocol must be specified, tcp is not implicit.

sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

Remove

Removal follows the same syntax as adding, with --remove-: the rule must match exactly the one that was set.

sudo firewall-cmd --zone=public --remove-service=https --permanent
sudo firewall-cmd --zone=public --remove-port=8080/tcp --permanent
sudo firewall-cmd --reload

List what is open

The output describes the permanent configuration or the current one, depending on whether --permanent is present: the two can differ.

sudo firewall-cmd --zone=public --list-services
sudo firewall-cmd --zone=public --list-ports
sudo firewall-cmd --zone=public --list-all

Rich rules: when services are not enough

Rich rules (--add-rich-rule) express criteria that simple services do not cover: a precise source, an advanced action, rate limiting, per-rule logging. Syntax:

# Allow HTTP only from an internal subnet
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.1.0/24"
  service name="http"
  accept
' --permanent

# Explicitly block a hammering IP
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="203.0.113.42"
  reject
' --permanent

# Rate-limit new SSH connections
sudo firewall-cmd --zone=public --add-rich-rule='
  rule service name="ssh"
  accept
  limit value="6/m"
' --permanent

sudo firewall-cmd --reload

The SSH limit only works without the ssh service

Measured on AlmaLinux 10 with nft list ruleset: in the filter_IN_public_allow chain, the rule of the ssh service (tcp dport 22 accept) comes before the limited rich rule. As long as the ssh service stays in the zone, the limit is never reached. For it to apply, set the rich rule, check it, and only then remove the service with --remove-service=ssh, from a session whose fallback access is ready.

List the active rich rules:

sudo firewall-cmd --zone=public --list-rich-rules

To delete one, replace --add-rich-rule with --remove-rich-rule. firewalld parses the rule before comparing it: whitespace and attribute order do not matter, but every element and every value must match. A rule that is not found only produces a NOT_ENABLED warning with a return code of 0: run --list-rich-rules again to confirm the removal.

Logging and troubleshooting

Refused packets leave no trace by default. Enable logging of refused packets:

# values: off | all | unicast | broadcast | multicast
sudo firewall-cmd --set-log-denied=unicast

The unicast value is enough for troubleshooting without flooding the log. These messages are emitted by the kernel, not by the daemon: they carry prefixes such as FINAL_REJECT: and are read in the kernel log, not in the log of the firewalld unit.

sudo journalctl -k --since "10 min ago" | grep -E 'REJECT|DROP'
# or live
sudo dmesg --follow | grep -i reject

Full state of the service:

sudo systemctl status firewalld
sudo firewall-cmd --state
sudo firewall-cmd --list-all-zones

Best practices

• Always test in runtime before saving with --permanent.
• Attach interfaces to an explicit zone rather than relying on the default zone: it avoids surprises after adding a new network card.
• Prefer services over raw ports: maintenance becomes readable (--add-service=http rather than --add-port=80/tcp).
• Create a custom service if you expose an application on a non-standard port: XML file under /etc/firewalld/services/<name>.xml, firewall-cmd --reload, then --add-service=<name>.
• Log (--set-log-denied=unicast) while opening a service, then disable it to keep the log clean.
• Back up /etc/firewalld/: it holds all your permanent customisations (XML files, can be versioned in Git). Do not confuse it with the effective state: see the warning below.

On a new machine, `/etc/firewalld/` is empty

The phrase "back up /etc/firewalld/ and you have your whole permanent state" needs a clarification that changes everything. On a fresh AlmaLinux 10, the zones/, services/ and policies/ directories of /etc/firewalld/ contain zero files. The effective definitions come from /usr/lib/firewalld/, shipped by the package, where you find for example 10 zones.

--permanent creates the local copy on the first write, and only for the modified object. Two practical consequences:

• backing up /etc/firewalld/ on a default machine backs up nothing;
• an empty ls /etc/firewalld/zones/ does not prove there are no rules: firewall-cmd --list-all-zones is what counts.

The corollary concerns --runtime-to-permanent, often presented as a harmless shortcut. A single invocation serialises the whole current state: on the same machine, it wrote 11 zone files, including a public.xml.old, and 6 policy files. The content is identical to the originals, but the machine then stops following the definitions shipped by the distribution, for all zones. A firewalld update will no longer make them evolve.

Security and rollback

When something goes wrong, three fallback levels exist, from the gentlest to the most drastic. The first two are almost always enough; the third, the panic mode, belongs to incident response.

# 1. Go back to the last loaded permanent configuration (cancels runtime changes)
sudo firewall-cmd --reload

# 2. Remove a runtime rule immediately
sudo firewall-cmd --zone=public --remove-service=<service>
sudo firewall-cmd --zone=public --remove-rich-rule='<exact rule>'

# 3. Panic mode: blocks ALL traffic, inbound AND outbound
sudo firewall-cmd --panic-on
# once the incident is under control from the fallback console:
sudo firewall-cmd --panic-off

panic-on cuts everything

--panic-on also cuts your SSH session. Only enable it with a fallback console access available. Useful for incident response, not in normal configuration.

For a full rollback of the permanent configuration, restore /etc/firewalld/ from your backup (or delete the modified file to fall back on the definition in /usr/lib/firewalld/, the one of the distribution), then run firewall-cmd --reload.

Quick troubleshooting

The table starts from the symptom you observe, gives the most likely cause, then the action that fixes it.

Symptom	Probable cause	Action
SSH cut after --reload	ssh service removed from the active zone, or default zone changed	Console → firewall-cmd --zone=<active> --add-service=ssh then --permanent
Rule visible but inactive	Added with --permanent without --reload	firewall-cmd --reload
Rule gone after reboot	Added in runtime only	Replay with --permanent
Port open but service unreachable	Service listens on 127.0.0.1 or wrong zone assigned to the interface	ss -tulpn on the server, firewall-cmd --get-active-zones
Packets blocked without a trace	log-denied disabled (default)	firewall-cmd --set-log-denied=unicast, then journalctl -k
Conflict with UFW or manual iptables	Two managers active at the same time	systemctl disable --now ufw; do not run direct iptables rules
rich-rule still present after --remove-rich-rule	An element or a value differs from the rule that was set (just a NOT_ENABLED warning)	Copy the rule from --list-rich-rules
limit value has no effect on SSH	The zone's ssh service accepts before the rich rule	Remove the ssh service once the rich rule is in place

Swipe to see more

Put it into practice

The runtime vs permanent pitfall is easier to understand by living it: this lab asks you to open a service in the right zone, make the rule permanent, then prove that it survives a reload of firewalld.

Guided lab Practice

Learn how to do it

Open a firewalld service permanently

$ dsoxlab run l4-firewall-persist

Environment: VM·Duration: ~20 min

How it is checked: the state of the system is checked after a reboot, not the command you typed.

First time? What DSOXLab is and how to install it

DSOXLab is the command line that prepares a disposable environment (an isolated shell or a VM), runs the lab scenario, then checks the real state of the system and computes a score. Nothing is installed or broken on your workstation.

It needs Python 3.11 or later, uv or pipx, and git. The installation guide details these prerequisites; on Windows, or on a Mac without Python, use the appliance instead.

This lab starts virtual machines: it also needs ansible-playbook, a hypervisor (KVM or Incus), Terraform and hardware virtualization (/dev/kvm), which inside a VirtualBox VM means nested virtualization. The first time, dsoxlab start l4-firewall-persist checks all of it before creating the machines. Prepare your machine for vm labs.

Install the CLI and add the catalogue, once:

uv tool install dsoxlab   # or: pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Before you run the lab, check:

• DSOXLab installed
• catalogue available
• compatible environment (isolated shell or VM)

To check, nothing is probed from this page: run dsoxlab doctor. Read the diagnosis

Run this lab, then validate your work:

dsoxlab run l4-firewall-persist
dsoxlab check l4-firewall-persist

See every lab: dsoxlab list-labs. Track your progress: dsoxlab progress. The full dsoxlab guide covers scoring and the pitfalls.

Key points

• firewalld attaches interfaces to zones; each zone carries its own services / ports / rich rules.
• Runtime ≠ permanent. Without --permanent, the rule is lost at the next --reload or reboot.
• firewall-cmd --reload replays the permanent configuration; it does not interrupt established TCP connections.
• Always allow SSH explicitly in the active zone of the admin interface before any deep change.
• For most needs, --add-service=<name> is more readable than --add-port=<n>/tcp.
• Rich rules for anything that needs a source, rate limiting or per-rule logging.
• --set-log-denied=unicast is the number one troubleshooting tool, and its traces are in the kernel log.
• --panic-on exists for incidents; never in normal configuration.
• On Debian/Ubuntu, UFW is almost always enough; firewalld on Red Hat, full stop.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →