Proxmox VE 9.2 SDN Audit Checklist Before VM Migration

A pre-migration audit for Proxmox VE 9.2 SDN zones is mostly a mapping exercise: record VLAN tags, VXLAN VNIs, firewall rule ownership, and DNS settings before VMs move. The outcome is a small, checked inventory that prevents a VM from landing on the wrong vnet, a firewall rule from being applied to the wrong zone, or DNS from pointing at a resolver that no longer exists.

Key Takeaways

• Audit first: confirm the Proxmox VE 9.2 zone inventory before moving VMs, not after.
• VLAN tags: compare the SDN zone tag with the physical bridge and switch VLAN before migration.
• VXLAN VNIs: verify the VXLAN zone id, overlay name, and host link details before moving workloads.
• Firewall rules: capture cluster, node, and VM firewall files so rule ownership is clear.
• DNS: check node DNS, search domain, and resolver settings before VMs start using the new network zone.

How to Audit Proxmox VE 9.2 SDN Zones

Start with the version check and the zone inventory. For a five-node cluster with 12 VMs, I usually budget 15 minutes for this pass and keep the result as a small markdown table. If you want to export the zones, vnets, firewall settings, and DNS values safely before editing anything, use the method from Proxmox SDN Snapshot: Export Zones, DNS, Firewall Safely.

Run the version check:

pveversion

Then inspect the SDN inventory files:

test -f /etc/pve/sdn/zones.cfg && cat /etc/pve/sdn/zones.cfg
test -f /etc/pve/sdn/vnets.cfg && cat /etc/pve/sdn/vnets.cfg

Use the zone inventory to identify which zones are VLAN, which are VXLAN, and which vnet belongs to which zone:

grep -E 'type|vlan|vxlan' /etc/pve/sdn/zones.cfg || true

The audit should answer three practical questions before migration:

1. Which zone is VLAN, and what tag is assigned?
2. Which zone is VXLAN, and what overlay id is assigned?
3. Which vnet will the VM actually use after it moves?

Do not stop at the Proxmox GUI. The GUI can show a zone name, but the runtime bridge and vnet may still be stale if a previous network change was saved but not applied.

What to record for VLAN zones

For VLAN zones, record the zone name, the VLAN tag, the bridge, and the VM or container that uses the vnet. A common failure is a VM that was created on a VLAN zone but later moved to a host where the physical bridge does not have that VLAN enabled.

Use these commands to capture the zone definition and the live bridge state:

grep -E 'type|vlan' /etc/pve/sdn/zones.cfg || true
bridge vlan show
ip -d link show

The bridge vlan show result is useful when VLAN filtering is enabled. If the bridge does not show the expected VLAN, the VM may start but fail to reach the physical network. The ip -d link show command is broader and shows the actual interface details, including names, flags, and link type.

For each VLAN zone, write down:

• zone name
• VLAN tag
• bridge name
• vnet name
• VM or container using the vnet
• whether the physical switch port allows that VLAN

This is the part where homelab networks often look fine until a VM moves to a different node.

What to record for VXLAN overlays

VXLAN zones need a different audit. The zone definition may look correct in Proxmox, but the overlay can fail if the VXLAN device is missing, the VNI is wrong, or the physical network does not allow multicast or unicast traffic where the overlay expects it.

Capture the zone definition and the live link details:

grep -E 'type|vxlan' /etc/pve/sdn/zones.cfg || true
ip -d link show

For each VXLAN zone, record:

• zone name
• VXLAN zone type
• overlay id
• vnet name
• VXLAN device name
• host link or physical interface
• whether the overlay is expected to work across nodes

VXLAN can hide a simple VLAN mismatch. A VM may appear to have a network interface, but the overlay may not be reachable from another node. That is why the audit should include both the Proxmox SDN file and the actual link state.

How to Audit Firewall Rules Before Migration

Firewall rules are easy to misread because Proxmox can apply rules at cluster level, node level, VM level, and SDN zone level. Before moving VMs to Proxmox VE 9.2, capture the firewall files so you know which rules are global, which are node-specific, and which belong to individual VMs.

Start with the cluster firewall:

cat /etc/pve/firewall/cluster.conf

Check the current node firewall file if it exists:

test -f /etc/pve/firewall/$(hostname).conf && cat /etc/pve/firewall/$(hostname).conf

Then capture the VM firewall files:

find /etc/pve/firewall -maxdepth 1 -name '[0-9]*.conf' -exec cat {} +

If the SDN zone or vnet inventory contains firewall settings, capture those too:

grep -R 'firewall' /etc/pve/sdn/ || true

The audit should not only list rules, but also show the rule ownership. A rule that applies to a cluster may be inherited by VMs, while a VM-specific rule may override the expected zone behavior. If you need a rule-by-rule inventory for Proxmox VE 9.2 network zones, Proxmox SDN Firewall Audit for VE 9.2 Network Zones is the closer companion post.

For SSH and fail2ban, keep the management path separate from the SDN data path. SSH should normally remain on the management network, not on a data zone used by VMs. If fail2ban is already running, confirm that it watches the management interface, not the SDN data bridge. The rule details are covered in Proxmox SDN Zones: Firewall, SSH, and fail2ban Hardening.

A practical firewall audit table should include:

• cluster firewall enabled or disabled
• node firewall enabled or disabled
• VM firewall enabled or disabled
• default policy for each VM
• rules that reference a specific vnet or zone
• rules that should not move with the VM

How to Audit DNS Before Migration

DNS is often the quiet failure in SDN migrations. The VM may have the right vnet, but the resolver may still be wrong. Before moving VMs, check the node DNS settings and the host resolver.

Check the node configuration:

cat /etc/pve/nodes/$(hostname)/pve-node.conf

Then check the DNS and search domain entries:

grep -Ei 'dns|searchdomain' /etc/pve/nodes/$(hostname)/pve-node.conf || true

Check the host resolver:

cat /etc/resolv.conf

For each VM or container, confirm three DNS values:

1. The resolver IP.
2. The search domain.
3. Whether the VM inherits DNS from the node, the vnet, or a container-specific setting.

If a VM uses a resolver that only exists on the old network zone, the migration can produce a confusing result. The VM may boot, the network interface may appear, but name resolution may fail. If your earlier host network audit was done on Proxmox VE 9.1, Proxmox VE 9.1 Network Audit Checklist Before New VMs gives the same pattern: audit the network before creating workloads.

VLAN vs VXLAN Audit Focus

Audit item	VLAN zone	VXLAN zone
Primary identifier	VLAN tag	VXLAN overlay id
Where to verify	SDN zone file and bridge VLAN state	SDN zone file and live link details
Common failure	VM uses wrong VLAN tag or switch port	Overlay id mismatch or missing VXLAN device
Best for	Simple segmented networks with known switch VLANs	Overlay networks across nodes or existing physical networks
Migration risk	Physical switch mismatch	Overlay reachability and VNI collision
Audit command focus	`grep -E 'type	vlan' /etc/pve/sdn/zones.cfg

The table shows the practical difference: VLAN zones are usually easier to audit because the VLAN tag is visible on the bridge and the switch. VXLAN zones require more care because the overlay can look correct in Proxmox while the underlying path is wrong.

Common Gotchas and Tradeoffs

A common gotcha is a VLAN tag that exists in Proxmox but not on the physical switch. The zone file may show the expected value, but the live bridge may not have VLAN filtering enabled. The VM can start, the interface can appear, and the network can still fail because the physical path does not carry that VLAN.

Another gotcha is VXLAN id collision. Two zones can have different names but the same overlay id. If those zones are used on different nodes, the VMs may appear to be isolated in Proxmox while the actual overlay traffic is not. The audit should include the live link state, not only the zone name.

Firewall ownership is another trap. A rule may look like it belongs to a zone, but the VM may have its own firewall file. If you move the VM to a new zone without checking the VM firewall, the VM may keep a rule that contradicts the zone policy. This is especially common when a VM was created before a zone firewall change.

DNS is the simplest failure to miss. A VM may move to the correct vnet but still use an old resolver. The resolver may be reachable on the old network but not on the new zone. The result is a VM that can ping an IP address but cannot resolve names.

The honest tradeoff is that VLAN zones are easier to audit, while VXLAN zones are more flexible. VLAN gives you a clear physical mapping. VXLAN can work across nodes without requiring every switch port to carry the same VLAN, but it adds overlay complexity. If your network is small and the switch VLANs are stable, VLAN is easier to verify. If your workloads move across nodes and the physical network is not fully controlled, VXLAN may be the better choice, but the audit must include the live overlay state.

Conclusion

The pre-migration audit should produce a small inventory that connects each VM to its SDN zone, VLAN or VXLAN identifier, firewall rule ownership, and DNS resolver. The next step is to compare that inventory against the live bridge, live link state, and firewall files before moving any VM to Proxmox VE 9.2.