Firewall Manager

Edit, validate, version, and apply the appliance’s nftables ruleset through a JSON editor in the browser, with three apply modes ranging from non-disruptive to full ruleset flush.

The Firewall Manager is the GUI control surface for the kernel-level enforcement engine described in Key Concepts (chapter 03). It stores nftables rulesets as named JSON snapshots in the database, lets you edit them in place, validates them against the live nft tool before you commit, and applies them to the running kernel with an explicit choice of how disruptive the swap should be.

Reach the page from the sidebar under Operations > Firewall Manager (route /firewall-config). What you see is a single scrollable page divided into a header, a config list, two collapsible panels (Editor Settings, Database Actions Sync), the JSON editor, an action footer, and a caution banner.

When to Use the Firewall Manager

Use the manager for any tuning that does not require a system reboot or an installer rerun.

Typical reasons to open this page:

Switch between the shipped throttling profiles (permissive / medium / strict) because your deployment is too quiet or too loud.
Raise a set’s size cap or timeout after watching tracked entries hit the ceiling.
Add a new counter inside a per-msg-type chain to see how often a rule fires.
Roll back to last week’s working ruleset after a misconfigured experiment.
Capture the current running state as a named snapshot before testing a change.

For emergency recovery, lockouts, and command-line work, jump to Firewall Guidance (chapter 22). To see how a saved ruleset routes packets through the chains, open Flow Visualizer (chapter 21).

The header shows the page title plus four buttons for getting a ruleset into the editor and refreshing the list.

Button	What it does
Load Running	Fetches the live kernel ruleset (the output of `nft -j list ruleset`) into the editor. Use this to start editing from the actual current state.
New	Opens an empty `{ "nftables": [] }` document so you can build a config from scratch or paste fragments in.
Paste	Opens a modal where you can paste JSON from the clipboard. The text is parsed; invalid JSON is rejected before it reaches the editor.
Refresh	Re-fetches the saved configurations list.

Loading a ruleset never alters the kernel — it only fills the editor.

Saved Configurations List

A table of every configuration snapshot stored in the database, with one-click validate, apply, edit, and delete controls.

Columns

Column	Meaning
Name	Human-readable label set when the config was saved.
Created	Timestamp the snapshot was created.
Comment	Optional free-text note.
Valid	Green check, red cross, or grey question mark. Reflects the last validation result; the question mark means the snapshot has never been validated.
Active	Green check on the configuration most recently applied with a flush mode. Multiple configs may be marked active in `add` mode (see Apply Modes).
Boot Config	Checkbox: if ticked, this snapshot is automatically applied when the processor starts. Only one snapshot can be the boot config at any moment.
Applied	When the snapshot was last applied and by which user.
Actions	Per-row buttons described below.

Per-row Buttons

From left to right:

Edit (pencil) — loads the snapshot into the JSON editor below.
Validate (shield) — re-runs validation against the live nft tool and updates the Valid column. Failure messages appear in a strip below the table.
Apply: add rules (grey play arrow) — first apply mode.
Apply: flush table (yellow play arrow) — second apply mode.
Apply: flush ruleset (red play arrow) — third, destructive apply mode.
Delete (trash) — soft-deletes the snapshot. Two-click confirm: the button turns red on the first click and only deletes on the second.

A “Show deleted” toggle at the top right of the table reveals soft-deleted snapshots. Deleted rows show a red “Deleted” badge and expose only a Restore button, which un-deletes the snapshot.

Tip: name your snapshots so you can recognise them later — 2026-05-pre-throttle-raise, strict-profile-tested, medium-profile-shipped. The Comment column is a good place for the reason behind the change.

Apply Modes

Three apply modes trade safety for thoroughness. Choose deliberately.

Mode	Button colour	What runs first	When to use
add	grey	nothing — rules are added on top of whatever is loaded	Adding new rules, sets, or counters without disturbing existing enforcement state
table	yellow	`nft flush table inet dhcp_inspection`	Swapping the DHCP DPI table cleanly without touching other tables managed by the host
all	red	`nft flush ruleset`	Total reset — wipes every table on the box, then loads only this snapshot

Each apply requires a two-click confirmation: the first click shows a hint strip describing what will happen and turns the button into a confirm state; the second click executes. Clicking elsewhere on the table cancels.

After a flush-style apply (table or all), all previously-active snapshots are marked inactive — only the just-applied snapshot is active. After an add apply, the existing active snapshots remain active because their rules are still present in the kernel.

Warning: “Apply: flush ruleset” will remove every nftables rule on the appliance, including ones added by other software. After it runs, only the contents of the chosen snapshot are present in the kernel. Reserve this mode for recovery or initial provisioning.

Invalid snapshots (red cross in the Valid column) cannot be applied — the apply buttons are disabled and a tooltip explains why. Run Validate first to surface the underlying nft error.

Boot Configuration

Mark exactly one saved snapshot to be loaded automatically when the processor service starts.

Ticking the Boot Config checkbox on a row opens an inline Yes/No confirm. On Yes, that snapshot becomes the boot config and any other snapshot’s boot flag is cleared. On startup the processor reads the boot snapshot from the database and applies it before opening the NFQueue.

If no snapshot is marked as boot config, the processor falls back to whatever is already loaded in the kernel — typically the contents of nft-v2.sh from the install — and logs that no managed boot config was found.

JSON Editor

A live JSON tree editor with collapsible nodes, undo/redo history, validation, and search.

The editor renders the loaded snapshot as a navigable tree. Click any value to edit it; click + next to an object or array to add an entry; click the trash icon to remove an entry. Every edit is appended to the in-memory history stack.

Editor Controls

The footer beneath the editor exposes:

Undo / Redo — step backward or forward through the in-page edit history. The history is per-load — switching to a different snapshot resets it.
Validate — sends the current editor contents to the appliance, which writes them to a temp file and runs nft -c -j -f <file>. The result appears next to the Undo button as a green “Valid” or red “Invalid” badge; on failure the full nft error is shown in a red strip beneath the warning banner.
Cancel — discards the in-page edits and closes the editor without saving.
Save — persists the snapshot. If the row already existed, this updates it; otherwise it creates a new row. Save does not apply to the kernel — it only stores the snapshot.

An “Unsaved changes” indicator appears next to the Undo button while the history index is past zero.

Search

A search box above the editor filters tree nodes by key or value. Matching nodes stay visible; non-matching nodes collapse. Clear the search to restore the full tree.

Editor Settings

The “Editor Settings” panel (collapsed by default) tunes the JSON editor itself — not the firewall:

Setting	What it controls
Theme	Editor colour scheme.
Collapse Level	How many levels of the tree are open by default.
Animation (ms)	Speed of expand/collapse animations. 0 disables them.
Indent	Spaces per indent level.
Max Height (px)	Maximum height of the editor viewport in pixels. 0 means fill available space.
Show Counts	Display child counts next to objects and arrays.
Allow Edit / Add / Delete	Disable individual editing capabilities (useful for read-only review).
Enable Clipboard	Per-node copy buttons.
Show String Quotes / Array Indices	Cosmetic toggles.

Settings are stored per-user in the browser and survive reloads.

Rule Structure

The editor expects standard nftables JSON — the same format nft -j produces.

The top-level document is an object with one key:

{
  "nftables": [ ... ]
}

Each entry in the nftables array is one definition: a table, chain, set, map, rule, counter, or limit. Common shapes:

Table — { "table": { "family": "inet", "name": "dhcp_inspection" } }
Chain — { "chain": { "family": "inet", "table": "dhcp_inspection", "name": "...", "type": "filter", "hook": "prerouting", "prio": -100, "policy": "accept" } }
Set / Map — { "set": { "family": "inet", "table": "...", "name": "llm_blocked_marks", "type": "mark", "size": 1000000, "timeout": "2h" } }
Counter — { "counter": { "family": "inet", "table": "...", "name": "v4_request_dropped", "packets": 0, "bytes": 0 } }
Rule — { "rule": { "family": "inet", "table": "...", "chain": "...", "expr": [ ... ] } }

The expr array describes a rule’s matches and actions in order. Familiar building blocks include match, meta, payload, lookup (against a set), counter, limit, accept, drop, queue, jump, goto, mangle, and vmap.

The shipped baseline (nft-v2.sh / nft-v2.json) is the best reference — load it into the editor to see real chain priorities, set timeouts, vmap dispatches, and per-msg-type chain organisation. The DHCP message type byte that drives the per-msg-type vmap, the seven llm_*_marks sets, and the safety-net mac_actions / dhcp_block chains are all visible there. The high-byte encoding and the role of each set are documented in Key Concepts (chapter 03).

Throttling Profiles

Three pre-built profiles ship with the appliance, each tuned to a different traffic discipline.

The shipped profile files live under /opt/dhcp-dpi/share/nft-config/:

Profile	Use case
Permissive (low throttling)	Quiet networks, lab and demo environments, lab traffic generators. Larger per-client rate budgets, longer set timeouts.
Medium (default)	Typical ISP or enterprise deployment. Balances responsiveness against false-positive blocks. Matches the timeouts and size caps listed in Key Concepts (chapter 03).
Strict	High-attack environments and stress testing. Lower per-client budgets, shorter timeouts, faster automatic blocks.

To switch profiles:

Click Paste in the header.
Open the profile JSON file in any text editor and copy its contents.
Paste into the modal and click Load JSON.
Set a name (e.g. strict-profile) and a comment.
Click Save, then Validate.
Decide between an add-mode apply (gentle, layers on top) or a table-mode apply (clean swap of the DHCP DPI table) and click the matching apply button.

You can also edit a saved profile in place — the editor lets you raise a single timeout or set size cap without rewriting anything else.

Database Actions Sync

A separate panel that reconciles the mac_actions table with the live nftables sets after a flush.

The panel sits below the Editor Settings, collapsed by default. Expanding it shows two cards:

Cleanup Expired

Reports the number of mac_actions rows whose timeout has passed but which are still marked active. Clicking Cleanup Database flips them to inactive. Safe — it only updates database rows, never the kernel.

Reapply to NFTables

Reports the number of active actions in the database (with a separate count of permanent ones) and the breakdown by action type. Clicking Reapply Actions re-writes every still-active mark into its corresponding llm_*_marks set.

Use Reapply after an all-mode firewall apply (which flushed everything), after a manual nft flush ruleset, or after restarting the nftables service. Without it the database believes a device is blocked but the kernel does not.

Both operations open a confirmation modal before running and report a result message inline on success.

Tip: make Database Actions Sync the first place you look after any flush-style firewall apply. The active sets are empty until you reapply, and devices that were blocked yesterday will be free until you do.

Validation

Validation runs the live nft tool against your snapshot and reports the exact parser error if there is one.

There are three places validation happens:

In the editor footer — the Validate button checks the in-editor (potentially unsaved) JSON. The badge in the footer turns green or red; on failure the full error appears in a red strip below the caution banner.
In the saved configurations list — the per-row shield icon validates the stored JSON without loading it. The Valid column updates with the result.
Implicitly on apply — the JSON is parsed and validated by nft itself when applied; if parsing fails the apply is aborted and the error returned.

Common validation failures and what they mean:

Error fragment	Likely cause
`syntax error, unexpected ...`	Malformed JSON or unknown rule expression.
`Could not process rule: No such file or directory`	Referenced a set or chain that the same JSON doesn’t define.
`Could not process rule: File exists`	Tried to create a set/chain that already exists in another (non-flushed) table.
`protocol family not supported`	Used a family (e.g. `ip`) that is not enabled in the kernel.
`range overflow`	Numeric value out of the type’s range (e.g. a too-large size cap).

Apply buttons are disabled for snapshots with a red Valid status. Validate before applying.

Rollback

Roll back by applying any older snapshot, or by un-deleting a soft-deleted one.

Two recovery paths:

Apply an older snapshot. Every previously-saved snapshot stays in the list. Pick one, validate, and apply with the same mode you’d use for a forward change.
Restore a deleted snapshot. Tick “Show deleted” to reveal soft-deleted rows, click Restore, then apply.

There is no automatic rollback timer — if a new ruleset starves the system you must either apply an older snapshot from the GUI, or fall back to the command line as described in Firewall Guidance (chapter 22).

Caution

The yellow warning banner at the bottom of the page is not decorative. Editing the firewall configuration directly affects which DHCP packets reach the rest of the appliance. Invalid configurations can prevent enforcement, allow flood traffic through, or — in the worst case — drop the DHCP service entirely. Always:

Validate before applying. A red strip is your last warning before something breaks in the kernel.
Take a snapshot of the running config before experiments. “Load Running”, then Save under a name like baseline-2026-05 is one click each.
Prefer add-mode applies during the working day. They are non-destructive and easy to reverse with another small add apply.
Schedule table- and all-mode applies for a maintenance window. They flush before they load, so for a brief moment the kernel has no rules at all.
After any flush apply, run Reapply Actions in the Database Actions Sync panel so that database-tracked enforcement returns to the kernel.

If everything goes wrong and you cannot recover from the GUI, log into the appliance and follow the recovery sequence in Firewall Guidance (chapter 22). The nft-v2.sh script ships as a known-good baseline you can re-run to get back to a working state.