Proxmox firewall: host, VM, security groups

Why this matters in production

The Proxmox firewall is the layer between the network and your workloads. Misconfigured firewalls either expose too much (security risk) or block legitimate traffic (operational pain).

Layers

The Proxmox firewall operates at three layers:

flowchart LR
  A[Network] --> B[Datacenter rules]
  B --> C[Node rules]
  C --> D[VM rules]
  D --> E[VM guest]

Enabling the firewall

GUI: Datacenter → Firewall → Options → Firewall: Yes. Or:

pvesh set /cluster/firewall/options --enable 1

Each VM has its own firewall=1 flag on each NIC.

Rule structure

A rule has:

• Direction (in/out)
• Action (ACCEPT, DROP, REJECT)
• Source / destination (IP, CIDR, alias, ipset)
• Port
• Comment (mandatory in production)

Aliases and IP sets

Aliases and IP sets let you write rules once and reuse them.

pvesh create /cluster/firewall/aliases --name mgmt-net --cidr 10.10.0.0/16

pvesh create /cluster/firewall/ipset --name blocklist --cidr 198.51.100.0/24

Then reference in rules: source = mgmt-net, source = +blocklist (negative).

Security groups

Security groups are collections of rules applied to multiple VMs:

pvesh create /cluster/firewall/groups --group web-tier --rule 'action=ACCEPT,iface=net0,source=mgmt-net,dport=443,proto=tcp,comment=Allow HTTPS from management'

Attach the group to a VM:

pvesh create /nodes/pve-01/qemu/100/firewall/groups --group web-tier --pos 0

Common mistakes

• “I’ll add rules later” — leaving the firewall off. Default is off.
• ACCEPT all for “simplicity” — that’s no firewall.
• Blocking Corosync traffic — breaks cluster.

A break/fix exercise

Production considerations

Common mistakes

• Enabling firewall without explicit allow-list for cluster traffic.
• Using ACCEPT-all as a “temporary” measure.
• Not testing rules before applying cluster-wide.

Key takeaways

• Default firewall is OFF. Enable it deliberately.
• Use aliases and security groups.
• Always allow cluster traffic.

Knowledge check