Proxmox Firewall Rules: Complete Guide

Overview of the Proxmox VE Firewall

Proxmox VE includes a built-in firewall that operates at three distinct levels: datacenter, node, and VM/container. This layered approach lets you define broad security policies at the top and apply granular rules to individual virtual machines. The firewall uses iptables (and nftables on newer versions) under the hood, but you manage it through a clean abstraction layer via the web GUI, CLI, or API.

Key advantages of the built-in Proxmox firewall over manually managing iptables:

• Rules follow VMs during live migration between cluster nodes.
• Centralized management through the datacenter level.
• Security groups and IP sets for reusable rule definitions.
• Built-in macros for common services (SSH, HTTP, DNS, etc.).
• Per-VM firewall that is independent of the guest OS.

Firewall Levels Explained

Datacenter Level

Datacenter-level rules apply to all nodes and all VMs in the cluster. This is where you define global policies, security groups, and IP sets. The configuration is stored in /etc/pve/firewall/cluster.fw and is replicated across all cluster nodes via pmxcfs.

Node Level

Node-level rules apply to traffic directed at the Proxmox host itself (not VM traffic). Use this to control access to the web GUI (port 8006), SSH (port 22), and other host services. The configuration lives at /etc/pve/nodes/<nodename>/host.fw.

VM/Container Level

VM-level rules control traffic to and from individual virtual machines or containers. Each VM can have its own firewall rules stored in /etc/pve/firewall/<vmid>.fw. This is the most granular level and where you will spend most of your time.

Enabling the Firewall

The Proxmox firewall is installed by default but not enabled. You must explicitly enable it at each level where you want it active. This is a safety measure to prevent accidental lockouts.

Before enabling the firewall, always create an ACCEPT rule for your management traffic (SSH and the web GUI on port 8006). Otherwise, you may lock yourself out of the Proxmox host.

Step 1: Enable at Datacenter Level

Go to Datacenter > Firewall > Options and set Firewall to Yes. You can also set the default input policy (recommended: DROP) and output policy (recommended: ACCEPT).

# Or via CLI - edit /etc/pve/firewall/cluster.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

Step 2: Enable at Node Level

Navigate to your node, then Firewall > Options, and enable it. Add rules to allow management access first:

# /etc/pve/nodes/pve1/host.fw
[OPTIONS]
enable: 1

[RULES]
IN ACCEPT -source 192.168.1.0/24 -p tcp -dport 8006 -log nolog -comment "Web GUI from LAN"
IN ACCEPT -source 192.168.1.0/24 -p tcp -dport 22 -log nolog -comment "SSH from LAN"

Step 3: Enable per VM

For each VM, go to Firewall > Options and enable it. Then add rules specific to that VM's role.

Firewall Rule Syntax

Each firewall rule consists of these components:

[DIRECTION] [ACTION] [OPTIONS]

# Examples:
IN ACCEPT -source 10.0.0.0/8 -p tcp -dport 443 -comment "HTTPS from internal"
IN DROP -p tcp -dport 3306 -comment "Block MySQL from outside"
OUT ACCEPT -p tcp -dport 53 -comment "Allow DNS queries"
OUT ACCEPT -p udp -dport 53 -comment "Allow DNS queries UDP"

Direction is IN or OUT (relative to the VM). Action is ACCEPT, DROP, or REJECT. Options include -source, -dest, -p (protocol), -dport (destination port), -sport (source port), and -comment.

Using Macros

Proxmox includes dozens of built-in macros that define well-known services. Instead of remembering port numbers, you can use macro names:

# Using macros instead of raw port numbers
IN ACCEPT -macro SSH -source 192.168.1.0/24 -comment "SSH access"
IN ACCEPT -macro HTTPS -comment "Allow HTTPS"
IN ACCEPT -macro HTTP -comment "Allow HTTP"
IN ACCEPT -macro Ping -comment "Allow ICMP ping"
IN ACCEPT -macro DNS -comment "Allow DNS"

To see all available macros, run:

pve-firewall macros

Security Groups

Security groups are reusable collections of firewall rules that you define once at the datacenter level and apply to multiple VMs. They are ideal for standard server roles.

# Define a security group in /etc/pve/firewall/cluster.fw
[group web-server]
IN ACCEPT -macro HTTP -comment "Allow HTTP"
IN ACCEPT -macro HTTPS -comment "Allow HTTPS"
IN ACCEPT -macro Ping -comment "Allow Ping"

Then apply it to a VM's firewall rules:

# In /etc/pve/firewall/101.fw
[RULES]
GROUP web-server

Now VM 101 inherits all rules from the web-server group. If you later add a rule to the group, it automatically applies to all VMs using it.

IP Sets

IP sets let you define named lists of IP addresses or CIDR ranges that you can reference in rules. This keeps your rules clean and makes updates easier.

# Define IP sets in /etc/pve/firewall/cluster.fw
[IPSET management]
192.168.1.10
192.168.1.11
10.0.0.0/24

[IPSET blocked]
203.0.113.0/24
198.51.100.50

Reference them in rules using the + prefix:

IN ACCEPT -source +management -p tcp -dport 22 -comment "SSH from management IPs"
IN DROP -source +blocked -comment "Block known bad actors"

Common Firewall Configurations

Web Server VM

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -macro HTTP -comment "HTTP"
IN ACCEPT -macro HTTPS -comment "HTTPS"
IN ACCEPT -macro SSH -source 192.168.1.0/24 -comment "SSH from LAN only"
IN ACCEPT -macro Ping -comment "Allow Ping"

Database Server VM

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -source 10.20.0.0/24 -p tcp -dport 3306 -comment "MySQL from app VLAN"
IN ACCEPT -source 10.20.0.0/24 -p tcp -dport 5432 -comment "PostgreSQL from app VLAN"
IN ACCEPT -macro SSH -source 192.168.1.0/24 -comment "SSH from management"

Firewall Logging

Logging helps you debug rules and monitor suspicious activity. You can enable logging per rule or set a default log level:

# Log dropped packets at the datacenter level
[OPTIONS]
log_level_in: nolog
log_level_out: nolog

# Log a specific rule
IN DROP -p tcp -dport 23 -log warning -comment "Log Telnet attempts"

Log levels include emerg, alert, crit, err, warning, notice, info, debug, and nolog. Firewall logs appear in /var/log/pve-firewall.log on the respective node.

Managing Firewall Rules Remotely

One advantage of the Proxmox firewall is that it can be managed entirely through the API, which means you are not limited to the web GUI. If you need to quickly check or adjust firewall rules while away from your computer, ProxmoxR provides a mobile interface for viewing and managing firewall rules on your VMs and nodes directly from your phone. This can be a lifesaver when you need to open a port or unblock an IP address during an after-hours incident.

Best Practices

• Start with a default DROP policy for inbound traffic. Only allow what is explicitly needed. This follows the principle of least privilege.
• Always secure management access first. Before enabling the firewall, ensure you have rules allowing SSH and web GUI access from your management network.
• Use security groups for consistency. Define standard rule sets for common server roles (web, database, mail) and apply them across VMs.
• Use IP sets for maintainability. Instead of hardcoding IPs in individual rules, use named IP sets so you can update addresses in one place.
• Test in a non-production VM first. Enable the firewall on a test VM and verify connectivity before rolling out to production.
• Keep output policy permissive initially. Setting the output policy to ACCEPT simplifies initial configuration. You can tighten it later for high-security environments.
• Document your rules with comments. Every rule should have a -comment explaining its purpose. Future you will be grateful.

Summary

The Proxmox VE firewall provides a powerful, layered security model that integrates directly with your virtualization platform. By using datacenter-level security groups and IP sets, node-level host protection, and VM-level granular rules, you can build a defense-in-depth strategy without relying on guest OS firewalls. Start with a restrictive inbound policy, use macros and security groups for clarity, and always test your rules before applying them to production workloads.