Network Security

Enterprise Feature

Network Security is available exclusively with an Enterprise license. The required feature flag is microsegmentation.

The Network Security page provides centralized firewall rule management for your entire Proxmox infrastructure. It covers firewall rules at every level -- VM, host, and cluster -- along with security groups, IP sets, aliases, and network microsegmentation for granular traffic control.

Overview

Proxmox VE includes a built-in firewall based on iptables/nftables, but managing rules across dozens of VMs and multiple nodes through individual Proxmox web interfaces is tedious and error-prone. ProxCenter aggregates all firewall configuration into a single view, letting you define, audit, and enforce network security policies across your entire infrastructure from one place.

Interface Tabs

The Network Security page is organized into nine tabs: Overview, Micro-segmentation, Security Groups, Aliases, IP Sets, VM Rules, Host Rules, Cluster Rules, and Settings.

Overview

The Overview tab provides a dashboard-level summary of your network security posture:

• Security Groups count with total rule count
• IP Sets count with total entry count
• Aliases count
• Cluster firewall status -- whether the cluster-level firewall is active or inactive

Below the stats, a detailed overview shows:

• Per-VM firewall status at a glance, including which VMs have firewalls enabled and how many rules are applied
• Top security groups by rule count
• Quick navigation links to other tabs

tip

Use the Overview tab as a daily check to verify that your firewall policies are applied consistently across all VMs. Click any stat card to jump directly to the relevant tab.

Micro-segmentation

Microsegmentation enables fine-grained network traffic control between individual VMs, regardless of which node they run on. Instead of relying solely on broad network-level rules, microsegmentation lets you define policies such as:

• Allow database VMs to communicate only with application VMs on specific ports
• Isolate development workloads from production entirely
• Restrict management traffic to a designated set of admin VMs

This tab provides a visual interface to define and manage microsegmentation policies, giving you zero-trust networking within your Proxmox clusters.

Security Groups

Security groups are reusable collections of firewall rules. Define a group once (e.g., "Web Servers" with rules allowing ports 80 and 443) and apply it to any number of VMs -- changes to the group automatically propagate to all associated VMs.

For each security group, you can:

• View and edit the rules it contains
• See which VMs reference the group, and attach or detach guests directly
• Add new rules with full control over direction (IN/OUT), action (ACCEPT, DROP, REJECT), protocol, source, destination, port, and log level

Attaching a group to guests. Each group row carries a chip with the number of guests that reference it, and a link button next to it. Both open the group's members dialog, where you can:

• Attach the group to one or several guests in a single step, picking them from a searchable list
• Detach it from a guest that currently references it

Attaching a group is not a separate object: ProxCenter inserts a rule of type group into the guest's own firewall rule list, exactly as the Proxmox interface does. That is also why the same operation is available one guest at a time from the guest's Firewall tab, and why the resulting entry can be reordered, disabled, or removed from either place.

If an attach fails on one guest of a batch, the ones that succeeded are kept and ProxCenter names the ones that did not, so you can retry only those.

info

Membership is derived, not stored. ProxCenter reads the rule list of each guest of the selected connection to find out which groups it references, which has two consequences: the count only covers guests you are allowed to see, and it is capped at 200 non-template guests per connection. When the scan is truncated, the dialog and the chip tooltip say so instead of reporting a smaller number as final.

A group can also be referenced by datacenter-level and node-level rules. The group row shows those references separately from the guest count, so a group that looks unused by guests is not mistaken for an unused group.

tip

Node-level references are only counted once the Host Rules tab has been loaded in the current session, because that is where node rules are read from. Open Host Rules first if you are auditing a group before deleting it.

Aliases

Aliases let you assign human-readable names to IP addresses or CIDR ranges. Instead of remembering that 10.0.5.20 is your monitoring server, create an alias called monitoring and reference it in your firewall rules.

• Create, edit, and delete aliases
• Use aliases in any firewall rule source or destination field
• Share aliases across the entire cluster

IP Sets

IP sets are named collections of IP addresses or CIDR ranges. They are useful when a firewall rule needs to reference multiple IPs -- for example, allowing access from a list of trusted management workstations.

For each IP set, you can:

• Add and remove IP entries
• Reference the IP set in firewall rules using the +ipsetname syntax
• Manage entries across clusters

tip

Combine aliases for single hosts and IP sets for groups of hosts to keep your firewall rules clean and readable.

VM Rules

The VM Rules tab shows firewall rules applied at the individual VM level. Select a connection to view all VMs with their firewall status and rule counts.

For each VM, you can:

• View the list of applied rules
• Toggle the VM-level firewall on or off
• See which security groups are referenced

Host Rules

The Host Rules tab manages firewall rules applied at the Proxmox host (node) level. These rules control traffic to and from the hypervisor itself -- for example, restricting SSH access or Proxmox web interface access to specific management networks.

Select a connection and node to view and manage host-level rules.

Cluster Rules

Cluster-level firewall rules apply across all nodes and VMs in a Proxmox cluster. The Cluster Rules tab lets you:

• View and edit cluster-wide firewall rules
• Toggle the cluster firewall on or off
• Set the default input/output policy (ACCEPT or DROP)

warning

Disabling the cluster firewall or changing the default policy to DROP without proper rules in place can lock you out of your Proxmox nodes. Always ensure management access rules are in place before making changes.

Settings

The Settings tab provides global firewall configuration options for the selected Proxmox connection, including:

• Cluster-level firewall enable/disable
• Default input and output policies
• Log rate limiting
• Additional firewall options exposed by the Proxmox API

Rule Log Level

Every firewall rule can carry a Proxmox log level, which decides whether a match is written to the firewall log and with which severity. ProxCenter exposes the nine values Proxmox accepts:

Value	Meaning
nolog	The rule does not log. This is the Proxmox default, and the value ProxCenter pre-selects on a new rule
emerg, alert, crit, err	Syslog severities for conditions worth alerting on
warning, notice, info, debug	Progressively more verbose severities

The level is set from a Log level select in the add and edit rule dialogs at every scope: datacenter, node, guest, and security group rules. It also appears as a Log column in the rules tables, where a rule that does not log is rendered as a dash.

info

This per-rule level is not the same setting as the log_level_in and log_level_out options found in a datacenter's, a node's, or a guest's firewall options. Those govern the traffic handled by the default policy, while the per-rule level applies only to matches of that one rule.

warning

There is no inherit state for a rule's log level. A rule created outside ProxCenter without one is displayed as nolog, and saving it from a ProxCenter dialog writes nolog explicitly. The filtering behaviour is identical, but the rule is rewritten.

Firewall Data Without the Orchestrator

ProxCenter normally reads and writes firewall configuration through the orchestrator. When no orchestrator is reachable it falls back to the Proxmox API directly, using the connection's stored credentials, so the firewall views are populated instead of empty. This is what an installation running the interface without the orchestrator service relies on.

The fallback covers writes as well as reads:

Object	Available without an orchestrator
Datacenter, node, and guest rules	Read, create, edit, reorder, enable, disable, delete
Datacenter, node, and guest firewall options	Read and update
Security groups and their rules	Read, create, delete, and attach or detach on a guest
Aliases and IP sets	Read, create, update, delete
A guest's firewall log	Read
A guest's per-interface firewall toggle	Update
Micro-segmentation	Not available, it stays orchestrator-only

info

The fallback triggers when the orchestrator refuses the connection or cannot be resolved, which is what a stopped orchestrator looks like on the network. An orchestrator that answers with an error, or that hangs until the request times out, is treated as a failure rather than as an absence, and the error is reported instead of being silently worked around.

info

The per-object Firewall tabs on a datacenter, a node, and a guest are available in every edition, and they are the views this fallback keeps usable. The Network Security page described on this page, micro-segmentation included, still requires an Enterprise licence with the microsegmentation feature.

Tenant VLAN Segmentation

On a multi-tenant install, a vDC tenant can be given VLAN pools: ranges of VLAN IDs, on named bridges, that the tenant may build its own networks in. The pools are declared by the provider in Settings > Virtual Datacenters and are the whole of what the tenant may reach on layer 2. The operator workflow is described in Virtual Datacenters; this section covers the enforcement side. (Enterprise)

Two independent checks

A VLAN tag can enter the cluster through two doors, and both are guarded:

1. Creating a network. A tenant asking for a VLAN network on a bridge must have a pool on that bridge. A tag it types must fall inside one of the vDC's ranges for that bridge, and must not already be carried on that bridge, whether by another vDC's network or by a zone the provider built directly in Proxmox. Leaving the field empty makes ProxCenter pick the lowest free tag in the ranges.
2. Writing a guest NIC. The netN string a tenant submits is parsed rather than trusted. The bridge must be one the vDC holds, and any tag= or trunks= value must fall inside the vDC's pools for that bridge.

The NIC check runs on every path that writes a guest network config: creating a VM or a container, editing a guest config, cloning a guest, and deploying from the templates wizard.

What is refused

Attempt	Result
A bridge the vDC does not hold	Refused, with the list of bridges the vDC does hold
tag= or trunks= outside the vDC's pools	Refused, naming the tag and the bridge
A tag on an SDN VNet	Refused. A VNet already carries its own tag; adding one would put the guest somewhere else
A repeated tag= or trunks= key in one config string	Refused outright, so a foreign value cannot ride in behind a legitimate one
A trunks= list expanding beyond 4094 ids	Refused as a whole, rather than expanded
A VLAN network on a bridge with no pool for this vDC	Refused

info

A VLAN pool only widens a bridge the vDC already receives as a shared bridge. It never opens a bridge on its own, so a leftover pool row cannot hand a tenant an unrelated uplink.

The shared zone backstop

All VLAN networks of a cluster share one provider-owned SDN zone per bridge, created automatically on first use and never deleted. That is deliberate: Proxmox enforces tag uniqueness inside a zone but not across zones, so keeping every tenant VLAN in the same per-bridge zone makes Proxmox itself the last line of defence. Two vDCs racing for the same tag end in a Proxmox error, not in a shared broadcast domain.

VXLAN VNIs are allocated from 10000 upward, cluster-wide, so a VLAN tag can never collide with a VNI on the same cluster.

Per-network firewall

A tenant network carries its own firewall flag, set from the create dialog and shown as a chip in the Virtual Networks table. Rules on a VNet are managed like any other Proxmox firewall object and are covered by the same fallback described above when no orchestrator is reachable.

Multi-Connection Support

If you have multiple Proxmox clusters connected to ProxCenter, a connection selector at the top of the page lets you switch between them. All tabs (security groups, aliases, IP sets, rules) reflect the currently selected connection.

Permissions

Permission	Description
admin.settings	Required to access Network Security and manage firewall rules

Users without the admin.settings permission will not see the Network Security entry in the navigation sidebar.