No internet connectivity in containers—I'm out of ideas

I’m unable to ping the outside world from within containers on my Debian 13 host. It’s a production server using docker compose. Everything was working fine for months until yesterday morning when container-to-internet connectivity was lost. I have tried all of the steps I can find to get it working again, but I’m out of ideas. I could really use some help.

debian@host:~$ docker run --rm busybox ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
debian@host:~$ ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=1.65 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=1.65 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.645/1.647/1.650/0.002 ms

Things I have tried

  • Restarting docker
  • Uninstalling and reinstalling docker via apt, without and with purge
  • rm -rf /var/lib/docker && rm -rf /var/lib/containerd and reinstalling
  • Manually clearing out iptables and removing the docker0 bridge interface and then reinstalling
  • Restarting the host

The docker0 bridge exists:

debian@host:~$ ip link show docker0
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 36:54:74:8b:0d:6e brd ff:ff:ff:ff:ff:ff

Docker’s iptables entries are there:

debian@host:~$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (1 references)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-CT (1 references)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination
DOCKER-CT  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-INTERNAL  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-BRIDGE  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-INTERNAL (1 references)
target     prot opt source               destination

Chain DOCKER-USER (1 references)
target     prot opt source               destination

IP forwarding is enabled on the host:

debian@host:~$ cat /proc/sys/net/ipv4/ip_forward
1

Docker info:

debian@host:~$ docker info
Client: Docker Engine - Community
 Version:    29.7.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.36.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.4.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 4
  Running: 1
  Paused: 0
  Stopped: 3
 Images: 2
 Server Version: 29.7.2
 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: aad11006b869517fcd3009450b6f82da282e1a9b
 runc version: v1.4.3-0-gbb14dabe
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.100+deb13-amd64
 Operating System: Debian GNU/Linux 13 (trixie)
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 62.42GiB
 Name: host
 ID: 841cdf12-9f89-436f-a581-204890c4885d
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables
  EnableUserlandProxy: true
  UserlandProxyPath: /usr/bin/docker-proxy

Bridge network info:

debian@host:~$ docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "fd6126aa5656cdf07756ed12f5ad90ecb9346103d432e5fd074112cca8c802fe",
        "Created": "2026-08-06T15:43:49.974176195Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv4": true,
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {},
        "Containers": {
            "9998670a3cf9dfea5aafc500b882ce764595c8118a8d4bcf7ce8bbcbdd696c88": {
                "Name": "compassionate_kilby",
                "EndpointID": "e7ea39c958858b2e0e1b49a6c7e452fa46f726dadf2721d389030c31126890f5",
                "MacAddress": "ee:1c:c5:48:98:67",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
        },
        "Status": {
            "IPAM": {
                "Subnets": {
                    "172.17.0.0/16": {
                        "IPsInUse": 4,
                        "DynamicIPsAvailable": 65532
                    }
                }
            }
        }
    }
]

Networking within the test busybox container:

debian@host:~$ docker run -it busybox sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether ea:c5:50:7b:26:70 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
/ # ip r
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.3
/ # ping 172.17.0.1
PING 172.17.0.1 (172.17.0.1): 56 data bytes
64 bytes from 172.17.0.1: seq=0 ttl=64 time=0.088 ms
64 bytes from 172.17.0.1: seq=1 ttl=64 time=0.105 ms
^C
--- 172.17.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.088/0.096/0.105 ms

Debian info:

debian@host:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 13 (trixie)
Release:	13
Codename:	trixie

Are we talking vanilla Debian 13, or an appliance style OS that happens to base on Debian 13, like Proxmox, TrueNAS, UGREEN UGS Pro?

Docker 29.7.2 was released a couple of days ago. Is it safe to assume that it broke when the docker-ce package was updated? Or was it broken, and you happen to install the latest Docker version afterwards? As far as I can tell, there is no matching issue in Docker’s upstream Repository Issues · moby/moby · GitHub.

I see you are using the latest version. Have you tried downgrading to the previous patch version at least? v29.7.2 was released yesterday.

Do you have automatic upgrade on the server?

@meyay and @rimelek, thank you so much for replying.

I finally figured it out. The host has 2 public IP addresses. Containers were using one of the IP addresses for egress, but that IP address was not being routed back to the containers. Packets were being sent out correctly, but responses were not making it back in.

The issue is described better in this post, which was what helped me investigate and ultimately fix the issue: https://serverfault.com/questions/1178515/docker-containers-have-no-internet-access-via-bridge-network-on-ubuntu-22-04-vps