A Proxmox bridge connects guest interfaces to a network. VLAN filtering determines which VLANs traverse its ports. Routing and firewall policy determine which subnets may communicate.

Start by documenting what the physical switch sends to the host. A correct guest VLAN tag cannot fix a mismatch on the uplink.

Verification status

Area Evidence and limits
Technical review Reviewed against the official references below on October 31, 2026.
Shell examples Bash syntax checked; no host networking commands executed.
Configuration Illustrative single-uplink IPv4 lab, not a captured production configuration.
Runtime Application, rollback, DHCP, guest traffic, and firewall behavior remain untested for this revision.

1. Identify the management path

These two designs are different:

Switch port toward PVE Host management placement Expected wire traffic
VLAN 99 tagged IP on vmbr0.99 Management frames carry VLAN 99.
VLAN 99 untagged/native IP on vmbr0 in a matching bridge/PVID design Management frames arrive without an 802.1Q tag.

A switch PVID classifies incoming untagged frames. Its egress VLAN membership controls whether transmitted frames are tagged. Both directions must agree with the host design.

For example, a port delivering VLAN 99 untagged and guest VLANs tagged must not be treated as a fully tagged management trunk. Decide which design you have before changing interfaces. See MikroTik’s bridge VLAN table reference.

The configuration below uses tagged management VLAN 99 throughout. It is not a migration recipe for an existing untagged management network.

2. Inspect and preserve the current configuration

Have a working local or out-of-band console before changing the interface used by SSH or the web UI. Test console access first.

Run this read-only inventory on PVE:

1
2
3
4
5
6

ip -br link
ip -br address
ip route
bridge link show
bridge vlan show
cat /etc/network/interfaces

Record NIC names, management address, gateway, active VLAN membership, and switch-port settings. Inspect any included interface files and pending PVE network changes too.

Before editing, preserve the main file in a unique directory:

1
2
3
4
5
6

(
set -euo pipefail
backup_dir=$(mktemp -d /root/pve-network-backup.XXXXXX)
cp -a /etc/network/interfaces "$backup_dir/interfaces"
printf 'Saved main interfaces file to %s\n' "$backup_dir/interfaces"
)

Copy included configuration files and relevant switch settings separately. Keep the backup path available through the console.

3. Review a tagged-management example

This example assumes:

  • One physical uplink named enp3s0.
  • Switch egress and ingress configured for tagged VLANs 10, 50, and 99.
  • Management subnet 10.0.99.0/24, with the unused host address 10.0.99.30 and router 10.0.99.1.
  • No cluster, bond, SDN, extra uplink, or IPv6 requirements in this illustrative file.

Stage it as a separate candidate; this command does not replace the active configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

cat > /root/pve-network-tagged-example.interfaces <<'EOF'
auto lo
iface lo inet loopback

iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10 50 99

auto vmbr0.99
iface vmbr0.99 inet static
    address 10.0.99.30/24
    gateway 10.0.99.1
EOF

Compare the candidate with the real host and retain required settings. Do not overwrite a working file with this reduced example. Review the PVE networking documentation for your installed version.

The host needs a VLAN interface only when the host itself participates at layer 3 on that VLAN. Guests on VLAN 10 or 50 do not require host IP addresses on those networks.

An IP directly on a bridge is valid for an untagged management design. VLAN IDs and IP subnets are separate concepts; this example uses similar numbers only to make the plan easier to read.

4. Put one disposable guest on an access VLAN

Use PVE’s guest network interface editor to select bridge vmbr0 and VLAN tag 10. Preserve existing MAC, firewall, rate, and other interface settings.

For a normal single-VLAN guest, leave the guest OS interface untagged. The bridge assigns the VLAN at its virtual port; the physical uplink carries the tag.

The same access-port principle applies to an LXC veth with tag=10. It does not mean the container receives a VLAN trunk. Configure its IP or DHCP separately. See PVE container documentation.

A guest that must process multiple VLANs needs an explicit trunk design with allowed VLANs and matching guest configuration. Simply omitting the access tag is not a complete trunk configuration. Keep that separate from this first test.

5. Apply deliberately and verify the path

Use the supported PVE network configuration workflow for the installed release, with console access and the saved configuration ready. Review pending changes before applying; avoid bringing down the management interface from the only remote session.

After application, inspect:

1
2
3
4

ip -br address
ip route show default
bridge link show
bridge vlan show

Check uplink and guest-port membership in the full VLAN table. A bridge-device-only query does not show every attached port. Consult the bridge command reference for the difference between PVID and untagged egress flags.

Verify management reachability from a separate workstation. Inside the disposable guest, test DHCP or its intended static address, gateway reachability, DNS resolution, and the actual service connection. A failed ping alone does not distinguish a missing route from ICMP filtering.

Test both allowed and denied inter-VLAN connections against the intended router/firewall rules. A VLAN-aware bridge is not an inter-VLAN firewall. A bridge without a physical uplink can switch between local guests, but needs routing or another uplink path to reach external networks.

6. Recover and extend only after the baseline works

If management access fails, use the console to compare active addresses, routes, and VLAN membership with the saved configuration and switch settings. Restore the known-good host file and any changed switch configuration, then apply through the supported local workflow. Recheck connectivity before leaving the console.

Keep the old management path available until the replacement is verified. Avoid changing VLAN tagging, IP addressing, switch membership, and firewall rules all at once.

Bonding, multiple uplinks, OVS, and cluster networking need their own plans. LACP requires matching switch configuration; a single flow does not automatically gain the sum of all link speeds. OVS supports VLANs and does not inherently require one bridge per VLAN. Do not add a second parallel bridge uplink without a loop-prevention design.

Continue reading