Proxmox Ports: Which Ones to Open, and for What

The short version:

• A human needs exactly one port: 8006. Everything else on this page is machine talking to machine.
• The console ports are not optional. The web GUI serves noVNC over 5900-5999 and SPICE through 3128; block them and the GUI loads but every console window hangs.
• Corosync uses UDP 5405-5412, not the 5404/5405 pair older guides still list, and it is the one service where a firewall mistake takes the cluster down rather than one guest.
• Nothing here belongs on the public internet. Not 8006, not 22, and certainly not corosync.
• Guest ports are a separate problem. Your web server’s port 443 is filtered at the guest firewall level, not by the host list below.

The full list

These are the ports Proxmox VE itself listens on, as documented in the firewall chapter of the administration guide:

Port	Protocol	Service	Who needs to reach it
8006	TCP	Web interface, HTTP/1.1 over TLS	Admin workstations only
5900-5999	TCP	VNC web console (WebSocket)	Admin workstations only
3128	TCP	SPICE proxy	Admin workstations running a SPICE client
22	TCP	sshd, also used for cluster actions	Admins, and every other node in the cluster
111	UDP	rpcbind	Nothing, on most installs
25	TCP	sendmail, outgoing	Outbound only, to your mail relay
5405-5412	UDP	Corosync cluster traffic	Every other node in the cluster, and nothing else
60000-60050	TCP	Live migration: guest memory and local-disk data	Every other node in the cluster

Add these if you run the matching service:

Port	Protocol	Service
8007	TCP	Proxmox Backup Server web interface and API
3300	TCP	Ceph monitor, messenger v2
6789	TCP	Ceph monitor, messenger v1 (legacy)
6800-7568	TCP	Ceph OSD, MDS and manager daemons

Port by port, and what breaks without it

8006, the web interface. pveproxy terminates TLS here and it is the only port a person genuinely interacts with. It is also the first thing an internet-wide scanner fingerprints a Proxmox host by, which is the argument for reaching it over a VPN rather than a port forward. If you want it behind a reverse proxy, remember that the console uses WebSockets on other ports, so proxying 8006 alone gives you a GUI with dead console buttons.

5900-5999, the noVNC console. Each console session is allocated a port in this range and torn down afterwards. Because the allocation is dynamic, a single-port rule is useless; the range has to be open from the admin network to the node. It is the usual cause of “the GUI works but the console spins forever” after someone enables the firewall, and it is worth checking before you go looking for certificate problems.

3128, the SPICE proxy. Only relevant if you use SPICE rather than noVNC, which mostly means desktop guests with a local virt-viewer. Safe to leave closed if nobody uses it.

22, sshd. Beyond shell access, Proxmox uses SSH between nodes for cluster join, for some migration modes, and for tunnelled operations. Blocking it between cluster members breaks pvecm add and more besides. Blocking it from the internet is simply correct.

111 (UDP), rpcbind. Present because of the NFS client stack. Nothing outside the host normally needs it, and on a node that mounts no NFS storage it is a candidate for closing outright.

25, sendmail. Outbound only, for the notification mail that tells you a backup failed or an HA service moved. It only matters as an egress rule, and it is worth having: a Proxmox host that cannot email you is a Proxmox host whose failures you find out about late.

5405-5412 (UDP), corosync. This is the range to get right. Corosync 3 with the kronosnet transport uses this range rather than the two-port arrangement older guides describe, and each configured link consumes a port from it. Corosync is also latency-sensitive rather than bandwidth-hungry, which is why the Proxmox cluster setup guide argues for a dedicated link and why sharing the corosync path with backup traffic causes quorum flapping that looks like a network fault. A firewall rule that silently drops these packets does not produce an error message; it produces a node that fences itself.

60000-60050 (TCP), live migration. Guest memory pages and, for local-disk migrations, disk contents cross on this range. It only needs to be open between cluster nodes. If migrations fail at “starting VM … on remote node” with no obvious cause, this range is the first thing to check. It matters a great deal to Proxmox high availability, because HA relocation depends on the same path.

8007, Proxmox Backup Server. PBS runs its own web interface and API on 8007 over HTTPS. Backup traffic from a Proxmox VE node to a PBS datastore goes to this port, so it needs to be reachable from every node you back up, and from your workstation if you want the PBS GUI. Setup and datastore layout are in the Proxmox Backup Server guide.

Ceph, 3300 / 6789 / 6800-7568. Monitors listen on 3300 for the v2 messenger protocol and 6789 for legacy v1. OSD, MDS and manager daemons bind dynamically inside the 6800-7568 range, with each OSD potentially using several ports, so Ceph’s own documentation recommends opening the whole range on the storage network rather than trying to pin individual daemons. This traffic should never be on the same network as anything else; the reasoning is in Proxmox Ceph vs ZFS replication.

Turning the list into firewall rules

Proxmox has three firewall levels that all have to agree before a rule takes effect, which is the single most common reason people conclude their rules “do nothing”. The mechanics are in Proxmox firewall setup: datacenter, node and VM rules; the port-specific part is short.

A workable shape for a homelab or a small production cluster:

• Define a management IPSet at datacenter level holding your admin subnet or jump host, and allow 8006, 5900-5999, 3128 and 22 from it to the nodes. Everything else on those ports gets dropped by policy.
• Define a cluster IPSet holding every node address on the corosync network, and allow UDP 5405-5412 and TCP 60000-60050 between them. Do not include this range in any rule sourced from a client network.
• Leave guest firewalls off except on guests that are actually exposed. Host rules and guest rules are separate objects; a rule at datacenter level does not filter traffic to a VM’s own service ports.
• Put Ceph and PBS on their own rules, sourced from the storage network only.
• Allow outbound 25 to your relay, and outbound 443 for the repositories.

Note the direction trap: the host firewall’s inbound chain (pvefw-host-in) is evaluated for traffic to the node itself, and guest traffic is filtered at the guest’s interface instead. Rules written at node level do not protect a VM, and rules written on a VM do not protect the API on 8006.

Verifying what is actually listening

Before writing rules, look at reality on the node:

ss -tulnp | sort -k5

That prints every listening socket with the owning process. On a fresh node you should see pveproxy on 8006, pvedaemon bound to localhost on 85, sshd on 22, rpcbind on 111, and corosync’s UDP sockets once the node has joined a cluster. Anything else listening on a public interface deserves an explanation. pvedaemon binding only to 127.0.0.1 is the expected and correct behaviour: it is the privileged API service, and pveproxy is what proxies authenticated requests to it.

To confirm a rule is doing what you think from outside, nc -zv <node> 8006 from an allowed host and from a disallowed one is faster than reading rule dumps.

What to expose to the internet

Nothing on this page. The honest recommendation for every one of these ports is a VPN or a WireGuard tunnel terminating on your network boundary, with the Proxmox management ports reachable only from inside it. A Proxmox host with 8006 forwarded is a credential-stuffing target with a full hypervisor behind it, and enabling two-factor authentication reduces but does not remove that exposure. If the boundary itself is what you are building, pfSenseLab covers that side.

Next steps

• Get the rules right before you get the ports right: Proxmox firewall setup.
• The interfaces those rules reference: Proxmox network bridges and VLANs.
• Why corosync wants its own link: Proxmox cluster setup: Corosync, quorum and QDevice.
• When a node stops answering on any port at all: common Proxmox problems and how to fix them.
• Building the whole stack in a sane order: the Proxmox VE homelab roadmap.

Related across the network

• Cloudflare Tunnel Setup: Your First Tunnel Step by Step — cloudflarezerotrust.org
• Cloudflare Tunnel Not Connected: Fixing Error 1033 — cloudflarezerotrust.org