Skip to content

outbound TCP destination IP from one container becomes the inbound host IP seen by other unrelated containers #7824

@argh

Description

@argh

Description

Background: After upgrading Docker Desktop after a long time running an old version, our local development environments stopped working. It turned out that all cross-container communications (bridge network) were now showing up as originating from a seemingly random external IP instead of the trusted RFC 1918 addresses expected, resulting in the proxy blocking the requests. We narrowed the problem down to whether NewRelic was enabled or not in our configuration, and in fact the external address showing up as the source IP was a NewRelic address! The key was the keepalive setting that created long-lived connections.

Doing some version bisecting (on a M1 running Sequoia, plus an Intel running Ventura) it appears the problem was introduced in 4.42.0, and does not occur in 4.41.2.

This can be reliably reproduced with a simple test setup, outlined below.

Oddly, not all addresses seem to trigger the issue. NewRelic and Google addresses both do, Amazon addresses apparently don't. (The publicized Docker allowlist addresses don't seem to either, so I'm not sure what's "special" about these.)

Reproduce

Open three windows.

  1. docker run -p 8000:8000 -t python:3.11-alpine python3 -m http.server 8000 (Python is irrelevant; just using it as a one-line connection-logging server. Bug happens with any service.)
  2. while true; do curl http://localhost:8000/; sleep 2; done (On host; trigger some traffic. Note IP logged in server.)
  3. docker run -t -i alpine /bin/sh (Pick your favorite container for interactive testing...

Now, in window 3, kick off a rate-limited request to make sure it lasts long enough to see the effect (newrelic needs the -L):

% docker run -t -i alpine /bin/sh
/ # apk add curl
...
(10/10) Installing curl (8.17.0-r1)
Executing busybox-1.37.0-r30.trigger
OK: 13.2 MiB in 26 packages
/ # curl -L --limit-rate 100 https://www.newrelic.com
<output elided>

Note that the IP address logged from the python server changed!
Here's mine:

192.168.65.1 - - [03/Jan/2026 00:41:39] "GET / HTTP/1.1" 200 -  (expected)
192.168.65.1 - - [03/Jan/2026 00:42:11] "GET / HTTP/1.1" 200 -
192.168.65.1 - - [03/Jan/2026 00:42:13] "GET / HTTP/1.1" 200 -
151.101.2.217 - - [03/Jan/2026 00:47:16] "GET / HTTP/1.1" 200 - (!??!?!?!)
151.101.2.217 - - [03/Jan/2026 00:47:18] "GET / HTTP/1.1" 200 -
151.101.2.217 - - [03/Jan/2026 00:47:20] "GET / HTTP/1.1" 200 -
151.101.2.217 - - [03/Jan/2026 00:47:22] "GET / HTTP/1.1" 200 -
151.101.2.217 - - [03/Jan/2026 00:47:24] "GET / HTTP/1.1" 200 -
192.168.65.1 - - [03/Jan/2026 00:47:26] "GET / HTTP/1.1" 200 - (connection closed)
192.168.65.1 - - [03/Jan/2026 00:47:28] "GET / HTTP/1.1" 200 -
192.168.65.1 - - [03/Jan/2026 00:47:30] "GET / HTTP/1.1" 200 -

This 151.101.2.217 address is one of the addresses of the connection. It somehow leaked over to an unrelated container!

% nslookup www.newrelic.com
Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
www.newrelic.com	canonical name = b2.shared.global.fastly.net.
Name:	b2.shared.global.fastly.net
Address: 151.101.2.217
Name:	b2.shared.global.fastly.net
Address: 151.101.194.217
Name:	b2.shared.global.fastly.net
Address: 151.101.66.217
Name:	b2.shared.global.fastly.net
Address: 151.101.130.217

It turns out you actually don't even need to send traffic, a connection is enough:

% docker run -t -i alpine /bin/sh
/ # nc 151.101.2.217 443
^Cpunt!

You can try this with www.google.com as well (nc 142.251.214.132 443, for example.)

Expected behavior

The incoming IP within a container should not be affected by outbound connections in other containers.

docker version

Client:
 Version:           28.2.2
 API version:       1.50
 Go version:        go1.24.3
 Git commit:        e6534b4
 Built:             Fri May 30 12:07:35 2025
 OS/Arch:           darwin/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.42.0 (195023)
 Engine:
  Version:          28.2.2
  API version:      1.50 (minimum version 1.24)
  Go version:       go1.24.3
  Git commit:       45873be
  Built:            Fri May 30 12:07:26 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:
 Version:    28.2.2
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/rg/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.24.0-desktop.2
    Path:     /Users/rg/.docker/cli-plugins/docker-buildx
  cloud: Docker Cloud (Docker Inc.)
    Version:  v0.3.9
    Path:     /Users/rg/.docker/cli-plugins/docker-cloud
  compose: Docker Compose (Docker Inc.)
    Version:  v2.36.2-desktop.1
    Path:     /Users/rg/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.41
    Path:     /Users/rg/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.1.9
    Path:     /Users/rg/.docker/cli-plugins/docker-desktop
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.29
    Path:     /Users/rg/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/rg/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  dev
    Path:     /Users/rg/.docker/cli-plugins/docker-mcp
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/rg/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.18.0
    Path:     /Users/rg/.docker/cli-plugins/docker-scout

Server:
 Containers: 11
  Running: 1
  Paused: 0
  Stopped: 10
 Images: 3
 Server Version: 28.2.2
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 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
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 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.10.14-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 7.656GiB
 Name: docker-desktop
 ID: d69809e9-28e0-49a4-8e0e-86a799d5c10e
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/rg/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

Diagnostics ID

BD1ECCB2-E1D1-4414-B27C-71E010128953/20260103010111

Additional Info

Note that I'm reporting this for the earliest version I detected the problem occurring (4.42.0), but it seems to still occur with the latest release (4.55.0).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions