Proxmox Firewall: VM Isolation and Microsegmentation for Businesses

When running Proxmox VE, network security often means a perimeter firewall — an OPNsense or pfSense appliance controlling traffic between your internal network and the internet. But that alone is not enough. Once an attacker gains a foothold in your internal network or compromises a single VM, they can move laterally without any further obstacles, reaching other VMs on the same host. The Proxmox Firewall addresses this directly: it filters traffic at the hypervisor level, before packets ever reach a VM’s virtual network card.

Why VM-Level Isolation Matters

In an unsegmented virtual environment, all VMs on the same Proxmox host communicate freely over the internal bridge (e.g., vmbr0) — without any filtering. If a web server is compromised, an attacker can reach database servers, backup systems, and management interfaces directly. This attack pattern is called lateral movement and is the most common propagation method in ransomware attacks and targeted intrusions.

Microsegmentation solves this problem: each VM receives exactly the network access it needs to function — and nothing beyond that. The principle of least privilege applies not just to user accounts, but to network connections as well.

Proxmox Firewall Architecture

The Proxmox Firewall operates at three hierarchical levels:

Level	Scope	Configuration location
Datacenter	All nodes and VMs	Datacenter > Firewall
Node	Single Proxmox host	Node > Firewall
VM / Container	Individual virtual machine	VM > Firewall

Rules at a higher level automatically apply to all subordinate levels. The VM level can add its own rules on top, but cannot override those above. Technically, Proxmox implements the firewall using iptables (on nodes without nftables) or nftables — but the web interface and API abstract away all the complexity.

Enabling the Firewall

The firewall is disabled by default and must be explicitly activated — both at the datacenter level and for each VM individually.

Step 1: Enable the datacenter firewall

In the Proxmox web interface: Datacenter > Firewall > Options — check the Firewall box.

Step 2: Enable the VM firewall

For each VM under VM > Firewall > Options: enable Firewall. Important: without this step, VM-specific rules will have no effect.

Step 3: Enable filtering on the VM’s network interface

In the VM settings under Hardware > Network Device, the Firewall checkbox must also be ticked. Only then will packets be filtered on that virtual NIC.

Security Groups: Reusable Rule Sets

Security groups are named collections of rules that can be applied to multiple VMs. Instead of creating identical rules for every web server individually, you create a webserver group and assign it to all relevant VMs.

# Create a security group via CLI
pvesh create /cluster/firewall/groups --group webserver --comment "Rules for web servers"

# Add a rule to the group: allow inbound HTTP and HTTPS
pvesh create /cluster/firewall/groups/webserver \
  --action ACCEPT --type in --proto tcp --dport 80 --comment "HTTP inbound"

pvesh create /cluster/firewall/groups/webserver \
  --action ACCEPT --type in --proto tcp --dport 443 --comment "HTTPS inbound"

In the web interface, security groups are found under Datacenter > Firewall > Security Groups. Changes to a group take effect immediately on all assigned VMs — ideal for enforcing consistent security policies across an entire VM fleet.

Creating Inbound and Outbound Rules

Rules consist of several parameters:

• Direction: in (inbound to the VM) or out (outbound from the VM)
• Action: ACCEPT, DROP, or REJECT
• Protocol: tcp, udp, icmp, or any
• Source / Destination: IP address, CIDR block, or IP set
• Port: Single port or port range

Practical Example: Web Server VM

A typical web server needs only a handful of inbound connections — everything else should be blocked:

# Inbound rules for VM 101 (web server)
Direction  Action  Protocol  Port   Source          Comment
in         ACCEPT  tcp       80     0.0.0.0/0       HTTP from anywhere
in         ACCEPT  tcp       443    0.0.0.0/0       HTTPS from anywhere
in         ACCEPT  tcp       22     10.0.0.0/8      SSH from mgmt network only
in         DROP    tcp       -      0.0.0.0/0       Drop everything else

# Outbound rules
out        ACCEPT  tcp       443    0.0.0.0/0       HTTPS outbound (updates etc.)
out        ACCEPT  udp       53     10.0.1.1        DNS to internal resolver
out        DROP    -         -      0.0.0.0/0       Block everything else

With these rules, the VM is isolated: it accepts only web traffic and legitimate admin connections, but cannot initiate connections to other internal systems — even if an attacker takes control of the VM.

IP Sets: Managing Groups of Addresses

IP sets let you name groups of addresses and reference them in rules as source or destination. This simplifies rule management significantly:

# Create an IP set for management addresses
pvesh create /cluster/firewall/ipset --name management --comment "Admin workstations"

# Add addresses to the IP set
pvesh create /cluster/firewall/ipset/management --cidr 10.0.0.10
pvesh create /cluster/firewall/ipset/management --cidr 10.0.0.11
pvesh create /cluster/firewall/ipset/management --cidr 10.0.0.12

In rules, the IP set is referenced as +management. When your admin team changes, a single update to the IP set is all it takes — every rule referencing it automatically uses the updated list.

Proxmox creates two predefined IP sets: +cluster_nodes (all Proxmox node IPs) and +management (user-configurable). These are directly usable in node-level firewall rules.

Macros for Common Services

Proxmox Firewall includes predefined macros for common protocols and services. Instead of entering protocol and port manually, you simply select the macro:

Macro	Equivalent
SSH	TCP Port 22
HTTP	TCP Port 80
HTTPS	TCP Port 443
DNS	UDP/TCP Port 53
SMTPS	TCP Port 465
Ping	ICMP Echo
NTP	UDP Port 123

Macros significantly improve the readability of your firewall configuration and reduce the risk of typos when entering port numbers.

Default Policies: ACCEPT vs. DROP

The default policy determines what happens to packets that do not match any explicit rule. There are two approaches:

Whitelist approach (recommended for production): Set the default policy to DROP, allow only explicitly permitted traffic. More secure, but requires more effort during initial setup.

Blacklist approach: Leave the default policy as ACCEPT, explicitly block undesired traffic. Easier to get started, but every forgotten service remains open.

For production VMs, we consistently recommend the whitelist approach. The default policy is set per VM under Firewall > Options — separately for inbound (Input Policy) and outbound (Output Policy) traffic.

Protecting the Proxmox Management Interface

The Proxmox web interface (port 8006) and the SSH access of nodes should never be reachable from the internet. At the node level, access can be restricted to defined source IPs:

# Allow access to port 8006 only from the management network
pvesh create /nodes/proxmox01/firewall/rules \
  --action ACCEPT --type in --proto tcp --dport 8006 \
  --source "+management" --comment "Proxmox WebUI"

# SSH from management network only
pvesh create /nodes/proxmox01/firewall/rules \
  --action ACCEPT --macro SSH --type in \
  --source "+management" --comment "SSH admin"

# Drop everything else
pvesh create /nodes/proxmox01/firewall/rules \
  --action DROP --type in --comment "Default DROP"

Microsegmentation with Security Groups

Microsegmentation means that VMs in different security zones cannot communicate with each other — even if they run on the same host. Typical zones:

• DMZ: Web servers, reverse proxies — publicly reachable
• App: Application servers — reachable only from the DMZ
• DB: Database servers — reachable only from the App zone
• Mgmt: Monitoring, backup — read access from all zones

For each zone, create a security group with matching rules. A database server with the db-server group, for example, allows only TCP/5432 (PostgreSQL) from the app subnet and blocks everything else — whether the attacker comes from outside or from a compromised app VM.

Enabling Firewall Logging

For audit purposes and troubleshooting, logging can be activated per rule. Every matched packet is then written to /var/log/pve-firewall.log:

# Create a rule with logging enabled
pvesh create /nodes/proxmox01/firewall/rules \
  --action DROP --type in --log warning --comment "DROP with logging"

The log contains timestamps, source and destination IPs, protocol, port, and the rule description. For centralized analysis, logs can be forwarded to a SIEM via rsyslog.

Proxmox Firewall vs. OPNsense vs. iptables/nftables

Feature	Proxmox Firewall	OPNsense	iptables/nftables
Integration	Native in Proxmox VE	Separate appliance/VM	Manual on node
Management	Web interface + API	Web interface + API	CLI / scripts
Granularity	Per VM	Subnet level	Arbitrary
Microsegmentation	Yes (per VM)	Limited	Yes (complex)
Stateful inspection	Yes	Yes	Yes
IDS/IPS	No	Yes (Suricata)	No
Effort	Low	Medium	High

The Proxmox Firewall and OPNsense are not mutually exclusive — they complement each other perfectly: OPNsense controls north-south traffic (internal ↔ internet), while the Proxmox Firewall handles east-west traffic (VM ↔ VM). Configuring iptables/nftables directly on the node is possible but error-prone, and may be overwritten by Proxmox updates.

DATAZONE Control: Firewall Monitoring Across All Hosts

With multiple Proxmox nodes and dozens of VMs, it quickly becomes difficult to track which firewall rules are active and whether the configuration is consistent. DATAZONE Control provides centralized monitoring of your entire Proxmox environment: rule discrepancies between nodes, unexpectedly open ports, and suspicious connection attempts all become visible in the dashboard and trigger automatic alerts. Firewall changes are also recorded in the audit log — traceable and audit-proof.

Frequently Asked Questions

Does the Proxmox Firewall slow down VM performance?

The overhead is minimal. Since the firewall operates at the kernel level, throughput is barely affected even with hundreds of rules. In benchmark tests, the impact is typically below 1–2%.

Can I manage firewall rules with Ansible or Terraform?

Yes. The Proxmox API is fully documented, and there are Terraform providers and Ansible modules that manage firewall configurations as code. This makes versioning and rollouts straightforward.

What happens if I accidentally lock myself out?

A misconfigured node-level firewall rule can lock you out of the Proxmox web interface. In that case, only direct console access (physical or IPMI) will help. Always test node firewall rules in a test environment first, or include a temporary ACCEPT rule for your current IP before applying restrictive policies.

---

Want to secure your Proxmox environment with firewall segmentation and microsegmentation? Get in touch — we analyze your network topology and implement a comprehensive security concept for your virtual infrastructure.