vendor libnetwork @1861587 #28257
Merged
vendor libnetwork @1861587 #28257
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Santhosh Manohar <santhosh@docker.com>
|
LGTM |
|
this seems to have broken the following fix #490 EDIT: I worked around the issue with |
|
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)? |
|
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 what if I remove docker 1.13 and install 1.12, should I fix iptables policy manually? |
|
Yes, that's what I had to do. |
This was referenced Jan 31, 2017
This was referenced Feb 16, 2017
openstack-gerrit
pushed a commit
to openstack/magnum
that referenced
this pull request
Aug 21, 2017
* 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
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
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
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
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
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
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
pushed a commit
to weaveworks/weave
that referenced
this pull request
Oct 16, 2017
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
pushed a commit
to weaveworks/weave
that referenced
this pull request
Oct 17, 2017
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
pushed a commit
to weaveworks/weave
that referenced
this pull request
Oct 17, 2017
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
…ecent Docker versions. Some details: moby/moby#28257
dis-xcom
pushed a commit
to Mirantis/tcp-qa
that referenced
this pull request
Mar 23, 2018
* 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
chinthakagodawita
added a commit
to chinthakagodawita/dinghy
that referenced
this pull request
Jan 8, 2019
…ting. Relevant issues: * moby/moby#28257 * boot2docker/boot2docker#1364
chinthakagodawita
added a commit
to chinthakagodawita/dinghy
that referenced
this pull request
Jan 8, 2019
…routing. Relevant issues: * moby/moby#28257 * boot2docker/boot2docker#1364
|
Is Ip-forwarding required to run docker. If i disable ipforwarding will it impact any functionality of docker application. |
|
@bharathvishwanathan please don't use old PR's (this pull request was merged three years ago) to start new discussions. Please keep in mind that the GitHub issue tracker is not intended as a general support forum,
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #14041
With this change if
ip_forwardis enabled by docker daemon then the iptables FORWARD policy will be set to DROP. On a docker upgrade ifip_forwardis 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 eitherip_forwardits 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