Description
Changes in v25 meant that containers in an 'internal' network are no longer accessible from the host.
This is a major limitation for me compared to v24, as I sometimes want to start productive containers in a local, isolated environment during development and testing without allowing the containers to connect to external systems.
Unfortunately, I am not aware of any documented, practicable workaround in v25.
Reproduce
services:
app:
image: nginx
networks:
mynet1:
ipv4_address: 172.28.6.6
networks:
mynet1:
internal: true
ipam:
config:
- subnet: 172.28.0.0/16
ip_range: 172.28.5.0/24
gateway: 172.28.5.254host$ curl --connect-timeout 5 172.28.6.6
curl: (28) Failed to connect to 172.28.6.6 port 80 after 5001 ms: Timeout was reached
Expected behavior
v24 behavior, i.e. the host can access the container (via IP)
docker version
Client: Docker Engine - Community
Version: 25.0.2
API version: 1.44
Go version: go1.21.6
Git commit: 29cf629
Built: Thu Feb 1 00:23:17 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 25.0.2
API version: 1.44 (minimum version 1.24)
Go version: go1.21.6
Git commit: fce6e0c
Built: Thu Feb 1 00:23:17 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.28
GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client: Docker Engine - Community
Version: 25.0.2
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.12.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.24.5
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 10
Server Version: 25.0.2
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: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.1.0-17-amd64
Operating System: Debian GNU/Linux 12 (bookworm)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 29.72GiB
Name: frink
ID: 72b443fd-a1f4-40aa-94fd-e3710cc47a6c
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Default Address Pools:
Base: 172.20.1.0/24, Size: 28Additional Info
No response
Description
Changes in v25 meant that containers in an 'internal' network are no longer accessible from the host.
This is a major limitation for me compared to v24, as I sometimes want to start productive containers in a local, isolated environment during development and testing without allowing the containers to connect to external systems.
Unfortunately, I am not aware of any documented, practicable workaround in v25.
Reproduce
Expected behavior
v24 behavior, i.e. the host can access the container (via IP)
docker version
Client: Docker Engine - Community Version: 25.0.2 API version: 1.44 Go version: go1.21.6 Git commit: 29cf629 Built: Thu Feb 1 00:23:17 2024 OS/Arch: linux/amd64 Context: default Server: Docker Engine - Community Engine: Version: 25.0.2 API version: 1.44 (minimum version 1.24) Go version: go1.21.6 Git commit: fce6e0c Built: Thu Feb 1 00:23:17 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.28 GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0docker info
Additional Info
No response