You rebooted and the firewall is gone
You rebooted your Fedora machine after a routine dnf upgrade, and your web server won't start. Or you ran a script that checks for an active firewall and it aborted with firewalld is not running. The service is stopped, disabled, or stuck in a failed state. You need the firewall back up before you expose your ports to the world.
What is actually happening
firewalld is the dynamic firewall manager on Fedora. It sits between your network interfaces and the kernel's netfilter subsystem. When the service stops, the kernel usually falls back to default policies, which often means all traffic is allowed. That is a security gap.
The service can stop for several reasons. A conflict with another firewall tool locks the netfilter hooks. A misconfiguration in the zone files causes a crash on startup. SELinux can block the daemon if the context is wrong. Or a manual systemctl stop command left it disabled.
Firewalld manages rules through XML zone files in /etc/firewalld/zones/. You should never edit files in /usr/lib/firewalld/. Those files ship with the package and get overwritten on update. If you need raw iptables commands that firewalld does not support, use the --direct interface. This allows you to inject low-level rules while keeping the firewalld daemon running. Mixing direct rules with zone rules can cause confusion, so document every direct rule you add.
Start and enable the service
Check the current state before touching anything. The output tells you whether the service is dead, failed, or just not enabled.
systemctl status firewalld
# WHY: Shows active state, recent log lines, and whether the unit is enabled for boot.
# Look for "active (running)" in green. If you see "inactive (dead)" or "failed", proceed to the next step.
Bring the service up and ensure it survives reboots. Enabling the unit creates the symlink in the systemd preset directory so the daemon starts automatically on boot.
sudo systemctl start firewalld
# WHY: Starts the daemon immediately in the current session.
sudo systemctl enable firewalld
# WHY: Creates the symlink so systemd starts firewalld automatically every time the system boots.
Verify the firewall is active
Confirm the firewall is managing traffic and the zone is set. The firewall-cmd tool talks directly to the daemon. If the daemon is down, these commands fail.
sudo firewall-cmd --state
# WHY: Returns "running" if the daemon is active and managing rules. Returns "not running" if the service is down.
sudo firewall-cmd --get-default-zone
# WHY: Shows which zone applies to interfaces without an explicit assignment. "public" is the default on Workstation.
Run firewall-cmd --state first. If it says not running, the rest of your troubleshooting is wasted.
Resolve conflicts with other firewall tools
Fedora uses firewalld by default. If you installed iptables-services or nftables, they fight for control of the netfilter hooks. Only one tool can hold the lock at a time. If a legacy service is running, firewalld will refuse to start or will fail to apply rules.
Clear conflicting services that lock the netfilter hooks. Stop them immediately and disable them to prevent recurrence.
sudo systemctl stop iptables-services
# WHY: Stops the legacy iptables service if it is currently running and holding the netfilter lock.
sudo systemctl disable iptables-services
# WHY: Prevents iptables-services from starting on boot and blocking firewalld again.
sudo systemctl stop nftables
# WHY: Stops the nftables service if it is active. Fedora uses firewalld as the frontend, so nftables should not run as a standalone service.
sudo systemctl disable nftables
# WHY: Ensures nftables does not restart and conflict with firewalld after a reboot.
Reboot the system after clearing conflicts. The netfilter hooks sometimes need a clean slate to release the lock.
Check for SELinux denials and log errors
If firewalld fails to start after clearing conflicts, inspect the logs. SELinux protects the daemon. If the security context is wrong, the service crashes or hangs during initialization.
Inspect the logs for AVC denials or configuration errors. The setroubleshoot service translates raw kernel denials into readable summaries.
sudo journalctl -u firewalld -n 50
# WHY: Shows the last 50 log lines for the firewalld unit. Look for "Permission denied" or "SELinux" errors.
sudo journalctl -t setroubleshoot -n 20
# WHY: Displays SELinux denial summaries. The setroubleshoot daemon translates raw AVC messages into human-readable warnings.
Test if SELinux is blocking the service. Set the mode to permissive temporarily, restart the service, and check if it comes up. Restore enforcing mode immediately after the test.
sudo setenforce 0
# WHY: Temporarily sets SELinux to permissive mode. Denials are logged but not enforced. Use this only for diagnosis.
sudo systemctl restart firewalld
# WHY: Attempts to start the service without SELinux blocking it. If this succeeds, SELinux is the cause of the failure.
sudo setenforce 1
# WHY: Restores enforcing mode immediately. Never leave the system in permissive mode on a production server.
Re-enable enforcing mode immediately after testing. A permissive system is an open door.
If the package files are corrupted, reinstall the package. This restores binaries and default zone files without touching your custom configuration in /etc/firewalld/.
sudo dnf reinstall firewalld
# WHY: Redownloads and reinstalls the package files without removing your local configuration in /etc/firewalld.
# This fixes missing binaries or corrupted zone files while preserving your custom rules.
Trust the package manager. Manual file edits drift, snapshots stay.
Manage runtime and permanent configuration
Once the service is running, you can manage rules. Firewalld maintains two sets of configuration: runtime and permanent. Changes to the runtime configuration apply immediately but are lost on reload or reboot. Changes to the permanent configuration are written to disk and survive reboots, but do not apply until you reload.
Demonstrate how to add a rule and apply it safely. Use --permanent to write the rule, then --reload to activate it without dropping connections.
sudo firewall-cmd --permanent --add-service=http
# WHY: Adds the HTTP service to the permanent configuration file. This change survives reboots but does not apply immediately.
sudo firewall-cmd --reload
# WHY: Reloads the firewall configuration from disk. This applies permanent changes without dropping existing active connections.
Run firewall-cmd --reload after every permanent rule change. Otherwise the runtime config and the persistent config diverge.
When to use firewalld versus alternatives
Use firewalld when you are running a standard Fedora Workstation or Server and need dynamic zone management. Use iptables directly when you are maintaining legacy scripts that require raw netfilter chains and cannot be converted to firewalld XML. Use nftables directly when you need advanced nftables features not yet exposed through the firewalld frontend. Stay on firewalld if you want the default Fedora security posture with minimal maintenance.