Network Bridges Explained

A network bridge is the software equivalent of an Ethernet switch — it forwards frames between connected interfaces based on MAC addresses. In a homelab, bridges are how virtual machines and containers get on the network. Understanding bridges turns "my VM has no IP and I don't know why" into a tractable problem.

What a bridge does

A bridge is a layer-2 switch implemented in software. It has multiple ports (each connecting to a network interface, physical or virtual). When a frame arrives on a port:

  1. The bridge records the source MAC and the port it came from (MAC learning).
  2. The bridge looks up the destination MAC in its table.
  3. If known, forward out the specific port; if unknown or broadcast, forward out all other ports (flooding).

Exactly what an Ethernet switch does. The bridge is the host's miniature switch.

The Linux bridge

Linux's bridge module (brctl historically, ip link / bridge command now) is the standard implementation. A typical homelab setup:

# Create a bridge
ip link add name br0 type bridge

# Add the physical interface to the bridge
ip link set eth0 master br0

# Give the bridge the host's IP (not eth0 anymore)
ip addr add 192.168.1.10/24 dev br0
ip link set br0 up

# Now eth0 has no IP — the bridge does

VMs and containers attach virtual interfaces to this bridge; they're now logically on the same Ethernet segment as anything reachable through eth0.

VM networking modes

ModeHow it worksVM visible to LAN?
BridgedVM's virtual NIC connected to a bridge that includes a physical interfaceYes; gets its own IP from LAN DHCP
NATVM on an isolated virtual network behind the host; host NATs outboundNo; only outbound works
Host-onlyVM on an isolated virtual network with no internet access; communicates with host onlyNo; no internet
InternalVM on an isolated network with other VMs only; no host accessNo
SR-IOV / passthroughPhysical NIC's virtual function passed directly to VMYes; bypasses bridge entirely

The bridged setup in homelab

For homelab VMs hosting services that need to be reachable by other devices on the LAN (Pi-hole, Home Assistant, file server VMs), bridged networking is the default:

  • Create a bridge on the hypervisor host.
  • Add the host's physical NIC to the bridge.
  • For each VM, attach its virtual NIC to the bridge.
  • VMs get DHCP from the home router just like any other device.

Proxmox uses this pattern out of the box — the default bridge is vmbr0 with the physical NIC attached.

Multi-VLAN homelab setup

When the homelab has multiple VLANs (corp, IoT, management), you typically use multiple bridges or VLAN-aware bridges:

  • Multiple bridges: one bridge per VLAN. The physical NIC's VLAN sub-interface (e.g., eth0.10, eth0.20) is added to each bridge. VMs attach to whichever bridge matches their intended VLAN.
  • VLAN-aware bridge: single bridge in VLAN-aware mode. VM virtual NICs are tagged with VLAN IDs; the bridge handles routing the right tag to the right port.

For more on VLAN concepts see homelab VLAN setup.

TAP and TUN devices

Virtual network devices in Linux come in two flavors:

  • TUN — operates at IP layer (layer 3). Used by VPNs (OpenVPN, WireGuard); the userspace program reads IP packets, not Ethernet frames.
  • TAP — operates at Ethernet layer (layer 2). Used by VMs; the hypervisor reads and writes full Ethernet frames. TAP devices typically connect to a bridge.

For VM bridged networking, the VM's virtual NIC is presented as a TAP device on the host; the TAP is added to the bridge.

Container networking and bridges

Docker's default bridge mode creates a bridge (typically docker0) on the host. Each container gets a virtual Ethernet pair: one end inside the container's network namespace (looks like eth0 to the container), the other end attached to the docker0 bridge.

Outbound traffic from containers is NATed through the host (the host's iptables rules implement source NAT). Containers can talk to each other through the bridge; external access requires explicit port mapping.

For more on container networking see container networking basics.

The bridge vs router decision

A bridge keeps everything in one broadcast domain — all attached interfaces are on the same subnet, see broadcasts, and don't go through a router. A router separates broadcast domains; traffic between them goes through the router and is subject to firewall rules.

Choose:

  • Bridge if you want VMs to be on the same logical LAN as the host (and as each other).
  • Router if you want VMs on a separate subnet with controlled access to the rest of the network.

Bridge performance

Linux bridges are efficient — frames are forwarded in kernel space with little overhead. For modern 10 GbE workloads, the bridge can saturate the link without significant CPU cost. For very high throughput or specialized workloads, alternatives exist:

  • Open vSwitch (OVS) — more features than the Linux bridge (VXLAN, OpenFlow, complex flow rules) at modestly higher overhead.
  • macvlan / ipvlan — alternative to bridges where the virtual interface gets a MAC of its own; no bridge needed.
  • SR-IOV — bypasses the bridge entirely; physical NIC presents virtual functions directly to VMs.

Debugging bridge issues

When a VM can't get an IP:

  1. Check that the VM's virtual NIC is attached to a bridge: bridge link shows all interfaces in bridges.
  2. Check the bridge has a physical uplink: bridge link show should list both the VM's interface and the physical NIC.
  3. Check the physical NIC is up and connected.
  4. Check DHCP requests are reaching the bridge: tcpdump -i br0 port 67 or port 68.
  5. Check the upstream router/switch isn't blocking the VM's MAC (some Wi-Fi APs filter unknown MACs).

Wireless and bridges

Bridging a Wi-Fi interface into a host bridge often doesn't work as expected. Most Wi-Fi APs reject frames with source MACs that don't match the registered client — so the VMs' MACs aren't visible to the AP. Workarounds:

  • Use NAT mode instead of bridged when the host is on Wi-Fi.
  • Use macvlan in passthrough mode (sometimes works).
  • Use a wired uplink.

Frequently Asked Questions

What is a network bridge?

A software equivalent of a physical Ethernet switch. It connects multiple network interfaces (physical and virtual) into one layer-2 broadcast domain. Frames sent into one port can be forwarded out any port where the destination MAC is known. Linux's brctl / ip link bridge is the standard implementation; virtually every hypervisor and container runtime uses it under the hood.

What is the difference between bridged and NAT networking for VMs?

Bridged: the VM's virtual NIC is connected to the host's physical network via a bridge. The VM gets an IP from the same DHCP server as the host, and other devices on the LAN can reach it directly. NAT: the VM is on an isolated virtual network behind the host; outbound traffic is NATed through the host's IP. Other LAN devices cannot reach the VM directly.

What is a TAP device?

A virtual network interface in Linux that behaves like an Ethernet device but is connected to a user-space program (a hypervisor, a VPN, etc.) instead of physical hardware. VMs and some container setups use TAP devices: the VM thinks it has a NIC; the hypervisor reads frames from one side of the TAP and forwards them, often into a bridge.

Why use a bridge instead of NAT?

To make the VM or container act like a real host on the LAN — accessible by IP from other devices, getting DHCP from your router, appearing in your network's device list. Bridged networking is the default for homelab VMs hosting services that need to be reachable. NAT is appropriate when isolation matters or when you don't want to expose the VM directly.

Can multiple bridges coexist?

Yes. A host can have any number of bridges; VMs and containers are attached to whichever bridge maps to the network they should be on. Combined with VLANs, this is how multi-VLAN homelab hosts work — one bridge per VLAN, each connected via a tagged trunk port to the upstream switch.

Related Guides

More From This Section