██FR█████ █INTELL███████████

Bridged Networking on Fedora Workstation for Virtual Machines


This content originally appeared on DEV Community and was authored by Miklos Halasz

When running virtual machines on Fedora Workstation, one common requirement is allowing them to communicate directly with your local network (LAN)—as if they were physical machines. The default NAT-based networking isolates them, which is fine for outbound traffic, but insufficient when inbound access or LAN integration is needed.

This post walks through setting up a Linux bridge interface using nmcli, explains what’s going on behind the scenes, and introduces key networking concepts like bridge slaves and virtual routing bridges (VRBs). If you’re using KVM, QEMU, or libvirt for virtualization, this is essential knowledge.

Why I Needed a Bridge

I had VMs running on Fedora 42, and I wanted them to:

  • Get an IP address from my home DHCP server (like other devices on the LAN)
  • Be accessible via their own IP addresses from any other machine on the network
  • Act like any other physical device in the network

To achieve this, I needed bridged networking, which effectively connects the VM to the same Layer 2 network as the host’s physical Ethernet.

Configuration Steps

Here’s what I ran to set up the bridge using nmcli:

nmcli connection delete localan
nmcli con add ifname br0 type bridge autoconnect yes con-name br0 ipv4.method auto
nmcli con add type bridge-slave autoconnect yes con-name br-slave-eno1 ifname eno1 master br0
nmcli connection up br0

These steps:

  1. Delete the old connection managing the physical interface (eno1)
  2. Create a new bridge interface named br0
  3. Attach eno1 to the bridge as a slave
  4. Bring up the bridge

Once complete, I configured my virtual machines to use br0 as their network interface.

Why Was the Existing Connection Deleted?

The default profile (localan) was already managing eno1. NetworkManager does not allow a device to be controlled by multiple profiles simultaneously. Before you can enslave a physical interface to a bridge, it must be released from any existing configuration.

This is a critical step. Without removing the existing connection, adding eno1 to the bridge would fail.

What Is a Bridge Interface?

A bridge interface acts like a virtual switch at Layer 2 (Data Link Layer). It connects multiple network interfaces and forwards Ethernet frames between them.

In this setup:

  • br0 acts like a virtual switch.
  • The physical NIC (eno1) is a port on that switch.
  • Virtual machines are plugged into the same switch, gaining full LAN access.

The bridge itself is the only interface that receives an IP address. The physical NIC becomes a passive conduit—passing traffic between the bridge and the network.

What Does “Controller Waiting for Ports” Mean?

When activating the bridge, NetworkManager returned:

$ nmcli connection up br0
Connection successfully activated (controller waiting for ports) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/25)

This message means that br0 is active but waiting for its slave interfaces (like eno1) to become fully ready—i.e., for link negotiation to complete. It’s typically harmless and resolves within seconds.

What Are Bridge Slaves and Why Are They Needed?

Any device added to a bridge is called a slave. Slaves pass data to and from the bridge but no longer operate independently.

In our case, eno1 became a bridge slave of br0. This means:

  • It no longer gets its own IP address.
  • It merely passes packets between the bridge and the physical network.
  • All IP configuration is now handled by the bridge (br0).

This setup allows your virtual machines, which are also connected to the bridge, to be treated like independent physical devices on the network.

Why a Bridge Is Needed for VM LAN Access

By default, virtualization platforms like libvirt configure VMs with NAT-based networking. This allows VMs to access the internet but keeps them isolated from the LAN.

To make a VM accessible from other devices on your network—via ping, SSH, or services—you need a bridge. It gives the VM a direct Layer 2 path to the LAN, enabling:

  • IP address assignment from the LAN’s DHCP server
  • Direct access to and from any device on the LAN

What’s Happening Behind the Scenes?

Here’s a high-level overview:

  1. Bridge creation (br0) defines a virtual switch.
  2. Physical NIC (eno1) is enslaved to br0, losing its own IP.
  3. Bridge gets an IP address and becomes the primary network device.
  4. VMs are connected to br0, making them peers on the LAN.

Linux handles the bridging logic via kernel modules. NetworkManager coordinates the configuration, making nmcli a powerful and reliable tool for managing this setup.

A Quick Word on Virtual Routing Bridges (VRB)

A Virtual Routing Bridge (VRB) is a more advanced networking concept used in cloud or SDN environments. Unlike a standard bridge that only operates at Layer 2, a VRB combines Layer 2 bridging with Layer 3 routing.

This means a VRB can:

  • Route between VLANs or subnets
  • Apply policies and firewall rules
  • Act as both a switch and a router

VRBs are used in complex setups like OpenStack or Kubernetes CNI plugins. For most homelab or desktop VM scenarios, a standard Linux bridge is simpler, faster, and entirely sufficient.

Conclusion

Setting up bridged networking on Fedora using nmcli is a clean and efficient way to allow VMs to function as full citizens of your LAN. Once configured, it just works—and avoids the limitations of NAT-based networking.

Whether you’re running development servers, containers, or full VM stacks, understanding Linux bridges is essential knowledge for any modern Linux user managing a virtualized environment.

Further Reading:


This content originally appeared on DEV Community and was authored by Miklos Halasz