The scenario
You just installed a Fedora VM. You want it to sit on the same subnet as your laptop, grab an IP from your router, and ping the host without jumping through NAT hoops. You open virt-manager, select Bridge device, and see a blank dropdown. The host network is stuck behind NetworkManager's default NAT profile. You need a virtual switch that connects the VM directly to your physical cable. You also need the host to keep working while the bridge takes over the link.
What a bridge actually does
A network bridge is a virtual switch. It sits between your physical network interface and the virtual interfaces your hypervisor creates. Traffic from the VM flows into the bridge, the bridge forwards it to the physical adapter, and the router treats the VM like another device plugged into your wall. The host operating system does not route the traffic. The host just passes it through. This means the VM gets its own IP address on your local network. It can host services that other machines can reach directly. It also means your router's DHCP server hands out an extra lease.
NetworkManager handles this through connection profiles. A profile is not the interface itself. It is a set of instructions that NetworkManager applies when the interface comes up. You will create two profiles. One profile defines the bridge. The second profile enslaves your physical interface to that bridge. The physical adapter loses its IP address and becomes a dumb port. The bridge inherits the IP stack and becomes the new gateway for the host.
Building the bridge with nmcli
Open a terminal. You need root privileges for network configuration. Run sudo -i or prefix commands with sudo. First, identify your active physical interface. Do not guess. NetworkManager names interfaces dynamically based on MAC addresses or firmware. The name might be enp3s0, eth0, or wlp2s0.
Here is how to find the active wired interface:
nmcli device status
# Lists all devices and their current state.
# Look for connected under the DEVICE column.
# Ignore lo and any interface marked unmanaged or disconnected.
Once you have the name, create the bridge profile. The bridge needs an interface name that matches the profile name. NetworkManager will create the virtual interface automatically when the profile activates.
Here is the command to create the bridge profile:
nmcli connection add type bridge con-name br0 ifname br0
# Creates a new connection profile named br0.
# Sets the virtual interface name to br0.
# Defaults to IPv4 DHCP, which pulls an address from your router.
Next, attach the physical interface to the bridge. This step removes the IP address from the physical adapter and moves it to the bridge. The physical adapter becomes a dumb port.
Here is the command to enslave the physical interface:
nmcli connection add type bridge-slave con-name br0-slave ifname enp3s0 master br0
# Replaces enp3s0 with your actual interface name.
# Creates a slave profile that binds the physical port to the bridge.
# The master parameter points to the bridge profile created earlier.
Activate both profiles. NetworkManager will reconfigure the link. Your terminal session might drop if you are connected over SSH. Run this from a local console or a serial console if possible.
Here is how to bring the bridge online:
nmcli connection up br0-slave
nmcli connection up br0
# Activates the slave first, then the bridge.
# Order matters. The bridge needs the slave attached before it requests an IP.
# NetworkManager handles the dependency automatically, but explicit activation avoids race conditions.
Convention aside: NetworkManager stores these profiles in /etc/NetworkManager/system-connections/. The files are owned by root and have strict permissions. Never edit them with a text editor while NetworkManager is running. Use nmcli or nmtui. Manual edits cause state drift and silent failures.
Configuring a static IP on the bridge
DHCP works for most home labs. Servers and persistent workstations often need a fixed address. You can assign a static IP to the bridge profile instead of relying on the router. This keeps the host reachable even if the DHCP server goes down.
Here is how to modify the bridge profile for a static address:
nmcli connection modify br0 ipv4.method manual
nmcli connection modify br0 ipv4.addresses 192.168.1.50/24
nmcli connection modify br0 ipv4.gateway 192.168.1.1
nmcli connection modify br0 ipv4.dns "1.1.1.1 8.8.8.8"
# Sets the IPv4 configuration method to manual.
# Assigns the static IP and subnet mask to the bridge.
# Defines the default gateway for outbound traffic.
# Provides primary and secondary DNS resolvers.
Apply the changes by cycling the connection. NetworkManager will drop the old DHCP lease and apply the static configuration.
Here is how to reload the modified profile:
nmcli connection down br0
nmcli connection up br0
# Deactivates the bridge to clear the DHCP state.
# Reactivates the bridge with the new static parameters.
# The slave interface remains attached throughout the cycle.
Reboot before you debug. Half the time the symptom is gone once the link state stabilizes.
Verify the traffic flows
Check the interface state and IP assignment. The bridge should show as connected and hold the IP address your router assigned or the static address you configured.
Here is how to confirm the bridge is active and routed:
nmcli device show br0
# Displays detailed state for the bridge interface.
# Look for IP4.ADDRESS[1] to verify assignment.
# Check GENERAL.STATE for connected.
Test connectivity from the host. Ping your router and an external address. Then boot the VM and assign its virtual network adapter to the br0 bridge in virt-manager or virsh. The VM should receive an IP from the same subnet.
Here is a quick connectivity check:
ip route show default
# Confirms the default gateway is reachable through the bridge.
ping -c 3 8.8.8.8
# Verifies outbound routing works. Replace with your preferred public DNS or IP.
Run journalctl -xeu NetworkManager if the bridge fails to activate. Read the actual error before guessing.
Common pitfalls and error messages
The most frequent failure happens when the physical interface already holds a static IP or a DHCP lease. NetworkManager refuses to enslave an interface that is already managing its own IP stack. You will see this in the terminal:
Error: Connection activation failed: Device not managed by NetworkManager or not available.
Or you might see a dependency failure during activation:
Error: Connection activation failed: Dependency failed for br0-slave.
Fix it by deactivating the existing profile first. Find the old profile name with nmcli connection show. Deactivate it, then run the bridge commands again.
Another common issue involves Wi-Fi adapters. Linux does not support bridging Wi-Fi interfaces at the link layer due to 802.11 frame structure limitations. You cannot attach a wlp interface to a bridge and expect it to work. Use NAT or macvtap for wireless hosts.
If the bridge comes up but the VM cannot reach the network, check the firewall. Fedora enables firewalld by default. The bridge interface inherits the public zone unless you change it. Ensure your VM's traffic is allowed.
Here is how to verify the firewall zone assignment:
firewall-cmd --get-active-zones
# Lists zones and the interfaces attached to them.
# Confirm br0 is in the expected zone.
firewall-cmd --zone=public --list-ports
# Shows which ports are open. Add services as needed.
MTU mismatches also break bridged traffic. If your physical link uses jumbo frames but the bridge defaults to 1500, packets get dropped silently. Match the MTU across the bridge and the slave interface.
Here is how to align the MTU settings:
nmcli connection modify br0 ipv4.mtu 9000
nmcli connection modify br0-slave 802-3-ethernet.mtu 9000
# Sets the bridge MTU to match your physical switch.
# Forces the slave interface to use the same frame size.
# Prevents fragmentation and silent packet loss.
Trust the package manager. Manual file edits drift, snapshots stay.
Bridge versus NAT versus macvtap
Virtualization networking offers three main paths. Each solves a different problem. Choose based on your traffic pattern and host constraints.
Use a bridge when you want the VM to appear as a separate device on your physical network. Use NAT when you only need outbound internet access and do not care about inbound connections. Use macvtap when you need near-native network performance and your hypervisor supports direct hardware offloading. Stay on the default NAT profile if you are running temporary test VMs and do not want to reconfigure the host network.
Convention aside: dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Keep your network configuration stable across upgrades by relying on NetworkManager profiles instead of manual scripts. Fedora deprecated the old ifcfg format years ago. NetworkManager is the single source of truth.