Installing Docker Engine on Fedora 44 breaks libvirt default network

[hardillb]

Description

After installing docker engine on a fresh Fedora 44 install all my lobvirt/boxes VMs are unable to connect to the internet via the default nat virtual network.

I installed using the instructions here:

https://docs.docker.com/engine/install/fedora/

If I disable the docker.service and docker.socket, then reboot the VMs work correctly.

I suspect this is a clash between the nft/iptables firewall rules added by the Docker service and libvirtd.

A dump of the nft list rules is attached, this is from when both libvirtd and Docker are running

nft-list-ruleset.txt

Open Fedora/RedHat Bugzilla issue
https://bugzilla.redhat.com/show_bug.cgi?id=2466836

Reproduce

1. Install Fedora 44
2. install Docker engine using instruction (https://docs.docker.com/engine/install/fedora/)
3. reboot
4. Start boxes and create a new Ubuntu 24.04 Server VM using the wizard
5. When the installer gets to the point of trying to find the closest deb mirror it fails as it can not access the internet

Expected behavior

I expect both docker and libvirt to work as expected and to not clash with each other

docker version

$ docker version
Client: Docker Engine - Community
 Version:           29.4.3
 API version:       1.54
 Go version:        go1.26.2
 Git commit:        055a478
 Built:             Wed May  6 17:11:32 2026
 OS/Arch:           linux/amd64
 Context:           default
failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory

docker info

$ docker info
Client: Docker Engine - Community
 Version:    29.4.3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.33.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.1.3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 6
 Server Version: 29.4.3
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
 runc version: v1.3.5-0-g488fc13e
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 7.0.4-200.fc44.x86_64
 Operating System: Fedora Linux 44 (Workstation Edition)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.06GiB
 Name: razor-crest
 ID: 45df1af3-cc09-4451-8a78-f3bcfbd790af
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
  ::1/128
 Live Restore Enabled: false
 Firewall Backend: iptables+firewalld

Additional Info

Do you think switching to "firewall-backend": "nftables" will help?

https://docs.docker.com/engine/network/firewall-nftables/#migrating-from-iptables-to-nftables

[hardillb]

Switching to nftables backend and adding /etc/sysclt.d/99-net-forward.conf

net.ipv4.ip_forward=1

Appears to work as expected, but this either needs to become the default for Fedora 44 or the default iptables rules need modifying to work with the default libvirtd rules (which is installed by default on the standard Fedora 44 image)

[thaJeztah]

cc @robmry

[robmry]

I've not tried it - but I think the issue is likely to be moby's iptables filter-FORWARD chain's DROP default policy, which it sets if it enables IP forwarding on the host.

When those rules are translated into nftables by iptables-nft, there will be more than one filter-FORWARD chain. So the policy on docker's chain may drop packets that have been (or would be) accepted by other filter-FORWARD chains. (In a pure iptables world, all applications have to use the same chain. So, a packet accepted by one application doesn't hit the DROP. With nftables, packets traverse all the filter-FORWARD chains - so an ACCEPT doesn't "stick" in the same way.)

With nftables, dockerd never sets the filter-FORWARD policy to DROP itself (as you found), it'll just report an error. Only the user can tell whether it's necessary and safe to set that policy. If a host with multiple interfaces isn't supposed to route between those interfaces, extra firewall rules to prevent that forwarding are probably required.

So, I don't think this is a Fedora 44 specific issue ... enabling IP forwarding before starting dockerd will prevent it from adding the DROP policy to its iptables rules. The dockerd --ip-forward-no-drop option mentioned here will have the same effect.