Choosing Between firewalld and nftables in RHEL 9

The Firewall Management Dilemma

Administrators managing Red Hat Enterprise Linux (RHEL) 9 must decide whether to use firewalld, the default dynamic management tool, or nftables, the underlying kernel framework. The primary challenge is balancing ease of administration and integration with the system's network stack against the need for granular packet-level control and maximum performance.

The Takeaway: Use firewalld for the vast majority of server deployments to leverage zone-based security and NetworkManager integration. Switch to raw nftables only when you require complex packet matching, high-performance rule sets that bypass the D-Bus API, or custom logging requirements that the firewalld abstraction cannot provide.

Comparison of Management Approaches

RHEL 9 uses nftables as the actual engine for filtering packets, but firewalld acts as a wrapper that translates high-level requests into nftables rules.

Feature	firewalld	nftables
Default Status	Installed and enabled by default	Available, but requires manual setup
Abstraction	Zones and Services (High-level)	Tables, Chains, and Rules (Low-level)
Runtime Reload	firewall-cmd --reload (State-preserving)	nft -f <file> (Flush/Replace)
Persistence	XML files in /etc/firewalld/	/etc/nftables.conf or custom scripts
NetworkManager	Automatic integration via dispatcher	Manual configuration required
Learning Curve	Low (Intuitive CLI/GUI)	Higher (Requires rule syntax knowledge)

Evaluating the Trade-offs

The Case for firewalld

firewalld is designed for dynamic environments. Its use of zones—predefined sets of rules for different trust levels (e.g., public, internal, drop)—allows you to change the security posture of a network interface without flushing the entire firewall. Because it communicates via a D-Bus API, it can update rules in real-time without dropping existing ESTABLISHED connections.

The Case for nftables

Direct nftables usage removes the overhead of the firewalld daemon. It is the superior choice for specialized security appliances or high-traffic gateways where every microsecond of packet processing matters. It allows for advanced features like sets, maps, and complex concatenation that are difficult or impossible to express through the firewall-cmd interface.

Implementation Examples

Option A: Implementing a Web Zone with firewalld

Use this method for standard web servers where you want to isolate web traffic into a specific security zone.

# Run these commands as root or with sudo permissions
# 1. Create a new zone for web traffic
firewall-cmd --permanent --new-zone=web

# 2. Add HTTP and HTTPS services to the zone
firewall-cmd --permanent --zone=web --add-service=http
firewall-cmd --permanent --zone=web --add-service=https

# 3. Assign the public interface to the web zone
firewall-cmd --permanent --zone=web --add-interface=eth0

# 4. Apply changes without dropping active connections
firewall-cmd --reload

Verification: Run firewall-cmd --zone=web --list-all to confirm the services and interfaces are correctly assigned. Test connectivity using curl -I http://localhost.

Option B: Implementing a Minimal Ruleset with nftables

Use this method if you have disabled firewalld and require a static, high-performance configuration.

# Edit /etc/nftables.conf as root
# Add the following configuration:

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        
        # Allow established/related traffic
        ct state established,related accept
        
        # Allow loopback
        iifname "lo" accept
        
        # Allow SSH and Web
        tcp dport { 22, 80, 443 } accept
    }
}

Execution: Load the configuration using nft -f /etc/nftables.conf. Enable the service for persistence: systemctl enable --now nftables.

Verification: Run nft list ruleset to ensure the table and chains are active. Use nft monitor trace to observe packet handling in real-time.

Critical Constraints and Risks

• Conflict Risk: Never run firewalld and the nftables systemd service simultaneously. They both manipulate the same kernel tables; running both can lead to unpredictable rule shadowing or accidental lockouts.
• Persistence: In firewalld, remember that commands without the --permanent flag are lost upon reboot. In nftables, rules applied via the CLI are volatile unless written to /etc/nftables.conf.
• Rollback: If you lose connectivity while testing nftables, you must access the system via a physical console or IPMI to run nft flush ruleset. For firewalld, you can use firewall-cmd --reload to revert to the last permanent configuration.