Docker Networking: Understanding the Default 172.17.0.0/16 Bridge

When you install Docker on a Linux host, it creates a virtual network bridge called docker0 and assigns it the address 172.17.0.1 from the 172.17.0.0/16 subnet. Every container you run without a custom network gets an address from this range. It works seamlessly on a standalone workstation — until you connect to a corporate VPN that also uses 172.x.x.x addresses.

Why Docker Chose 172.17.0.0/16

Docker needed an address range for its default bridge that would not collide with the most common home and office networks. Most home routers use 192.168.x.x, and large enterprises typically use 10.x.x.x. The 172.16.0.0/12 private range — which includes 172.16.0.0 through 172.31.255.255 — was less commonly used by consumer networking equipment in Docker's early days, so it was a reasonable default. The specific 172.17.0.0/16 subnet was simply the first usable block within that range.

The VPN Conflict Problem

Corporate VPNs frequently allocate addressing from the entire 172.16.0.0/12 range. When a developer connects to the VPN, the VPN client adds routes for 172.16.0.0/12, which overlaps with Docker's 172.17.0.0/16. Traffic destined for containers gets routed through the VPN tunnel instead of the local Docker bridge — and containers become unreachable. The fix is to reconfigure Docker to use a different subnet.

Reconfiguring the Default Bridge

Edit (or create) /etc/docker/daemon.json to specify a different CIDR for the default bridge:

{
  "bip": "192.168.200.1/24"
}

Restart Docker (sudo systemctl restart docker) and the bridge will use 192.168.200.0/24 instead. Choose a subnet that does not overlap with your VPN, corporate network, or other local subnets. Use the CIDR calculator to verify the range and check for overlaps before committing.

User-Defined Networks

For production containers, Docker recommends creating user-defined bridge networks rather than relying on the default. You can specify the subnet explicitly:

docker network create \
  --driver bridge \
  --subnet 10.10.1.0/24 \
  --gateway 10.10.1.1 \
  myapp-network

User-defined networks also enable DNS-based container discovery — containers can reach each other by name instead of IP address, which is far more robust in dynamic environments.

Compose and Kubernetes

Docker Compose creates a network per project, allocating from the 172.16.0.0/12 pool by default. In Kubernetes, pod networking is configured at the cluster level with a dedicated pod CIDR — typically 10.244.0.0/16 for Flannel or 192.168.0.0/16 for Calico. These ranges are separate from your node network and service CIDR. Good planning of these three address spaces avoids the overlap issues that are common in multi-environment setups.