The command "iptables -S -t filter | grep -- '^-A FORWARD '" produces the following output: -A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -p icmp -j ACCEPT -A FORWARD -j REJECT --reject-with icmp-host-prohibited It's my understanding that the rules mentioning virbr0 are added automatically by libvirtd in response to me having a virtual machine with the default NAT networking. Good so far. Alas, the virbr0-related REJECT rules appear quite early in this table, making it impossible to influence packets with rules added to the FORWARD_* subtables by the firewall-config tool. Please consider arranging for firewalld's rules to be processed before libvirtd's REJECT rules.
For the benefit of anyone having the same problem, I'll mention that as a workaround I have added the following to my /etc/rc.d/local: ( sleep 60; iptables -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable; iptables -D FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable ) &
Thank you very much Peter for the investigation and work-around ! *** This bug has been marked as a duplicate of bug 1079088 ***