Proxmox VE estate
VLAN-aware bridges, isolated guest bridges, SDN/VNet isolation and firewall-path audits on a self-directed estate.
Evidence tier: Lab. This is my own estate on my own hardware. The audit findings are real; the numbers describe one machine on one day, and nothing here has been applied to an employer system.
This page is a placeholder. The full write-up will cover the network design, the firewall-path analysis, and the OpenTofu provisioning that validates cleanly but has never been applied. What follows is what can be stated today.
What exists
- VLAN-aware bridges and isolated guest bridges, with SDN/VNet port isolation.
- Firewall ruleset and firewall-path analysis, including the discovery that a guest marked
firewall=1was being filtered by nothing in particular, which is exactly the kind of control that looks present until it is measured. - OpenTofu with the
bpg/proxmoxprovider:initresolves the provider from the registry,validatereports the configuration valid, andfmt -recursive -checkis clean on OpenTofu 1.13.1.
What Broke / Challenges
A firewall flag that filtered nothing. A guest was configured with firewall=1, and the estate
behaved as though a control were in place. The audit measured what was actually happening: the flag was
set, the ruleset was empty of the rules people assumed, and traffic was not being filtered by it at
all. The failure is not “the firewall was wrong”, it is that a control can be present, report as
enabled, and do nothing - which is worse than an absent control, because nobody looks again.
Four schema errors that only validate could see. The provisioning configuration was written from
documentation and looked correct. tofu validate rejected it four times, each for a different reason:
ssh is a block rather than an argument, timeout is not a provider argument, raw_file became
source_file, and ip_config requires a nested ipv4 block. Writing the prose first would have
published a configuration that had never been parsed. That is the entire argument for running the gate
before writing the page.
An assertion written twice is two ways to be wrong. The expected state of the edge exists as a file-to-host-to-sha256 map, and the design decision was to keep it as assertions rather than generating configuration from it. The temptation was to have one artefact serve both purposes. That would have made the same fact exist in two places, and the second copy is the one that goes stale.
What is not claimed
- No
planand noapplyhas run against any host. No API token has been issued, so no state exists. The accurate description is “provisions Proxmox guests declaratively”, not “manages a Terraform estate”. - Not professional Terraform experience. Lab level, and the page says so rather than implying otherwise.
- VLAN segmentation is design, not deployment. The live LAN is a single flat subnet; the segmented design has not been cut over.
- No public repository. The provisioning repository has no remote at all, by choice: it is a lab artefact, and a link would imply a level of readiness this work does not have.