Proxmox VE 9.1 Network Audit Checklist Before New VMs

Before you add VMs to Proxmox VE 9.1, run a short network audit of bridges, VLANs, firewall rules, and SDN zones so you catch miswired uplinks, missing VLAN tags, and open management ports before guests inherit them. This takes about 10 minutes on a single node and turns most "why can't my VM reach the internet?" problems into a checklist you can fix in the host config.

Key Takeaways

Bridge health: Verify the physical uplink, bridge state, and MTU before assigning VMs to the bridge.
VLAN hygiene: Confirm VLAN-aware bridges expose only the VLAN IDs you expect to VMs.
Firewall defaults: Set DROP/ACCEPT rules at datacenter or node level so new VMs do not inherit open ports.
SDN mapping: Check that SDN zones map to the right physical bridge and do not create duplicate bridge names.
Management access: Lock down SSH and fail2ban before VMs start generating traffic.

Why run a network audit before the first VM?

Proxmox VE 9.1 does not create a clean network sandbox by default. A VM inherits the bridge, VLAN tagging, firewall posture, and management exposure of the host you configured earlier. If the host bridge is on the wrong physical port, a VLAN ID is missing from the bridge, or the node firewall is disabled, the first VM will look like a mystery.

Running the audit before you add guests gives you a small set of facts you can act on: which bridge is healthy, which VLAN IDs are allowed, which firewall layer is active, and whether SDN zones are mapped to the right uplink. If you are starting from a fresh node, pair this with the Proxmox VE 9.1 homelab checklist and finish the storage and backup checks before you move to VMs.

How to check bridge and uplink health?

Start with the live bridge state, not the GUI screenshot. The host may have a bridge that looks correct in the config but is blocked, down, or attached to the wrong port.

ip -br link show
ip -s link show
bridge link show
cat /etc/network/interfaces

Look for three things: the bridge is UP, the physical port is a bridge port, and the port state is forwarding. A blocked port can happen when STP is enabled and the switch has not converged. Proxmox bridges often use STP off for simple single-host setups, but that is a tradeoff if you later connect multiple hosts to the same switch.

Next, verify the physical interface and MTU. A 1 GbE link should report 1000 Mb/s, and the bridge MTU should match the uplink unless you are intentionally using jumbo frames.

ip link show type bridge
ip link show dev "$(ip route show default | awk '{for(i=1;i<=NF;i++) if($i=="dev") print $(i+1); exit}')"
apt update
apt install -y ethtool
ethtool "$(ip route show default | awk '{for(i=1;i<=NF;i++) if($i=="dev") print $(i+1); exit}')"

I once spent an hour chasing a VM that could ping the gateway but not the internet. The bridge was attached to a 100 Mb/s management port on the switch, not the 1 GbE trunk. The fix was a cable move, but the audit would have caught it in one line of output.

How to validate VLAN-aware bridges?

VLANs are where homelab Proxmox setups usually break. You can use separate bridges per VLAN, or you can use a VLAN-aware bridge and tag VM NICs. Both work, but they require different configuration and different checks.

First, see what the host thinks it is doing:

grep -nE 'bridge-vids|vlan-raw-dev|bridge-vlan-aware' /etc/network/interfaces
bridge vlan show

If you expect a trunk on the physical uplink, the bridge should allow the VLAN IDs you plan to use. A common pattern for a management bridge plus tagged VM traffic is a VLAN-aware bridge with a range of VLAN IDs:

auto eth0
iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
bridge-ports eth0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-100

Adjust the range to match your native management VLAN and switch trunk. If you prefer one bridge per VLAN, the configuration looks more like this:

auto eth0.100
iface eth0.100 inet manual
vlan-raw-dev eth0

auto vmbr100
iface vmbr100 inet static
address 192.168.100.2/24
bridge-ports eth0.100
bridge-vlan-aware yes
bridge-vids 100

The tradeoff is real. A VLAN-aware bridge keeps the number of bridges low and makes VLAN IDs explicit in VM NIC settings, but it requires a switch trunk and careful ID planning. Separate bridges are easier to reason about for small labs, but they create more interfaces and more places for a typo.

When you create a VM on a VLAN-aware bridge, the NIC should carry the tag. A typical QEMU NIC line looks like this:

net0: virtio=02:50:00:00:00:01,bridge=vmbr0,firewall=1,tag=100

If you use a separate bridge such as vmbr100, the VM points to that bridge directly and usually does not need the tag. Mixing the two approaches is a common source of "the VM is on the right bridge but the wrong subnet" bugs.

How to audit Proxmox firewall defaults?

Firewall rules in Proxmox are layered: datacenter, cluster, node, and then each VM or container. If you only set rules on one VM, the next VM you add may start with a different posture.

Check which layers are active:

pve-firewall status
cat /etc/pve/firewall/datacenter-firewall.conf 2>/dev/null
cat /etc/pve/firewall/node-firewall.conf 2>/dev/null
ls -l /etc/pve/firewall/

A safe homelab default is to enable the node firewall, drop inbound traffic by default, and allow only the ports you actually need for management. A minimal node firewall file can look like this:

[OPTIONS]
enable: 1
log_level: warn

[DEFAULT]
IN: DROP

[RULES]
IN: ACCEPT tcp dport 22
IN: ACCEPT tcp dport 8000
IN: ACCEPT tcp dport 8443

If you change the SSH port later, update this rule to match. For a VM, enable the VM firewall and keep the rule list small. A basic web service VM might use:

[OPTIONS]
enable: 1

[RULES]
IN: ACCEPT tcp dport 22
IN: ACCEPT tcp dport 80
IN: ACCEPT tcp dport 443

The goal is not to build a perfect firewall before the first VM. The goal is to make sure the default posture is intentional, so the first VM does not become the template for every VM after it.

How to verify SDN zones before VMs?

If you use Proxmox SDN, the zone is another layer that can hide a bad bridge mapping. A zone may point to the wrong physical uplink, create a bridge with an unexpected name, or conflict with a manually created bridge.

List the zones and inspect the bridge names on the host:

pvesdn list
ls -l /etc/pve/sdn/zones/ 2>/dev/null
ip -br link show
grep -R "bridge-ports" /etc/network/interfaces /etc/network/interfaces.d 2>/dev/null

If you do not use SDN, this check is short. If you do use SDN, confirm that the zone is mapped to the bridge you expect and that the bridge appears in the live interface list. For multi-node clusters, also make sure the same zone names and VLAN IDs are consistent across nodes; the Proxmox Datacenter Manager homelab cluster guide is a good companion for the cluster side of that work.

A common SDN mistake is creating a zone that generates a bridge with the same name as an existing manual bridge. The result is not always an error message. Sometimes the bridge exists, but it is attached to the wrong port, and VMs end up on a network that looks correct in the GUI but does not behave on the switch.

How to harden SSH and fail2ban?

Network checks are not only about VMs. The Proxmox host itself is a management target, and SSH is often the first port scanned. Before you add VMs, make sure the host SSH posture is deliberate.

Inspect the effective SSH configuration:

sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|port|allowusers|allowgroups)'

A reasonable hardening step is to require keys, restrict root login, and limit access to a group. Keep a session open before you reload SSH, because a bad drop-in can lock you out.

groupadd -f ssh
usermod -aG ssh root
cat > /etc/ssh/sshd_config.d/10-proxmox-hardening.conf <<'EOF'
Port 2222
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
AllowGroups ssh
EOF
sshd -t
systemctl reload ssh

Changing the SSH port is an honest tradeoff. It reduces brute-force noise, but it can break scripts, monitoring agents, and recovery workflows that expect port 22. If your automation depends on 22, keep 22 and rely on keys, fail2ban, and firewall rules instead.

Then install fail2ban and configure a jail that matches your SSH port:

apt update
apt install -y fail2ban
cat > /etc/fail2ban/jail.local <<'EOF'
[sshd]
enabled = true
port = 2222
logpath = /var/log/auth.log
maxretry = 5
bantime = 1h
findtime = 10m
EOF
systemctl restart fail2ban
fail2ban-client status sshd

The jail should show a banned IP count and a log file. If you keep SSH on port 22, change the jail port to 22. If you use a non-standard port, make sure the firewall allows that port before you rely on fail2ban.

How to turn findings into a pre-VM checklist?

Use the audit as a gate before you create VMs. The table below is the short version of the checks above.

Check	What a pass looks like	Common failure
Bridge and uplink	Bridge is UP, port is forwarding, speed and MTU match the switch	Bridge on 100 Mb/s port, wrong MTU, STP blocking
VLAN configuration	Bridge VLAN list matches the VLAN IDs you plan to assign	Missing VLAN ID, access port treated as trunk, tag on wrong bridge
Firewall defaults	Node or datacenter firewall is enabled with a default DROP policy	New VMs start with open ports or no firewall rules
SDN zones	Zone maps to the expected bridge and no duplicate bridge names exist	SDN bridge attached to wrong uplink or hidden conflict with manual bridge
Management access	SSH requires keys, fail2ban is active, and management ports are limited	Password SSH open to the LAN or exposed to the internet

If a check fails, fix the host before you add the VM. A VM that works around a bad host network setting teaches the lab the wrong pattern. Once the VMs are running and you start adding backup jobs, the PBS 4.2 S3 backup checklist is the natural next audit, because backup traffic and restore paths depend on the same bridges, VLANs, and firewall rules you just verified.

Conclusion

The practical outcome is a Proxmox VE 9.1 host where the bridge, VLAN IDs, firewall defaults, SDN mapping, and SSH exposure are all known before the first VM depends on them. Run the five checks on each node, fix the host-level gaps, and then add VMs with explicit NIC tags and firewall rules. Your next step is to create one test VM on the least important VLAN and verify that it reaches the gateway, the internet, and only the ports you intended to expose.