Firewall
Proxploy surfaces the full Proxmox firewall configuration at every scope: cluster-wide, per-node, per-security-group, and per-guest (both LXC apps and VMs). Every scope exposes the same primitives — rules, aliases, IP sets, options, and a log — so you don’t need to learn a different shape for each level.
Scopes
Section titled “Scopes”| Scope | Path in UI | What it governs |
|---|---|---|
| Cluster | Firewall → Cluster | Rules applied to every node in the cluster. Aliases and IP sets defined here are shared cluster-wide. |
| Node | Firewall → pick a node | Rules applied to a single Proxmox node, on top of any cluster rules that already match. |
| Security group | Firewall → pick a group | Reusable rule sets that can be referenced by guest firewall rules. Edit a group and every guest that references it picks up the change. |
| Guest (app) | Apps → pick app → Firewall tab | Per-container rules, stacked on top of node and cluster rules. |
| Guest (VM) | VMs → pick VM → Firewall tab | Per-VM rules, same stacking model. |
A firewall rule has a type (in or out) and an action (ACCEPT, DROP,
REJECT). Optional fields let you narrow the match: source/destination
address or alias, port range, protocol, interface, and a comment. An
enable flag lets you keep a rule in the list while temporarily
disabling it without deleting it.
Rules are ordered: the first matching rule decides the packet’s fate. The Move action reorders a rule by its index in the list, so rule order in the UI is exactly what Proxmox enforces.
Options
Section titled “Options”Per-scope options control the firewall’s behavior at that level:
- Enable: turn the firewall on or off at this scope. Disabled means no rules at this level are evaluated.
- Default policies:
policy_inandpolicy_outset the default action (ACCEPT,DROP,REJECT) when no rule matches. - DHCP, NDP, RADV: allow or block DHCP, Neighbor Discovery, and Router Advertisement traffic, which Proxmox can handle before rules are evaluated.
- MAC filter, IP filter: per-guest options that restrict which MAC/IP addresses a guest can use.
Options use a digest-based optimistic concurrency model: you provide the digest from the last read, and the write is refused if the options changed since you last read them, so you never silently clobber someone else’s change.
Aliases and IP sets
Section titled “Aliases and IP sets”Aliases give a human-readable name to a CIDR range (e.g. trusted-lan
→ 10.0.0.0/8). Rules can reference aliases instead of raw IPs, so
redefining trusted-lan updates every rule that uses it in one place.
IP sets are named lists of CIDR members, each with an optional comment
and a nomatch flag (for exclusion rules). Rules reference IP sets the
same way they reference aliases.
Both aliases and IP sets are scoped: an alias defined at the cluster level is visible to every node and guest in that cluster. An alias defined at the guest level is only usable by that guest’s rules.
Firewall log
Section titled “Firewall log”Each scope has its own /log endpoint that returns recent firewall log
entries: which rule matched, the source and destination, the action taken,
and a timestamp. The log is a live read from Proxmox, never cached, so it
reflects the current state even if you just added a rule.
Security groups
Section titled “Security groups”A security group is a reusable set of rules. A guest firewall rule can
reference a security group instead of duplicating every rule inline.
This is the standard Proxmox model: define a group like allow-ssh once
at the cluster level, then every guest that needs SSH just references
that group rather than copying the same three rules into every guest’s
own rule list.