New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vendor libnetwork @1861587 #28257

Merged
merged 1 commit into from Nov 10, 2016

Conversation

Projects
None yet
9 participants
@sanimej

sanimej commented Nov 10, 2016

Fixes #14041

With this change if ip_forward is enabled by docker daemon then the iptables FORWARD policy will be set to DROP. On a docker upgrade if ip_forward is already enabled this change will not take effect, because in that case the user might have intended to have the default policy ACCEPT. Changing it to DROP will break such setups. Current users of docker can avoid this issue by either

  1. setting the FORWARD policy to DROP manually
  2. reload the host before upgrading to 1.13. If docker daemon enabled ip_forward its not persistent. So after a reload the fix will take effect and the policy will be set to DROP.

Signed-off-by: Santhosh Manohar santhosh@docker.com

Santhosh Manohar
vendor libnetwork @1861587
Signed-off-by: Santhosh Manohar <santhosh@docker.com>
@mavenugo

LGTM

@vieux

This comment has been minimized.

Show comment
Hide comment
@vieux

vieux Nov 10, 2016

Collaborator

LGTM

Collaborator

vieux commented Nov 10, 2016

LGTM

@vieux vieux merged commit f700a86 into moby:master Nov 10, 2016

5 checks passed

dco-signed All commits are signed
experimental Jenkins build Docker-PRs-experimental 26609 has succeeded
Details
janky Jenkins build Docker-PRs 35180 has succeeded
Details
vendor Jenkins build Docker-PRs-vendor 2447 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 6093 has succeeded
Details

@sanimej sanimej deleted the sanimej:iptables branch Jan 4, 2017

@AlmirKadric

This comment has been minimized.

Show comment
Hide comment
@AlmirKadric

AlmirKadric Jan 21, 2017

this seems to have broken the following fix #490
I haven't been able to work around this with the daemon config file either
IP forwarding is broken on docker for windows

EDIT: I worked around the issue with iptables: false inside my docker daemon config. However this is extremely undesirable and probably unacceptable to most people. If anyone has a better fix please let me know. Otherwise we will need a nice way to configure iptables entries from docker compose (per network) or daemon config (we need a command line to interact with this).

AlmirKadric commented Jan 21, 2017

this seems to have broken the following fix #490
I haven't been able to work around this with the daemon config file either
IP forwarding is broken on docker for windows

EDIT: I worked around the issue with iptables: false inside my docker daemon config. However this is extremely undesirable and probably unacceptable to most people. If anyone has a better fix please let me know. Otherwise we will need a nice way to configure iptables entries from docker compose (per network) or daemon config (we need a command line to interact with this).

@1ma

This comment has been minimized.

Show comment
Hide comment
@1ma

1ma Jan 26, 2017

It appears this change of policy broke my use case (PHP debugging with XDebug, which involves opening TCP connections from the container back to the host).

How can I restore the old policy (short of pinning the 1.12.6 version on my development machine)?

1ma commented Jan 26, 2017

It appears this change of policy broke my use case (PHP debugging with XDebug, which involves opening TCP connections from the container back to the host).

How can I restore the old policy (short of pinning the 1.12.6 version on my development machine)?

@1ma

This comment has been minimized.

Show comment
Hide comment
@1ma

1ma Jan 26, 2017

Solved. Note that if you accidentally upgraded to 1.13 its not enough to downgrade back to 1.12, the iptables default policy has to be manually reverted.

1ma commented Jan 26, 2017

Solved. Note that if you accidentally upgraded to 1.13 its not enough to downgrade back to 1.12, the iptables default policy has to be manually reverted.

@PavelPrischepa

This comment has been minimized.

Show comment
Hide comment
@PavelPrischepa

PavelPrischepa Jan 26, 2017

@1ma what if I remove docker 1.13 and install 1.12, should I fix iptables policy manually?

PavelPrischepa commented Jan 26, 2017

@1ma what if I remove docker 1.13 and install 1.12, should I fix iptables policy manually?

@1ma

This comment has been minimized.

Show comment
Hide comment
@1ma

1ma Jan 26, 2017

Yes, that's what I had to do.

1ma commented Jan 26, 2017

Yes, that's what I had to do.

holser pushed a commit to holser/kargo that referenced this pull request Feb 17, 2017

Sergii Golovatiuk
iptables switch for docker
Docker 1.13 changes the behaviour of iptables defaults from allow
to drop. This patch allows operator to change behaviour back as it was
in Docker 1.12 [1]

[1] moby/moby#28257

holser pushed a commit to holser/kargo that referenced this pull request Feb 21, 2017

Sergii Golovatiuk
iptables switch for docker
Docker 1.13 changes the behaviour of iptables defaults from allow
to drop. This patch allows operator to change behaviour back as it was
in Docker 1.12 [1]

[1] moby/moby#28257

holser pushed a commit to holser/kargo that referenced this pull request Feb 21, 2017

Sergii Golovatiuk
Statically disable iptables management for docker
Docker 1.13 changes the behaviour of iptables defaults from allow
to drop. This patch disables docker's iptables management as it was
in Docker 1.12 [1]

[1] moby/moby#28257

Signed-off-by: Sergii Golovatiuk <sgolovatiuk@mirantis.com>

holser pushed a commit to holser/kargo that referenced this pull request Feb 21, 2017

Sergii Golovatiuk
Statically disable iptables management for docker
Docker 1.13 changes the behaviour of iptables defaults from allow
to drop. This patch disables docker's iptables management as it was
in Docker 1.12 [1]

[1] moby/moby#28257

Signed-off-by: Sergii Golovatiuk <sgolovatiuk@mirantis.com>

chadswen pushed a commit to chadswen/kargo that referenced this pull request Jul 31, 2017

Sergii Golovatiuk Chad Swenson
Statically disable iptables management for docker
Docker 1.13 changes the behaviour of iptables defaults from allow
to drop. This patch disables docker's iptables management as it was
in Docker 1.12 [1]

[1] moby/moby#28257

Signed-off-by: Sergii Golovatiuk <sgolovatiuk@mirantis.com>

openstack-gerrit pushed a commit to openstack/magnum that referenced this pull request Aug 21, 2017

tests: Use swarm-mode for api tests
* Swarm-mode is the fastest cluster to deploy since it doesn't
  require to pull anything from outside.
* Add the output nodes for swarm-mode too.
* Disable copy logs (I think a better practice is to copy logs
  on demand).
* Don't run test_create_list_sign_delete_clusters, because it is
  very unstable on the CI.

Partially-Implements: blueprint swarm-mode-support

2nd commit message:

Update to Fedora Atomic 26

This patch moves the current master to test against Fedora Atomic 26,
in addition, it switches to downloading from Fedora mirrors.

2nd-Change-Id: I9a97c0eb78b2c9d10e8be1501babb19e73ee70c1

3rd commit message:

Set default iptables FORWARD policy to ACCEPT

With the release of Docker 1.13 which is available in Fedora
Atomic 26, it no longer sets the policy of the FORWARD chain
to ACCEPT[1].  Therefore, CNI networking such as Flannel will
cease to work.

This patch sets the policy to ACCEPT so that traffic can work
once again for deployments which are based on Docker versions
which are newer than 1.13

[1]: moby/moby#28257

3rd-Change-Id: I1457602748619f38f87542fc01a2996ee80e58b7
Closes-Bug: #1708454

Co-Authored-By: Mohammed Naser <mnaser@vexxhost.com>
Change-Id: I86d4dcc94fff622be4ee2acc8dd60ed81bc5d433

brb added a commit to weaveworks/weave that referenced this pull request Aug 25, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

brb added a commit to weaveworks/weave that referenced this pull request Aug 25, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

brb added a commit to weaveworks/weave that referenced this pull request Aug 28, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

brb added a commit to weaveworks/weave that referenced this pull request Sep 14, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

brb added a commit to weaveworks/weave that referenced this pull request Sep 17, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

brb added a commit to weaveworks/weave that referenced this pull request Sep 17, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

bboreham added a commit to weaveworks/weave that referenced this pull request Oct 16, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

bboreham added a commit to weaveworks/weave that referenced this pull request Oct 17, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

bboreham added a commit to weaveworks/weave that referenced this pull request Oct 17, 2017

Create WEAVE-EXPOSE iptables chain
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(moby/moby#28257) which makes containers
inaccessible from a remote host when the bridge is exposed.

The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.

The chain is a target of the rule "-t filter -A FORWARD -o weave".

ToroNZ pushed a commit to ToroNZ/k8s-snowflake that referenced this pull request Dec 28, 2017

ToroNZ pushed a commit to ToroNZ/k8s-snowflake that referenced this pull request Dec 28, 2017

caseycs added a commit to caseycs/docker-k8s-lab that referenced this pull request Feb 16, 2018

dis-xcom pushed a commit to Mirantis/tcp-qa that referenced this pull request Mar 23, 2018

Fix tests
* replace service to systemctl call for sync time
* Add forward policy accept after docker install
due to moby/moby#28257 break gtw node

Change-Id: I790bc9c1b2f203119d4142ec25956634bf6bb94f

iamrgon added a commit to iamrgon/ansible-kubernetes-openshift-pi3 that referenced this pull request Jul 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment