Firewalld v1.0.0 included breaking changes [1] that affect the libvirt firewalld backend when using a routed network. Routed networks worked pre v1.0.0 because of firewalld issue 177 [2]. This was fixed in v1.0.0. Now packets world -> libvirt are blocked. Assuming we want to address the situation, I think libvirt should use a firewalld policy to expose the routed VM network. # firewall-cmd --permanent --new-policy libvirt-fwd-in # firewall-cmd --permanent --policy libvirt-fwd-in --add-ingress-zone ANY # firewall-cmd --permanent --policy libvirt-fwd-in --add-egress-zone libvirt # firewall-cmd --permanent --policy libvirt-fwd-in --set-target ACCEPT This policy could be shipped similar to the libvirt zone. Of course, you don't want this policy to go active when using a NAT'd configuration. To control that the shipped policy could omit the egress-zone (making it inactive) and libvirt only adds it at runtime for routed networks. [1]: https://firewalld.org/2021/06/the-upcoming-1-0-0 "Default target is now similar to reject" [2]: https://github.com/firewalld/firewalld/issues/177
Test on libvirt-9.5.0-3.el9.x86_64, the issue is fixed. Refer to bug 2055706#c3 for the test steps.
Test on libvirt-9.5.0-3.el9.x86_64, the issue is fixed. 1. Prepare and start a network with forward mode='route': # virsh net-dumpxml route <network> <name>route</name> <uuid>ad814f81-3ffe-4f3b-b662-1e997a524156</uuid> <forward mode='route'/> <bridge name='virbr1' stp='on' delay='0'/> <mac address='52:54:00:4e:26:38'/> <ip address='192.168.100.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.100.2' end='192.168.100.254'/> </dhcp> </ip> <ip family='ipv6' address='2001:db8:ca2:2::1' prefix='64'> <dhcp> <range start='2001:db8:ca2:2::10' end='2001:db8:ca2:2::ff'/> </dhcp> </ip> </network> 2. Start a vm with network type interface connected to this network; 3. On a remote host which can access to this local host, add a route like as below: # ip route add 192.168.100.0/24 dev eno1 via ${ip_of_local_host} 4. On remote host, ping guest(both ipv4 and ipv6), succeed; 5. On guest, ping the remote host(both ipv4 and ipv6), succeed;
Hi Laine, as the test results in comment 3 and what you have confirmed on bug 2055706#c5, I think we can close this bug as "current release". What do you think? Thank you!
Agreed, and done. Thanks for following up!