RHEL firewalld and nftables Administration

Anil Jalela · Published Sep 3, 2026 · 7 min read

A firewall rule is one decision in a complete packet path. Current RHEL systems commonly use firewalld as the management layer and nftables as the packet-filtering backend. Editing nftables independently while firewalld owns the rules creates two control planes and unreliable persistence. Start by identifying the owner, active zone and interface/source assignment.

Choose one firewall control plane

firewalld zones express trust for interfaces or sources, services describe protocol/port groups and policies control traffic between zones. Runtime changes take effect now; permanent changes survive reload. A safe procedure can test runtime first, then write the reviewed permanent state and reload only after proving recovery access.

A port opened locally may remain unreachable because the application is not listening, binds another address, SELinux denies it, a cloud/security device blocks it or return routing fails. Never solve every timeout by widening the host firewall.

Map rule ownership and traffic direction

Open one service with bounded exposure

1. Confirm application listener, intended source, protocol/port and owner.
2. Capture active zones, complete firewalld configuration and recovery access.
3. Prefer a named service definition or source-scoped rule over a broad port.
4. Apply a runtime test and verify intended allow plus unintended deny.
5. Add the same reviewed rule permanently and compare runtime/permanent state.
6. Reload in the window, repeat tests and retain an exact removal command.

Inspect firewalld and nftables state

systemctl status firewalld
firewall-cmd --state
firewall-cmd --get-active-zones
firewall-cmd --get-default-zone
firewall-cmd --list-all-zones
firewall-cmd --list-all --permanent
firewall-cmd --get-services
firewall-cmd --info-service=ssh
nft list ruleset
ss -lntup
firewall-cmd --zone=internal --add-service=https
firewall-cmd --zone=internal --add-service=https --permanent
firewall-cmd --check-config

• The add examples affect every source classified into the internal zone; verify that zone scope first.
• nft list ruleset is evidence when firewalld owns policy, not permission to append unmanaged rules.
• Runtime and permanent output must agree before a reload acceptance test.
• Use a custom service XML only through the supported firewalld location and validate it before reload.

Evidence and acceptance criteria

Worked scenario: opening a port in the default zone exposes another network

An administrator adds a database port to the default zone because one application cannot connect. A second interface also uses that zone, exposing the database to a less trusted network. The original problem was a missing source classification.

The team removes the broad runtime rule, assigns the management/application interface or source to the correct zone, creates a narrowly scoped service policy and tests from allowed and denied networks. Permanent state is written only after the runtime behavior matches the design.

Practical how-to cases

firewall-cmd --get-active-zones
firewall-cmd --info-service=https
sudo firewall-cmd --zone=public --add-service=https
firewall-cmd --zone=public --list-all
sudo firewall-cmd --runtime-to-permanent
sudo firewall-cmd --check-config

sudo firewall-cmd --permanent --new-zone=management
sudo firewall-cmd --permanent --zone=management --add-source=192.0.2.0/24
sudo firewall-cmd --permanent --zone=management --add-service=ssh
sudo firewall-cmd --reload
firewall-cmd --zone=management --list-all

sudo firewall-cmd --zone=public --add-forward-port=port=8080:proto=tcp:toport=80
sudo firewall-cmd --zone=public --list-forward-ports
sysctl net.ipv4.ip_forward
sudo nft list ruleset | less
curl -v http://SERVER_IP:8080/

ss -lntp
firewall-cmd --get-active-zones
sudo nft list ruleset
sudo tcpdump -ni any tcp port 22
journalctl -u firewalld -b --no-pager

Independent practice tasks

1. Create a custom firewalld service for two lab ports.
2. Build an inter-zone policy in a routed lab.
3. Compare runtime-only and permanent changes across reload.
4. Recover SSH after assigning the interface to the wrong zone.

For this lesson on RHEL Firewall Administration, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: nft flush ruleset or firewall replacement can remove SSH and workload protection instantly. Keep console and exact rollback.
• Unsafe: opening a port to every source because a test fails expands exposure without diagnosing listener or path.
• Unsafe: maintaining simultaneous firewalld and unmanaged nftables policy creates drift and reload surprises.

Rewritten knowledge checks

Guided lab and acceptance test

1. Record active zones and assign a disposable interface/source to a lab zone.
2. Run a test HTTPS listener on a private lab address.
3. Add HTTPS to the lab zone at runtime and test one allowed and one denied source.
4. Inspect nftables effective rules and counters without editing them.
5. Make the rule permanent, validate and reload, then repeat both tests.
6. Remove the lab rule and zone assignment and confirm the listener is no longer reachable externally.

Primary references

• RHEL 10 configuring firewalls and packet filters
• RHEL 10 documentation
• RHEL 9 documentation