How to Fix UFW Blocking KVM Guest from Getting IP Address and Accessing Network

UFW blocks KVM guests from obtaining IP addresses by filtering DHCP broadcasts on the host bridge interface. To restore connectivity, you must configure UFW to allow traffic specifically on the bridge device (typically br0) while keeping the physical interface restricted. This ensures the guest VM can communicate with the DHCP server and access the network without compromising host security.

Understanding the Root Cause

When you set up a KVM virtual machine with bridged networking, the host creates a virtual bridge interface (often named br0 or similar) that connects the guest directly to your local network. The guest VM sends DHCP requests as broadcast packets to this bridge. If UFW is enabled on the Ubuntu host, it may inadvertently drop these essential broadcast packets because they arrive on the bridge interface rather than the physical Ethernet port (eth0 or wlan0). By default, UFW policies often apply to incoming traffic on all interfaces unless explicitly scoped. If the policy is set to DROP or REJECT for incoming connections, the DHCP discovery packets from the guest never reach the DHCP server on your router. Consequently, the guest fails to obtain an IP address via DHCP, leaving it isolated. Additionally, even if static IPs are assigned, general network traffic might be blocked if the bridge interface is not correctly whitelisted in the firewall rules. It is crucial to distinguish between the physical interface and the bridge interface. Allowing traffic only on eth0 does not automatically permit traffic on br0. You must explicitly configure UFW to trust the bridge interface. This approach maintains security by restricting direct access to the host's physical network stack while enabling the necessary layer-2 communication for virtual machines. For more context on firewall setups for virtual networks, you might find Setting Up a Firewall on Ubuntu Network Gateway for a Virtual Network with VirtualBox helpful, although the principles of interface-specific rules apply similarly to KVM.

Step 1: Identify Your Bridge Interface

Before modifying firewall rules, you need to confirm the name of the bridge interface used by your KVM guests. Run the following command in the terminal:

ip addr show

Look for an interface with type bridge. It is typically named br0, but it could also be virbr0 (if using libvirt's default NAT bridge) or a custom name defined in your Netplan configuration. Note the exact name, as you will use it in the next steps. If you are using Netplan, check the YAML files in /etc/netplan/ to see how the bridge is defined.

Step 2: Configure UFW for the Bridge Interface

The most effective solution is to allow all traffic on the bridge interface. Since the bridge operates at Layer 2, allowing incoming and outgoing traffic on this interface ensures that DHCP broadcasts and subsequent network packets pass through unimpeded. Open the UFW application profiles or modify the rules directly. The recommended method is to add specific rules for the bridge interface. Execute the following commands, replacing br0 with your actual bridge interface name:

sudo ufw allow in on br0
sudo ufw allow out on br0

These commands tell UFW to ignore filtering rules for any traffic entering or leaving the specified bridge interface. This effectively whitelists the virtual network segment connected to the bridge. If you have multiple bridge interfaces, repeat these commands for each one. If you prefer a more granular approach, you can allow only specific protocols. However, for DHCP and general LAN access, allowing all traffic on the bridge is standard practice because the bridge itself handles MAC address filtering and forwarding. The host kernel manages the separation between the host and guest traffic, so broad rules on the bridge interface do not expose the host to external threats from the guest side beyond what the bridge already permits.

Step 3: Verify UFW Status and Rules

After adding the rules, verify that they have been applied correctly. Run:

sudo ufw status verbose

You should see lines indicating "ALLOW IN" and "ALLOW OUT" for your bridge interface. Ensure that the default policies for other interfaces (like eth0) remain restrictive if desired. For example, you might want to keep SSH access restricted to specific IPs on the physical interface while allowing full access on the bridge. If the guest still cannot get an IP, check if UFW is actually active. Sometimes, services like firewalld or other iptables-based firewalls may conflict. On Ubuntu, UFW is the primary tool, but ensure no other firewall service is running. You can check with:

systemctl status ufw

Step 4: Restart Networking and Test

Once the rules are in place, restart the networking service or reboot the host to ensure the changes take effect cleanly. Alternatively, you can restart the KVM guest. Inside the guest VM, request a new IP address using:

sudo dhclient -r
sudo dhclient

Or simply reboot the guest. The guest should now successfully receive an IP address from your router's DHCP server. Test connectivity by pinging an external site or accessing internal resources. For further troubleshooting if remote access remains an issue, refer to Can't Connect to VM Remotely: Troubleshooting Guide, which covers common connectivity pitfalls beyond just DHCP.

Alternative: Using NAT Instead of Bridging

If configuring UFW for bridged networking proves too complex or insecure for your use case, consider switching the KVM guest to use NAT networking instead. In NAT mode, the guest shares the host's IP address and is hidden behind the host's firewall. UFW rules on the host will naturally protect the guest, and the guest can access the internet without needing explicit bridge rules. However, inbound connections from the external network to the guest will require port forwarding rules, which adds complexity. Bridged networking is generally preferred for servers that need to be directly accessible on the local network.

Frequently Asked Questions

Why does my KVM guest fail to get an IP via DHCP?

The most common reason is that UFW is blocking DHCP broadcast packets on the bridge interface. Since DHCP relies on broadcasts, and UFW may filter them by default, the guest cannot complete the lease process. Whitelisting the bridge interface resolves this.

Can I allow only DHCP traffic on the bridge instead of all traffic?

Technically yes, by allowing UDP ports 67 and 68, but it is impractical. Once the IP is obtained, the guest needs general network access. Restricting to only DHCP would break all other connectivity, requiring additional rules for HTTP, SSH, etc., making it harder to maintain than simply allowing the bridge.

Does allowing traffic on the bridge expose my host to security risks?

It exposes the host to traffic originating from the guest VM, but not directly from the external network. The host's physical interface filters external traffic. As long as you secure the guest VM itself and do not share sensitive data unnecessarily, this setup is considered safe for home and lab environments.

What if I am using Libvirt's default virbr0 bridge?

If you are using the default Libvirt NAT bridge (virbr0), UFW usually allows it by default via its application profile. If it is blocked, run sudo ufw allow in on virbr0 and sudo ufw allow out on virbr0. Check if Libvirt has added its own iptables rules that might override UFW.

How do I revert these changes if something goes wrong?

To remove the rules, use sudo ufw delete allow in on br0 and sudo ufw delete allow out on br0. Replace "br0" with your interface name. You can view current rules with sudo ufw status numbered to identify the rule numbers for deletion.