Proxmox Deep Dive Part 5: The Built-In Firewall

Part 4 covered bridges, VLANs, and SDN. This part covers the firewall Proxmox layers directly on top of that networking, built in rather than bolted on, and structured around three separate levels that each guard a different kind of traffic.

The three levels, and what each one actually protects.

Datacenter level is the broadest scope: rules and settings defined here apply cluster-wide, and this is also where reusable security groups and IP sets get defined for use at the other two levels. Node level protects the node itself, its own management surfaces, the web GUI on 8006, SSH, anything listening on the host’s own IP, distinct from traffic destined for a guest running on that node. VM/container level protects an individual guest specifically, rules scoped to that one VM or container’s own network traffic, tailored to whatever it actually runs, a web server’s rule set looks nothing like a database server’s.

That separation exists because those three things are genuinely different traffic. A rule permitting inbound HTTPS to a VM running a web server says nothing about whether the Proxmox host’s own web GUI should be reachable from the same network, and a rule locking down the node’s SSH access says nothing about what a guest VM is allowed to do on its own network. Each level can be configured independently, which is exactly the point, node-level lockdown for management access and VM-level rules for guest services aren’t in tension with each other because they’re governing different things.

Security groups and IP sets: keeping rule sets from becoming unmanageable.

A security group is a named, reusable bundle of firewall rules, defined once at the datacenter level and then applied to multiple VMs or containers that share the same access pattern, a “web-facing” group permitting 80/443, applied identically to every VM that’s actually a web server, rather than retyping the same two rules on every VM individually. An IP set is a named, reusable list of addresses or subnets, useful for referencing “the management subnet” or “the lab network” by name in a rule rather than repeating the literal CIDR block everywhere it’s needed. Both exist for the same reason: a homelab with more than a handful of VMs quickly turns unreadable if every rule is written out fully on every guest, and a named group or set is one place to update when the underlying access pattern changes.

A practical homelab default.

Lock down the node level first: restrict the web GUI and SSH to a management subnet or a specific set of trusted addresses, since that’s the surface that, if compromised, hands over the whole node. Leave datacenter-level rules permissive by default and use per-VM rules for anything that actually needs to be reachable from outside its own lab network, the same principle already applied on the pve host’s own isolated lab bridges, each lab (vmbr-sniperlab, vmbr-msflab) gets no route out by design, so the firewall’s job there is mostly making sure nothing unexpected bridges two labs together, not filtering traffic that was never going to leave the bridge in the first place.

Part 6 moves off networking and storage entirely, to the actual decision between running a workload as a KVM virtual machine or an LXC container, and when each one is genuinely the right call.