8000 External networking not working with user-defined networks (since Fedora 42 upgrade) · Issue #49842 · moby/moby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

External networking not working with user-defined networks (since Fedora 42 upgrade) #49842

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Ezwen opened this issue Apr 18, 2025 · 6 comments
Labels
area/networking kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. status/0-triage version/28.1

Comments

@Ezwen
Copy link
Ezwen commented Apr 18, 2025

Description

Since I upgraded to Fedora 42, using the Docker CE rpm repos, a container that is running with a user-defined bridge cannot use external networking (eg. the internet).

I tried uninstalling / reinstalling all docker packages entirely, including nuking /var/lib/docker, but to no avail.

Reproduce

docker network create mynetwork
docker container run --rm --network mynetwork -ti debian:bookworm apt-get update

apt-get will fail downloading package lists, due to not having external networking

Expected behavior

apt-get should work

docker version

Client: Docker Engine - Community
 Version:           28.1.1
 API version:       1.49
 Go version:        go1.23.8
 Git commit:        4eba377
 Built:             Fri Apr 18 09:53:32 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.1.1
  API version:      1.49 (minimum version 1.24)
  Go version:       go1.23.8
  Git commit:       01f442b
  Built:            Fri Apr 18 09:51:47 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client: Docker Engine - Community
 Version:    28.1.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.23.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.35.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 28.1.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 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
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.14.2-300.fc42.x86_64
 Operating System: Fedora Linux 42 (Workstation Edition)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.28GiB
 Name: goudurix
 ID: 7689fa24-1706-47f9-ac51-b48ccd87f537
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

Additional Info

I also observed the following strangeness: the default bridge network also stops working properly when I create a new network

Example:

docker network create othernetwork
docker container run --rm -ti debian:bookworm apt-get update # using default bridge, *not* using othernetwork

This does not work, no working external networking (as above).

But then, staying in the same context, if I then run:

sudo systemctl restart docker

followed by:

docker container run --rm -ti debian:bookworm apt-get update

then this time it works − in other words the bridge network works properly once more (until I create a new network)

@Ezwen Ezwen added kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. status/0-triage labels Apr 18, 2025
@thaJeztah
Copy link
Member

cc @robmry

@vvoland
Copy link
Contributor
vvoland commented Apr 18, 2025

It's a bug in the iptables: https://bugzilla.redhat.com/show_bug.cgi?id=2360423

@thaJeztah
Copy link
Member

Oh! I thought that one was fixed, but looks like Fedora missed the patch. Thanks!

@Ezwen
Copy link
Author
Ezwen commented Apr 21, 2025

It's a bug in the iptables: https://bugzilla.redhat.com/show_bug.cgi?id=2360423

Indeed, thanks for the pointer!

I installed the upcoming patch with the command provided in the tracker:

sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-4c37f9fd93

and that does make the problem disappear 🥳

@CodeDead
Copy link

It's a bug in the iptables: https://bugzilla.redhat.com/show_bug.cgi?id=2360423

Indeed, thanks for the pointer!

I installed the upcoming patch with the command provided in the tracker:

sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-4c37f9fd93

and that does make the problem disappear 🥳

Awesome! Be sure to leave an upvote on bodhi so it is pushed to stable faster

https://bodhi.fedoraproject.org/updates/FEDORA-2025-4c37f9fd93

@robmry
Copy link
Contributor
robmry commented Apr 23, 2025

Thank you all - it looks like Fedora have pushed the patch to stable ... I don't think there's any more to track here, so will close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. status/0-triage version/28.1
Projects
Archived in project
Development

No branches or pull requests

5 participants
0