Network Bridge br0 Problem: Hypervisor KVM VM Accesses Internet but Host Can't Access Other Computers

When a KVM host loses external connectivity while VMs retain it, the issue usually stems from IP forwarding being disabled, incorrect routing tables, or firewall rules blocking the bridge interface. This guide provides a distro-agnostic troubleshooting path to restore bidirectional communication between the host and the network.

Understanding the Symptom Pattern

The scenario where Virtual Machines (VMs) can access the internet but the host cannot is a classic indicator of asymmetric configuration in Linux networking. In a typical br0 setup, the physical NIC is enslaved to the bridge, and both the host’s original IP address and the VMs’ virtual MAC addresses are routed through that bridge. If the VMs work, the physical link is up, and the upstream router is responding to ARP requests for the VM IPs. The failure on the host side suggests that packets originating from the host are either not being forwarded correctly by the kernel or are being dropped by local firewall rules before they reach the bridge. It is crucial to distinguish this from a case where neither the host nor the VMs have internet. That would imply a broken physical connection or a misconfigured DHCP client on the bridge itself. Here, the isolation of the problem to the host requires checking kernel parameters and routing logic specific to the host’s network stack.

Verify IP Forwarding Configuration

A common oversight when setting up bridged networks is assuming that IP forwarding is enabled by default. While many modern distributions enable it automatically, manual configurations or security hardening scripts may disable it. IP forwarding allows the kernel to route packets between interfaces, which is essential if your host acts as a gateway, but it also affects how the host interacts with the bridge in certain NAT or masquerading setups. Check the current status of IP forwarding using the following command:

sysctl net.ipv4.ip_forward

If the output is net.ipv4.ip_forward = 0, you must enable it. To do so temporarily for testing, run:

sudo sysctl -w net.ipv4.ip_forward=1

To make this change persistent across reboots, edit the /etc/sysctl.conf file or create a drop-in file in /etc/sysctl.d/. Add the line:

net.ipv4.ip_forward=1

Then apply the changes with:

sudo sysctl --system

Note that enabling IP forwarding alone does not guarantee internet access for the host; it simply ensures the kernel permits packet movement between interfaces. If the host still cannot connect after this step, proceed to routing verification.

Inspect Routing Tables and Default Gateways

The most frequent cause of host-only connectivity loss in bridged environments is an incorrect or missing default gateway. When you create a bridge, the network manager (such as Netplan, NetworkManager, or systemd-networkd) may assign the default route to the bridge interface (br0) instead of the physical interface (eth0 or enp3s0). If the routing table is confused, the host might try to send traffic out an interface that isn’t properly configured to handle it. View the current routing table with:

ip route show

Look for a line starting with default via. Ensure that the gateway IP matches your router’s actual IP address. For example:

default via 192.168.1.1 dev br0

If the default route points to dev eth0 but eth0 is enslaved to br0 and has no IP address, the host will fail to route packets. You should see the default route associated with br0. If it is missing entirely, the host has no way to reach outside its local subnet. In some cases, multiple routes may exist. Use ip route get 8.8.8.8 to see which path the kernel selects for outbound traffic. If it shows an unexpected interface, you may need to adjust your network configuration files to ensure the bridge handles the default route.

Review Firewall Rules on the Bridge Interface

Firewalls like iptables or nftables can inadvertently block host traffic while allowing VM traffic. This happens because VMs often use different source IPs or MAC addresses than the host. If your firewall has rules that restrict input/output based on the interface name, ensure that br0 is treated similarly to your physical interface. Avoid flushing all rules with sudo iptables -F, as this can lock you out of SSH sessions. Instead, inspect the filter table for restrictive policies:

sudo iptables -L INPUT -v -n

sudo iptables -L OUTPUT -v -n

Look for chains that DROP or REJECT packets. If you see rules limiting traffic to specific interfaces, verify that br0 is included. For instance, a rule might accept traffic only on eth0, ignoring br0. Modify these rules to allow established connections and necessary incoming traffic on the bridge. For nftables users, check the active sets and maps in /etc/nftables.conf or use nft list ruleset to identify any explicit blocks on the bridge interface.

Check DNS Resolution

Sometimes the issue is not connectivity but resolution. If the host cannot ping IP addresses but fails to resolve domain names, the problem lies in DNS configuration. Check /etc/resolv.conf to ensure it contains valid nameserver entries. If you are using a local DNS cache like systemd-resolved, verify its status:

resolvectl status

Ensure that the bridge interface is listed under the correct DNS server assignments. Misconfigured DNS can mimic a complete network failure. For more insights on resolving static IP issues in KVM environments, consider reading KVM/QEMU: Resolving Static IP Address Assignment Issues with TAP Devices. This resource details how TAP devices interact with host networking stacks, which can help clarify complex routing scenarios.

Frequently Asked Questions

Why do my VMs have internet but my host doesn't?

This occurs because VMs typically inherit the bridge’s MAC address or use distinct virtual MACs that are accepted by the upstream switch, while the host’s original IP configuration might be conflicting with the bridge settings. It often indicates a routing table error or a firewall rule blocking the host’s specific source IP.

How do I check if IP forwarding is causing the issue?

Run sysctl net.ipv4.ip_forward; if it returns 0, the kernel is dropping packets intended for routing. Enabling it with sysctl -w net.ipv4.ip_forward=1 can resolve issues where the host relies on the kernel to forward traffic between the bridge and the physical network.

What is the safest way to troubleshoot firewall rules?

Never flush all rules with iptables -F as it removes loopback and SSH protections. Instead, list specific chains with iptables -L INPUT -v -n and look for DROP or REJECT actions targeting the bridge interface or the host’s source IP.

Can Netplan configuration cause this problem?

Yes, if Netplan defines the bridge but fails to assign the default gateway to it, the host will lose external connectivity. Ensure your YAML configuration explicitly sets the gateway4 or gateway6 directive under the bridge definition, not just the physical interface.

Why can I ping the gateway but not the internet?

If you can ping the gateway IP but not external sites, the issue is likely DNS resolution or a missing default route. Verify /etc/resolv.conf for valid nameservers and check ip route to ensure a default route exists pointing to your router.