Linux Bridge Networking for VMs: How-To

By default, a KVM virtual machine sits behind libvirt's NAT network: it can reach the outside world, but nothing on your LAN can reach it directly, and it has no address on your real network. A Linux bridge fixes that. It turns the host into a virtual switch, so VMs and containers get IP addresses on the same subnet as the host and appear as first-class devices on the LAN.

This how-to creates a persistent bridge on Ubuntu 24.04 with Netplan, attaches a KVM VM to it, and tests connectivity — with the gotchas that catch people out. The Linux bridge is also the primitive beneath OpenStack Neutron and OVN, so understanding it demystifies how cloud tenant networking really works.

Prerequisites

You need Ubuntu 24.04 with Netplan (the default), a working KVM/libvirt install, a wired interface (the examples use eno1), and ideally console or IPMI access — reconfiguring the primary NIC over SSH can disconnect you. Confirm your interface name first:

ip -br link

How a bridge works

A bridge (br0) is a software Layer-2 switch. You enslave the physical NIC to it, move the host's IP onto the bridge, and then every VM tap interface attached to br0 shares that switch. Traffic flows as if all of them were plugged into the same physical switch port.

Step 1: Back up the current Netplan config

Always keep a rollback. Copy the existing file aside before editing:

sudo cp /etc/netplan/50-cloud-init.yaml \
  /etc/netplan/50-cloud-init.yaml.bak
ls /etc/netplan/

Step 2: Define the bridge in Netplan

Edit your Netplan file so the physical NIC carries no IP and the bridge owns the static address. Use a static IP on the bridge — DHCP on a bridge is fragile. (For a refresher on static addressing, see configuring a static IP with Netplan.)

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      dhcp6: no
  bridges:
    br0:
      interfaces: [eno1]
      dhcp4: no
      addresses:
        - 10.10.10.20/24
      routes:
        - to: default
          via: 10.10.10.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
      parameters:
        stp: false
        forward-delay: 0

Step 3: Apply safely

Use netplan try, which auto-reverts after 120 seconds if you do not confirm — your safety net against locking yourself out:

sudo netplan try

If the network still works, press Enter to keep it. Once confident, apply permanently:

sudo netplan apply

Verify the bridge is up and carries the IP, and that the NIC is enslaved:

ip -br addr show br0
bridge link
ip route

Step 4: Create a libvirt network for the bridge

So VMs can select the bridge by name, define a libvirt network that points at br0:

cat > br0-net.xml <<'EOF'
<network>
  <name>br0-net</name>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>
EOF
virsh net-define br0-net.xml
virsh net-start br0-net
virsh net-autostart br0-net

Step 5: Attach a VM to the bridge

For a new VM, pass --network bridge=br0,model=virtio to virt-install. For an existing VM, attach a bridged interface live and persistently:

virsh attach-interface ubuntu-test \
  --type bridge --source br0 \
  --model virtio --persistent

Inside the guest, it now gets an address on the host's subnet (via your LAN DHCP or a static config) instead of the old NAT range.

Step 6: Test connectivity

From another machine on the LAN, ping the VM's new address. From the VM, ping the gateway and an external host:

ping -c3 10.10.10.50
ping -c3 10.10.10.1
ping -c3 1.1.1.1

Confirm the VM's tap device is enslaved to the bridge on the host:

bridge link | grep br0

Troubleshooting and pitfalls

• Host loses network after apply — the IP is still on eno1 instead of br0, or both hold an address; only the bridge should. This is why netplan try matters.
• VM has no connectivity — the host firewall or br_netfilter is filtering bridged traffic; check sysctl net.bridge.bridge-nf-call-iptables.
• Wi-Fi will not bridge — most wireless NICs refuse to join a bridge in client mode; bridging is for wired interfaces.
• Spanning Tree delays — if STP is on, ports take ~30s to forward; keep stp: false on a simple host bridge.
• Duplicate IP — you left DHCP enabled on both NIC and bridge; disable it on the enslaved interface.

Where to go next

A host bridge is manual, single-machine Layer-2. The cloud equivalent — software-defined tenant networks, routers, and floating IPs across many hosts — is covered in OpenStack Neutron networks, routers and floating IPs. For the addressing basics underneath it all, revisit static IP configuration with Netplan.

Conclusion

With a Linux bridge, your VMs and containers become real citizens of your network instead of hiding behind NAT — essential for servers that must be reachable on the LAN. This same Layer-2 primitive is what OpenStack Neutron and OVN automate, programmatically, across an entire cluster. Designing, isolating, and operating that networking at scale is a serious undertaking; clouditiv runs a sovereign, ISO 27001 / BSI C5 private cloud on Ubuntu 24.04 + OpenStack 2025.2 with self-service tenant networks and your data in Germany. Explore our on-premise cloud solution.