Please help, networking issue after upgrade from F40 to F41

Ask Fedora
1

Hi,
Using a Fedora Mate spin running 2 VMs under QEMU/KVM plus docker containers. System was upgraded from f40 to f41 using dnf.

The system has an IP address on the 192.168.0.0/24 network. The VMs have macvtap interfaces to the interface on the 192.168.0.0/24 network, plus host-only interfaces on 192.168.122.0/24 network.

The 5 docker containers running Zabbix monitoring have bridge interface 172.23.0.0/24 network allowing them to communicate between each other, plus a published interface on 127.0.0.1 which allows them to appear as services on the host.

Prior to upgrade, the Zabbix monitoring system was able to reach all machines on the 192.168.0.0/24 network and also the VMs on the 192.168.122.0/24 network.

After upgrade, the Zabbix monitoring system can reach all machines on the 192.168.0.0/24 network, but is unable to reach the 192.168.122.0/24 network.

This means that the VMs cannot be monitored by Zabbix - which is the issue.

I would really appreciate help restoring the previous connectivity, not sure if this is a bug or not.

Thank you

2

Check the output:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-active-policies
sudo firewall-cmd --info-zone=libvirt
3

Hi Vladislav,

Thank you for your response.

sudo firewall-cmd --get-active-zones
FirewallD is not running

So instead I listed the iptables rules:

sudo iptables-save

Generated by iptables-save v1.8.10 on Mon Feb 17 23:29:44 2025

*nat
:PREROUTING ACCEPT [421:57221]
:INPUT ACCEPT [105:14797]
:OUTPUT ACCEPT [60:4186]
:POSTROUTING ACCEPT [62:4371]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.23.0.0/16 ! -o br-6d5acbfa379f -j MASQUERADE
-A POSTROUTING -s 172.23.0.2/32 -d 172.23.0.2/32 -p tcp -m tcp --dport 3306 -j MASQUERADE
-A POSTROUTING -s 172.23.0.3/32 -d 172.23.0.3/32 -p tcp -m tcp --dport 10051 -j MASQUERADE
-A POSTROUTING -s 172.23.0.4/32 -d 172.23.0.4/32 -p tcp -m tcp --dport 8443 -j MASQUERADE
-A POSTROUTING -s 172.23.0.6/32 -d 172.23.0.6/32 -p udp -m udp --dport 1162 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER -i br-6d5acbfa379f -j RETURN
-A DOCKER -d 127.0.0.1/32 ! -i br-6d5acbfa379f -p tcp -m tcp --dport 3306 -j DNAT --to-destination 172.23.0.2:3306
-A DOCKER ! -i br-6d5acbfa379f -p tcp -m tcp --dport 10051 -j DNAT --to-destination 172.23.0.3:10051
-A DOCKER ! -i br-6d5acbfa379f -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.23.0.4:8443
-A DOCKER ! -i br-6d5acbfa379f -p udp -m udp --dport 162 -j DNAT --to-destination 172.23.0.6:1162
COMMIT

Completed on Mon Feb 17 23:29:44 2025

Generated by iptables-save v1.8.10 on Mon Feb 17 23:29:44 2025

*filter
:INPUT ACCEPT [2160:933388]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1870:525943]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o br-6d5acbfa379f -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-6d5acbfa379f -j DOCKER
-A FORWARD -i br-6d5acbfa379f ! -o br-6d5acbfa379f -j ACCEPT
-A FORWARD -i br-6d5acbfa379f -o br-6d5acbfa379f -j ACCEPT
-A DOCKER -d 172.23.0.2/32 ! -i br-6d5acbfa379f -o br-6d5acbfa379f -p tcp -m tcp --dport 3306 -j ACCEPT
-A DOCKER -d 172.23.0.3/32 ! -i br-6d5acbfa379f -o br-6d5acbfa379f -p tcp -m tcp --dport 10051 -j ACCEPT
-A DOCKER -d 172.23.0.4/32 ! -i br-6d5acbfa379f -o br-6d5acbfa379f -p tcp -m tcp --dport 8443 -j ACCEPT
-A DOCKER -d 172.23.0.6/32 ! -i br-6d5acbfa379f -o br-6d5acbfa379f -p udp -m udp --dport 1162 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-6d5acbfa379f ! -o br-6d5acbfa379f -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-6d5acbfa379f -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT

Completed on Mon Feb 17 23:29:44 2025

Thank you

4

You are probably affected by this change:

On the other hand, consider the following:

  • Firewalld is the recommended firewall appliance.
  • Docker and libvirt can integrate with Firewalld.
  • iptables is on the way to deprecation.

Note that you can greatly simplify the setup by replacing macvtap/host-only with a shared host bridge:

If you continue using virtual networks, incoming traffic can be allowed like this:

Then use policies to forward traffic between zones:

sudo firewall-cmd --permanent --add-masquerade
sudo firewall-cmd --permanent --zone=libvirt --set-target=default
sudo firewall-cmd --permanent --zone=libvirt --remove-rich-rule="rule priority=32767 reject"
sudo firewall-cmd --permanent --new-policy=libvirt-any
sudo firewall-cmd --permanent --policy=libvirt-any --set-target=ACCEPT
sudo firewall-cmd --permanent --policy=libvirt-any --add-ingress-zone=libvirt
sudo firewall-cmd --permanent --policy=libvirt-any --add-egress-zone=ANY
sudo firewall-cmd --permanent --new-policy=docker-any
sudo firewall-cmd --permanent --policy=docker-any --set-target=ACCEPT
sudo firewall-cmd --permanent --policy=docker-any --add-ingress-zone=docker
sudo firewall-cmd --permanent --policy=docker-any --add-egress-zone=ANY
sudo firewall-cmd --reload
5

Hi Vladislav,

Thank you for all that information and recommendations. It will take me a while to work through all this as it introduces quite a lot of change - while also moving to more modern and supported technologies. I can see how your approach also simplifies things.

So again, thank you, I might need to come back to you if I have further questions.

Best Regards

1 Like