Adding or removing a rule doesn't reload the firewall, restart a process, or briefly pass traffic unfiltered. It's a small, targeted update to the running fast filter and an atomic transaction in the firewall rules layer — with rollback if either layer fails partway through.
If applying a rule change means reloading a process, briefly passing traffic unfiltered, or dropping active connections, then every routine policy update becomes a scheduled maintenance window — which defeats the point of an API-driven, continuously-updated firewall in the first place.
If rule updates from CI/CD or automated threat response required a maintenance window, the automation patterns described in Automate Your Firewall would be impractical at any real frequency.
Blocking an actively attacking IP is only useful if it takes effect in milliseconds — not after a reload cycle that briefly interrupts everyone else's traffic too.
Any window where the firewall briefly passes traffic unfiltered (or drops all traffic) during a reload is an availability and security risk in its own right, independent of the rule change's intent.
If a rule update fails halfway — written to one enforcement layer but not the other — the system needs a defined, safe outcome rather than an inconsistent state nobody notices.
A rule add or remove is applied as a single targeted update to the fast filter, followed by an atomic firewall-rules transaction — not a full reload of either layer. Both are designed to run against rule sets that are actively being read by live traffic.
On rule removal, the order reverses — the fast-filter entry is removed first, then the firewall rule, with the fast-filter delete rolled back (re-added) if the firewall-rules removal fails. In both directions, the goal is the same: never leave the two enforcement layers disagreeing about a rule's state. The fast filter is designed to support concurrent reads from live traffic while being written to, so a single targeted update doesn't require pausing packet processing.
This targeted-update path is distinct from the state-preserving mechanism used when switching filtering modes — that's a heavier operation (swapping the loaded filter build) that preserves state across the switch. Routine rule changes never trigger that path.
It's worth being precise about what "zero downtime" means here: the update process itself doesn't pause or interrupt traffic. It does not mean every existing connection is guaranteed to survive a rule change unaffected — that depends on connection tracking, which is deliberately limited in scope.
| Traffic path | What actually happens on a rule change |
|---|---|
| INPUT chain (traffic to the firewall itself) | A global connection-tracking rule accepts established/related traffic and drops invalid — existing connections to the firewall's own services are protected by this blanket rule |
| FORWARD chain (pass-through/gateway traffic) | Stateless by design — no per-rule connection-state option exists here, so a new or tightened rule takes effect on the very next matching packet, established connection or not |
| Individual rules | None carry their own connection-state option — state-aware protection is the global INPUT-chain default only, not something configurable per rule |
The practical implication: the mechanism for applying a change is genuinely non-disruptive, but a rule that tightens FORWARD-chain policy can affect in-progress gateway traffic immediately — which is often exactly the intended behavior for a security-driven change (e.g., an emergency block), but worth knowing before assuming "zero downtime" means "zero impact to existing sessions" in every case.