Proxmox uses Linux bridges to connect LXC containers and VMs to the network. The concept is simple — a bridge is like a software switch — but the configuration has enough non-obvious details to catch people out. This post is the reference I wanted when I built my first cluster.
How Proxmox LXC networking works
Every Proxmox node has at least one Linux bridge (vmbr0). The physical NIC connects to the bridge as an uplink. Containers and VMs each get a virtual ethernet pair (veth) — one end inside the container, one end attached to the bridge. The host’s management IP also lives on the bridge.
Task 1: Understand the network configuration file
All network configuration on Proxmox lives in /etc/network/interfaces. This is the authoritative source — the web UI edits this file.
cat /etc/network/interfaces
A typical Proxmox host looks like this:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.0.0.73/24
gateway 10.0.0.1
bridge-ports eth0
bridge-stp off
bridge-fd 0
bridge-ports eth0 means the bridge has eth0 as its uplink. bridge-fd 0 disables the forwarding delay (unnecessary in a homelab, saves 15 seconds on startup).
Task 2: Assign a static IP to a container
The recommended approach is to set the IP in Proxmox at container creation time or via the Network tab. This writes a configuration entry in /etc/pve/lxc/<VMID>.conf.
To modify an existing container:
CT → Network → Select interface → Edit
Set:
- IPv4: Static
- IPv4/CIDR:
10.0.0.76/24 - Gateway:
10.0.0.1
The container must be stopped before modifying its network interface in the UI.
For Ubuntu 24.04 containers, networking is managed by systemd-networkd. Create a network file:
cat > /etc/systemd/network/10-eth0.network << 'EOF'
[Match]
Name=eth0
[Network]
Address=10.0.0.76/24
Gateway=10.0.0.1
DNS=10.0.0.1
EOF
systemctl restart systemd-networkd
If you set the IP both in the Proxmox container config AND inside the container with netplan/networkd, you’ll have a conflict. Pick one method per container. The Proxmox method (config file) is simpler and works across all OS templates.
Task 3: Create a VLAN-aware bridge
VLAN tagging lets you put different containers on different logical networks using the same physical infrastructure. Useful for isolating IoT devices, separating management traffic, or creating a DMZ for public-facing services.
In the Proxmox web UI: Node → Network → vmbr0 → Edit
Enable VLAN aware.
Or edit /etc/network/interfaces directly:
# Add this line to the vmbr0 stanza
# bridge-vlan-aware yes
# Then apply without rebooting:
ifreload -a
When creating or editing a container, set the VLAN Tag in the Network tab to the VLAN ID you want (e.g. 20 for an IoT VLAN, 30 for a management VLAN).
The bridge handles tagging/untagging automatically — the container sees a plain, untagged interface at its assigned IP; Proxmox handles the 802.1Q tagging on the wire.
For this to work, your router or switch must also be configured to trunk the same VLANs to the Proxmox host’s port.
Task 4: Add a second bridge for storage or isolated traffic
Some setups benefit from a second bridge — dedicated storage network, Corosync cluster link, or an isolated lab network.
If you have a second NIC (or want a bridge with no uplink for internal-only traffic):
auto vmbr1
iface vmbr1 inet static
address 172.16.0.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
ifreload -a
bridge-ports none creates a bridge with no physical uplink — containers on this bridge can only communicate with each other and the host. Useful for a private lab network that has no internet access.
Common networking mistakes and fixes
# Check the container has an IP
ip addr show eth0
# Check the gateway is reachable
ping 10.0.0.1
# Check DNS
ping 8.8.8.8 # if this works but domains don't, it's a DNS issue
cat /etc/resolv.conf
Most common cause: missing gateway in the container’s network config. Second most common: the bridge has no uplink (bridge-ports is empty or wrong interface name).
If two containers on the same bridge can’t communicate:
# Can you reach the other container's IP?
ping 10.0.0.76
# Check the container firewall isn't blocking it
# (Proxmox → CT → Firewall → enable/disable)
If you have the container-level firewall enabled, you need explicit rules to allow intra-LAN traffic. The easiest fix is an ACCEPT rule for the entire +lablan IPSET at the container level.
# Reload all interfaces
ifreload -a
# Or reload just one interface
ifdown vmbr0 && ifup vmbr0
Running ifdown vmbr0 on your management bridge will drop your SSH connection. Have a console session (Proxmox web terminal or IPMI) ready if you’re doing this remotely.
Network configuration reference
# List all bridges and their ports
brctl show
# Show which VMs/CTs use which tap/veth interface
cat /etc/pve/lxc/*.conf | grep net
# View bridge forwarding table (which MAC is on which port)
brctl showmacs vmbr0
# Check routing table on host
ip route show
Related posts:
- Proxmox Firewall Guide: Rules, Zones, and Container Isolation — apply firewall rules to the bridges and containers you configured here
- Proxmox Security Hardening — harden the host after setting up networking
- Proxmox Storage Guide: LVM, ZFS, NFS, and Ceph — the storage side of container setup
- Proxmox Cluster Setup: Quorum, Corosync, and Node Joining — the cluster whose inter-node traffic uses these bridges
- Tailscale Subnet Router: Remote Access to Your Entire Homelab — route remote access through these same bridges
- Creating Your First Proxmox VM — when a container isn’t enough and you need a full VM
- Proxmox VM vs LXC: When to Use Each — decide whether a workload belongs in a container or a VM before you network it
- Pi-hole on Proxmox LXC — run your own DNS server and resolve local hostnames across these bridges