Firewalls
A firewall is a named set of rules that you attach to servers and to Kubernetes clusters. Attaching to a cluster applies the rules to that cluster’s nodes; there is no second security model to learn.
What runs underneath
Section titled “What runs underneath”Rules are written directly onto each virtual machine using the Proxmox firewall, which enforces them at the hypervisor — outside the guest, where a compromised machine cannot disable them.
They are not written as cluster-wide security groups. That was the original design and it was changed deliberately: creating a cluster security group requires a Proxmox privilege that widens the platform’s API token beyond “manage virtual machines, do not change the system”. The feature was redesigned so the token could stay narrow. The user-visible model did not change. This trade — redesign the feature rather than widen the privilege — is the same one applied throughout; see Credentials and secrets.
Every rule carries the firewall’s name in its comment, so an operator looking at a VM in the Proxmox UI can see which panel firewall produced it.
The scoping rule
Section titled “The scoping rule”This is the part that surprises people, and it is deliberate.
If the server has a public interface, rules apply only to that interface. The private interfaces are left open.
If the server has no public interface, rules apply to all of its interfaces.
The reasoning: an internet-facing policy such as “allow only 443” should not silently cut a database server off from the application servers that are its whole purpose. Private neighbours keep talking. When you do want to restrict private traffic — “only 5432, and only from the application subnet” — you express that on a machine with no public interface, where the rules apply everywhere.
Each rule has a direction, a protocol, a port or port range, one or more source addresses in CIDR notation, an action, and a description. A rule with several sources is written as one line per source at the hypervisor, because Proxmox takes a single source per rule; you do not have to think about that.
The default posture for inbound traffic is deny. A firewall with no matching rule drops the packet.
Attaching
Section titled “Attaching”Ağ → Güvenlik Duvarları (Network → Firewalls). Create a firewall, add rules, attach it to servers or clusters. A server may have more than one firewall attached; the rules are the union.
Changes are a job like everything else: the panel writes the full desired rule set rather than diffing, so the outcome does not depend on the order in which you edited things.
Recommended starting point
Section titled “Recommended starting point”For a public web server:
| Direction | Protocol | Port | Source | Action |
|---|---|---|---|---|
| in | tcp | 22 | your office/VPN CIDR | accept |
| in | tcp | 80 | 0.0.0.0/0 | accept |
| in | tcp | 443 | 0.0.0.0/0 | accept |
Do not open 22 to 0.0.0.0/0. If you want administrative access without exposing it at
all, use a Zero Trust gateway and give the machine no public
address.
Limits
Section titled “Limits”- IPv4 only.
- Inbound and outbound rules only; no connection tracking policy, no rate limiting, no layer-7 inspection. Those belong at the edge device or in front of the application.
- Rules written by an operator directly in Proxmox that are unrelated to the panel are left alone, but a panel-managed rule that is edited by hand is overwritten on the next apply. Intent wins.