A rule's quota shows on its row as one line (what it used, how it
resets) that opens a dialog with the rest: the allowance, last and next
reset, usage (each address's, with Reset and Give back), and Reset and
Give back for everyone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
POST /rules/{ref}/reset-quota takes an optional address (one entry of a
per-address quota starts again) and give (bytes taken off what was used,
one address's or everyone's, until the next reset). The firewall keeps
the adjustment for its next apply, which writes the new usage into the
ruleset; housecarld applies at once and saves the usage. hc rule
reset-quota --address/--give; Reset and Give back in the web UI, per
address in the usage dialog.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Reverse lookups (internal/names, POST /names) put a name beside each
inside address in connections, the log, quota usage, the dashboard's
quotas and the statistics' devices and blocked sources, in the web UI
and hc (--no-names to leave them out). Only inside addresses are looked
up: an inside zone's networks, and private ones outside the external
zones'. Names are cached (names.cache, 10m) and never stored;
names.resolver picks the DNS server.
Also: hc stats top devices listed each device twice; the dashboard's
quotas named the rule's ID twice.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Quotas panel with each quota's allowance, use (or, per address, the
count and the busiest), a usage bar and the next reset. The usage bar
moves to widgets.js and the Rules page's usage dialog shares it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A rule named in the matrix, the log, the tracer, statistics or the
dashboard opens the Rules page on its chain, scrolled to it and
highlighted (#/rules?rule=ID; the chain is looked up when the link has
none). The Rules page shows each rule's ID beside its order.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Connections: the kernel's tracked connections, read and closed over
ctnetlink (internal/conntrack, raw netlink like the drop log), with
their NAT and TCP state; closing one makes the rules check its next
packet again (GET /connections, POST /connections/close; hc
connections; Traffic → Connections).
- Rules can check every packet (every_packet, --every-packet): before
established connections are accepted, so a drop or reject also stops
connections already open. They can't accept.
- A packet tracer (internal/trace): a table of its own, inet
housecarl-trace, marks the packets a filter picks, `nft monitor trace`
reports every rule and policy they meet in every table, and the tracer
names what accepted or dropped them, Housecarl's rules by name (POST,
GET, DELETE /trace; hc trace; Traffic → Trace). One trace at a time,
at most 200 packets and 20 a second; the table goes when it ends.
e2e: 157 checks, among them an upload a normal block doesn't stop and an
every-packet one does, and a trace naming the blocking rule.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Undo is staged like any edit: in review mode the web UI's Undo, and hc
history undo with -C or HOUSECARL_CHANGESET, add a revert operation
that checks, when replayed, that nothing it touches changed since;
applied, History links the entries. Imports and takeovers still can't
be staged.
- The rules page sums up a chain's built-ins in one line; a window lists
them with what they do and their hits, and switches them.
- Warnings about the machine (dashboard, hc status): nftables.service
enabled (it loads /etc/nftables.conf at boot and flushes every table
when stopped), and the imported table still in force beside
Housecarl's. The docs say to disable nftables.service but not stop it.
- A raw rule with other fields set is refused (raw_conflict) instead of
silently ignoring them; the rule dialog's nftables section hides what
it replaces, and the importer's raw rules carry only their text.
- A dynamic set with configured entries is refused
(set_dynamic_entries): they were silently ignored. The set dialog
shows entries or the entry timeout, as fits.
- The rule dialog's chain choices are just the chains' names.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The new rule window shows chain, zones, addresses, services, family,
action, log and comment; connection state, time window, rate limit,
quota, connection limit and raw nftables open with "+" buttons (and
close with ✕, which unsets them). Editing a rule opens what it uses.
Group addresses appears only when a per-address limit, quota or
connection limit is set. Clearer help for connection state and status.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Changesets, as in Jarl: configuration changes are operations that can be
staged in a changeset, checked as they are added (validation and nft -c),
reviewed with the diff of the ruleset, and applied together as one
history entry, then on probation like any change made over the network.
The web UI collects edits for review by default (pending rows, a bar with
Review and Apply now, a Changes page, a switch for live edits); hc stages
with -C ID or HOUSECARL_CHANGESET (checked like JARL_CHANGESET) and has
hc changeset create/list/show/diff/apply/discard/remove. Undo, import and
takeover refuse a changeset. --dry-run shows the ruleset's diff.
Bandwidth and quotas: rate limits in bytes, per source or destination;
quotas per rule or per address that reset daily, weekly, monthly on a
day, or by hand, with their usage carried across reloads, saved for
reboots, shown by hc quotas and on the rules page, and reset with hc rule
reset-quota. Rules that count traffic are checked before established
connections are accepted (so they see every packet) and can't accept.
Per-address limits group IPv6 by /64 by default (--group-v4/-v6).
Per-source rate meters use update. The importer turns meters, byte rates
and quotas into these fields.
The examples in the web UI, hc's help and the docs use documentation
addresses and generic names instead of the maintainer's network.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Zones, address sets (IPv4 and IPv6 mixed, dynamic sets with timeouts) and
services, ordered rules in the early, input, forward and output chains,
port forwards with hairpin NAT and IPv6 pinholes, source NAT, redirects,
and switchable built-ins (loopback, conntrack, ICMPv6, antispoofing, MSS
clamping, DHCPv6 client, flowtable). Every change is validated, checked
with nft -c and applied in one transaction to Housecarl's own table,
inet housecarl; changes made over the network roll back unless
confirmed, and the confirmed ruleset is loaded at boot by
housecarl-ruleset.service. An empty configuration applies nothing.
Also: hit counters and the drop log (nflog), 'hc import' of an existing
nftables ruleset and 'hc takeover', the hc CLI, the REST API and the web
UI, users, scoped tokens (sets:write:NAME), the audit log, the web UI's
certificate through Jarl, Debian packages, docs, unit tests with real
nft 1.1.3, and an e2e test with real traffic (71 checks).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
abrown38andClaude Opus 5.5