I've installed docker on a fresh ubuntu desktop 18.04 machine and I lost internet connection in the host immediately after the installation finished. More specifically, I can ping but I can't ping www.google.com.

The steps to reproduce the error are the following:

  1. Install ubuntu 18.04
  2. Install docker-ce using a local DNS server.


The most important difference between a clean install and my situation is that my machine is using a local DNS server, which has a fixed address at and in a corporate network.

From what I've read so far, either the problem comes from NetworkManager's attempt to manage the docker0 interface or something in the docker installation process breaks systemd resolve capabilities. Note that systemd-resolve uses by default

So far I've attempted the following:

So far the only thing that works is hardcoding the google dns server address in resolv.conf, which is not a clean approach in my opinion. I also have to automate this process on startup, which is something I don't like.

How does one properly fix the NetworkingManager problem in a development machine that has docker?

Current environment

My default resolv.conf has


and systemd-resolve --status returns (I've checked with a colleague and we have the same output)

          DNSSEC NTA: 10.in-addr.arpa

Link 4 (docker0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (eno1)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers:

Link 2 (eno2)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

ifconfig docker0

bluesmonk@laptop:/etc/NetworkManager$ ifconfig docker0
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        ether 02:42:86:e0:f0:94  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

and the status of the docker service

$ sudo service docker status
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-07-03 10:17:35 -04; 4min 52s ago
     Docs: https://docs.docker.com
 Main PID: 14992 (dockerd)
    Tasks: 31
   CGroup: /system.slice/docker.service
           ├─14992 /usr/bin/dockerd -H fd://
           └─15015 docker-containerd --config /var/run/docker/containerd/containerd.toml

jul 03 10:17:32 laptop dockerd[14992]: time="2018-07-03T10:17:32.981563020-04:00" level=warning msg="Your kernel does not support swap memory limit"
jul 03 10:17:32 laptop dockerd[14992]: time="2018-07-03T10:17:32.981595408-04:00" level=warning msg="Your kernel does not support cgroup rt period"
jul 03 10:17:32 laptop dockerd[14992]: time="2018-07-03T10:17:32.981603807-04:00" level=warning msg="Your kernel does not support cgroup rt runtime"
jul 03 10:17:32 laptop dockerd[14992]: time="2018-07-03T10:17:32.982040899-04:00" level=info msg="Loading containers: start."
jul 03 10:17:34 laptop dockerd[14992]: time="2018-07-03T10:17:34.403909997-04:00" level=info msg="Default bridge (docker0) is assigned with an IP address Daemon option --bip can be used
jul 03 10:17:35 laptop dockerd[14992]: time="2018-07-03T10:17:35.083366302-04:00" level=info msg="Loading containers: done."
jul 03 10:17:35 laptop dockerd[14992]: time="2018-07-03T10:17:35.458766295-04:00" level=info msg="Docker daemon" commit=9ee9f40 graphdriver(s)=overlay2 version=18.03.1-ce
jul 03 10:17:35 laptop dockerd[14992]: time="2018-07-03T10:17:35.458857295-04:00" level=info msg="Daemon has completed initialization"
jul 03 10:17:35 laptop dockerd[14992]: time="2018-07-03T10:17:35.470042819-04:00" level=info msg="API listen on /var/run/docker.sock"
jul 03 10:17:35 laptop systemd[1]: Started Docker Application Container Engine.
lines 1-20/20 (END)

Related to my machine

 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Wed Jun 20 21:43:51 2018
 OS/Arch:      linux/amd64
 Experimental: false
 Orchestrator: swarm

  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Wed Jun 20 21:42:00 2018
  OS/Arch:      linux/amd64
  Experimental: false

docker info:

docker info
Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 1
Server Version: 18.03.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
  Profile: default
Kernel Version: 4.15.0-23-generic
Operating System: Ubuntu 18.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 31.38GiB
Name: bluesmonk-ubuntu
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
Live Restore Enabled: false

WARNING: No swap limit support

about the distro

$ cat /etc/*release
VERSION="18.04 LTS (Bionic Beaver)"
PRETTY_NAME="Ubuntu 18.04 LTS"

Probably related


ps: I've opened a question in the docker forums with the same info https://forums.docker.com/t/cant-access-internet-after-installing-docker-in-a-fresh-ubuntu-18-04-machine/53416

  • Does your host have an interface on the same network as the DNS server? What is the address that docker assigns to the docker0 interface?
    – larsks
    Dec 4, 2018 at 16:05
  • Adresses of DNS Servers are and and if I'm answering your question right, ip a show docker0 (or ifconfig docker0) shows inet
    – bluesmonk
    Dec 4, 2018 at 18:03
  • and ip a show eno2 which is my host interface shows inet
    – bluesmonk
    Dec 4, 2018 at 18:28
  • More answers here, but this is a really frustrating problem to work around especially for a vpn: serverfault.com/questions/916941/…
    – jozxyqk
    Aug 11, 2020 at 0:34

2 Answers 2


So here's your problem:

Docker has assigned the range to your docker0 interface. This includes all addresses from through You will note that this range includes your DNS servers ( and What you have is a routing problem:

Whenever you host needs to reach your DNS servers, it sees that it has an interface already on the same network (docker0), so it tries to route packets using that interface...which of course go nowhere, which is why your DNS stops working.

Docker doesn't have a simple mechanism for excluding an address range from it's automatic selection process, so you'll probably need to do two things to resolve the problem:

First, explicitly set the address of docker0 in your /etc/docker/daemon.json. Use any network that doesn't conflict your internal networks. E.g.:

  "bip": ""

You'll need to restart Docker.

Next, to prevent Docker from selecting the same network range for a user defined network (one that you create explicitly using docker network create or implicitly using, e.g., docker-compose or docker stack ...), create a new network and then never use it:

docker network create --subnet --config-only do_not_use

This should both resolve your problem and prevent it from cropping back up in the future.


Docker actually documents an arguably better way of accomplishing this in How do I influence which network address ranges Docker chooses during a 'docker network create'?.

This requires setting persistent static routes on your system, which varies between Linux distributions.

  • 1
    I'm adding this for the sake of completeness. After changing "bip", some stray networks left were still conflicting with my DNS (and later I found out also with the VPN server) So I did the following: 1. stopped containers using those networks 2. docker network prune until no conflicting network remained 3. next time I run compose up it would fail because some networks were obviously missing, so I did compose up --force-recreate
    – bluesmonk
    Dec 5, 2018 at 14:17
  • 1
    I am running into this same exact case on 18.04. We have 16.04 systems that this does NOT happen on. Why? Feb 1, 2019 at 22:18
  • 1
    I'm not sure but my guess is that network management works differently between versions of Ubuntu
    – bluesmonk
    Apr 24, 2019 at 18:41
  • I'm having this problem on 19.10, I don't have a /etc/docker/daemon.json file! Should I create it? And not really sure how to add a route that the article on docker.com is talking about.
    – barro32
    Mar 2, 2020 at 14:16
  • 2
    You can just create the daemon.json file.
    – larsks
    Mar 2, 2020 at 14:24

systemd-resolve --status gave me a DNS server of and ifconfig docker0 gave me: inet netmask broadcast All I had to do was to add /etc/docker/daemon.json as above and restart docker

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.