Proxmox SDN Firewall Audit for VE 9.2 Network Zones

Enabling SDN zones in Proxmox VE 9.2 reshapes your network topology in ways that silently invalidate firewall rules you wrote months ago. After you bring up VLAN or VXLAN zones, traffic between SDN-managed interfaces and legacy Linux bridges can flow unfiltered unless you explicitly close the gaps. This audit walks you through identifying those paths, writing the rules that block them, and verifying the result on a two-node homelab cluster.

Key Takeaways

Audit scope: SDN zones create new interface names (like pve-<zone>-<ifname>) that your existing bridge-level firewall rules do not cover. Default-deny first: Apply a default-deny ingress rule on every SDN-managed interface before adding allows, or you will open ports you never intended to. VTEP isolation: VXLAN control-plane traffic (UDP 4789) must be scoped to the management subnet only; leaving it open on the production bridge is the most common homelab leak. Verification is mandatory: pvesh get /vm/<vmid>/firewall confirms what the API sees, but you must also run live traffic tests between zones to catch rules that look correct but don't match the actual interface.

Why SDN Changes Your Firewall Picture

Before SDN, your firewall rules referenced vmbr0, vmbr1, and any custom bridges you created by hand. Those rules still work. But the moment you enable an SDN zone, Proxmox creates a new set of kernel interfaces and, in the case of VXLAN, a VTEP endpoint on the host. The datacenter firewall in /etc/pve/firewall/datacenter-firewall.conf does not automatically generate rules for these new interfaces.

In a typical homelab, you might have vmbr0 for management, vmbr1 for production, and then you spin up a VLAN zone called prod-vlans and a VXLAN zone called lab-overlay. A VM in the lab overlay can still reach vmbr0 if it also has a legacy interface attached, or if the host's default route sends return traffic through the management bridge. The SDN zone gives you logical segmentation, but the kernel bridge still mediates all traffic on that host.

If you completed the network audit we covered in Proxmox VE 9.1 Network Audit Checklist Before New VMs before you enabled SDN, you have a baseline. That baseline is now incomplete. You need to re-run the interface inventory and extend your firewall rules to cover the new SDN interfaces.

How to Identify Cross-Tenant Paths

Start by mapping every interface on each node and noting which one belongs to which zone.

pvesh get /network/zone --output-format json

This returns every zone. For each zone, list its interfaces:

pvesh get /network/zone/prod-vlans --output-format json
pvesh get /network/zone/lab-overlay --output-format json

Now check what the kernel actually created:

ip -br link show type bridge
ip -br link show | grep pve-

On a node with both a VLAN zone and a VXLAN zone active, you will see entries like pve-prod-vlans-100 and pve-lab-overlay-0. These are the interfaces that your firewall must reference.

The cross-tenant risk is specific: a VM that has an interface in lab-overlay and a second interface on vmbr0 (management) can route between the two. Even without a dual-homed VM, the host itself participates in both the management bridge and the VXLAN VTEP. If the node firewall allows all traffic on vmbr0, the VTEP's UDP 4789 packets are also allowed in and out, which means any host on the management network can inject VXLAN frames.

Document your tenants explicitly. In a homelab, a reasonable split looks like this:

Tenant	Zone / Bridge	Purpose	Should reach management?
Management	`vmbr0`	Proxmox API, SSH, PBS	Yes (it is management)
Production	`prod-vlans` (VLAN zone)	Docker, Home Assistant, NAS	No
Lab	`lab-overlay` (VXLAN zone)	Test VMs, K3s clusters	No
IoT	`vmbr2` (legacy bridge)	Smart home, sensors	No

The goal of the audit is to make the "No" rows actually true.

How to Lock Down the Bridges and SDN Interfaces

Work top-down: datacenter firewall first, then node firewall, then per-VM.

Datacenter Firewall: Default-Deny on SDN Interfaces

Edit the datacenter firewall:

pvesh create /cluster/firewall

Or, if it already exists, edit the file directly:

nano /etc/pve/firewall/datacenter-firewall.conf

Add a default-deny rule for each SDN-managed interface. The IN and OUT fields accept interface names. For a VXLAN zone, the VTEP interface is typically the bridge it is attached to, but you scope the rule to the zone's VTEP:

enable: 1
log_level: warn
IN: pve-lab-overlay-0 -d
OUT: pve-lab-overlay-0 -d

The -d flag means "default-deny" — all traffic not matched by a subsequent allow rule is dropped. Add this for every SDN interface you identified in the previous section.

Then add explicit allows for the management plane. The Proxmox API uses TCP 8006, and SSH uses TCP 22. If your PBS node is on a different subnet, you also need the PBS sync port (TCP 10200–10201):

IN: vmbr0 -p tcp -dport 8006 -snet 192.168.1.0/24
IN: vmbr0 -p tcp -dport 22 -snet 192.168.1.0/24
IN: vmbr0 -p tcp -dport 10200 -snet 192.168.1.0/24

Save and confirm the firewall is active:

pvesh get /cluster/firewall

You should see enabled: 1 and log_level: warn.

Node Firewall: Scope the VTEP

On each node, the node firewall file lives at /etc/pve/firewall/node-<nodename>-firewall.conf. The critical rule here is scoping VXLAN traffic to the management subnet only:

nano /etc/pve/firewall/node-pve1-firewall.conf

enable: 1
log_level: warn
IN: vmbr0 -p udp -dport 4789 -snet 192.168.1.0/24
OUT: vmbr0 -p udp -dport 4789 -dnet 192.168.1.0/24

Without this rule, any host on the production or IoT bridge that can reach the node's VTEP IP can send encapsulated VXLAN frames and inject them into your lab overlay. In a homelab this is a low-risk scenario, but if you ever expose the management bridge to a guest Wi-Fi network (a common mistake), it becomes a real attack surface.

Per-VM Firewall: Close the Dual-Homed Gap

For any VM that has interfaces in two zones, the VM-level firewall is your last line of defense. Edit the VM's firewall:

nano /etc/pve/firewall/105-firewall.conf

enable: 1
log_level: info
IN: pve-lab-overlay-0 -d
OUT: pve-lab-overlay-0 -d
IN: vmbr0 -p tcp -dport 22 -snet 192.168.1.0/24

This says: on the lab overlay interface, deny everything by default. On the management bridge, allow only SSH from the management subnet. If you need the VM to reach a production service, add a specific allow:

IN: pve-prod-vlans-100 -p tcp -dport 5432 -snet 10.100.0.0/24

The same pattern applies to OCI LXC containers. The Proxmox OCI LXC Traffic Lockdown checklist covers the container-specific rules, but the zone-level rules you set here are what protect the container from the outside.

Verification: Prove the Rules Actually Work

Configuration files can lie. The API returns what it thinks is active, but a typo in an interface name silently means "no rule matches this traffic." You need live tests.

Check the API View

pvesh get /vm/105/firewall
pvesh get /nodes/pve1/firewall
pvesh get /cluster/firewall

Compare the output against your files. If you see enabled: 0 on any level, the rules above it are irrelevant.

Run Traffic Tests Between Zones

From a VM in the lab overlay, attempt to reach a production service:

nc -zv 10.100.0.10 5432 -w 3

If the rules are correct and you have not added an explicit allow for that path, you expect a timeout (3 seconds with -w 3). If you get a connection, the rule is missing or the interface name is wrong.

Test the reverse direction:

nc -zv 10.200.0.5 22 -w 3

From a production VM, try to reach a lab VM on the overlay. Same expectation: timeout.

Check the Log

Because you set log_level: warn (or info at the VM level), dropped packets appear in the log:

journalctl -u pve-firewall --since "5 minutes ago" --no-pager

You should see lines like:

pve-firewall[12345]: IN=pve-lab-overlay-0 SRC=10.200.0.5 DST=10.100.0.10 LEN=60 PROTO=TCP SPT=44321 DPT=5432 ...

If you see no log entries for traffic you expect to be dropped, the rule is not matching the interface. Double-check the interface name with ip link show | grep pve-.

Gotchas and Tradeoffs

The interface-name gotcha. When you delete and recreate an SDN interface, Proxmox may assign a different suffix. Your firewall rules still reference the old name. The firewall does not error — it simply stops matching. After any SDN zone change, re-run ip -br link show and compare against your rules. This is the single most common reason a homelab SDN firewall "stops working" after a zone edit.

Log volume tradeoff. Setting log_level: info on a busy VM generates roughly 200–400 log lines per minute during a port scan or a misbehaving service. On a homelab with a 500 GB NVMe, this is negligible. On a node with an SSD that already runs ZFS with aggressive sync=always, the write amplification from journald can add 2–3% to your I/O latency. Use warn at the datacenter and node level, and info only on the specific VMs you are actively debugging.

VXLAN MTU. If you are running a VXLAN zone, the encapsulated frames are 50 bytes larger than the original. Your default MTU of 1500 becomes effectively 1450 for VXLAN traffic. If a VM in the lab overlay sends a full-size 1500-byte frame to a production VM, it will fragment or drop unless both sides have jumbo frames enabled. This is not a firewall issue, but it surfaces during your traffic tests as intermittent timeouts that look like a missing rule. Set the MTU on the VXLAN zone interface to 1450 (or enable 9000-byte jumbo frames end-to-end) before you start interpreting test results.

When to Re-Run This Audit

Re-run the full audit every time you:

Add or remove an SDN zone or interface.
Add a new VM or LXC container with a dual-homed interface.
Change the management subnet or add a new node to the cluster.
Upgrade Proxmox VE to a new minor version (the SDN module has received interface-naming changes in past releases).

If you are running a cluster and want to automate the interface inventory, the Proxmox Datacenter Manager 1.1 host install workflow gives you a scriptable API for pulling node configuration. You can diff the interface list against your firewall files in a cron job and alert on mismatches.

Conclusion

The SDN firewall audit is not a one-time task — it is a recurring check that keeps your homelab's logical segmentation honest after every topology change. Run the interface inventory, confirm default-deny rules exist on every SDN interface, scope your VTEP traffic to the management subnet, and verify with live nc tests between zones. Your next step is to pick the one VM or container that is dual-homed, apply the per-VM rules shown above, and confirm the cross-zone timeout in under five minutes.