Add a rule that survives a reload
Task
Make each of the two firewalld mistakes deliberately -- forgetting --permanent and forgetting --reload -- observe how each fails, and learn the pattern that avoids both. Then find out which zone your interface is actually in.
Steps
- Record the starting state:
firewall-cmd --state,firewall-cmd --get-active-zonesandfirewall-cmd --list-all. - Add a rule the runtime-only way:
firewall-cmd --add-service=http. Confirm it appears in--list-alland that the port is reachable. - Reload with
firewall-cmd --reload, then check--list-allagain. The rule is gone. Explain why in one sentence. - Add it the permanent way:
firewall-cmd --permanent --add-service=http. Check--list-all-- it is NOT there, because permanent changes need a reload to become active. Check--permanent --list-alland see it. - Reload, and confirm it is now in both.
- Learn the safe pattern for a remote machine: add a rule with
--timeout=120, confirm it works, and let it expire without confirming. Then add it properly and use--runtime-to-permanentto save what you tested. - Move the interface to a different zone and confirm that a rule in the old zone no longer applies.
Verify
firewall-cmd --get-active-zones
firewall-cmd --list-services # runtime
firewall-cmd --permanent --list-services # saved
diff <(firewall-cmd --list-services) <(firewall-cmd --permanent --list-services) \
&& echo "runtime and permanent agree"
The diff producing no output is the state you want before walking away. If they differ, you have either a rule that will vanish at the next reload or one that is saved but not active -- and both are surprises waiting for someone else.
Notes
--runtime-to-permanent is the command that makes this workflow safe: test in runtime, where a mistake reverts on reload, then persist exactly what you proved works. It is better than --permanent first, because a permanent mistake survives the reboot you use to recover from it.