Decide whether Hicks should reach all of Winterfell and ImaginationLAN

[Gerrrt]

What and why

Found while writing ADR-0013 for #104; the finding is recorded there, the decision is not.

Hicks (50) reaches all of Winterfell (99) and all of ImaginationLAN (30), on every protocol and port. No rule grants that and no rule denies it. The Hicks interface blocks CasaBonita, Skids and Degens, and then passes to any:

block drop from vlan50 to vlan40
block drop from vlan50 to vlan20
block drop from vlan50 to vlan10
pass       from vlan50 to any        <-- 30 and 99 fall through to here

There is a narrow explicit rule above it — vlan50 → 10.0.99.1:22/tcp, Allow SSH to pfSense — which is what ADR-0002 and security.md described as the management path. It is real, and it is also redundant: the catch-all below grants far more than it does.

docs/network.md has recorded this correctly the whole time ("Reaches: Internet, 99, 30"). It was ADR-0002 ("exactly two inter-VLAN rules"), security.md ("Specific hosts on Hicks may reach Winterfell on management ports") and README.md ("three inter-VLAN rules, each directional and documented") that described a rule set narrower than the deployed one. ADR-0013 fixed the description. This issue is about the posture.

Why it matters more than the existing residual

SECURITY.md and ADR-0012 already accept that a compromised Hicks workstation reaching 10.0.99.20 can write to the metric and log stores without a credential, because Prometheus and Loki publish unauthenticated ingest ports for oracle's agent. That residual was scoped to one host and two ports.

The actual exposure is the whole segment: every host on Winterfell, every port, plus all of ImaginationLAN. ADR-0002 predicted the direction of this ("a compromised workstation reaches Winterfell") but the design was written as two narrow rules, and it is not implemented that way.

The decision

Not obviously "narrow it". Hicks is the only segment with a management path, and it exists so the estate can be administered. Narrowing means enumerating what a workstation legitimately needs — SSH to the firewall, the Grafana and Prometheus web UIs, Proxmox, the wiki, the iLO web UI, whatever else has accumulated — and getting that list wrong breaks management access and the lab in ways that are annoying to debug from a segment that can no longer reach anything.

Options, roughly:

1. Accept and record it. Cheapest. Turns an undocumented posture into a documented one, which ADR-0013 has already half-done. The residual in SECURITY.md would need widening from "one host, two ports" to "the whole segment".
2. Block 50 → 99 and 50 → 30, then allow-list back. The default-deny posture the rest of the estate has. Highest confidence, most work, and the failure mode during rollout is losing management access.
3. Block 50 → 99 only. Winterfell is where compromise is total; ImaginationLAN is explicitly the segment where broken things live, and ADR-0007 argues the lab is meant to be reachable from trusted workstations.

Option 3 is probably the shape, but the enumeration in option 2 is the work either way.

Worth doing first

Whatever is chosen, do it before #102 builds ADR-0008's sensitive tier — that adds 50→40 and 99→20, and adding rules to a segment whose posture is undecided is how the next four-documents-four-numbers situation starts.

Which VLAN does this touch

🟠 50 — Hicks (trusted), 🔴 99 — Winterfell (management), 🟢 30 — ImaginationLAN (lab)

[Gerrrt]

Decided on 2026-09-01, on the wiki side: option 3, with the enumeration done. Hicks keeps a named list on Winterfell — SSH (22) to every host, the pfSense web UI on 10.0.99.1:443, the wiki on 10.0.99.30 (80/443), Grafana on 10.0.99.20:3000, DNS/NTP on 10.0.99.1, and ping — and a logged block for the rest. Hicks → ImaginationLAN stays fully open, by an explicit rule on the Hicks interface, and the inert copy on the ImaginationLAN interface is deleted. Whole segment, not an admin-host alias, because the admin devices are DHCP leases.

The full ordered rule set, the two hazards it has to route around (the DHCP scope may hand Hicks clients 10.0.99.1 for DNS; the placement of the new block on Apply), and the verification list are on Gerrrt/Lemmiwinks#67. Nothing has been applied yet.

What this issue still owns: the ADR superseding the Hicks paragraph of ADR-0013, and the docs/network.md ("Reaches: Internet, 30, 99 on named ports") and docs/security.md updates once the firewall matches. The wiki PR that closes #67 will link back here.

[Gerrrt]

Applied and documented. Gert applied the narrowed Hicks rule set on morpheus on 2026-09-02, and Gerrrt/Lemmiwinks#106 is merged — it regenerated the wiki's rule tables from the post-change <filter> export and closed Lemmiwinks#67.

What the firewall now enforces on the Hicks interface, in order: SSH (22) to all of Winterfell; HTTPS to 10.0.99.1; DNS (tcp/udp 53) and NTP (123) to 10.0.99.1; ICMP echo to Winterfell; the wiki on 10.0.99.30 (80, 443); Grafana on 10.0.99.20:3000; HTTP to the switch at 10.7.7.2; TCP to all of ImaginationLAN; then Block access to Winterfell and Block access to LAN ahead of the existing blocks and the catch-all. The inert copy of the lab rule on the ImaginationLAN interface is deleted.

Two deviations from the plan worth knowing when the ADR is written: neither new block has logging on, and the lab pass is TCP-only (UDP and ICMP to the lab still arrive through the catch-all). Whether the Hicks DHCP scope hands out 10.0.99.1 or 10.0.50.1 for DNS is still unread; the DNS pass is correct either way.

This issue still owns the ADR superseding the Hicks paragraph of ADR-0013, and the docs/network.md ("Reaches: Internet, 30, 99 on named ports") and docs/security.md updates.

[Gerrrt]

One correction to the comment above: the DNS field is now read. A Hicks laptop's DHCP offer shows domain_name_server = {10.0.50.1}, so clients resolve at their own VLAN's gateway, not at 10.0.99.1. The DNS and NTP passes to 10.0.99.1 on the Hicks interface therefore carry nothing the household depends on; they are harmless and can be listed as such, or dropped, when the ADR is written. The wiki's DNS runbook, which asserted 10.0.99.1 for every VLAN, is being corrected.