The scenario
You just finished a fresh Fedora install or you inherited a server where the firewall was disabled for troubleshooting and never turned back on. The terminal is open, the system is exposed to the network, and you need to lock it down without breaking your own SSH session. You know systemctl exists, but you are unsure whether enable makes the service run immediately, whether start survives a reboot, and what happens if you simply kill the process. The firewall is the first line of defense. Getting the service management right prevents accidental exposure and keeps your network rules intact across power cycles.
How firewalld actually works
firewalld is not a static list of rules that you compile once and forget. It is a dynamic firewall daemon that manages rules at runtime while keeping a persistent configuration on disk. When you launch the service, it reads zone definitions, binds network interfaces to those zones, and hands the actual packet filtering to the kernel. Modern Fedora uses nftables under the hood, but firewalld provides a higher-level abstraction that handles service definitions, port ranges, and rich rules without requiring you to write raw netfilter expressions.
The daemon maintains two separate configurations. The runtime configuration lives in memory and applies immediately to all new connections. The persistent configuration lives on disk and loads the next time the service starts. Changes made with firewall-cmd without the --permanent flag only affect the runtime state. If you modify the runtime state and then restart the service, those changes disappear. If you modify the persistent state and do not reload, the running firewall ignores them. This split design prevents accidental lockouts during live configuration, but it requires discipline. Always apply permanent changes and reload, or accept that your rules will vanish on the next reboot.
Edit configuration files in /etc/firewalld/. Never edit files in /usr/lib/firewalld/. The /usr/lib/ directory ships with the package and gets overwritten on updates. Your custom zones and service definitions belong in /etc/. Trust the package manager. Manual file edits drift, snapshots stay.
Managing the service with systemctl
Systemd handles the lifecycle of the firewall daemon. You need three distinct operations to manage it properly: enabling it for automatic startup, starting it for the current session, and stopping it when you need to troubleshoot or replace it. Each command serves a specific purpose. Mixing them up leaves gaps in your security posture.
Here is how to enable the service so it launches automatically every time the system boots.
# Create a symlink in the systemd preset directory
# This tells systemd to launch firewalld during the multi-user.target phase
sudo systemctl enable firewalld
Here is how to start the daemon immediately without rebooting.
# Launch the firewalld process in the current session
# Reads the persistent config from /etc/firewalld/ and applies it to the kernel
sudo systemctl start firewalld
Here is how to stop the daemon when you need to disable filtering temporarily.
# Terminate the firewalld process and flush all nftables rules
# Warning: this drops all established connections and removes all packet filtering
sudo systemctl stop firewalld
You will often see these commands chained together. sudo systemctl enable --now firewalld combines the symlink creation and the immediate start into a single transaction. The --now flag is equivalent to running enable followed by start. Use it during initial setup. Use the separate commands when you need to audit each step or when you are writing automation scripts that require explicit state transitions.
Run systemctl status firewalld before you make any changes. Read the active state and the recent log lines. Guessing the state wastes time.
Verifying the firewall state
Starting the service does not guarantee the rules are applied correctly. You need to verify three things: the systemd unit is active, the daemon reports a running state, and the zone bindings match your network interfaces.
Here is how to check the systemd unit state and recent journal entries.
# Show active state, main PID, and the last 10 log lines
# The -u flag scopes the output to firewalld only
sudo systemctl status firewalld
Here is how to ask the daemon directly whether it is processing packets.
# Query the firewalld D-Bus interface
# Returns 'running' if the daemon is alive and managing nftables
firewall-cmd --state
Here is how to inspect the active zone configuration and interface bindings.
# List all active zones, their sources, interfaces, and allowed services
# Use --verbose if you need to see port ranges and rich rules
firewall-cmd --list-all
If firewall-cmd --state returns not running but systemctl status shows active (running), the daemon crashed or failed to initialize the nftables backend. Check the journal for the actual failure reason. Type journalctl -xeu firewalld to see explanatory text and jump to the end of the log. The x flag adds high-priority context and the e flag skips the noise. Most sysadmins type this muscle-memory style when a service misbehaves.
Run firewall-cmd --state first. A dead daemon means zero protection.
Common pitfalls and error patterns
The runtime versus persistent split causes the most frequent mistakes. You add a permanent rule, forget to reload, and wonder why the service is unreachable. You change a runtime rule, reboot, and lose the configuration entirely. The fix is consistent: use --permanent for disk changes, then run firewall-cmd --reload to sync the runtime state. Skipping the reload leaves the runtime and persistent configurations diverging. The next reboot will load the old rules, and your troubleshooting session will start from scratch.
Another common trap is stopping the firewall while connected over SSH. sudo systemctl stop firewalld flushes all nftables rules and drops the connection tracking table. Your SSH session terminates immediately. If you are working on a remote machine, keep a second terminal open or schedule the stop command with a delay. Better yet, test rule changes in a VM or container before applying them to production.
SELinux denials appear when you manually edit zone files or service definitions with incorrect contexts. The daemon refuses to load malformed XML or files with wrong ownership. You will see a one-line summary in journalctl -t setroubleshoot pointing to the exact file. Fix the syntax or restore the context with restorecon -v /etc/firewalld/. Do not disable SELinux to work around a configuration error. The denial is telling you exactly what went wrong.
If you see Error: COMMAND_FAILED from firewall-cmd, the daemon rejected the syntax or the zone does not exist. Check the zone name with firewall-cmd --get-zones. Verify the service name with firewall-cmd --get-services. Typos in zone or service names are the leading cause of silent failures.
Reload after every permanent change. Runtime and persistent configs must match.
When to use firewalld versus alternatives
Fedora ships with multiple firewall tools. Each one targets a different workflow and skill level. Pick the tool that matches your operational model.
Use firewalld when you want a dynamic firewall that supports runtime changes without dropping established connections. Use nftables directly when you need low-level packet filtering, custom chains, or performance tuning that bypasses the daemon abstraction. Use ufw when you are migrating from Ubuntu or Debian and prefer a simplified command-line interface with a flat rule list. Use iptables when you are maintaining legacy infrastructure that depends on the older netfilter userspace tools. Stay on firewalld if you are running standard Fedora desktop or server workloads and need zone-based networking with minimal configuration drift.