Verify platform support before enabling encrypted Docker overlays

An encryption flag is not evidence that every attached operating system receives encrypted service.

Source facts

Docker overlay networks can enable IPsec encryption for VXLAN data traffic. Docker documents a performance cost that should be tested. It explicitly warns against attaching Windows containers to encrypted overlays: the feature is unsupported there, and Swarm may not report an error when a Windows host connects. The resulting connectivity and confidentiality assumptions can therefore be wrong without an obvious setup failure.

Source: Docker documentation — Overlay network driver.

Applicability

Review Docker overlay data-path encryption, its performance cost and its documented Windows limitations.

DSE recommendation

DSE recommends inventorying node operating systems before enabling the option. Establish which workloads may join the encrypted network and how that restriction is enforced. Keep a supported alternative for incompatible nodes rather than depending on a silently accepted configuration. Measure representative throughput and latency before committing to a production design. Record which traffic the network encryption covers and which connections still require their own transport protection so the control is not overstated.

Verification

In a controlled compatible-node cluster, inspect the network configuration and verify required service communication under representative load. Confirm unsupported node types cannot become an accidental dependency. Review the documented Windows limitations directly rather than interpreting the absence of a Swarm error as a compatibility test. Retain the node operating-system inventory with the network definition. Ask the platform owner to approve the measured performance and supported-node membership, and record any incompatible workload’s separate network design before rollout.

Official reference

Docker documentation — Overlay network driver. Reviewed October 20, 2026.