A fresh Proxmox installation normally presents a bridge named vmbr0. The
name can make it sound like a special virtualization component, but the useful
mental model is simpler: it is a software Ethernet switch inside the host.
The physical network interface is one port on that switch. Each virtual NIC belonging to a VM or container becomes another port. Frames can move between a guest and the physical network much as they would between devices connected to a small hardware switch.
Reading the basic configuration #
A common /etc/network/interfaces configuration looks like this:
1auto lo
2iface lo inet loopback
3
4iface enp3s0 inet manual
5
6auto vmbr0
7iface vmbr0 inet static
8 address 192.0.2.31/24
9 gateway 192.0.2.1
10 bridge-ports enp3s0
11 bridge-stp off
12 bridge-fd 0
The physical interface has no address of its own. It is attached to vmbr0
through bridge-ports, while the Proxmox host's management address and default
gateway live on the bridge. Guests connected to vmbr0 can then participate in
the same Layer 2 network.
This is why moving the management address back to enp3s0 is not a harmless
cleanup. The host and its guests would no longer share the intended bridge in
the same way.
What a bridge does not provide #
A bridge does not automatically provide DHCP, DNS, routing, NAT, or a firewall. Those functions must exist elsewhere. On a typical home network, the router still supplies DHCP and the default route. The bridge merely carries Ethernet traffic between guests and that network.
It is also possible to create an isolated bridge with no physical port:
1auto vmbr1
2iface vmbr1 inet static
3 address 198.51.100.1/24
4 bridge-ports none
5 bridge-stp off
6 bridge-fd 0
Guests on vmbr1 can communicate with the host and with one another, but they
do not gain outside connectivity by magic. Routing and firewall rules would
need to be designed deliberately.
VLAN-aware bridges #
One bridge can carry multiple VLANs when the connected switch port is configured as a trunk and VLAN awareness is enabled:
1auto vmbr0
2iface vmbr0 inet static
3 address 192.0.2.31/24
4 gateway 192.0.2.1
5 bridge-ports enp3s0
6 bridge-stp off
7 bridge-fd 0
8 bridge-vlan-aware yes
9 bridge-vids 10-40
A guest NIC can then receive a VLAN tag in its Proxmox configuration. The switch, bridge, and guest assignment must agree. A mismatch often looks like a random connectivity problem even though every component is behaving exactly as configured.
There are two common ways to hand a VLAN to a guest. Proxmox can tag the virtual NIC, in which case the guest sees ordinary untagged Ethernet for one network. Alternatively, the virtual NIC can carry a trunk and the guest can create its own VLAN interfaces. The first option is easier for a single-purpose server. The second belongs to routers, firewalls, and appliances that genuinely need several networks. Do not use a trunk merely because it feels more flexible; it expands both the guest's responsibility and its reach.
Linux exposes useful read-only checks when the diagram and reality disagree:
1ip -brief link
2ip -brief address
3ip route
4bridge link
5bridge vlan show
Read these outputs before restarting networking. Confirm the physical interface name, bridge membership, host address, default route, and allowed VLAN IDs. Packet counters and a targeted capture can come next, but most mistakes are already visible in those five views.
Change networking from a safe position #
Network edits can disconnect the web interface and SSH simultaneously. Keep a local console or out-of-band management path available, save a copy of the working configuration, and change one layer at a time. First establish the bridge, then confirm host connectivity, then attach a disposable guest, and only afterward add VLAN or routing complexity.
Once vmbr0 is understood as a software switch, Proxmox networking becomes
much less mysterious. The remaining work is ordinary network design—ports,
addresses, routes, tags, and failure recovery—just implemented partly in
software.
Keep that model nearby.