The firewall blocks your new service
You installed a database and restarted the service. Your application complains it cannot connect. You check the service status and it is running. You check the port and it is listening. Yet the connection times out. The firewall is likely blocking the traffic, or you opened the wrong port, or the zone is misconfigured. You need to see exactly what firewalld is doing right now, not what you think you configured last week.
How firewalld manages traffic
Fedora uses firewalld as the default firewall manager. It manages nftables under the hood, but you interact with zones and services. A zone defines the trust level of a network interface. The public zone is the default for most desktops and servers. It allows SSH and DHCP but blocks everything else. The trusted zone allows all traffic. The drop zone drops all incoming traffic without reply.
firewalld maintains two states. The runtime state is active right now in the kernel. The permanent state is saved to disk and loads on boot. Changes to the permanent state do not affect the runtime state until you reload. This separation prevents locking yourself out during a misconfiguration. If you add a rule to the permanent config and it breaks connectivity, the runtime config keeps you connected until you reboot or reload.
Services are abstractions for ports and protocols. The ssh service maps to port 22/tcp. If you open the ssh service, you are opening port 22. This makes rules readable and maintainable. If you change the SSH port, you update the service definition or use a rich rule. Opening raw ports works but loses the semantic meaning.
Reload the firewall after every permanent change. Divergent configs are a debugging nightmare waiting to happen.
Inspect the active configuration
Here is how to check the active configuration of the default zone. This shows what is enforced right now.
sudo firewall-cmd --list-all
# WHY: Shows the runtime configuration for the default zone.
# WHY: Includes interfaces, sources, services, ports, and rich rules.
# WHY: This is the state currently enforced by the kernel.
# WHY: If a connection fails, this output is the ground truth.
The output lists the zone name, the interfaces assigned to it, and the allowed services. If you see interfaces: eth0, that interface is governed by these rules. If you see services: ssh dhcpv6-client, only SSH and DHCPv6 are allowed. Everything else is rejected.
Here is how to see every configured zone at once. This helps when multiple interfaces are active.
sudo firewall-cmd --list-all-zones
# WHY: Dumps the runtime state for all zones.
# WHY: Useful when multiple interfaces are assigned to different zones.
# WHY: Helps identify if a service is open in a zone that no interface uses.
# WHY: A rule in an unused zone has no effect on traffic.
Check the zone assignment. A rule in the wrong zone is invisible to the traffic.
Check zone assignments
NetworkManager assigns interfaces to zones based on connection profiles. When you switch from a home network to a coffee shop, the zone might change automatically. This changes the active rules instantly. You need to verify which zone is handling the traffic.
Here is how to list the active zones and their interfaces.
sudo firewall-cmd --get-active-zones
# WHY: Shows which zones are currently active.
# WHY: Lists the interfaces or sources bound to each zone.
# WHY: Confirms the interface you expect is in the zone you think.
# WHY: If the interface is missing, NetworkManager may have changed the zone.
If the interface is not listed, check NetworkManager. The interface might be unmanaged or assigned to a zone that has no active connection. Run nmcli device show to see the GENERAL.CONNECTION and IP4.ADDRESS. Match the connection name to the zone assignment.
Compare runtime and permanent states
Here is how to compare what is running against what is saved. This reveals pending changes or drift.
sudo firewall-cmd --list-all --permanent
# WHY: Shows the configuration stored on disk.
# WHY: These rules will apply after a reboot.
# WHY: If this differs from the runtime output, a reload is pending.
# WHY: Drift indicates changes were made but not reloaded.
If the permanent output includes a rule that the runtime output lacks, you added the rule with --permanent but forgot to reload. The rule will vanish on reboot. Run sudo firewall-cmd --reload to sync the permanent config to the runtime.
If the runtime output includes a rule that the permanent output lacks, you added a temporary rule with --add-service or --add-port. This is useful for testing. If the test succeeds, add the rule permanently and reload.
Edit /etc/firewalld/, never /usr/lib/firewalld/. Package updates destroy manual edits in /usr/lib/.
Verify the application is listening
Firewall rules control traffic at the network stack. They do not start services. If the application is not listening, the firewall allows the packet to arrive, but the kernel drops it with no listener. You need to confirm the service is bound to the port.
Here is how to list all listening sockets with process names.
sudo ss -tulpn | grep LISTEN
# WHY: Lists all listening TCP and UDP sockets.
# WHY: Shows the process name and PID bound to each port.
# WHY: Confirms the application is actually accepting connections.
# WHY: Firewall rules are useless if the service is not listening.
If firewall-cmd shows port 5432 open but ss shows nothing listening on 5432, the application is misconfigured. The firewall is doing its job. Fix the application binding. Check the application logs for bind errors.
Verify the listener. The firewall cannot save a service that isn't running.
Common pitfalls and error messages
You add a rule with --permanent but forget to reload. The rule works until reboot, then vanishes. You see the error Error: COMMAND_FAILED if you try to reload with a syntax error in the XML files. This usually happens when you edit config files manually instead of using the CLI.
Here is how to check the firewalld journal for reload errors.
journalctl -u firewalld -n 20
# WHY: Shows recent log lines from the firewalld service.
# WHY: Reveals XML parsing errors or invalid rule syntax.
# WHY: Essential when --reload fails silently or with a generic error.
# WHY: Look for "Failed to reload" or "Invalid XML" messages.
You add a port to the public zone, but your interface is assigned to trusted. The traffic is allowed by the zone, not the rule. You think the rule failed, but the zone policy overrides it. Check --get-active-zones to confirm the interface assignment.
You open port 8080 but the service listens on 80. The firewall allows the traffic, but the application rejects it. The connection times out or resets. Check ss to match the port.
SELinux blocks the daemon from binding to the port. You see Permission denied in the journal. The firewall allows the traffic, but SELinux denies the process. Check journalctl -t setroubleshoot for denials. Do not disable SELinux. Fix the boolean or file context.
Rich rules allow source IP restrictions. If you use a rich rule, ensure the source address matches the client. A mismatch results in dropped traffic. Use --list-rich-rules to verify the syntax.
Run journalctl first. Read the actual error before guessing.
When to use which tool
Use firewalld when you are managing a standard Fedora system and want zone-based policies. Use nft list ruleset when you need to debug low-level packet matching or firewalld is behaving unexpectedly. Use ss when you need to verify application bindings rather than firewall rules. Use iptables-save only when you are migrating legacy scripts and do not plan to maintain firewalld. Stay on firewalld for 99% of Fedora administration. It handles reloads safely and integrates with NetworkManager.