Managing firewalld on RHEL 10 is primarily about expressing network trust and service intent clearly. The daemon provides a dynamic firewall interface over the system’s packet-filtering stack, allowing administrators to change rules without rebuilding the entire ruleset after every small adjustment. The difficult part is rarely typing a command. It is choosing the correct zone, deciding whether a named service or explicit port is more appropriate, separating temporary tests from permanent policy, and understanding how traffic moves between zones.
These are practical skills for Red Hat RHCSA EX200 and the wider Red Hat certifications ecosystem. They also reinforce the general purpose of a firewall: permit the traffic a host actually needs while denying unnecessary exposure. On RHEL 10, the cleanest configurations normally use firewalld zones, services, ports, policies, and rich rules rather than dropping directly into low-level packet-filter syntax for routine cases.
Zones express trust boundaries
A firewalld zone is a logical trust boundary. Interfaces and source addresses are associated with zones, and each zone contains its own permitted services, ports, and rules. A host connected to an internal management network may therefore apply a different policy from the same host’s Internet-facing interface.
Begin troubleshooting or configuration by asking which zone is actually active for the traffic. Commands such as firewall-cmd --get-active-zones and firewall-cmd --get-default-zone reveal the current assignment. On systems managed by NetworkManager, zone membership is commonly associated with the NetworkManager connection profile, so a change made in the wrong layer can disappear or be replaced when a connection is reactivated.
Do not assume the default zone applies to every interface. Explicitly assigned connections keep their own zone. That distinction matters on multi-homed servers, routers, bastion hosts, and systems with management, storage, and application networks.
Prefer named services when they describe the application
Firewalld ships with predefined service definitions for many common protocols. A service can represent one or more ports, protocols, helpers, or related settings. Allowing ssh or https as a service is often clearer than opening a raw port because the rule documents application intent rather than only transport details.
Inspect a service before using it with firewall-cmd --info-service=<name>. This prevents assumptions about which ports the definition includes. If an application uses a genuinely custom port or protocol, an explicit port rule may be more honest than borrowing an unrelated service name.
For long-lived internal standards, you can define a custom firewalld service rather than scattering the same set of port numbers across multiple hosts. The objective is maintainability. Someone reviewing the host months later should be able to understand why a rule exists without reconstructing application intent from numbers alone.
Runtime and permanent configuration serve different purposes
Firewalld maintains a runtime configuration and a permanent configuration. Runtime changes take effect immediately but are lost after a reload or restart. Permanent changes survive, but depending on the command sequence they may not affect current runtime state until the configuration is reloaded.
This split is useful for safe testing. An administrator can add a rule to runtime, test connectivity, and remove it if the application behaves unexpectedly. Once the rule is confirmed, make the intended configuration permanent. The danger comes from forgetting which layer was changed: a temporary rule that fixes an outage may vanish after reboot, while a permanent rule added without testing may create unwanted exposure.
A disciplined workflow is to inspect the current zone, test the narrow rule, verify the application from the expected source network, make the rule permanent, reload if needed, and then verify again. Record the final state with firewall-cmd --list-all or a more targeted query instead of trusting command history.
Rich rules are for conditions that services and ports cannot express
Named services and simple port rules cover many systems. Rich rules become useful when policy depends on source addresses, address families, logging, rate limiting, or more specific accept/reject behavior. They let administrators express these conditions while staying within the firewalld policy model.
Use rich rules sparingly and read them as policy statements. A rule that allows SSH from one management subnet is easy to reason about. A large collection of overlapping rich rules with different priorities becomes difficult to audit and may indicate that the host’s trust boundaries should be represented with zones or policy objects instead.
RHEL 10 also supports policy objects for traffic that flows between zones. This is important when the host forwards traffic rather than simply protecting services terminating on the local machine. Thinking in ingress zone, egress zone, and direction makes forwarded policy much clearer than trying to force router behavior into host-service rules.
Know when nftables is the better abstraction
Red Hat positions firewalld as the normal interface for typical host firewall configuration, while nftables provides lower-level control for cases that firewalld does not model well. Administrators should therefore resist two opposite mistakes: dropping into nftables for every simple service rule, or forcing a complex packet-processing design into firewalld when the lower-level framework is more appropriate.
RHEL 10 documentation also warns about older firewalld direct rules that interact with iptables-style mechanisms. The iptables component is unmaintained and intended to disappear from a future major RHEL version, so designs that depend on direct rules should be reviewed and migrated toward supported firewalld or nftables approaches.
Operationally, mixing multiple rule-management tools without a clear ownership model is dangerous. If automation modifies nftables directly while administrators also manage firewalld, troubleshooting can become a contest between layers. Decide which tool owns which part of the host policy and document exceptions.
Troubleshoot policy by tracing the packet’s actual path
When a connection fails, verify that the service is listening before changing the firewall. Then identify the source address, destination address, interface, zone, and protocol. A rule in the public zone will not help traffic entering through an interface assigned to internal, and an allowed TCP port will not help an application using UDP.
Use ss or equivalent socket tools to confirm the application, then inspect the active firewalld zone and rules. Check whether the change exists only in permanent configuration while runtime remains unchanged. If multiple zones are involved, examine policy objects and source-based assignments. For forwarded traffic, confirm IP forwarding and routing as separate concerns.
Logging can help with difficult cases, but enable it intentionally and limit noisy diagnostics. The goal is to determine which rule or boundary rejects the traffic, not to flood the journal with every dropped packet on an Internet-facing interface.
Safe firewall changes include rollback and verification
Remote firewall administration deserves extra care because one incorrect rule can cut off the management session used to repair it. Before changing the zone on a remote interface, confirm how SSH or the management protocol will remain permitted. When possible, use an out-of-band console, a second session, or a timed rollback mechanism for high-risk changes.
After applying policy, test from the networks that matter. A service that is reachable locally proves only that the application is listening; it does not prove the correct external path is allowed. Conversely, a successful connection from one subnet does not prove the service is appropriately restricted from other zones.
Finish by comparing runtime and permanent state, saving the intended configuration, and verifying behavior after a controlled reload. Good RHEL firewall administration produces a policy that is not only effective now but also predictable after NetworkManager reconnects, firewalld reloads, and the server reboots.
The most useful mental model is simple: zones say where traffic comes from, services and ports say what the host exposes, rich rules add precise conditions, and policies describe traffic moving between zones. Keep those responsibilities clear and firewalld remains much easier to secure, troubleshoot, and audit.
Automate firewalld without hiding the resulting policy
Automation is useful for consistent firewall configuration, but the generated state should remain readable with native tools. Whether policy is delivered through Ansible, system roles, provisioning scripts, or configuration management, an administrator should still be able to run firewall-cmd and understand which zone, service, port, rich rule, or policy object is responsible for traffic.
Make automation idempotent and explicit about permanent versus runtime changes. A task that repeatedly appends equivalent rules can create clutter, while a script that modifies only runtime state may appear successful during provisioning and fail after reboot. Define desired state, apply it to the permanent configuration, and use a controlled reload or runtime synchronization method appropriate to the change window.
Version the intended host firewall configuration alongside application infrastructure. When an application introduces a new listener, the service deployment and firewall change should be reviewed together. Removing an application should also trigger review of obsolete firewall rules; otherwise hosts accumulate open ports and services that no longer have a business reason to exist.
Use verification from both sides of the firewall
After a rule change, verify more than the command return code. On the server, confirm the service is listening on the intended address and port. From an allowed client network, test that the connection succeeds. From a network that should remain blocked, confirm the same service is not reachable. This positive-and-negative verification is the fastest way to prove that the trust boundary matches design.
Also recheck after a reload and, for important systems, after a controlled reboot. Persistent policy, NetworkManager zone assignment, and service startup order can interact in ways that are not visible immediately after a manual test. A firewall configuration is finished only when the expected exposure remains stable across the host lifecycle.