Overlay network reports "EnableIPv4": false #50139
Description
Description
When creating an overlay network with Docker Swarm (using --attachable and optionally a defined subnet), the network's metadata (docker network inspect) incorrectly reports "EnableIPv4": false in Docker 28.x.
This issue does not occur in Docker 24.x, where the flag is correctly shown as true.
While container IPs are still assigned correctly from the subnet (e.g., 172.30.1.0/24), the broken flag correlates with real networking problems across Swarm nodes, including services being unable to connect to each other.
For example, in my setup:
authentik_worker (on node A) could not reach PostgreSQL (on node B).
Both are connected to the same overlay network, created with docker network create -d overlay --attachable proxy-net
This same setup works perfectly in Docker 24.x. I have not yet tested in more recent versions, but so far it is behaving this way in all v28.x
Reproduce
Install Docker 28.x (tested on 28.2.2, build e6534b4).
Initialize swarm and create an overlay network:
docker swarm init
docker network create -d overlay --subnet=172.30.1.0/24 --gateway=172.30.1.1 --attachable proxy-net
docker network inspect proxy-net
Observe that "EnableIPv4": false even though an IPv4 subnet is defined.
Deploy multi-node services (e.g. Postgres and Authentik worker) across the swarm — overlay routing fails.
Expected behavior
EnableIPv4 should reflect the real state — true when IPv4 is configured and used.
Inter-node overlay routing should function properly.
docker version
Docker: 28.2.2 (also tried 28.1.x and 28.0.x — all show same issue)
OS: Debian 12 (Bookworm)
Swarm: enabled
Observed both in single-node and multi-node setupsdocker info
docker info
Client: Docker Engine - Community
Version: 28.2.2
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.24.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.36.2
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 3
Server Version: 28.2.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
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: active
NodeID: pyujroi7rasvb0ydaciydd7n5
Is Manager: true
ClusterID: 145o6spa75ai8g5r5lgyun5s1
Managers: 1
Nodes: 1
Default Address Pool: 172.30.0.0/16
SubnetSize: 24
Data Path Port: 4789
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 10
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Force Rotate: 0
Autolock Managers: false
Root Rotation In Progress: false
Node Address: 10.0.10.36
Manager Addresses:
10.0.10.36:2377
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:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.1.0-37-amd64
Operating System: Debian GNU/Linux 12 (bookworm)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.824GiB
Name: srvtest01
ID: ba9dd3ad-d2ed-457f-beda-c46b8b20d933
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: falseAdditional Info
Workaround
Downgrading to Docker 24.x resolves the issue (though this version is quite old). All 28.x are behaving this way. I am yet to test v25+ to v27
Suggestion
Please verify whether recent changes in network driver metadata or Swarm overlay handling in 28.x have introduced regressions.