Proxmox Firewall Basics for a Home Server

Quick answer

Proxmox can apply firewall policy at three main scopes:

Datacenter
   |
Node
   |
VM or LXC

A guest network device can also have its Proxmox firewall processing enabled.

Before enabling restrictive policy, add and verify the management allow rules you need. Keep local-console access available. A broad deny policy applied before a valid allow rule can lock you out of the web interface and SSH.

Start with Proxmox Linux Bridge Explained and What Is Proxmox VE?.

What the Proxmox firewall protects

The firewall can control traffic to:

• the Proxmox host
• the web management interface
• SSH
• cluster and migration services
• individual VMs
• individual LXC containers
• guest network interfaces

It does not replace:

• router perimeter rules
• Tailscale access policy
• guest operating-system firewalls
• application authentication
• updates and account security
• independent backups

Use defence in depth, but document which layer owns each rule.

Understand the scopes

Datacenter

Datacenter settings establish cluster-wide policy, aliases, IP sets and rules.

A mistake here can affect more than one node or guest.

Node

Node rules protect services on one Proxmox host.

This is where access to the management address must be planned carefully.

VM or LXC

Guest rules control traffic associated with one guest.

They are useful when one service should accept only specific sources or ports.

Guest network-device firewall flag

A VM or container network device has a firewall option. Confirm that the intended firewall path is active; creating rules while the relevant firewall processing is disabled does not provide the expected protection.

Build an access inventory first

Record:

Service	Destination	Port	Approved sources
Proxmox web interface	Node	TCP 8006	Admin LAN or tailnet devices
SSH	Node	TCP 22 unless changed	Admin devices only
DNS service	Guest	TCP/UDP 53	Intended clients
Web application	Guest	Application port	Intended LAN or tailnet
Backup traffic	Node or guest	Backend-specific	Backup system

These are examples. Do not enable unused services merely because they appear in a table.

For clusters, migration, Ceph or other advanced services, use current Proxmox documentation and a design specific to that environment.

Safe enablement sequence

1. Confirm local-console access.
2. Record the current LAN, management IP and remote-access path.
3. Export or copy existing firewall configuration.
4. Create reusable aliases or IP sets for trusted admin sources.
5. Add explicit allow rules for the web interface and any required SSH access.
6. Enable logging for the test rules at a sensible rate.
7. Enable firewall processing at the narrowest intended scope.
8. Test from an allowed device.
9. Test from a source that should be denied.
10. Reboot only after access is proven.
11. Verify guests and backups after reboot.

Do not start with a blanket deny while connected only through the interface being protected.

Example rule planning

A home server might allow TCP 8006 only from:

• a trusted management VLAN
• one admin workstation
• an approved Tailscale address or group

It might deny management access from:

• ordinary guest Wi-Fi
• IoT devices
• untrusted VLANs
• the public internet

Write policy around roles, not temporary IP addresses, where the platform supports stable aliases or IP sets.

The exact rule editor and available macros can change between Proxmox versions. Check the effective options in the Proxmox VE 9 interface and current documentation.

Proxmox firewall versus guest firewall

Suppose an Ubuntu VM hosts a web service.

Traffic may be checked by:

1. Proxmox Datacenter policy
2. Proxmox guest policy
3. Ubuntu UFW or nftables
4. Docker rules
5. the application’s own access controls

When access fails, inspect every active layer.

Inside Ubuntu:

sudo ufw status verbose
sudo nft list ruleset
ss -lntup

Do not assume the Proxmox firewall is responsible merely because its rules are visible.

Protect the management interface

Good home-server practice includes:

• never forward public router traffic directly to TCP 8006
• limit management access to trusted LAN or tailnet sources
• use individual accounts
• enable two-factor authentication
• remove stale tokens and users
• keep Proxmox updated
• review failed logins
• use Tailscale or another authenticated private-access method remotely
• retain a local-console recovery path

Use How to Access Proxmox Remotely with Tailscale for the private remote path.

Avoid common lockouts

Allow rule is at the wrong scope

A rule on one VM does not allow node management traffic.

Source address is wrong

A connection passing through NAT, a subnet router or another VLAN may not arrive from the address you expect.

Record the actual source before narrowing the rule.

IPv6 remains unplanned

Allowing IPv4 while forgetting IPv6 can cause unexpected access or confusing failures. Decide whether IPv6 is used and protect both protocols accordingly.

Rule order changes the result

A broad earlier rule may match before a later specific rule. Review ordering and effective policy.

SSH works but the web interface does not

TCP 22 and TCP 8006 are separate services and rules.

Tailscale policy and Proxmox policy disagree

Both layers must permit the intended path.

Logging without filling the disk

Firewall logs are useful for proving why traffic was accepted or denied.

However, logging every packet on a noisy rule can consume space quickly.

Use:

• targeted logging
• sensible log levels
• rate limits where available
• short observation windows
• routine storage monitoring

If storage pressure occurs, use Proxmox Disk Full: Find What Is Using the Space.

Check status and evidence

Use the Proxmox interface for rule status, logs and effective scope.

Useful host checks include:

systemctl status pve-firewall --no-pager
journalctl -b -u pve-firewall --no-pager
pve-firewall status
ss -lntup

Proxmox VE versions may offer different firewall back ends and service names. Treat the web interface and current official documentation as authoritative for the selected back end.

Record:

• Proxmox version
• enabled firewall back end
• datacenter, node and guest options
• policy defaults
• aliases and IP sets
• rule order
• test source and destination
• accepted and denied results

Emergency recovery

If remote access is lost:

1. Stop changing rules remotely.
2. Use the local console.
3. Confirm the host IP and bridge first.
4. Inspect firewall status and recent logs.
5. Identify the rule or policy change that caused the lockout.
6. Revert that specific change.
7. Restore access from the trusted source.
8. Re-enable protection only after the allow path is proven.

Do not permanently disable all firewall protection as the final fix. Correct the rule design and retest.

Verification checklist

• Local-console access is available.
• Required services and sources are inventoried.
• TCP 8006 is not exposed publicly.
• Management allow rules exist before restrictive policy.
• Rule scopes and order are understood.
• IPv4 and IPv6 have both been considered.
• Guest firewall layers are documented.
• Allowed access succeeds.
• Unapproved access is denied.
• Logs show the expected decision.
• Access survives a controlled reboot.
• Recovery instructions are stored offline.

This guide provides a safe method; it does not claim that SmallGrid has tested the example firewall policy.

Phase 3 is now complete. Continue with Run Docker in a Proxmox VM or LXC?, the first guide in the practical Proxmox project phase.

Official reference: Proxmox VE Firewall.