FedoraRHEL Based

How To Configuring Network Bridge on Fedora 43

Configuring Network Bridge on Fedora 43

If you run virtual machines on Fedora 43 and your VMs can only reach the internet but nothing on your local network can reach them back, the root cause is almost always NAT-based networking. Setting up a Network Bridge on Fedora 43 solves this by giving each VM its own Layer 2 presence on your physical LAN, just like any other device plugged into your router. This guide walks you through the full process using nmcli, the recommended command-line tool for NetworkManager on Fedora 43, and also covers the GNOME GUI method for desktop users. By the end, your bridge will be active, persistent across reboots, and ready to serve virtual machines, containers, or any other use case that requires direct LAN connectivity.

What Is a Network Bridge and Why It Matters

A network bridge is a virtual Layer 2 switch running inside the Linux kernel. It connects two or more network interfaces and forwards Ethernet frames between them transparently, as if all connected devices share the same physical switch.

The most common reason sysadmins and developers set up a bridge is virtual machine networking. By default, tools like libvirt and QEMU put VMs behind a NAT interface called virbr0. NAT works fine for outbound internet traffic, but it hides your VMs from the rest of the network. No other machine on your LAN can reach them by IP unless you manually set up port forwarding.

A bridge changes that completely. Once your physical Ethernet adapter (enp3s0, for example) becomes a bridge slave, the bridge interface br0 takes over its IP configuration. Any VM connected to br0 gets its own IP directly from your LAN’s DHCP server and is reachable from every device on the network, no port forwarding needed.

Three practical use cases:

  • KVM/QEMU virtual machines that need their own LAN-visible IP addresses for SSH, web servers, or database access from other machines
  • Container networking where containers must communicate with physical hosts on the same subnet
  • Home lab routing where two physical segments need to be joined at Layer 2 without a dedicated switch

Fedora 43 uses NetworkManager as its default network management daemon. The primary tool for scripted and terminal-based configuration is nmcli. The older brctl command and legacy ifcfg scripts under /etc/sysconfig/network-scripts/ are deprecated on Fedora 43 and should not be used. All configuration now lives as keyfiles in /etc/NetworkManager/system-connections/.

Prerequisites

Before you start, make sure your system meets these requirements:

  • Fedora 43 installed (Workstation or Server edition)
  • A physical Ethernet interface available (e.g., enp3s0, eno1, enp1s0); Wi-Fi adapters cannot be bridged due to 802.11 protocol restrictions
  • Root or sudo access on the system
  • NetworkManager running and active
  • Basic comfort working in a terminal

Verify NetworkManager is running before you touch anything:

systemctl status NetworkManager

If the output shows active (running), you are good to go. If not, start and enable it:

sudo systemctl start NetworkManager
sudo systemctl enable NetworkManager

Important: If you are connected to this machine over SSH, the step where you delete the existing Ethernet connection will briefly drop your session. Run these commands from a local terminal or a console session whenever possible, or plan for the reconnect.

Key Terms You Should Know Before Configuring Network Bridge on Fedora 43

Understanding these terms will make every command below feel logical rather than mechanical.

  • br0: The virtual bridge interface. It acts as the central switch and is the only interface that holds an IP address after the bridge is configured.
  • Bridge slave (bridge port): The physical Ethernet interface you add to the bridge. It gives up its own IP and simply passes frames between the bridge and the physical network.
  • nmcli connection: A NetworkManager profile stored on disk that defines how an interface behaves, its IP settings, and whether it starts automatically at boot.
  • autoconnect: A connection property that tells NetworkManager to bring the interface up automatically when the system boots or when the link becomes available.
  • STP (Spanning Tree Protocol): A bridge feature that prevents network loops. For simple single-bridge setups with one uplink, you can disable STP to eliminate the 30-second boot delay it introduces.

Once the bridge is active, enp3s0 no longer has its own IP. It becomes a passive conduit. All IP traffic flows through br0, which is the device you configure with an address, gateway, and DNS.

Step 1: Check Your Current Network Configuration

Before creating anything, gather the facts about your current setup. This prevents you from using the wrong interface name and breaking the configuration halfway through.

List all interfaces and their states:

nmcli device status

Expected output (your interface names will differ):

DEVICE   TYPE      STATE      CONNECTION
enp3s0   ethernet  connected  Wired connection 1
lo       loopback  unmanaged  --

Note the DEVICE name (enp3s0 in this example) and the CONNECTION name (Wired connection 1). You will need both.

Also run this to confirm the interface is physically up:

ip link show

And this to see all stored connection profiles:

nmcli connection show

Write down the exact connection name tied to your Ethernet interface. You will delete this connection in the next step. Getting the name wrong here will cause the delete command to fail without doing any harm, so double-check it now.

Step 2: Remove the Existing Ethernet Connection

NetworkManager does not allow a physical interface to be managed by two connection profiles at the same time. Before you can add enp3s0 to a bridge as a slave, you must remove the existing profile that currently manages it.

Replace "Wired connection 1" with your actual connection name:

sudo nmcli connection delete "Wired connection 1"

If successful, you will see:

Connection 'Wired connection 1' (uuid) successfully deleted.

At this point, enp3s0 has no active connection profile. Your network access will be down until you complete Steps 3 through 5. This is normal and expected.

Step 3: Create the Bridge Interface (br0)

Now create the bridge connection profile. This defines br0 as a virtual bridge device that NetworkManager will manage:

sudo nmcli connection add type bridge \
  autoconnect yes \
  con-name br0 \
  ifname br0

What each flag does:

  • type bridge tells NetworkManager this is a bridge-type connection, not a standard Ethernet profile
  • autoconnect yes ensures the bridge comes up automatically on every boot without manual intervention
  • con-name br0 sets the profile name inside NetworkManager (what you see in nmcli connection show)
  • ifname br0 sets the kernel interface name (what you see in ip link show)

You should see:

Connection 'br0' successfully added.

The bridge now exists as a NetworkManager profile but has no physical interface attached to it yet. That happens in Step 5.

Step 4: Assign an IP Address to the Bridge

Option A: DHCP (Recommended for Workstations)

If your router has a DHCP server and you want br0 to receive an IP automatically:

sudo nmcli connection modify br0 ipv4.method auto

This is the simplest choice for desktop users and home lab setups where IP addresses do not need to be fixed.

Option B: Static IP (Recommended for Servers)

For server environments where the host must always have the same IP address:

sudo nmcli connection modify br0 \
  ipv4.addresses 192.168.1.100/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns 1.1.1.1 \
  ipv4.method manual

Replace 192.168.1.100/24, 192.168.1.1, and 1.1.1.1 with the actual values for your network. The /24 notation means a 255.255.255.0 subnet mask, which covers 254 usable addresses in the 192.168.1.x range.

Step 5: Add the Physical Interface as a Bridge Slave

This step connects your physical Ethernet adapter to the bridge. Replace enp3s0 with your actual interface name:

sudo nmcli connection add type bridge-slave \
  autoconnect yes \
  con-name bridge-slave-enp3s0 \
  ifname enp3s0 \
  master br0

What this command does:

  • type bridge-slave marks this profile as a bridge port rather than a standalone connection
  • master br0 links this slave to the br0 bridge you created in Step 3
  • ifname enp3s0 specifies which physical interface becomes the slave

At this point, enp3s0 is fully surrendered to br0. It will no longer appear with its own IP address. All network identity moves to the bridge.

Step 6: Bring Up the Bridge and Verify

Activate the bridge connection:

sudo nmcli connection up br0

NetworkManager automatically brings up the slave connection (bridge-slave-enp3s0) when the bridge activates. You may see this message:

Connection successfully activated (controller waiting for ports) (D-Bus active path: ...)

This is normal. It means br0 is active and waiting for enp3s0 to finish link negotiation, which typically takes two to three seconds.

Verify the bridge has an IP address:

ip address show br0

Expected output (IP will match your DHCP lease or static setting):

3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 52:54:00:d6:57:e4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global noprefixroute br0

Confirm the slave is attached to the bridge:

bridge link show

Expected output:

2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding

The master br0 and state forwarding entries confirm everything is working correctly. Your Network Bridge on Fedora 43 is live.

Configuring the Bridge for KVM and QEMU Virtual Machines

With br0 running, you can attach VMs to it for full LAN access. The exact steps depend on your virtualization tool.

Using virt-manager (GUI)

  1. Open virt-manager and select your VM
  2. Go to View > Details > NIC
  3. Change Network Source from Virtual network 'default' to Bridge device
  4. Enter br0 as the device name
  5. Click Apply and start the VM

Using QEMU Command Line

QEMU needs explicit permission to use the bridge for unprivileged users. Add this entry:

echo "allow br0" | sudo tee /etc/qemu/bridge.conf
sudo chmod 0640 /etc/qemu/bridge.conf

Without this file, QEMU will refuse the bridge with a permission error even when run as root in some configurations.

Using libvirt XML

In your VM’s XML definition, change the network interface section to:

<interface type='bridge'>
  <source bridge='br0'/>
  <model type='virtio'/>
</interface>

Once a VM boots with this configuration, your LAN’s DHCP server assigns it a real IP address directly. From that point on, any device on the network can reach the VM by its IP, with no port forwarding or proxy needed.

Using the GNOME GUI to Configure Network Bridge on Fedora 43 Setup

For Fedora 43 Workstation users who prefer a graphical approach, GNOME Settings offers a usable (though less flexible) bridge configuration option.

  1. Open Settings and navigate to Network
  2. Click the + button to add a new connection
  3. Select Bridge as the connection type
  4. Name the bridge br0 in the Interface name field
  5. Set the IPv4 method to Automatic (DHCP) or Manual (static IP)
  6. Under the Bridge Ports section, click Add and select your Ethernet adapter from the list
  7. Click Add to confirm, then Apply to save the connection

NetworkManager handles the slave configuration automatically when you add the port through the GUI. The connection activates immediately.

The GUI method is suitable for one-off desktop configurations. For servers, scripts, or any setup you need to reproduce reliably, the nmcli method from the steps above is the correct choice. The GUI does not expose all bridge parameters, such as STP settings, forward delay, or MAC aging time.

Persistent Configuration Across Reboots

One of the main strengths of using nmcli is that every change you make gets written to disk immediately. NetworkManager stores connection profiles as keyfiles in /etc/NetworkManager/system-connections/.

Verify the files exist:

ls /etc/NetworkManager/system-connections/

You should see files for br0.nmconnection and bridge-slave-enp3s0.nmconnection.

Confirm that autoconnect is set on both profiles:

nmcli connection show br0 | grep autoconnect
nmcli connection show bridge-slave-enp3s0 | grep autoconnect

Both should return connection.autoconnect: yes. With this setting, the bridge and its slave come up automatically at boot without any rc.local hacks or systemd unit files.

The legacy ifcfg format under /etc/sysconfig/network-scripts/ is deprecated on Fedora 43. Do not use it. Any configuration written in that format may be ignored or cause conflicts with the modern keyfile system.

Troubleshooting Common Issues

Bridge has no IP address after activation

Run nmcli device status and check if enp3s0 shows as unmanaged. This usually means the interface name in your slave profile does not match the actual hardware name. Delete the slave profile and recreate it with the correct interface name from ip link show.

Network dropped after deleting the Ethernet connection

The bridge was not activated before you deleted the old connection. Restore access by running:

sudo nmcli connection up br0

If the bridge itself is not configured yet, temporarily re-add the original Ethernet connection to restore access, then follow the steps above from the beginning.

VMs still use NAT and do not get a LAN IP

The VM NIC is still pointing at virbr0, libvirt’s internal NAT bridge. Change the network source in virt-manager or the VM’s XML definition from virbr0 to br0 and restart the VM.

nmcli rejects type bridge-slave

Some Fedora builds and NetworkManager versions use slightly different syntax. If you get an error, try the alternative form:

sudo nmcli connection add type ethernet \
  slave-type bridge \
  con-name bridge-slave-enp3s0 \
  ifname enp3s0 \
  master br0

Check your NetworkManager version with nmcli --version if you are unsure which syntax applies.

30-second delay when the bridge comes up at boot

This is STP (Spanning Tree Protocol) running its initial port state calculation. For a simple home lab or single-uplink server with no network loops, you can safely disable STP:

sudo nmcli connection modify br0 bridge.stp no
sudo nmcli connection up br0

This eliminates the boot delay entirely.

Wi-Fi adapter refuses to bridge

This is a hard protocol limitation of the 802.11 standard, not a Fedora bug. Wi-Fi access points will silently drop frames from MAC addresses they do not recognize, which breaks bridging at the hardware level. The only solutions are to use a USB Ethernet adapter or a PCIe NIC for bridging.

Removing the Network Bridge

When you no longer need the bridge, clean it up in three steps.

Delete the slave connection first:

sudo nmcli connection delete bridge-slave-enp3s0

Then delete the bridge:

sudo nmcli connection delete br0

Recreate the original Ethernet connection so the physical interface regains network access:

sudo nmcli connection add type ethernet \
  con-name enp3s0 \
  ifname enp3s0 \
  ipv4.method auto \
  autoconnect yes

Bring it up:

sudo nmcli connection up enp3s0

Verify the physical interface has reclaimed its IP:

ip address show enp3s0

VPS Manage Service Offer
If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal!

r00t

r00t is a dedicated and highly skilled Linux Systems Administrator with over a decade of progressive experience in designing, deploying, and maintaining enterprise-grade Linux infrastructure. His professional journey began in the telecommunications industry, where early exposure to Unix-based operating systems ignited a deep and enduring passion for open-source technologies and server administration.​ Throughout his career, r00t has demonstrated exceptional proficiency in managing large-scale Linux environments, overseeing more than 300 servers across development, staging, and production platforms while consistently achieving 99.9% system uptime. He holds advanced competencies in Red Hat Enterprise Linux (RHEL), Debian, and Ubuntu distributions, complemented by hands-on expertise in automation tools such as Ansible, Terraform, Bash scripting, and Python.
Back to top button