moby: Containers cannot access internet (outbound)
I cannot access the internet from my containers, however inbound connections still work. As far as I know the problem occurred without human intervention (“it was working fine and now it isn’t”)
Steps to reproduce the issue:
nepoxx@host:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=12.7 ms
...
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 12.683/12.834/13.345/0.239 ms
nepoxx@host:~$ docker run -i --rm alpine ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss
I had this issue with docker 1.13, I’ve upgraded to 17.12.0-ce in the hopes that it would fix it but it didn’t help. I’ve restarted both docker and the host. I’ve tried:
pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d
to no avail
Output of docker version
:
Docker version 17.12.0-ce, build c97c6d6
Output of docker info
:
Containers: 3
Running: 2
Paused: 0
Stopped: 1
Images: 13
Server Version: 17.12.0-ce
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 74
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
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: 89623f28b87a6004d4b785663257362d1658a729
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-112-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.85GiB
Name: host
ID: K4EK:CQHO:MGWH:HFFS:IWHS:NIAN:WMXE:6VHX:6AM3:CPQ5:A3AD:6GS3
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Additional environment details (AWS, VirtualBox, physical, etc.):
Linux host 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
For the record the following works:
docker run -i --net=host --rm alpine ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=59 time=15.757 ms
...
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 12.835/14.595/16.393 ms
edit: I even tried sudo iptables -F
to make sure it wasn’t the issue, and that didn’t solve it. Using host networking mode works fine.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 20
- Comments: 51 (1 by maintainers)
For anyone running into this, rebooting the OS fixed it.
Has anyone managed to solve this any other way?
I’ve tried restarting the Docker service, rebooting the OS, and forcing a bridge rebuild. No success so far.
I’m running
Ubuntu 18.10 (Pop!_OS 18.10)
andDocker version 18.06.1-ce, build e68fc7a
.Solved it for me:
Since systemd version >=219 ip forwarding (net.ipv4.conf.interfaceName.forwarding) is off by default. To activate I had to place the option IPForward=true in the respective systemd network config file:
After restart of systemd-networkd (
systemctl restart systemd-networkd
) everything works as expected.Reference: https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems
try
systemctl stop firewalld
or
firewall-cmd --permanent --zone=trusted --change-interface=docker0
firewall-cmd --reload
systemctl restart docker
After A LOT of time trying to solve this issue I think I finally found a solution in an ebook I found on the internet.
Here’s the steps I took to solve the issue:
Edit the file and uncomment the DOCKER_OPTS option modifying it to somthing like this:
DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4 --iptables=false --ip-forward=false"
Now hopefully your containers have access to the internet again.
I hope to help someone 😃
I’ve had a similar networking problem and found a solution…
Under an hypervisor, I had made a template out of a plain Docker VM. I then cloned it into 3 different hosts, clearly sharing the exact same config and data, at least at first boot.
From there on, I started having containers unable to reach the internet.
The solution? Wipe all configs and data.
Seems like Docker re-configures itself in that case. The next thing I’ve realized, my containers started working flawlessly.
Enabling ip forwarding (which had become suddenly disabled in the host) worked for me.
sudo sysctl net.ipv4.ip_forward=1
I used to stop nftables before starting docker :
systemctl stop nftables
systemctl start docker
It stopped working, containers couldn’t reach internet.
Disabling nftables and rebooting fixed the issue :
systemctl disable nftables
reboot
systemctl start docker
Will try downgrading nftables.
for me Rebooting the OS worked.
After three years of using docker without problems, this issue is affecting me today. The only two new things at the time it showed up are (1) used a debian container for the first time, (2) added my user to the docker group and began using docker without sudo.
Attempted fixes which did not work:
sudo systemctl restart docker
Toggle
--iptables
dockerd switch between true and false, restarting docker service between toggles.Adding VIF using
sudo brctl addif docker0 <vif>
.Forcing rebuild of bridge
I am using docker
version 17.12.1-ce, build 7390fc6
on Ubuntu 17.10.What worked for me is loading the
br_netfilter
kernel module:This was on a CentOS 7 node, where I had to upgrade the kernel before I could load the kernel module.
Another possible solution is to run the
docker0
interface in promiscuous mode:I’m also seeing this issue on Ubuntu 16 & 18 LTS:
Same things with different image:
Docker Version:
Things I’ve attempted to fix this issue with no luck:
--iptables
flagiptables -F
Note, this is happening out of the box. The first thing I did after I setup my new Ubuntu 18 OS was install docker / docker-compose and ran
docker run --rm alpine ping -c 2 www.google.com
.Also wanted to point out that using the
host
network driver allows me to make any requests to the outside world. But, using the default bridge or a custom network (with the bridge driver) results in no access to the internet.Really hoping this can be resolved 🙏
Lost my whole day to this. A reboot (Win 10) worked in the end. Thanks @expz
reboot
helped.For me, this problem occurred because I was using nftables and had installed my own
inet filter
table for both ipv4 and ipv6. This table default-dropped traffic from docker. Now you’d think that docker installs rules to get around this default drop throughiptables-nft
, but that only affects theip filter
table. Both tables need to accept the traffic.Thank you!! Your solution works for me!
I’m sorry to say this but it really sounds that you are seeing this issue because you are using non-supported configuration(s).
@trinhpham combination of Windows Server and CE version of Docker is not supported. Please use either Win 10 with Docker CE (if you need Linux support) or Win Srv with enterprise edition.
@DMeechan I have ever heard about Pop!_OS but I guess that it causes your problem. Please, test with normal version of Ubuntu and latest Docker-CE version
@prakashs-treselle I think that AWS Linux 2 is not supported Docker host OS. How ever you can run it inside of Docker.
@jobinau please check that you don’t have any special iptables rules. Docker uses iptables to provide networking for containers.
Here is example from Ubuntu box with standard config and latest version of Docker:
And here is same from Windows Server 2019 with latest Docker version on Azure:
In my case, the reboot of the OS probably solved the problem because it killed the VPN connection and restarted the docker service. There is some conflict between my VPN connection and the docker networking setup. You could also try the four methods I listed.