8000 [27.x backport] Enable bridge netfiltering if userland-proxy=false by robmry · Pull Request #48685 · moby/moby · GitHub
[go: up one dir, main page]
Skip to content

[27.x backport] Enable bridge netfiltering if userland-proxy=false #48685

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Oct 17, 2024
Merged

[27.x backport] Enable bridge netfiltering if userland-proxy=false #48685

merged 1 commit into from
Oct 17, 2024

Conversation

robmry
Copy link
Contributor
@robmry robmry commented Oct 17, 2024

- What I did

In release 27.0, ip6tables was enabled by default. That caused a problem on some hosts where iptables was explicitly disabled and loading the br_netfilter module (which loads with its nf-call-iptables settings enabled) caused user-defined iptables rules to block traffic on bridges, breaking inter-container communication.

In 27.3.0, #48511 delayed loading of the br_netfilter module until it was needed. The load now happens in the function that sets bridge-nf-call-ip[6]tables when needed. It was only called for icc=false networks.

However, br_netfilter is also needed when userland-proxy=false. Without it, packets addressed to a host-mapped port for a container on the same network are not DNAT'd properly (responses have the server container's address instead of the host's).

That means, in all releases including 26.x, if br_netfilter was loaded before the daemon started - and the OS/user/other-application had disabled bridge-nf-call-ip[6]tables (which apparently some OSs try to do), it would not be enabled by the daemon. So, ICC would fail for host-mapped ports with the userland-proxy disabled.

The change in 27.3.0 made this worse - previously, loading br_netfilter whenever iptables/ip6tables was enabled meant that bridge-netfiltering got enabled, even though the daemon didn't check it was enabled.

- How I did it

Check that br_netfilter is loaded, with bridge-nf-call-ip[6]tables enabled, if userland-proxy=false.

- How to verify it

New test that disables bridge-nf-call-iptables and the userland proxy, then tries to access another container's mapped port ... not quite the same as unloading br_netfilter - but this test fails with a daemon built from the 26.1 branch (as well as 27.x).

Manually tested on an Ubuntu VM, including with br_netfilter unloaded before starting the daemon.

- Description for the changelog

- Fix an issue that meant published ports from one container on a bridge network were not accessible
  from another container on the same network with `userland-proxy` disabled, if the kernel's `br_netfilter`
  module was not loaded and enabled. The daemon will now attempt to load the module and enable
  `bridge-nf-call-iptables` or `bridge-nf-call-ip6tables` when creating a network with the userland proxy
   disabled.

@robmry
Enable bridge netfiltering if userland-proxy=false
0f8fc31 
In release 27.0, ip6tables was enabled by default. That caused a
problem on some hosts where iptables was explicitly disabled and
loading the br_netfilter module (which loads with its nf-call-iptables
settings enabled) caused user-defined iptables rules to block traffic
on bridges, breaking inter-container communication.

In 27.3.0, commit 5c499fc delayed
loading of the br_netfilter module until it was needed. The load
now happens in the function that sets bridge-nf-call-ip[6]tables when
needed. It was only called for icc=false networks.

However, br_netfilter is also needed when userland-proxy=false.
Without it, packets addressed to a host-mapped port for a container
on the same network are not DNAT'd properly (responses have the server
container's address instead of the host's).

That means, in all releases including 26.x, if br_netfilter was loaded
before the daemon started - and the OS/user/other-application had
disabled bridge-nf-call-ip[6]tables, it would not be enabled by the
daemon. So, ICC would fail for host-mapped ports with the userland-proxy
disabled.

The change in 27.3.0 made this worse - previously, loading br_netfilter
whenever iptables/ip6tables was enabled meant that bridge-netfiltering
got enabled, even though the daemon didn't check it was enabled.

So... check that br_netfilter is loaded, with bridge-nf-call-ip[6]tables
enabled, if userland-proxy=false.

Signed-off-by: Rob Murray <rob.murray@docker.com>
(cherry picked from commit 0548fe2)
Signed-off-by: Rob Murray <rob.murray@docker.com>
@robmry robmry added this to the 27.4.0 milestone Oct 17, 2024
@robmry robmry self-assigned this Oct 17, 2024
@robmry robmry marked this pull request as ready for review October 17, 2024 17:22
thaJeztah
thaJeztah approved these changes Oct 17, 2024
View reviewed changes
Copy link
Member
@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@thaJeztah thaJeztah merged commit bd021c3 into moby:27.x Oct 17, 2024
150 checks passed
@robmry robmry deleted the backport-27.x/48664_br_netfilter_noproxy branch November 15, 2024 18:33
@robmry robmry mentioned this pull request Nov 25, 2024
Closed
@thaJeztah thaJeztah mentioned this pull request Jan 20, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@thaJeztah thaJeztah thaJeztah approved these changes

Assignees

@robmry robmry

Labels
area/networking/d/bridge Networking area/networking/firewalling Networking area/networking/portmapping Networking area/networking Networking impact/changelog kind/bugfix PR's that fix bugs
Projects
None yet
Milestone
27.4.0
Development

Successfully merging this pull request may close these issues.
2 participants
@robmry @thaJeztah
0