Saruman's Proxmox firewall was never enabled: ADR-0014's rule exists only in a runbook, and phoenix's 8006 line has no wall to go in

[Gerrrt]

Found 2026-09-20, building phoenix (#436)

build-the-jumpbox.md §4 writes ADR-0043's one line — IN ACCEPT -source 10.0.30.70 -p tcp -dport 8006 — beneath ADR-0014's three in Saruman's host.fw. There is no such file. On Saruman:

pve-firewall status            → Status: disabled/running
/etc/pve/firewall/cluster.fw   → does not exist
/etc/pve/nodes/*/host.fw       → does not exist

and from morpheus (10.0.30.1, not on 10.0.50.0/24), nc -z 10.0.30.110 8006 and 22 both connect. ADR-0014's management-plane rule — 8006, 8007 and 22 from Hicks only — was decided in 2026-09 and is applied by build-the-playground.md §4, which is gated on #101 and has not run. Nothing in SECURITY.md, network.md or architecture.md claimed it was on; ADR-0043 did ("today nothing on VLAN 30 is admitted"), and #544 corrects that with a marked note.

Also found: the Proxmox node is Saruman, capitalised, as pvesh get /nodes prints it. The runbook said lower-case, so its /nodes/saruman ACL, host.fw path and API URL were wrong; #544 fixes all three.

What this means today

Every address on VLAN 30 — and anything routed to it — reaches the hypervisor's login surface. The token is the control and the rule was only ever the door, as ADR-0043 says, but the door is recorded in two ADRs as if it stood. It does not. phoenix was built without writing the line, per the runbook's CAUTION: a DROP input policy with the rules unrendered locks the console out of a machine whose console is a KVM switch away, and that is not a side effect to take while building a guest.

Done when

build-the-playground.md §4 has been run on Saruman with the console to hand — cluster.fw with policy_in: DROP, /etc/pve/nodes/Saruman/host.fw with ADR-0014's three rules and ADR-0043's fourth, firewall=0 on every guest NIC (140 and 170 today) — and:

• pve-firewall status says enabled/running;
• from phoenix, the §4 curl in build-the-jumpbox.md still returns the guest list;
• from morpheus, nc -z -w 3 10.0.30.110 8006 is refused;
• Saruman's Alloy still remote-writes to 10.0.99.20 (outbound is unaffected by policy_in, but check up{instance="saruman"} after);
• the note on ADR-0043 and the sentences in network.md and architecture.md that docs: phoenix is built at 10.0.30.70 on Saruman, the lab has its first off-host client, and Saruman admits it to 8006 (#436) #544 rewrote to say "decided, not applied" are rewritten again to say applied, with the date.

Not gated on #101: the range's other constraints are, but the estate's own hypervisor closing its management plane needs no attack VM to exist first.

Refs #436, ADR-0014, ADR-0039, ADR-0043.

[Gerrrt]

Filed 2026-09-20: #576 watches what this enables — a homelab_pve_firewall_enabled gauge and a rule, so a pve-firewall stop or a reinstall that skips §4 again pages rather than waits for the next person to run nc. Kept apart from this for the #93/#249 reason. This issue is unchanged: the console session, the four rules, the checks above.

[Gerrrt]

Closed 2026-09-20, and enabling the firewall was not what closed it

Ran build-the-playground.md §4 on Saruman with the console to hand, ahead of ifrit and ahead of #442, because the remote path was about to put a device that is not on Hicks in front of this hypervisor's login page. #590 is the repository half.

The done-when above would have passed the firewall and failed the check, and the reason is a rule nobody wrote. Proxmox derives a management address set from the local network it auto-detects, and gives that set five RETURN rules in the host input chain. Saruman is 10.0.30.110/24, so the detected value was the whole lab segment:

add PVEFW-0-management-v4 10.0.30.0/24
-A PVEFW-HOST-IN -m set --match-set PVEFW-0-management-v4 src -p tcp --dport 8006 -j RETURN
-A PVEFW-HOST-IN -m set --match-set PVEFW-0-management-v4 src -p tcp --dport 5900:5999 -j RETURN
-A PVEFW-HOST-IN -m set --match-set PVEFW-0-management-v4 src -p tcp --dport 3128 -j RETURN
-A PVEFW-HOST-IN -m set --match-set PVEFW-0-management-v4 src -p tcp --dport 22 -j RETURN
-A PVEFW-HOST-IN -m set --match-set PVEFW-0-management-v4 src -p tcp --dport 60000:60050 -j RETURN

So cluster.fw with policy_in: DROP plus ADR-0014's three rules plus ADR-0043's fourth would have left VLAN 30 reaching the GUI, SSH, VNC, the SPICE proxy and the migration range — more surface than the 8006 this issue was filed about, and ADR-0014's rules redundant underneath it. Nothing in the ruleset looks wrong. pfctl has no equivalent, so there was no habit here to catch it.

The fix is an alias in cluster.fw, which is what Proxmox's own documentation advises for a single host on a network it does not trust:

[ALIASES]
local_network 10.0.30.110

This estate runs no cluster (ADR-0039), so the detected /24 bought nothing. It withdraws direct VNC, SPICE and migration from the segment. ADR-0014 granted three ports; the box now grants three instead of eight.

Done when, answered

Check	Result
pve-firewall status	enabled/running
cluster.fw, /etc/pve/nodes/Saruman/host.fw	Both present, all four rules render
nc -z -w 3 10.0.30.110 8006 from morpheus	Refused
nc -z -w 3 10.0.30.110 22 from morpheus	Refused
Control: 10.0.30.40 3100 from morpheus	Connects, so the prober works
Saruman's Alloy still remote-writing	Saruman-metrics and Saruman-alloy both 1
firewall=0 on guest NICs 140 and 170	Set, MACs preserved
ADR-0043, network.md, architecture.md, roadmap	Rewritten to say applied, with the date — #590

Still yours: build-the-jumpbox.md §4's curl from phoenix, which proves the fourth rule admits the host it was written for. Everything above was verifiable from the monitoring host and from morpheus.

Three defects in the procedure, now fixed in §4

1. The CAUTION named a check that cannot run. "Write both files, check the rules render, and only then enable" — pve-firewall compile renders nothing at all while the firewall is disabled, just empty cmdlists and firewall disabled. The order that works is enable with policy_in: ACCEPT, read the chain back, then flip to DROP.
2. The host.fw path is case-sensitive, and pvesh get /nodes prints Saruman. A mis-cased path is a rule set that silently does not exist. This is the fourth instance of that trap after the three docs: phoenix is built at 10.0.30.70 on Saruman, the lab has its first off-host client, and Saruman admits it to 8006 (#436) #544 fixed, and the done-when above is the fifth: up{instance="saruman"} matches no series, so that check would have read as no data while the agent was fine.
3. qm set --net0 replaces the whole option, so clearing the guest firewall flag by retyping it mints a new MAC and breaks the DHCP reservation and the OUI column in network.md.

What this unblocks

#442's blocked label comes off when #590 merges. The runbook's Before this line names this issue, and the sequencing reasoning is in the checklist comment there.

#576 is the right follow-up and is unchanged by this: a homelab_pve_firewall_enabled gauge would have caught the original state, and it would now also want to watch that the management set has not widened back to a /24 — a reinstall or a pve-firewall localnet change restores the default silently.