https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Bug ID: 1033606 Summary: Failed to connect to network from Docker container Product: Fedora Version: 20 Component: docker-io Assignee: lsm5@redhat.com Reporter: mfojtik@redhat.com QA Contact: extras-qa@fedoraproject.org CC: golang@lists.fedoraproject.org, lsm5@redhat.com, mattdm@redhat.com, mgoldman@redhat.com, vbatts@redhat.com
Description of problem:
Connecting to external network from Docker container fail due to firewalld. I guess you must have masquerade enabled, however this is not mentioned anywhere. I think docker-io should set the firewalld rules automatically, or tell users that they need to enable masquarade in firewalld.
Version-Release number of selected component (if applicable):
Name : docker-io Arch : x86_64 Version : 0.7 Release : 0.17.rc6.fc20
Steps to Reproduce: 1. $ yum install docker-io 2. $ systemctl enable docker.service 3. $ systemctl start docker.service 4. $ docker pull mattdm/fedora 5. $ docker run -i -t mattdm/fedora:latest /bin/bash 6. $ ping google.com ping: unknown host google.com
When I stop firewalld on host (systemctl stop firewalld) and then restart the docker (systemctl restart docker), the ping works like a charm.
Actual results:
Unable to connect outside the Docker container with firewalld enabled.
Expected results:
Docker should configure firewalld automatically (during install?), or inform users to do so manually.
Additional info:
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Lokesh Mandvekar lsm5@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jpoimboe@redhat.com
--- Comment #1 from Lokesh Mandvekar lsm5@redhat.com --- Josh,
looks like something similar to Bug 1026045 is happening again. is this a known issue?
Just verified it on 0.7-0.19.rc7.fc19
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #2 from Josh Poimboeuf jpoimboe@redhat.com --- I installed docker-io-0.7-0.19.rc7.fc19.x86_64 but wasn't able to recreate. Is it possible you ran an older version of docker without rebooting before trying this version? Can you post the output of "iptables -Lv"?
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #3 from Josh Poimboeuf jpoimboe@redhat.com --- correction: iptables -L -v
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #4 from Marek Goldmann mgoldman@redhat.com --- Created attachment 829120 --> https://bugzilla.redhat.com/attachment.cgi?id=829120&action=edit iptables output
I can see this issue as well, with the upcoming 0.7.0-1 release, attaching my iptables output.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #5 from Marek Goldmann mgoldman@redhat.com --- We have following rules executed:
The systemd service (before docker starts):
/usr/sbin/sysctl -w net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
And docker runs this on its own:
lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-D FORWARD -i docker0 -o docker0 -j DROP] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-C FORWARD -i docker0 -o docker0 -j ACCEPT] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -D PREROUTING -m addrtype --dst-type LOCAL -j DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -D OUTPUT -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -D OUTPUT -m addrtype --dst-type LOCAL -j DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -D PREROUTING -j DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -D OUTPUT -j DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -F DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -X DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -N DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER] lis 26 10:43:15 mistress docker[11602]: [DEBUG] [iptables]: /usr/sbin/iptables, [-t nat -A OUTPUT -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER]
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #6 from Marek Goldmann mgoldman@redhat.com --- After boot I cannot connect to the Internet from container, but when I do:
systemctl restart firewalld systemctl restart docker
then I can. Restarting docker service alone does not help. Adding hard requires to docker systemd file in the [Unit] section:
Requires=firewalld.service
doesn't help either. BTW, we should add "Wants=firewalld.service" to make sure the firewalld service is started before Docker, if it's available.
I suspect that the issue is in the time which is needed to create all the required devices. If we add:
ExecStartPre=/usr/bin/sleep 3
to the [Service] section makes it possible to connect to the Internet from the container. Even 1s is sufficient on my system.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #7 from Michal Fojtik mfojtik@redhat.com --- FYI I was playing with this and I discover this (dunno if it helps):
[root@localhost redis-server]# docker run -i -t mattdm/fedora /bin/bash bash-4.2# ping google.com ping: unknown host google.com
[root@localhost redis-server]# systemctl stop firewalld [root@localhost redis-server]# docker run -i -t mattdm/fedora /bin/bash lxc-start: failed to attach 'vethkb9kR0' to the bridge 'docker0' : No such device lxc-start: failed to create netdev lxc-start: failed to create the network lxc-start: failed to spawn '1db793c53b22a2fda433a9ce2ddbb9022cca6a0c33126389ac95ca7b176c947c' [error] commands.go:2459 Error resize: Error: bad file descriptor
[root@localhost redis-server]# systemctl restart docker
[root@localhost redis-server]# docker run -i -t mattdm/fedora /bin/bash bash-4.2# ping google.com PING google.com (173.194.41.135) 56(84) bytes of data.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #8 from Michal Fojtik mfojtik@redhat.com --- Marek: http://fpaste.org/56877/38547748/
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #9 from Josh Poimboeuf jpoimboe@redhat.com --- This isn't right:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
There should be more docker-related rules there. Is there a unit file that creates the docker0 device before docker starts? If so, remove it so that docker can create it and set up its iptables rules.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #10 from Marek Goldmann mgoldman@redhat.com --- (In reply to Josh Poimboeuf from comment #9)
There should be more docker-related rules there. Is there a unit file that creates the docker0 device before docker starts? If so, remove it so that docker can create it and set up its iptables rules.
This is what I have:
$ systemctl list-units -a | grep docker sys-devices-virtual-net-docker0.device loaded active plugged /sys/devices/virtual/net/docker0 sys-subsystem-net-devices-docker0.device loaded active plugged /sys/subsystem/net/devices/docker0 docker.service loaded inactive dead Docker container management daemon
And indeed, the docker0 interface is up, even when we stop the docker service.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #11 from Josh Poimboeuf jpoimboe@redhat.com --- Ok. Removing those unit files and rebooting should fix the issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #12 from Marek Goldmann mgoldman@redhat.com --- (In reply to Josh Poimboeuf from comment #11)
Ok. Removing those unit files and rebooting should fix the issue.
Josh, above are devices. These cannot be listed with the "systemctl list-unit-files" command. I think the real issue is that docker leaves the docker0 interface running, even after we stop the service. WDYT?
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #13 from Josh Poimboeuf jpoimboe@redhat.com ---
Josh, above are devices. These cannot be listed with the "systemctl list-unit-files" command. I think the real issue is that docker leaves the docker0 interface running, even after we stop the service. WDYT?
Sorry, I misunderstood. It should be ok for docker to leave the docker0 bridge device after it exits. In fact it's probably necessary so that already running containers won't lose their network if the docker daemon has to restart.
When docker starts up, it checks for the existence of docker0. If it doesn't exist then it creates it and sets up the iptables rules appropriately. So future starts of docker will re-use the same bridge device, which should work fine.
The debug trace you posted seemed to show that docker0 already existed. So what I'm still confused about is how is the the docker0 device getting created to start with? It looks like somebody created docker0 without setting up its needed iptables rules.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #14 from Marek Goldmann mgoldman@redhat.com --- (In reply to Josh Poimboeuf from comment #13)
Sorry, I misunderstood. It should be ok for docker to leave the docker0 bridge device after it exits. In fact it's probably necessary so that already running containers won't lose their network if the docker daemon has to restart.
When docker starts up, it checks for the existence of docker0. If it doesn't exist then it creates it and sets up the iptables rules appropriately. So future starts of docker will re-use the same bridge device, which should work fine.
OK, this makes sense.
The debug trace you posted seemed to show that docker0 already existed. So what I'm still confused about is how is the the docker0 device getting created to start with? It looks like somebody created docker0 without setting up its needed iptables rules.
I wouldn't assume this, since the rules are executed no matter if the docker0 interface is started up or not:
https://github.com/dotcloud/docker/blob/v0.7.0/iptables/iptables.go#L105
This bridge was created by running the systemd service, no other tool created it.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #15 from Josh Poimboeuf jpoimboe@redhat.com ---
The debug trace you posted seemed to show that docker0 already existed. So what I'm still confused about is how is the the docker0 device getting created to start with? It looks like somebody created docker0 without setting up its needed iptables rules.
I wouldn't assume this, since the rules are executed no matter if the docker0 interface is started up or not:
https://github.com/dotcloud/docker/blob/v0.7.0/iptables/iptables.go#L105
This bridge was created by running the systemd service, no other tool created it.
Actually the rules that seem to be missing are the ones in the FORWARD table, which are created whenever the docker0 bridge is created:
https://github.com/dotcloud/docker/blob/v0.7.0/network.go#L180
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Marek Goldmann mgoldman@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|lsm5@redhat.com |mgoldman@redhat.com
--- Comment #16 from Marek Goldmann mgoldman@redhat.com --- Thanks Josh!
It looks like the iptables rules creation in docker is wrong. It assumes that the bridge interface is started every time. I created a patch which can be found here: https://github.com/goldmann/docker/commit/0ff9bc1be3ae044107732c605986a0af20...
Additionally I prepared a scratch build for Fedora 20 (x86_64) with this patch already applied, please test the build and let me know if this fixes the issue:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6231401
I'm going to open an upstream bug report for this.
P.S. I'm assigning this ticket to me.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #17 from Marek Goldmann mgoldman@redhat.com --- Please use this scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=6231502
I've added this to the docker.service:
[Unit] ... Requires=firewalld.service After=firewalld.service
To make sure the iptables rules are executed after the firewalld is actually running (if available) to prevent seeing network connectivity issues after boot.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #18 from Marek Goldmann mgoldman@redhat.com --- Upstream pull request opened: https://github.com/dotcloud/docker/pull/2907
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #19 from Lokesh Mandvekar lsm5@redhat.com --- +1
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #20 from Lokesh Mandvekar lsm5@redhat.com --- hmm, so it seems if i try a docker pull after immediately starting docker service, it'll complain /var/run/docker.sock no such file or directory, but it seems to work well after sometime. This could vary between machines though, also sometimes it'll work right away
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #21 from Josh Poimboeuf jpoimboe@redhat.com --- (In reply to Marek Goldmann from comment #16)
Thanks Josh!
It looks like the iptables rules creation in docker is wrong. It assumes that the bridge interface is started every time. I created a patch which can be found here: https://github.com/goldmann/docker/commit/ 0ff9bc1be3ae044107732c605986a0af20220134
AFAICT, the FORWARD rules only need to be created once, at bridge creation time. The bridge device and the FORWARD rules are never removed. They can then be re-used if the docker daemon exits and restarts.
It seems like somebody is either a) creating the bridge without creating the rules or b) removing the rules without removing the bridge. I still don't understand what's happening here.
That said, the patch itself looks fine to me. And it might be a good idea anyway, to make sure the rules are always correct.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #22 from Lokesh Mandvekar lsm5@redhat.com --- i'm planning to push in Marek's pull request commit 0ff9bc1 to yum
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #23 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-6.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/docker-io-0.7.0-6.fc20
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #24 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-6.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/docker-io-0.7.0-6.fc19
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #25 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-9.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/docker-io-0.7.0-9.fc20
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #26 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-9.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/docker-io-0.7.0-9.fc19
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #27 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-9.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/docker-io-0.7.0-9.el6
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #28 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-10.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/docker-io-0.7.0-10.fc20
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #29 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-10.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/docker-io-0.7.0-10.fc19
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #30 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-10.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/docker-io-0.7.0-10.el6
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #31 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-10.fc20 has been pushed to the Fedora 20 testing repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Michal Fojtik mfojtik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |MODIFIED
--- Comment #32 from Michal Fojtik mfojtik@redhat.com --- After update and reboot, I can still reproduce this problem. Now is even worse, because stopping firewalld does not help:
[root@localhost ~]# docker run -i -t mattdm/fedora /bin/bash bash-4.2# ping google.com ping: unknown host google.com
[root@localhost ~]# systemctl status firewalld firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled) Active: active (running) since Fri 2013-11-29 23:06:35 CET; 4min 41s ago
[root@localhost ~]# systemctl status docker docker.service - Docker container management daemon Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled) Active: active (running) since Fri 2013-11-29 23:09:39 CET; 1min 56s ago Process: 2451 ExecStartPre=/usr/sbin/sysctl -w net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 (code=exited, status=0/SUCCESS) Main PID: 2452 (docker) CGroup: /system.slice/docker.service ├─2452 /usr/bin/docker -d ├─2557 lxc-start -n a98a431f8b6c8666ed6a77265f48ee883b737059cd932677f37f390df1d7ef8d -f /var/lib/docker/containers/a98a431f8b6c8666ed6a77265f48ee883b737059cd932677f37f390df1d7ef8d/... └─2564 /bin/bash
Nov 29 23:10:47 localhost.localdomain docker[2452]: 2013/11/29 23:10:47 POST /v1.7/containers/create Nov 29 23:10:47 localhost.localdomain docker[2452]: [/var/lib/docker|aa7b0df9] +job create() Nov 29 23:10:48 localhost.localdomain docker[2452]: 0f3196cd4b7f343a3a487bd38860c92ad289fc66ffa672c9583a484844c07962 Nov 29 23:10:48 localhost.localdomain docker[2452]: [/var/lib/docker|aa7b0df9] -job create() = OK (0) Nov 29 23:10:48 localhost.localdomain docker[2452]: 2013/11/29 23:10:48 POST /v1.7/containers/0f3196cd4b7f343a3a487bd38860c92ad289fc66ffa672c9583a484844c07962/attach?stderr=1&stdi...t=1&stream=1 Nov 29 23:10:48 localhost.localdomain docker[2452]: 2013/11/29 23:10:48 POST /v1.7/containers/0f3196cd4b7f343a3a487bd38860c92ad289fc66ffa672c9583a484844c07962/start Nov 29 23:10:48 localhost.localdomain docker[2452]: [/var/lib/docker|aa7b0df9] +job start(0f3196cd4b7f343a3a487bd38860c92ad289fc66ffa672c9583a484844c07962) Nov 29 23:10:48 localhost.localdomain docker[2452]: [/var/lib/docker|aa7b0df9] -job start(0f3196cd4b7f343a3a487bd38860c92ad289fc66ffa672c9583a484844c07962) = OK (0) Nov 29 23:10:48 localhost.localdomain docker[2452]: 2013/11/29 23:10:48 POST /v1.7/containers/0f3196cd4b7f343a3a487bd38860c92ad289fc66ffa672c9583a484844c07962/resize?h=47&w=194 Nov 29 23:11:12 localhost.localdomain docker[2452]: 2013/11/29 23:11:12 GET /v1.7/containers/0f3196cd4b7f343a3a487bd38860c92ad289fc66ffa672c9583a484844c07962/json Hint: Some lines were ellipsized, use -l to show in full.
Version:
Name : docker-io Arch : x86_64 Version : 0.7.0 Release : 10.fc20
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #33 from Lokesh Mandvekar lsm5@redhat.com --- Michal, can you change your Requires=firewalld.service to Wants=firewalld.service as in Bug 1036217 and check if it helps?
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #34 from Michal Fojtik mfojtik@redhat.com --- Lokesh: I tried, but unfortunatelly it did not help. However, the behavior changed a bit (note I do a full reboot after the change).
[root@localhost ~]# systemctl stop firewalld [root@localhost ~]# docker run -i -t base/arch /bin/bash lxc-start: failed to attach 'vethOjHimB' to the bridge 'docker0' : No such device lxc-start: failed to create netdev lxc-start: failed to create the network lxc-start: failed to spawn '2331a2594cd703ca76f15bf382f0c2724b149c64c6529081cc767beb4c22868d'
After restarting Docker service:
[root@localhost ~]# systemctl restart docker [root@localhost ~]# docker run -i -t base/arch /bin/bash [root@d50801ccec40 /]# ping google.com ping: unknown host google.com
So the result is still the same :-(
BUT, I found the workaround:
[root@localhost ~]# firewall-cmd --add-masquerade success [root@localhost ~]# docker run -i -t base/arch /bin/bash [root@f3b88e508538 /]# ping google.com PING google.com (173.194.35.70) 56(84) bytes of data. 64 bytes from 173.194.35.70: icmp_seq=1 ttl=55 time=14.5 ms
So adding a MASQUARADE in firewalld seems to fix this problem. Can we make this call in Docker service, or alternatively create a 'docker' zone in firewalld and enable MASQUARADE for this zone?
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #35 from Lokesh Mandvekar lsm5@redhat.com --- I could add
ExecStartPost=firewall-cmd --add-masquerade ... to the unit file, unless there's a cleaner solution
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #36 from Lokesh Mandvekar lsm5@redhat.com --- So, this service file should work (works for me) even if firewalld isn't present on the system:
[Unit] Description=Docker container management daemon Wants=firewalld.service After=firewalld.service
[Service] Type=simple ExecStartPre=/usr/sbin/sysctl -w net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 ExecStart=/usr/bin/docker -d ExecStartPost=firewall-cmd --add-masquerade Restart=on-failure
[Install] WantedBy=multi-user.target
Comments?
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #37 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-10.el6 has been pushed to the Fedora EPEL 6 testing repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #38 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-12.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/docker-io-0.7.0-12.fc20
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #39 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-12.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/docker-io-0.7.0-12.fc19
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #40 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-12.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/docker-io-0.7.0-12.el6
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #41 from Marek Goldmann mgoldman@redhat.com --- (In reply to Lokesh Mandvekar from comment #35)
I could add
ExecStartPost=firewall-cmd --add-masquerade ... to the unit file, unless there's a cleaner solution
Please don't do this. This should be already covered in my patch.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #42 from Michal Fojtik mfojtik@redhat.com --- Marek: Is the patch included in docker-io-0.7.0-12.el6?
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #43 from Michal Fojtik mfojtik@redhat.com --- After system update and reboot, the networking and routing to containers seems to work perfectly fine. The --add-masquarade is not longer needed. Lokesh, Marek thanks for help!
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #44 from Lokesh Mandvekar lsm5@redhat.com --- (In reply to Marek Goldmann from comment #41)
Please don't do this. This should be already covered in my patch.
Alright, pushing out another release without masquerade, thanks for the heads up
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #45 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-14.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/docker-io-0.7.0-14.fc20
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #46 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-14.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/docker-io-0.7.0-14.fc19
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #47 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-14.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/docker-io-0.7.0-14.el6
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Fixed In Version| |docker-io-0.7.0-14.el6 Resolution|--- |ERRATA Last Closed| |2013-12-02 20:20:13
--- Comment #48 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-14.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version|docker-io-0.7.0-14.el6 |docker-io-0.7.0-14.fc19
--- Comment #49 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-14.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version|docker-io-0.7.0-14.fc19 |docker-io-0.7.0-14.fc20
--- Comment #50 from Fedora Update System updates@fedoraproject.org --- docker-io-0.7.0-14.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
michael.faille@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael.faille@gmail.com
--- Comment #51 from michael.faille@gmail.com --- I use Fedora 20 freshly updated and the problem persist for me. Docker version : Docker version 0.7.6, build bc3b2ec/0.7.6
Steps to Reproduce: 1. $ yum install docker-io 2. $ systemctl enable docker.service 3. $ systemctl start docker.service 4. $ docker pull mattdm/fedora 5. $ docker run -i -t mattdm/fedora:latest /bin/bash 6. $ ping google.com ping: unknown host google.com
(It also dindn't work with any image)
Watch could I do to quick fix ?
Thank you !
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #52 from Marek Goldmann mgoldman@redhat.com --- Please try again with the fedora:latest image (not mattdm/fedora:latest - it shouldn't be used). If it doesn't work please run:
yum update docker-io --enablerepo updates-testing
to get the 0.8.0 version and try again.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #53 from michael.faille@gmail.com --- Hum, finally, I have the problem when I run a container... and my default route change !
Before starting docker $ ip route default via 192.168.1.1 dev wlp3s0 proto static metric 1024 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1 192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
After starting docker $ ip route default via 192.168.0.1 dev vethyzDqJ5 proto static metric 1024 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1 192.168.0.0/24 dev vethyzDqJ5 proto kernel scope link src 192.168.0.50 192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
The problem persist with firewall activated : sudo systemctl stop firewalld # and start container
sudo sysctl -a | grep ".forwarding net.ipv4.conf.all.forwarding = 1 net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.docker0.forwarding = 1 net.ipv4.conf.lo.forwarding = 1 net.ipv4.conf.p3p1.forwarding = 1 net.ipv4.conf.virbr0.forwarding = 1 net.ipv4.conf.virbr0-nic.forwarding = 1 net.ipv4.conf.wlp3s0.forwarding = 1 net.ipv6.conf.all.forwarding = 1 net.ipv6.conf.default.forwarding = 1 net.ipv6.conf.docker0.forwarding = 1 net.ipv6.conf.lo.forwarding = 1 net.ipv6.conf.p3p1.forwarding = 1 net.ipv6.conf.virbr0.forwarding = 1 net.ipv6.conf.virbr0-nic.forwarding = 1 net.ipv6.conf.wlp3s0.forwarding = 1
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #54 from Marek Goldmann mgoldman@redhat.com --- Could you please provide output of the commands:
docker version rpm -q docker-io rpm -V docker-io
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #55 from michael.faille@gmail.com --- I use Fedora 20 with last update.
sudo rpm -q docker-io docker-io-0.7.6-4.fc20.x86_64
rpm -V docker-io # give me nothing
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #56 from michael.faille@gmail.com --- Ho sorry, I just see your help to update docker. Few min. plz.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #57 from michael.faille@gmail.com --- You have all info in this 20 sec video made with Gnome-Shell record tool : https://www.youtube.com/watch?v=MGKMGzOjrxE&feature=youtu.be
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #58 from Josh Poimboeuf jpoimboe@redhat.com --- Can you post the output of "iptables -vL FORWARD"?
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #59 from michael.faille@gmail.com --- # In the first terminal sudo docker run -i -t fedora /bin/bash
# In the second sudo iptables -vL FORWARD [sudo] password for michael: Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- docker0 docker0 anywhere anywhere 0 0 ACCEPT all -- docker0 !docker0 anywhere anywhere 0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #60 from michael.faille@gmail.com --- When I ping with this on my docker container term with this output 12 packets transmitted, 0 received, +10 errors, 100% packet loss, time 10996ms pipe 3
And executing "sudo iptables -vL FORWARD" after : Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- docker0 docker0 anywhere anywhere 29 2436 ACCEPT all -- docker0 !docker0 anywhere anywhere 0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
It give packets count on the second rule
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #61 from Josh Poimboeuf jpoimboe@redhat.com --- I have no idea why starting a container would affect the host's routing table. Strange...
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #62 from michael.faille@gmail.com --- I think I have this problem since I have make Docker start from boot, cause I'm sure it has worked before that. sudo systemctl enable docker
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #63 from michael.faille@gmail.com --- Weird..... I fix the problem, I know exact what command I done. ...But, I don't know why it work.
My recipe :
#1. finding manual LXC lunch command ps aux | grep docker root 20606 0.0 0.0 154140 5296 pts/4 S+ 06:01 0:00 vim /var/lib/docker/containers/abe17802ba8958c91295fb33831ce769ef393da4f5c7e70cee32713ec165ba85/config.lxc root 22508 0.0 0.0 209328 4072 pts/0 S+ 06:18 0:00 sudo strace -f -s 1000 -o out.trace docker -d root 22514 0.0 0.0 4704 888 pts/0 D+ 06:18 0:00 strace -f -s 1000 -o out.trace docker -d root 22519 0.0 0.0 0 0 pts/0 Zl+ 06:18 0:00 [docker] <defunct> root 22620 0.0 0.0 19192 1228 ? Ss 06:19 0:00 lxc-start -n 3be52160a2e3f7bbbf987726edc83823a938920e39992ee9cd1726f56ca7f99e -f /var/lib/docker/containers/3be52160a2e3f7bbbf987726edc83823a938920e39992ee9cd1726f56ca7f99e/config.lxc -- /.dockerinit -driver lxc -g 172.17.42.1 -i 172.17.0.2/16 -mtu 1500 -- /bin/sh -c apt-get install -y inotify-tools openssh-server root 22631 0.0 0.0 10292 2376 ? Dl 06:19 0:00 /.dockerinit -driver lxc -g 172.17.42.1 -i 172.17.0.2/16 -mtu 1500 -- /bin/sh -c apt-get install -y inotify-tools openssh-server michael 23573 0.0 0.0 112688 968 pts/1 S+ 06:25 0:00 grep --color=auto docker
#2. Shudown all docker/lxc container/process
#3. Run following LXC command to just enter in the shell + test surprisingly internet with success. sudo lxc-start -n 3be52160a2e3f7bbbf987726edc83823a938920e39992ee9cd1726f56ca7f99e -f /var/lib/docker/containers/3be52160a2e3f7bbbf987726edc83823a938920e39992ee9cd1726f56ca7f99e/config.lxc -- /.dockerinit -driver lxc -g 172.17.42.1 -i 172.17.0.2/16 -mtu 1500 -- /bin/sh
#4. Start run docker normally......
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Michael Gauthier mike@silverorange.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@silverorange.com
--- Comment #64 from Michael Gauthier mike@silverorange.com --- I had this problem in Fedora 20 using Docker 1.0.
If I stop firewalld and then restart docker I am able to access the Internet from containers.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Andrei Gherzan andrei@gherzan.ro changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrei@gherzan.ro Flags| |needinfo?
--- Comment #65 from Andrei Gherzan andrei@gherzan.ro --- I can reproduce this issue again on Fedora 22. The workaround for it was to configure firewall-config as follows: 1. add the docker0 interface to default zone (it wasn't there by default, why?) 2. configure masquerade for default zone
Without (2) a restart or docker is needed after every boot.
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
--- Comment #66 from Andrei Gherzan andrei@gherzan.ro --- (In reply to Andrei Gherzan from comment #65)
I can reproduce this issue again on Fedora 22. The workaround for it was to configure firewall-config as follows:
- add the docker0 interface to default zone (it wasn't there by default,
why?) 2. configure masquerade for default zone
Without (2) a restart or docker is needed after every boot.
on docker*
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Peter Williams peter@newton.cx changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |peter@newton.cx
--- Comment #67 from Peter Williams peter@newton.cx --- I've been having the same issues. For reference, here's the command-line method for implementing the configuration mentioned by Andrei in #65, which tentatively seems to fix things for me too:
sudo firewall-cmd --permanent --zone=public --add-interface=docker0 sudo firewall-cmd --permanent --zone=public --add-masquerade
golang@lists.fedoraproject.org
-
Red Hat Bugzilla