Terminal.Drill Get the app
ch07/l03

Firewall state without accidental changes

Audit zones, services, ports, runtime, and permanent rules before editing.

firewall-cmd --list-all 20 min read, 30 min lab operator

Firewalld uses zones attached to interfaces and sources. Runtime changes can disappear after reboot unless made permanent. Audit first; change only with a rollback plan.

In the field

Port 8443 should be reachable, but nobody knows whether the host firewall permits it.

Worked command

$ firewall-cmd --get-active-zones$ firewall-cmd --zone=public --list-all$ firewall-cmd --runtime-to-permanent$ firewall-cmd --reload
Anti-pattern

Do not add ports to the default zone without checking which zone owns the interface.

Safer pattern

List active zones and current rules before proposing any change.

Knowledge check

You ran `firewall-cmd --add-port=8443/tcp` and the port opened. Why might 8443 be closed again after a reboot?

  • A The change was runtime-only; without --permanent (or --runtime-to-permanent) it is lost on reboot
  • B firewalld disables all custom ports at boot
  • C The port must also be added with --reload to persist
  • D Adding a port always requires restarting the network interface
Show the answer

Correct: A. The change was runtime-only; without --permanent (or --runtime-to-permanent) it is lost on reboot

Why

Runtime rules live only in the running config and vanish on reboot unless written to the permanent config. The trap is --reload: it re-applies the permanent config, so without making the rule permanent first, reload actually drops the runtime-only change rather than persisting it.

Practice checklist

  1. Use a VM or sample output.
  2. Identify active zones and services.
  3. Write a proposed change without applying it.

Deliverable evidence

  • Firewall audit note with zone, services, ports, and runtime/permanent status.
Teaching diagramch07 · mental model
walk the symptom down the ladderaddress + routeip addr / ip routename (DNS)dig +shortsocketss -tulpnHTTP responsecurl -I / -veach step proves ONE layergreen here does not prove green therefirewallfirewall-cmd --list-allaudit before editruntime vs permanentping reaching a host does not prove the application answers

shows: The diagnostic ladder for a reachability symptom: address and route, then DNS name resolution, then listening socket, then HTTP response, with firewall audited separately, and each command proving only its own layer.

does not prove: It does not prove the failure is single-layer: more than one layer can be broken at once, and a green check at one step is evidence for that step only, not proof the whole path works.

Memorize this

Commit these to memory, then drill them until recall is automatic.

--get-active-zones--list-all--add-port--permanent--reload

Reference

firewall-cmd --list-all
Recall practice · Scenario -> next check

cue You added firewall ports at runtime and want them to survive a reboot without re-typing each rule

show recall target

firewall-cmd --runtime-to-permanent

See this drill type Practice recall in the app