[Gerrrt]

Closes #223. The firewall change is already applied to morpheus; this is the repository catching up with it.

The obvious fix does not work

#223 said to enable logging on the inter-VLAN pass rules. That was wrong, and checking the rule set before touching it is what caught it: every inter-VLAN pass rule is sourced from an internal segment (vlan50 → vlan99, vlan50 → vlan30). No packet any of them passes can have a terminal VLAN as its source, and the alert needs src ∈ {10,20,40} and dst ∈ {30,50,99}. Logging them would have populated the dashboard's pass panels and left the alert exactly as dead.

Logging the terminal VLANs' own → any egress rules does work, and costs:

Interface	Inbound pkts/day	vs current filterlog
igc0.20 Skids/IoT	11,293,285	127×
igc0.40 CasaBonita/TV	968,266	11×
igc0.10 Degens/guest	312,031	4×
combined	12,573,581	≈142×

On a 30-day retention on one disk, that is a disk-filling change.

What was done instead

Three tripwire rules on morpheus, one per terminal interface — pass + log for <terminal net> → Internal_Segments, placed below the eight block rules that already stop that path and above the → any egress rule:

pass in log quick on igc0.40 inet from <OPT3__NETWORK> to <Internal_Segments>
pass in log quick on igc0.20 inet from <OPT5__NETWORK> to <Internal_Segments>
pass in log quick on igc0.10 inet from <OPT6__NETWORK> to <Internal_Segments>

While segmentation holds the blocks match first, so the tripwire logs nothing and adds no volume. It matches only if those blocks are removed or reordered — the exact failure the alert exists for — and in that case → any would have passed the packet anyway, so nothing is weakened by its presence.

Applied through pfSsh.php (write_config() + filter_configure()), not by hand-editing config.xml. Encrypted backups taken before and after: config-20260901T042022Z (62 rules) and config-20260901T044457Z (65). Gateway, DNS, outbound HTTPS and log ingestion all verified afterwards; exactly 3 pass rules log, and no others.

Proving it, rather than assuming it

A tripwire that never fires is indistinguishable from a broken one — which is this entire family of defect. The monitoring host is on VLAN 99 and cannot originate terminal-segment traffic, so the logging path was proven instead: logging was briefly enabled on the lowest-volume terminal egress rule (Degens, ~3.6 lines/s) and then reverted.

• 49 of 49 resulting pass lines carried the source address in exactly the position the alert's regex reads.
• The destination half of that same regex already matched 2058 block lines.

Both halves are therefore verified against real traffic. Only the combination is absent, which is what "the segmentation is holding" looks like.

What changes here

• Dashboard — no longer claims the alert cannot fire. Terminal→internal passes now reads 0 (that path is instrumented, so zero is a measurement); Passed (1h) still reads not logged, because ordinary egress genuinely is not.
• docs/observability.md, docs/security.md — record why the obvious fix fails, what was done, and how it was verified.
• docs/roadmap.md — TerminalSegmentReachedInternalNetwork cannot fire — the firewall logs blocks only #223 moves to Done.
• docs/runbooks/restore-the-firewall.md — a new verification step. A config restored from a backup older than today drops the tripwires silently, they log nothing either way, and the alert goes quietly back to being unfirable. That trap is worth more than the rules themselves.

make validate passes: 7 dashboards, 140 panels, 132 PromQL and 28 LogQL expressions, docs OK.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The dashboard’s noValue change can mask missing/absent data as a numeric 0, and the new restore verification commands are overly broad and should be made more specific to avoid false results.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates the security observability docs and Grafana dashboard text to reflect the new pfSense “tripwire” pass+log rules that instrument terminal → internal traffic, allowing TerminalSegmentReachedInternalNetwork to become meaningful without exploding log volume.

Changes:

• Update the security-overview Grafana dashboard panel descriptions to reflect tripwire-based pass logging and treat terminal→internal passes as an instrumented signal.
• Document the tripwire approach, rationale, and verification steps in docs/security.md and docs/observability.md.
• Add a firewall-restore verification step for the tripwire rules and move #223 to Done in the roadmap.

File summaries

File	Description
stacks/observability/grafana/dashboards/security-overview.json	Updates dashboard copy and panel “no value” behavior to reflect tripwire pass logging.
docs/security.md	Documents the tripwire rules as the enforcement/verification mechanism for terminal-segment isolation.
docs/runbooks/restore-the-firewall.md	Adds a restore verification step to ensure tripwire rules still exist after restoring older backups.
docs/roadmap.md	Moves #223 to Done and records the rationale for tripwire rules vs broad pass logging.
docs/observability.md	Expands observability narrative explaining why prior alerting was unfireable and how tripwires fix it.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.