Firewall Decisions
The Firewall Decisions page shows all devices with active enforcement actions in the kernel-level nftables sets, including confidence levels, expiry timers, and LLM reasoning.
This page reads directly from nftables sets at query time — it shows what the kernel is currently enforcing, not historical records. Each entry represents a device mark present in one of the firewall decision sets, with the system resolving marks back to MAC addresses via ClickHouse.
What This Page Shows
Section titled “What This Page Shows”Every device listed here has an active enforcement action in the Linux kernel’s nftables framework.
The page queries six nftables sets within the inet dhcp_inspection table:
| Set Name | Display Name | Purpose |
|---|---|---|
blocked_macs | Blocked by rate limiter (automatic) | MACs auto-blocked by DDoS/rate limit protection |
llm_blocked_marks | Blocked (set by LLM or manually) | Devices blocked by LLM analysis or admin action |
llm_denied_marks | Denied (set by LLM or manually) | Devices denied service (no events recorded) |
llm_throttled_marks | Throttled (set by LLM or manually) | Devices with rate limits applied |
llm_allowed_marks | Allowed (set by LLM or manually) | Trusted devices explicitly whitelisted |
llm_monitored_marks | Monitored (set by LLM or manually) | Devices under observation (no traffic impact) |
Each set has a configurable timeout. When an entry expires, the kernel removes it automatically and the device returns to normal processing.
Device List
Section titled “Device List”The main table lists each device with its enforcement status, identity, confidence level, and time remaining.
Columns
Section titled “Columns”| Column | Description |
|---|---|
| Client MAC | Resolved MAC address (or mark pattern if unresolved) |
| Hostname | Last known hostname from DHCP events |
| Vendor Class | Device vendor identifier |
| Set | Which nftables set contains this entry |
| Confidence | How reliably the mark was resolved to a MAC (see below) |
| Expires In | Time remaining before the kernel removes this entry |
| Request Count | Number of DHCP requests from this device in the last 7 days |
| Last Seen | When this device was last observed in DHCP traffic |
Sorting and Filtering
Section titled “Sorting and Filtering”- Sort by any column by clicking the column header. Default sort is by expiry time (ascending), showing entries about to expire first
- Filter by set using the set dropdown to show only blocked, throttled, or monitored devices
- Search by MAC using the search box to find a specific device across all sets
Confidence Levels
Section titled “Confidence Levels”Confidence indicates how reliably the system matched an nftables mark back to a specific MAC address.
The system resolves marks back to MAC addresses by querying ClickHouse for MACs matching the mark’s suffix pattern. Because the 32-bit mark uses only the last 3 bytes of the MAC (see Key Concepts — The nftables Mark), two MACs sharing the same last 3 bytes produce the same mark — a collision.
| Confidence | Meaning | Visual Indicator |
|---|---|---|
| High | Exactly one MAC in the last 7 days matches this mark | Green badge |
| Low | Multiple MACs match this mark (collision detected) | Yellow badge with “All Matches” expandable |
| Unknown | No matching MAC found in recent DHCP history | Gray badge |
Low Confidence (Collisions)
Section titled “Low Confidence (Collisions)”When confidence is “low,” the primary MAC shown is the one with the highest request count. Click “All Matches” to see every MAC that shares this mark. Review hostnames and vendor classes to determine which device is actually affected.
Unknown Confidence
Section titled “Unknown Confidence”An “unknown” confidence entry means the mark is in the nftables set but no matching MAC appeared in DHCP events within the last 7 days. Common causes:
- The device has not sent DHCP traffic recently
- The mark was added manually or via API with an incorrect value
- The entry is a DHCPv6 device identified by DUID hash (the system attempts DUID-based resolution as a fallback)
- The device is in the
llm_denied_marksset — denied devices do not generate new events, so their mark resolution relies entirely on historical data that may age out
Expiry Chart
Section titled “Expiry Chart”A stacked bar chart at the top of the page shows how many entries in each set fall into different time-remaining buckets.
Buckets: 0-10 minutes, 10-30 minutes, 30 minutes to 1 hour, 1-2 hours, 2-6 hours, 6-24 hours, 1-3 days, and 3+ days. This visualization helps you see at a glance whether most entries are about to expire (healthy turnover) or have long remaining times (persistent blocks).
Summary Statistics
Section titled “Summary Statistics”A stats bar shows aggregate counts across all enforcement sets.
| Stat | Description |
|---|---|
| Total Blocked | Count of entries across all sets |
| Avg Remaining | Average time remaining across all entries |
| High Confidence | Entries with single-MAC match |
| Low Confidence | Entries with multiple possible MACs |
| Unknown | Entries with no matching MAC |
Taking Action on a Device
Section titled “Taking Action on a Device”You can modify a device’s enforcement status directly from this page.
From the device row, you can:
- Remove from set: Removes the mark from the nftables set immediately, restoring normal traffic processing for this device
- Change action: Move a device from one set to another (e.g., change from “blocked” to “monitored”)
- Extend duration: Add more time before the entry expires
- View analysis: If the action was triggered by LLM analysis, click through to see the full analysis with risk score, evidence, and reasoning
Actions executed from this page are logged in the mac_actions table with executed_by set to your username, providing a full audit trail.
Relationship to the Actions Log
Section titled “Relationship to the Actions Log”Firewall Decisions shows what the kernel is enforcing right now. The Actions Log (under Enforcement > Actions Log) shows the complete history.
Key differences:
| Firewall Decisions | Actions Log |
|---|---|
| Live nftables state | ClickHouse mac_actions table |
| Only active entries | Active and expired entries |
| Updated every page refresh | Persistent history |
| Shows confidence levels | Shows executed_by, analysis_id, source_type |
An entry may appear in the Actions Log as “active” but not on the Firewall Decisions page if the nftables set entry expired before the database record was updated. Use the sync tools (Enforcement > Sync Status) to reconcile database and kernel state.
Troubleshooting
Section titled “Troubleshooting”“No devices found” but you know devices are blocked? The nftables table or sets may not exist. Run
sudo nft list table inet dhcp_inspectionto verify. If the table is missing, deploy it withsudo ./nft-config/nft-v2.sh.
All entries show “Unknown” confidence? ClickHouse may be unreachable or the
dhcp_eventstable may have no recent data. Check the ClickHouse connection from the System Health page.
An entry disappeared but the device is still blocked? The nftables set entry expired, but another mechanism (e.g., the rate limiter or a different set) may still be blocking the device. Check all six sets.