A Docker network is allocated 172.20.0.0/16, which the corporate VPN also routes. How do you fix the collision?

### Why a collision breaks things Docker's allocator picks from a list of private ranges that a great many enterprises also use — 172.16.0.0/12 in particular is extremely common inside corporate networks and VPNs. When the daemon hands a network 172.20.0.0/16, it also installs a route on the host sending that whole block to the bridge interface. Now the host has two ways to reach 172.20.x.x: the VPN's route and the local bridge route. The local, directly-connected route wins, so packets aimed at a colleague's internal service on 172.20.4.9 go to the bridge, find nothing, and time out. From inside a container it is the same story from one hop further in. The reason this bites laptops especially hard is timing. The allocator does check the host routing table before it takes a candidate pool, so if the VPN is already up when the network is created, Docker usually skips the range. But developers create networks with the VPN down and connect later, and the network keeps the subnet it was given — allocation is a one-time decision, not something re-evaluated when routes change. ### Fixing one network If only one network is in the way, give it an address block explicitly instead of letting the allocator choose: ``` docker network rm checkout-net docker network create --subnet 10.42.7.0/24 --gateway 10.42.7.1 checkout-net ``` Where the network is created by a file rather than by hand, put the same subnet in that file's IPAM section so it is reproduced on every machine. The important part is that the choice is recorded somewhere, not typed once. ### Fixing the host One network at a time does not scale, and it does not help the *next* network, which the allocator will happily place back in the same neighbourhood. The host-wide control is `/etc/docker/daemon.json`: ``` { "bip": "10.202.0.1/24", "default-address-pools": [ { "base": "10.203.0.0/16", "size": 24 }, { "base": "10.204.0.0/16", "size": 24 } ] } ``` `default-address-pools` replaces the built-in candidate list. Each entry gives a `base` block and a `size`, and `size` is the prefix length of each network carved from that base — so a /16 base at size 24 yields 256 networks of 254 usable addresses each. `bip` (bridge IP) is separate: it sets the address and subnet of `docker0` itself, written as the gateway address with a prefix, and it is the reliable way to move the default bridge specifically. Restart the daemon after editing (`systemctl restart docker`); on Docker Desktop the same JSON is edited through the engine settings pane and the engine restarts itself. Validate the JSON before restarting. A syntax error in `daemon.json` stops the daemon from coming back up, which turns a routing annoyance into an outage. ### The step people forget Changing the pools changes nothing that already exists. Subnets are assigned when a network is created and are immutable afterwards, so every network already sitting on 172.20.0.0/16 stays there until you remove and recreate it: ``` docker network ls --filter driver=bridge docker network rm <name> # after disconnecting or stopping its containers ``` Then recreate them and verify: ``` docker network inspect <name> -f '{{range .IPAM.Config}}{{.Subnet}}{{end}}' ``` A candidate who edits the config, restarts, and declares victory without re-creating the networks has not fixed the machine. ### Choosing the replacement range Do not simply move one square along and hope. Ask the network team which blocks are genuinely unrouted — in a large enterprise most of 10.0.0.0/8 is spoken for too, and the answer is usually a specific allocation reserved for container hosts. Two properties matter: nothing on any VPN, peering link or partner network routes it, and it is big enough that the size you choose leaves plenty of networks. Because container ranges are host-local and NAT'd on the way out, the same block can be reused identically on every host, which is what makes it practical to bake the file into configuration management and have every machine addressed the same way. ### Distinguishing the failure One diagnostic sentence separates this from every other networking complaint: the destination that fails is *inside a range Docker owns locally*. `ip route get 172.20.4.9` on the host naming a bridge interface rather than the VPN interface proves it in one command, and no amount of DNS or firewall investigation would have found it.