firewalld's zone-based model differs meaningfully from simpler firewall tools, leading to some distinctive troubleshooting scenarios. This guide covers the most common firewalld issues and their resolutions.
"Connection Refused" Despite Adding a Firewall Rule
sudo firewall-cmd --list-allVerify the rule was actually added to the correct, currently-active zone — a common mistake is adding a rule to a zone that isn't actually applied to the relevant network interface.
Forgetting --permanent (Rule Disappears After Reboot)
sudo firewall-cmd --add-port=8080/tcp # Temporary only
sudo firewall-cmd --permanent --add-port=8080/tcp # Persists across rebootsA very common mistake — without --permanent, changes apply immediately but don't survive a reboot; always include this flag for changes meant to be permanent, and remember to reload afterward.
Forgetting to Reload After Permanent Changes
sudo firewall-cmd --reload--permanent changes are staged but not actually active until you reload — a rule added with --permanent alone (without a subsequent reload) won't take effect immediately, only after the next reload or reboot.
Checking Which Zone an Interface Is Actually In
sudo firewall-cmd --get-active-zonesUnderstanding the Default Zone
sudo firewall-cmd --get-default-zoneNew interfaces without explicit zone assignment use this default — verify it's the zone you expect, particularly on servers with multiple network interfaces.
Rule Order and Conflicting Rules
Unlike raw iptables where rule order matters significantly, firewalld's zone-based model generally handles this more predictably — but conflicting rules across different zones can still cause confusion if an interface's zone assignment isn't what you expect.
Rich Rules Not Working as Expected
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.5" accept'Verify rich rule syntax carefully — a small syntax error can cause the rule to silently not apply as intended; use firewall-cmd --list-rich-rules to confirm exactly what's actually configured.
SELinux Interfering, Not firewalld
Sometimes a connectivity issue attributed to firewalld is actually SELinux blocking the connection instead — check /var/log/audit/audit.log for SELinux denials if firewalld configuration appears correct but connections still fail.
Testing Rule Effectiveness
sudo firewall-cmd --add-port=8080/tcp --zone=public
curl http://localhost:8080Test both from the server itself and from an external source to distinguish between local application issues and genuine firewall blocking.
Checking firewalld Service Status
sudo systemctl status firewalldOccasionally, the underlying issue is simply that firewalld itself isn't running — verify basic service status before diving into rule-level troubleshooting.
Reverting to a Known-Good State
sudo firewall-cmd --reloadIf you've made several changes and lost track of the current effective state, reload restores the actually-persisted (permanent) configuration, clearing any temporary/runtime-only changes that might be causing confusion.
Common Errors
Rule works when tested locally but not from external network — verify your VPS provider's separate network-level firewall/security groups (distinct from firewalld itself) also allow the traffic; both layers need to permit the connection.
Continue Reading
- How to Configure firewalld on AlmaLinux/Rocky Linux
- Understanding SELinux Basics on AlmaLinux/Rocky Linux
- How to Fix "Address Already in Use" Port Binding Errors
Browse more articles in AlmaLinux & Rocky Linux.
