This bug is basically a duplicate of #903635. On Tuesday, 27 November 2018 9:00:20 AM AEDT Marvin Renich wrote: > HUH??? Since when is it okay for software that is not advertised as > firewall software to modify the sysadmin's implicit or explicit iptables > setup for IP packets completely unrelated to said software? > > I understand that this is a non-trivial problem because of the history > behind /proc/sys/net/ipv4/ip_forward and the FORWARD chain, but docker > can and needs to do better. My first approximation would be to only > change the policy for FORWARD if ip_forward was 0 before docker added > its own iptables rules. This will probably work 99.9% of the time. > > The current behavior appears to break other software 100% of the time > if that software relies on ip_forward being 1 and the FORWARD chain > being in its default state.
Situation is unfortunate and upstream does not care enough. They probably want Docker users to use Docker exclusively without any other software on the host. I very much dislike this approach but that's Docker for you... :( About 6 months ago I've moved all my application containers from Docker to "rkt" and I couldn't be happier. Although still immature, in the future libpod/podman will likely become a worthy Docker successor. > I'm raising this back to critical (makes unrelated software on the > system break), as I cannot fathom how this could not be broken for > anyone using KVM with a bridging network interface unless they have > found one of the workarounds given in this thread (i.e. the > /etc/docker/daemon.json modification, or manually modifying the FORWARD > chain). I'm lowering severity back to "important". You are not wrong that Docker is hostile to other applications but I think many users would agree that we need Docker in "testing" and upcoming Debian release despite of this problem. -- All the best, Dmitry Smirnov. --- Truth never damages a cause that is just. -- Mahatma Gandhi
signature.asc
Description: This is a digitally signed message part.