My docker container has no internet
DockerDevopsDocker Problem Overview
I had it working allright but now it stopped. I tried the following commands with no avail:
docker run -dns 8.8.8.8 base ping google.com
docker run base ping google.com
sysctl -w net.ipv4.ip_forward=1
- both on the host and on the container
All I get is unknown host google.com
. Docker version 0.7.0
Any ideas?
P.S. ufw
disabled as well
Docker Solutions
Solution 1 - Docker
First thing to check is run cat /etc/resolv.conf
in the docker container. If it has an invalid DNS server, such as nameserver 127.0.x.x
, then the container will not be able to resolve the domain names into ip addresses, so ping google.com
will fail.
Second thing to check is run cat /etc/resolv.conf
on the host machine. Docker basically copies the host's /etc/resolv.conf
to the container everytime a container is started. So if the host's /etc/resolv.conf
is wrong, then so will the docker container.
If you have found that the host's /etc/resolv.conf
is wrong, then you have 2 options:
-
Hardcode the DNS server in daemon.json. This is easy, but not ideal if you expect the DNS server to change.
-
Fix the hosts's
/etc/resolv.conf
. This is a little trickier, but it is generated dynamically, and you are not hardcoding the DNS server.
1. Hardcode DNS server in docker daemon.json
-
Edit
/etc/docker/daemon.json
{ "dns": ["10.1.2.3", "8.8.8.8"] }
-
Restart the docker daemon for those changes to take effect:
sudo systemctl restart docker
-
Now when you run/start a container, docker will populate
/etc/resolv.conf
with the values fromdaemon.json
.
2. Fix the hosts's /etc/resolv.conf
A. Ubuntu 16.04 and earlier
-
For Ubuntu 16.04 and earlier,
/etc/resolv.conf
was dynamically generated by NetworkManager. -
Comment out the line
dns=dnsmasq
(with a#
) in/etc/NetworkManager/NetworkManager.conf
-
Restart the NetworkManager to regenerate
/etc/resolv.conf
:
sudo systemctl restart network-manager
-
Verify on the host:
cat /etc/resolv.conf
B. Ubuntu 18.04 and later
-
Ubuntu 18.04 changed to use
systemd-resolved
to generate/etc/resolv.conf
. Now by default it uses a local DNS cache 127.0.0.53. That will not work inside a container, so Docker will default to Google's 8.8.8.8 DNS server, which may break for people behind a firewall. -
/etc/resolv.conf
is actually a symlink (ls -l /etc/resolv.conf
) which points to/run/systemd/resolve/stub-resolv.conf
(127.0.0.53) by default in Ubuntu 18.04. -
Just change the symlink to point to
/run/systemd/resolve/resolv.conf
, which lists the real DNS servers:
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
-
Verify on the host:
cat /etc/resolv.conf
Now you should have a valid /etc/resolv.conf
on the host for docker to copy into the containers.
Solution 2 - Docker
Fixed by following this advice:
> [...] can you try to reset everything?
pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d
> It will force docker to recreate the bridge and reinit all the network rules
https://github.com/dotcloud/docker/issues/866#issuecomment-19218300
Seems the interface was 'hung' somehow.
Update for more recent versions of docker:
The above answer might still get the job done for you but it has been quite a long time since this answer was posted and docker is more polished now so make sure you try these first before going into mangling with iptables
and all.
sudo service docker restart
or (if you are in a linux distro that does not use upstart) sudo systemctl restart docker
Solution 3 - Docker
The intended way to restart docker is not to do it manually but use the service
or systemctl
command:
service docker restart
or
systemctl restart docker
Solution 4 - Docker
Updating this question with an answer for OSX (using Docker Machine)
If you are running Docker on OSX using Docker Machine, then the following worked for me:
docker-machine restart
<...wait for it to restart, which takes up to a minute...>
docker-machine env
eval $(docker-machine env)
Then (at least in my experience), if you ping google.com from a container all will be well.
Solution 5 - Docker
I do not know what I am doing but that worked for me :
OTHER_BRIDGE=br-xxxxx # this is the other random docker bridge (`ip addr` to find)
service docker stop
ip link set dev $OTHER_BRIDGE down
ip link set dev docker0 down
ip link delete $OTHER_BRIDGE type bridge
ip link delete docker0 type bridge
service docker start && service docker stop
iptables -t nat -A POSTROUTING ! -o docker0 -s 172.17.0.0/16 -j MASQUERADE
iptables -t nat -A POSTROUTING ! -o docker0 -s 172.18.0.0/16 -j MASQUERADE
service docker start
Solution 6 - Docker
I was using DOCKER_OPTS="--dns 8.8.8.8"
and later discovered and that my container didn't have direct access to internet but could access my corporate intranet. I changed DOCKER_OPTS
to the following:
DOCKER_OPTS="--dns <internal_corporate_dns_address"
replacing internal_corporate_dns_address
with the IP address or FQDN of our DNS and restarted docker using
sudo service docker restart
and then spawned my container and checked that it had access to internet.
Solution 7 - Docker
No internet access can also be caused by missing proxy settings. In that case, --network host
may not work either. The proxy can be configured by setting the environment variables http_proxy
and https_proxy
:
docker run -e "http_proxy=YOUR-PROXY" \
-e "https_proxy=YOUR-PROXY"\
-e "no_proxy=localhost,127.0.0.1" ...
Do not forget to set no_proxy as well, or all requests (including those to localhost) will go through the proxy.
More information: Proxy Settings in the Archlinux Wiki.
Solution 8 - Docker
I was stumped when this happened randomly for me for one of my containers, while the other containers were fine. The container was attached to at least one non-internal network, so there was nothing wrong with the Compose
definition. Restarting the VM / docker daemon did not help. It was also not a DNS issue because the container could not even ping
an external IP. What solved it for me was to recreate the docker network(s). In my case, docker-compose down && docker-compose up
worked.
Compose
This forces the recreation of all networks of all the containers:
docker-compose down
&& docker-compose up
Swarm mode
I suppose you just remove and recreate the service, which recreates the service's network(s):
docker service rm some-service
docker service create ...
If the container's network(s) are external
Simply remove and recreate the external networks of that service:
docker network rm some-external-network
docker network create some-external-network
Solution 9 - Docker
for me, my problem was because of iptables-services was not installed, this worked for me (CentOS):
sudo yum install iptables-services
sudo service docker restart
Solution 10 - Docker
For me it was the host's firewall. I had to allow DNS on the host's firewall. And also had to restart docker after changing the host firewall setting.
Solution 11 - Docker
On centos 8, My problem was that I did not install & start iptables before starting docker service. Make sure iptables service is up and running before you start docker service.
Solution 12 - Docker
Sharing a simple and working solution for posterity. When we run a docker container without explicitly mentioning the --network
flag, it connects to its default bridge network which prohibits connecting to the outside world. To resolve this issue, we have to create our own bridge network(user-defined bridge) and have to explicitly mention it with the docker run command.
docker network create --driver bridge mynetwork
docker run -it --network mynetwork image:version
Solution 13 - Docker
If you're on OSX, you might need to restart your machine after installing Docker. This has been an issue at times.
Solution 14 - Docker
You may have started your docker with dns options --dns 172.x.x.x
I had the same error and removed the options from /etc/default/docker
The lines:
# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="--dns 172.x.x.x"
Solution 15 - Docker
For me it was an iptables forwarding rule. For some reason the following rule, when coupled with docker's iptables rules, caused all outbound traffic from containers to hit localhost:8080
:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080
Solution 16 - Docker
I had the problem on Ubuntu 18.04. However the problem was with the DNS. I was in a corporate network that has its own DNS server and block other DNS servers. This is to block some websites (porn, torrents, ... so on )
To resolve your problem
-
find your DNS on host machine
-
use --dns your_dns as suggested by @jobin
docker run --dns your_dns -it --name cowsay --hostname cowsay debian bash
Solution 17 - Docker
For Ubuntu 19.04 using openconnect 8.3 for VPN, I had to symlink /etc/resolve.conf to the one in systemd (opposite of answerby wisbucky )
sudo ln -sf /etc/resolv.conf /run/systemd/resolve/resolv.conf
Steps to debug
- Connect to Company VPN
- Look for correct VPN settings in either /etc/resolv.conf or /run/systemd/resolve/resolv.conf
- Whichever has the correct DNS settings, we'll symlink that to the other file ( Hint: Place one with correct settings on the left of assignment )
Docker version: Docker version 19.03.0-rc2, build f97efcc
Solution 18 - Docker
Tried all answers, none worked for me.
After a few hours of trying everything else I could find, this did the trick:
reboot
-_-
Solution 19 - Docker
Other answers have stated that the docker0
interface (bridge) can be the source of the problem. On Ubuntu 20.04 I observed that the interface was missing its IP address (to be checked with ip addr show dev docker0
). Restarting Docker alone did not help. I had to delete the bridge interface manually.
sudo ip link delete docker0
sudo systemctl restart docker
Solution 20 - Docker
On windows (8.1) I killed the virtualbox interface (via taskmgr) and it solved the issue.
Solution 21 - Docker
Originally my docker container was able to reach the external internet (This is a docker service/container running on an Amazon EC2).
Since my app is an API, I followed up the creation of my container (it succeeded in pulling all the packages it needed) with updating my IP Tables to route all traffic from port 80 to the port that my API (running on docker) was listening on.
Then, later when I tried rebuilding the container it failed. After much struggle, I discovered that my previous step (setting the IPTable port forwarding rule) messed up the docker's external networking capability.
Solution: Stop your IPTable service:
sudo service iptables stop
Restart The Docker Daemon:
sudo service docker restart
Then, try rebuilding your container. Hope this helps.
Follow Up
I completely overlooked that I did not need to mess with the IP Tables to forward incoming traffic to 80 to the port that the API running on docker was running on. Instead, I just aliased port 80 to the port the API in docker was running on:
docker run -d -p 80:<api_port> <image>:<tag> <command to start api>
Solution 22 - Docker
for me, using centos 7.4, it was not issue of /etc/resolve.conf, iptables, iptables nat rules nor docker itself. The issue is the host missing the package bridge-utils which docker require to build the bridge using command brctl. yum install -y bridge-utils and restart docker, solve the problem.
Solution 23 - Docker
it help me:
sudo ip link delete docker0
sudo systemctl stop docker.socket
sudo systemctl stop docker.service
sudo systemctl start docker.socket
sudo systemctl start docker.service
NOTE: after this, interface docker0 must have ip adress smth like that:
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
Solution 24 - Docker
Just adding this here in case someone runs into this issue within a virtualbox container running docker. I reconfigured the virtualbox network to bridged instead of nat, and the problem went away.
Solution 25 - Docker
There are lot of good answer already. I faced similar problem in my orange pi pc running armbian recently. Docker container was blocked to internet. This command solve the problem in my case. So I like to share it
docker run --security-opt seccomp=unconfined imageName
Solution 26 - Docker
I've tried most answers in here, but the only thing that worked was re-creating the network:
$ docker network rm the-network
$ docker network create --driver=bridge the-network
I also needed to re-create the docker container that used it:
$ sudo docker create --name the-name --network the-network
Then it started with internet access.
Solution 27 - Docker
I am on Arch Linux and after trying all the above answers I realized that I had a firewall enabled in my machine, nftables
, and disabling it did the trick. I did :
sudo systemctl disable nftables
sudo systemctl stop nftables
sudo reboot
My network cards:
➜ ~ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether 68:f7:28:84:e7:fe brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether d0:7e:35:d2:42:6d brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:43:3f:ff:94 brd ff:ff:ff:ff:ff:ff
5: br-c51881f83e32: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:ae:34:49:c3 brd ff:ff:ff:ff:ff:ff
6: br-c5b2a1d25a86: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:72:d3:6f:4d brd ff:ff:ff:ff:ff:ff
8: veth56f42a2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
link/ether 8e:70:36:10:4e:83 brd ff:ff:ff:ff:ff:ff link-netnsid 0
and my firewal configuration, /etc/nftables.conf
, which I now disabled and will futurely try to improve so I can have the docker0
network card rules setup correctly:
#!/usr/bin/nft -f
# vim:set ts=2 sw=2 et:
# IPv4/IPv6 Simple & Safe firewall ruleset.
# More examples in /usr/share/nftables/ and /usr/share/doc/nftables/examples/.
table inet filter
delete table inet filter
table inet filter {
chain input {
type filter hook input priority filter
policy drop
ct state invalid drop comment "early drop of invalid connections"
ct state {established, related} accept comment "allow tracked connections"
iifname lo accept comment "allow from loopback"
ip protocol icmp accept comment "allow icmp"
meta l4proto ipv6-icmp accept comment "allow icmp v6"
#tcp dport ssh accept comment "allow sshd"
pkttype host limit rate 5/second counter reject with icmpx type admin-prohibited
counter
}
chain forward {
type filter hook forward priority filter
policy drop
}
Solution 28 - Docker
I also encountered such an issue while trying to set up a project using Docker-Compose on Ubuntu.
The Docker had no access to internet at all, when I tried to ping any IP address or nslookup some URL - it failed all the time.
I tried all the possible solutions with DNS resolution described above to no avail.
I spent the whole day trying to find out what the heck is going on, and finally found out that the cause of all the trouble was the antivirus, in particular it's firewall which for some reason blocked Docker from getting the IP address and port.
When I disabled it - everything worked fine.
So, if you have an antivirus installed and nothing helps fix the issue - the problem could be the firewall of the antivirus.
Solution 29 - Docker
I've had a similar problem for the last few days. For me the cause was a combination of systemd, docker and my hosting provider. I'm running up-to-date CentOS (7.7.1908).
My hosting provider automatically generates a config file for systemd-networkd. Starting with systemd 219 which is the current version for CentOS 7, systemd-networkd took control of network-related sysctl parameters. Docker seems to be incompatible with this version and will reset the IP-Forwarding flags everytime a container is launched.
My solution was to add IPForward=true
in the [Network]
-section of my provider-generated config file. This file might be in several places, most likely in /etc/systemd/network
.
The process is also described in the official docker docs: https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems
Solution 30 - Docker
Just run
sudo apt install bridge-utils
Solution 31 - Docker
After struggling for hours I finally solved my problem
The issue was of linux using old version of libseccomp2
Get signing keys to verify the new packages, otherwise they will not install
rpi ~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
Add the Buster backport repository to apt sources.list
rpi ~$ echo 'deb http://httpredir.debian.org/debian buster-backports main contrib non-free' | sudo tee -a /etc/apt/sources.list.d/debian-backports.list
rpi ~$ sudo apt update
rpi ~$ sudo apt install libseccomp2 -t buster-backports
After this try
rpi ~$ docker run -it --rm alpine:3.15.0
(alpine shell)# apk update
apk update
will fetch and hence your are connected to internet
I was using
Linux raspberrypi 5.10.63-v7l+ #1496 SMP Wed Dec 1 15:58:56 GMT 2021 armv7l GNU/Linux
you may check using uname -a
Solution 32 - Docker
In my case, for some unknown reason, docker was configured (by someone else) to not generate the iptables rules containers need for networking. The docker container could only ping the host, nothing else. Most answers here did not help; recreating the bridge nor restarting the service changed anything.
But then, by pure chance, I found the following:
$ cat /etc/docker/daemon.json
{"iptables": false}
I deleted the file /etc/docker/daemon.json
and restarted the daemon (default is to create the iptables rules). This solved the networking problem.
Below, the iptables rules before the fix:
$ iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Now, the iptables rules after the fix:
$ iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-1 all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (2 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:8443
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0
DROP all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0