Actions

The Actions area is where you see what enforcement has been applied to which devices, take new manual actions, and run actions across many devices at once.

There are two pages under Actions: the Actions History log at /actions/log, and the Bulk Actions builder at /actions/bulk. Both share the same underlying action catalog — Block, Deny, Throttle, Monitor, Allow, Cleanup — and write through to the same nftables sets and the same audit table.

This chapter documents both pages and explains, for each control, what the system actually does behind the scenes.

Actions History

A time-ranged, filterable log of every enforcement action ever taken on the appliance — manual, automation, or LLM.

The page opens to the last 24 hours by default. The header is followed by two stat rows, a collapsible filter panel, and the table itself.

From left to right:

Time range — previous/next arrows step backward or forward by one window length; the picker selects relative (“Last 1 hour”, “Last 7 days”) or an absolute calendar range.
Refresh — re-fetch the visible page.
CSV — download the current filtered result as a CSV.
Add Action — open the Add Action Modal and apply a new action by typing a MAC.

Active Stats Row

Counts every action that is currently in force on the appliance, ignoring the time-range filter.

This row is the “what’s enforcement state right now?” answer. It shows the total along with a per-type breakdown: Blocked, Denied, Throttled, Monitored, Allowed, Cleanup. Numbers come from active rows in the action audit table and are not affected by the filter panel.

Historical Stats Row

Counts every action recorded in the time range, including ones that have since expired.

Same shape as the active row but scoped to the time range and any user filters. Use it to see, for example, “how many blocks did we apply yesterday between 14:00 and 18:00?”.

Filters

Click Filters to expand the panel. All filters are AND-combined.

Filter	Description
MAC Address	Substring match against the client MAC
Action Type	All, or one of Blocked / Denied / Throttled / Monitored / Allowed / Cleanup
Executed By	Substring match against the username, `automation`, or `llm`
Duration	All, less than 1 hour, less than 24 hours, less than 7 days, or 7 days and longer
Expires After / Expires Before	Calendar range on the action’s expiration timestamp
Status	All, Active only, or Inactive only

Apply Filters runs the query; Clear All resets the panel and re-loads the full time range.

Table Columns

Column	Meaning
Client MAC	Device the action targets — click the row to open Device Details
Hostname	Last-known hostname, when available
Action Type	Coloured badge: Blocked, Denied, Throttled, Monitored, Allowed, Cleanup
Executed At	When the action was recorded
Expires At	When the action expires (empty for permanent actions)
Duration	Human-friendly duration (“2h”, “7d”)
Executed By	A username, `automation`, `llm`, or `system`
Active	Green “Active” badge if currently in force, gray “Inactive” if expired or undone
Details	Free-text reason supplied at execution time, often including the firing rule name
Actions	Per-row buttons (see below)

Per-row buttons:

Eye — open the device on the Device Details (chapter 14) page.
Undo (only on active rows that have an inverse) — execute the matching unblock, undeny, unthrottle, unmonitor, or unallow action. You are asked to confirm. There is no undo for Cleanup, since it has no inverse.

Pagination appears above and below the table (page sizes 25 / 50 / 100). Rows are sorted by Executed At descending.

Apply one action to one MAC, from anywhere on the page.

Opens from the Add Action button in the header. Four inputs:

MAC Address — strict aa:bb:cc:dd:ee:ff format required.
Action Type — Block, Deny, Throttle, Monitor, Allow, or Cleanup.
Duration — preset (30m, 1h, 2h, 6h, 24h, 7d, 30d, 1y) or Custom (e.g. 30s, 5m, 2h).
Reason — optional free text. Empty values are stored as “Manual from UI”.

When you click Create Action, the system writes a row to the action audit table, then immediately updates the matching nftables set. The MAC stays in that set until either the duration elapses (nftables expires the entry automatically) or you Undo it.

What Each Action Does

Action	nftables set updated	Default duration	Effect on traffic
Block	`llm_blocked_marks`	2 hours	All DHCP packets from the device are dropped at the kernel. Events are still recorded by the inspector.
Deny	`llm_denied_marks`	Permanent	All DHCP packets are dropped, and the inspector suppresses event emission for the device entirely. Strongest action; recovers only via explicit Undeny.
Throttle	`llm_throttled_marks`	1 day	Per-MAC rate limit of 10 packets per minute. Excess packets are dropped.
Monitor	`llm_monitored_marks`	7 days	No enforcement. The device is tagged for extra event logging in the per-message-type chain.
Allow	`llm_allowed_marks`	30 days	Bypass all enforcement chains. The device is trusted; firewall counters still tick.
Cleanup	All of the above	—	Remove the device from every set in one step. Use this to undo “everything” at once.

The default durations above are the catalog defaults shown in the Add Action Modal description. They are the same defaults the automation engine uses when a rule specifies “use default”. For per-MAC details about whether enforcement is currently active, see the Enforcement Status section of Device Details (chapter 14).

Why a denied device vanishes from the dashboard. Because Deny suppresses event emission (see the table above), a denied device disappears from most dashboard widgets, while a blocked device stays visible. For a widget-by-widget breakdown of what a Deny changes, see How a Deny Changes Your Widgets (chapter 7).

CSV Export

The CSV button downloads the same rows you currently see, filtered by both the time range and any user filters. The file is named actions-log-<YYYY-MM-DD>.csv.

Bulk Actions

Apply one action to many devices in one operation, selected by criteria — not by typing each MAC.

Open at /actions/bulk. The page shows a list of every bulk job (queued, running, completed, failed, cancelled) and a New Bulk Action button that opens a three-step wizard.

Job List

The header has a refresh button, a New Bulk Action button, and two filters:

Status — Pending, Scheduled, Running, Completed, Failed, Cancelled.
Action — Filter by action type (all action types plus the inverse actions Unblock, Undeny, Unthrottle, Unmonitor, Unallow).

The total job count is displayed next to the filters.

Columns:

Column	Meaning
Status	Pending / Scheduled / Running (spinner) / Completed / Failed / Cancelled
Action	Coloured action-type label
Progress	A progress bar with percentage (`0–100%`)
Affected	”executed / preview-count” — how many devices have been actioned out of the preview count
Duration	Per-device action duration (“7d”, “2h”); blank for actions that don’t take one
Created	Timestamp and the username who submitted the job
Scheduled	Future-start timestamp, or `-` for run-immediately jobs
Actions	Per-row buttons: Details, Cancel (if scheduled or running), Delete (if terminal)

The page auto-refreshes every 30 seconds so a running job’s progress updates without manual reload.

Job Detail / Preview

Clicking Details opens a modal with the job’s status, criteria summary, and a sample of the matched MACs. Use this to verify what a job actually targeted, especially after the fact for compliance and audit.

Cancelling and Deleting

Cancel stops a Scheduled job before it starts, or interrupts a Running job between batches. Devices already actioned remain actioned — cancel does not roll back.
Delete removes a terminal-state job (Completed, Failed, or Cancelled) from the list. You are asked to confirm; the action is permanent for the job record only. The underlying device actions are not affected.

Bulk Action Wizard

A three-step modal that walks you from “what devices?” through “what action?” to “go”.

The steps are shown across the top with a progress indicator; you can step Back to revise.

Step 1 — Define Criteria

Pick the conditions a device must satisfy to be included.

Criteria are AND-combined across the panel. At least one criterion is required before you can preview.

Action History

MACs with any past actions — devices that have at least one row in the action log.
MACs with currently active actions — devices currently in any enforcement set.
Filter by past action types — restrict to devices that had a specific past action (block, deny, throttle, monitor, allow).

Time Range (for DHCP events)

A From/To window in local time. Narrows the criteria to devices whose DHCP events fell in that window.

DHCP Criteria

Field	Notes
Relay IP	CIDR supported (`10.0.0.0/8`)
Source IP	CIDR supported
Hostname	Substring contains
Vendor Class	Substring contains
Matched Rule	Substring contains, against the inspector rule name
Message Types	Multi-select among DISCOVER / OFFER / REQUEST / DECLINE / ACK / NAK / RELEASE / INFORM

Activity Thresholds

Min Request Count — minimum number of DHCP requests in the window.
Max Request Count — maximum number.

DHCP Options

Pick one or more required DHCP options the device must have sent (Subnet Mask, Router, DNS, Hostname, Parameter Request, Vendor Class, Client Identifier, TFTP Server, Bootfile, Relay Agent).

Step 2 — Preview

The system counts the matching devices and shows a random sample.

You see:

A large count of devices that match. Green check if the set is non-empty and within limits; yellow warning if zero; red warning if it exceeds the configured maximum (the maximum is enforced server-side).
A Random Sample grid of MAC addresses (about 20 entries). For DHCPv6 devices that exist only as a DUID, the entry shows a “v6” badge and a truncated DUID. MAC entries are clickable links to Device Details (chapter 14) for spot-checking before you commit.
A collapsible Selection Criteria summary that restates the conditions in plain text.

You can step Back to refine the criteria, or Continue if the preview looks right. Continue is disabled when the count is zero or when the limit is exceeded.

Step 3 — Confirm

Pick the action, set its duration, and choose whether to run now or schedule it.

Action Type — choose Block, Deny, Throttle, Monitor, Allow, or Cleanup. Each tile has a short description.

Duration — appears only for Block, Throttle, and Allow (Deny is permanent, Monitor uses the catalog default, Cleanup has no duration). Presets: 30m, 1h, 2h, 6h, 24h, 7d, 30d, 1y.

Reason — free text, minimum 3 characters, required. This is written into every individual action row created by the job and shows up in Actions History.

Execution Timing

Execute immediately — the job starts as soon as you click the button.
Schedule for later — pick a future date/time; the job sits in Scheduled until then.

A yellow confirmation banner restates “you are about to block N devices immediately” so you can sanity-check before pressing Execute Now (or Schedule if scheduled).

What Bulk Actions Do Behind the Scenes

When you click Execute Now or Schedule:

The system pins the criteria via a hash captured during the preview so the executed set matches what you saw.
The job runs in batches against the action catalog. Each batch resolves the device list to MACs (and DUIDs for DUID-only IPv6 clients), writes one row per device to the action audit table, and updates the corresponding nftables set (or removes the device from all sets, for Cleanup).
Progress updates appear in the job list as the job runs.
Errors on individual devices do not stop the job. The Affected counter (“executed / preview-count”) shows progress against the preview snapshot; the difference is the number of devices that failed.

Tip. Bulk Cleanup is the fastest way to reset enforcement after testing an automation rule. Pin the criteria to “MACs with active actions” — the job removes every device from every enforcement set in one pass.

Where Each Page Fits

Automation (chapter 16) writes to the same action catalog when its rules fire. Actions recorded by automation appear in the Actions History with automation in the Executed By column and the rule name in Details.
Firewall Manager (chapter 20) is where you tune the nftables sets themselves — set sizes, timeouts, and per-action rate limits. Action defaults shown in this chapter come from that configuration.
Device Details (chapter 14) is the per-device view of all this: the same actions, the same nftables sets, but pivoted around one MAC.
Automated Actions (chapter 25) explains how the LLM analyser auto-executes actions above configurable risk thresholds.
Statistics (chapter 19) lets you build a report that selects devices by activity and then promote it directly into the Bulk Actions wizard.

Troubleshooting

An action says Active in the table but the device is still being seen in DHCP traffic. Active in the audit table means the action row is still flagged active. It does not guarantee the nftables set still contains the device — set entries expire when the kernel timeout fires, even if the audit row is not yet updated. Open the device on Device Details (chapter 14) and look at Enforcement Status for the authoritative kernel-level state.

Bulk preview says “exceeds limit”. The appliance enforces a maximum number of devices per bulk job to protect the kernel from a single very large mutation. The cap is set by bulk_actions.max_limit in config.yaml (default 1,000,000). Either narrow the criteria — tighten the time range, raise the request-count threshold, or split into smaller protocol/vendor segments — then preview again, or raise the limit in config.yaml and restart the appliance.

Cancelled a scheduled job and devices were still actioned. Some devices may have been actioned in an early batch before the cancel reached the worker. Open Actions History, filter by the executed-by user and the time window, and Undo any rows that should not have been applied.

An undo didn’t work for a Cleanup row. Cleanup has no inverse action — it removed the device from every set, and there is no way to “uncleanup”. To re-apply the original enforcement you need to issue the original action again (Block, Throttle, etc.).