Configuring a firewall with firewalld on RHEL

firewalld provides a zone-based way to control traffic on RHEL, CentOS Stream and Fedora. It manages host firewall rules through nftables or iptables, so administrators can change access without rewriting low-level rules by hand.

Australian teams use these platforms for banking, government, telecommunications and mining systems. The same tools fit workstations in Sydney and Melbourne offices, servers in Australian cloud regions, and machines supporting .com.au domains.

How firewalld zones shape traffic

firewalld is a firewall daemon that separates policy from raw packet-filter rules. Each interface or source can be assigned to a zone, and each zone carries its own services, ports and restrictions. The default zone normally applies when no stronger match exists.

The public zone is deliberately restrictive, while trusted should remain limited to controlled relationships. A home or work network is not automatically trusted merely because it uses a private address. NetworkManager connection profiles often determine the interface’s zone.

For design details, the firewalld maintainer’s upstream project background explains the zone model. Read the active policy before changing it; rules inherited from a cloud security group do not appear in the host’s firewall-cmd output.

Install and inspect the active ruleset

On RHEL 8 and 9, use sudo dnf install firewalld if the package is absent. Before starting it on a remote server, check the relevant file under /etc/firewalld/zones/ for the SSH service; the default public zone normally includes ssh. Then run sudo systemctl enable --now firewalld, and use sudo firewall-cmd --state plus sudo firewall-cmd --get-active-zones to confirm its state and interfaces.

Use sudo firewall-cmd --list-services to view active services and sudo firewall-cmd --zone=public --list-all to inspect ports and other settings. For broader command-line study, the broader Linux reference includes related system-administration material.

Runtime and permanent configurations are separate. A normal firewall-cmd change affects runtime policy immediately; adding --permanent changes stored configuration, which normally requires sudo firewall-cmd --reload before it becomes active. Have a gander at both views rather than assuming they match.

Allow essential services and ports

Prefer named firewall services when they match the application. They bundle the correct protocol and port, reducing the chance of opening unnecessary traffic.

Useful read-only checks

• List active services: firewall-cmd --list-services.
• Show exposed ports: firewall-cmd --list-ports.
• Check one service: firewall-cmd --query-service=ssh.
• Display a zone: firewall-cmd --zone=public --list-all.

Treat each opening as a security decision. SSH needs the ssh service; web servers commonly need http and https; Cockpit needs cockpit. Database ports should not be opened to the public zone merely to make a client work.

Common permanent allowances

• Permit HTTP traffic: sudo firewall-cmd --permanent --add-service=http.
• Permit HTTPS traffic: sudo firewall-cmd --permanent --add-service=https.
• Permit Postfix SMTP: sudo firewall-cmd --permanent --add-service=smtp.
• Permit Cockpit: sudo firewall-cmd --permanent --add-service=cockpit.

Add these only when the services are required. If mail is hosted for an Australian business domain, this Fedora mail-server guide covers the Postfix side. After permanent additions, reload firewalld and repeat the read-only checks.

Add targeted rules for local services

A rich rule can limit a port by source address, which is safer than exposing it through a general zone. For example, an internal application on TCP 8443 might be reachable only from a corporate VPN range: sudo firewall-cmd --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port port="8443" protocol="tcp" accept'. Replace the example range with the real network.

Use --permanent on the same command when the rule must survive a reload or reboot. Review rich rules with sudo firewall-cmd --list-rich-rules and keep them narrow. A rule that accepts every source is effectively a public service definition, regardless of the port number.

For a regional office, bind an interface to an approved zone with sudo firewall-cmd --permanent --zone=public --change-interface=ens160, then reload. Confirm the interface name first with ip -br link. Avoid moving remote SSH interfaces into an unverified zone, because a mistyped assignment can lock out the session.

Verify, troubleshoot, and retain changes

Verify from the affected client, not only from the server. Run sudo firewall-cmd --check-service=ssh, inspect sudo firewall-cmd --list-rich-rules, and use sudo nft list ruleset to confirm the generated nftables policy. A successful connection proves less than expected, so negative checks for blocked ports are useful.

If rules look correct but traffic still fails, inspect sudo journalctl -u firewalld -b and the application’s own logs. SELinux, container networking, reverse proxies and upstream load balancers can each block traffic outside firewalld. On AWS or Azure, cloud security groups remain a separate layer and must also allow the port.

Australian operators often schedule firewall work around AEST and AEDT daylight-saving changes while supporting systems in several time zones. Change records should list each zone, service, source range and owner, with the final configuration captured for audit purposes. The key to remember is that a disciplined host policy combines narrow rules, explicit checks of runtime and permanent configuration, and verification across every network control in front of the server.