Libvirt guests on isolated networks cannot ping each other primarily due to firewall rules blocking ICMP traffic, misconfigured virtual bridges, or IP address conflicts within the subnet. By verifying the bridge interface status, ensuring the
virsh net-autostart setting is active, and configuring guest-level firewalls like
ufw or
iptables to allow ICMP echo requests, you can restore connectivity between virtual machines that are otherwise logically separated from external networks.
Verifying Virtual Network Configuration
The first step in troubleshooting connectivity issues is to ensure that the virtual network defined in Libvirt is correctly configured and active. An isolated network typically uses a NAT or private bridge configuration where guests share an internal subnet but do not have direct access to the physical host’s LAN or the internet unless explicitly routed. You should check the status of your virtual network using the
virsh net-list command. This will display all defined networks along with their active state. If the network associated with your guests shows as inactive, it must be started manually using
virsh net-start [network-name].
Furthermore, it is crucial to verify that the network is set to autostart so that it initializes automatically upon host reboot. Use the command
virsh net-autostart [network-name] to enable this feature. Without this setting, your virtual machines may fail to obtain IP addresses via DHCP if the network service was restarted or if the host booted up before the VMs were powered on. Additionally, inspect the XML definition of the network using
virsh net-dumpxml [network-name] to confirm the bridge name, subnet mask, and DHCP range are consistent across all guest configurations. A mismatch in the subnet definition can lead to routing failures where guests believe they are on different networks.
Checking Guest Firewall Rules
Even when the underlying Libvirt infrastructure is perfectly configured, the most common reason for ping failures is the operating system running inside the guest VM. Modern Linux distributions often enable default firewalls such as UFW (Uncomplicated Firewall) or firewalld which block incoming ICMP packets by default. To test if this is the cause, temporarily disable the firewall on one of the guest machines. For systems using UFW, run
sudo ufw disable. For those using firewalld, execute
sudo systemctl stop firewalld. After disabling the firewall, attempt to ping the other guest again.
If the ping succeeds after disabling the firewall, you need to configure it to allow ICMP traffic permanently rather than leaving the system unprotected. In UFW, you can allow ICMP by adding a rule such as
sudo ufw allow icmp. For firewalld, use
sudo firewall-cmd --permanent --add-service=ping followed by
sudo firewall-cmd --reload. It is important to note that some security best practices discourage allowing all ICMP traffic; however, for basic connectivity testing and internal network diagnostics, allowing echo requests is standard. If you are using Windows guests, ensure that File and Printer Sharing (Echo Request - ICMPv4-In) is enabled in the Windows Defender Firewall advanced settings under the appropriate network profile.
Inspecting ARP Tables and IP Conflicts
Another potential issue arises from Address Resolution Protocol (ARP) cache inconsistencies or duplicate IP addresses. If two guests are assigned the same static IP address, or if the DHCP server has handed out conflicting leases, communication will fail intermittently or completely. Check the ARP table on both guests by running
arp -a on Linux or
arp -a in PowerShell on Windows. Look for the MAC address associated with the target guest's IP. If the MAC address changes unexpectedly or appears incorrect, there may be an IP conflict.
To resolve this, assign static IPs outside the DHCP pool range defined in your Libvirt network XML, or reserve specific IPs in the DHCP configuration. You can also flush the ARP cache on both machines to force a fresh resolution. On Linux, use
sudo ip neigh flush all, and on Windows, use
arp -d *. After flushing, try pinging again. If the issue persists, verify that the guests are actually receiving IP addresses in the same subnet by checking their network interfaces with
ip addr show or
ifconfig. Ensure they share the same gateway if routing is required, although pure isolated bridges often operate without a traditional gateway for inter-VM traffic.
Testing Connectivity with Diagnostic Tools
When simple ping tests fail, deeper diagnostic tools can reveal where the packet loss occurs. Use
tcpdump on the host machine to monitor traffic on the virtual bridge interface. Identify the bridge name from your Libvirt network configuration (often something like
virbr0) and run
sudo tcpdump -i virbr0. Watch for ICMP echo request and reply packets. If you see requests leaving one guest but no replies arriving, the issue is likely within the guest OS or its firewall. If you see neither requests nor replies, the problem lies in the Libvirt bridge configuration or the VM's network attachment.
Additionally, consider using
traceroute or
mtr inside the guests to map the path to the destination. While these tools rely on ICMP or UDP, they can help identify if packets are being dropped at a specific hop, even within a flat Layer 2 broadcast domain. If you find that guests can ping the host but not each other, the issue might be related to the host's kernel parameters regarding IP forwarding or bridge filtering. Although less common in isolated NAT setups, checking
/proc/sys/net/ipv4/ip_forward can provide clues if complex routing scenarios are involved.
Frequently Asked Questions
Why can my VMs ping the host but not each other?
This usually indicates that the virtual bridge is functioning correctly, but the guests' internal firewalls are blocking inbound ICMP from other local IPs while allowing traffic from the host. Verify that the guest firewalls permit ICMP from the entire subnet, not just the gateway IP.
Does disabling the guest firewall compromise security?
Yes, completely disabling the firewall exposes the VM to all network services. Instead of turning it off entirely, configure specific rules to allow only ICMP echo requests and necessary application ports. This maintains a baseline level of protection while enabling diagnostic connectivity.
How do I find the correct bridge name in Libvirt?
Run
virsh net-dumpxml default (or your custom network name) and look for the
<bridge> tag. The value inside this tag, such as
virbr0, is the Linux interface name you should use with commands like
ip link or
tcpdump.
Can IP conflicts cause intermittent ping failures?
Yes, if two VMs have the same IP, ARP responses will bounce between them unpredictably, leading to packet loss or connection drops. Assigning static IPs outside the DHCP range or using DHCP reservations prevents this conflict from occurring.
What if I am unable to traceroute but able to ping?
This scenario suggests that basic connectivity exists but intermediate hops are dropping ICMP time-exceeded messages. This is common in environments where firewalls restrict traceroute-specific protocols. For detailed analysis of why specific paths fail, refer to our guide on
Unable to traceroute but able to ping.
How does WSL2 networking differ from Libvirt isolated networks?
WSL2 uses a hyper-v switch and NAT differently than Libvirt's user-mode networking or KVM bridges. If you are comparing cross-platform networking issues, understanding the routing differences is key. See our article on
Understanding WSL2 Networking and Routing with Ping Google.com for context on how different hypervisors handle isolation.