Skip to content
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

Fix issue caused by different iptables versions #72

Merged
merged 1 commit into from
Jul 19, 2021

Conversation

geektoor
Copy link
Contributor

A backport of "nft: Optimize class-based IP prefix matches" from
newer iptables versions broke the hairpin mode detection of ipv6nat.
This is caused by newer versions on the host create optimized ipt
rules, which will be interpreted different by older versions of
iptables. This can be spotted when you dump the rules on the host
and compare it to the rules dumped inside the ipv6nat container.
The outside rule contains the correct subnet for the detection,
127.0.0.0/8 while inside it is displayed as 127.0.0.0/32 which
causes the detection (code in manager.go) to fail. As this is only
a display issue (the rule is correct), accepting both versions
should be fine to get around this issue.

Big thanks to Phil Sutter who provided me the code to implement
my idea to cover old and new versions to be matched, as it is
very hard to ensure the same iptables version to be used inside
and outside the container. A test build is available on docker
hub at geektoor/ipv6nat-devel.

Closes: #67
Cc: Phil Sutter phil@nwl.cc
Signed-off-by: Sven Michels michels@redhat.com

A backport of "nft: Optimize class-based IP prefix matches" from
newer iptables versions broke the hairpin mode detection of ipv6nat.
This is caused by newer versions on the host create optimized ipt
rules, which will be interpreted different by older versions of
iptables. This can be spotted when you dump the rules on the host
and compare it to the rules dumped inside the ipv6nat container.
The outside rule contains the correct subnet for the detection,
127.0.0.0/8 while inside it is displayed as 127.0.0.0/32 which
causes the detection (code in manager.go) to fail. As this is only
a display issue (the rule is correct), accepting both versions
should be fine to get around this issue.

Big thanks to Phil Sutter who provided me the code to implement
my idea to cover old and new versions to be matched, as it is
very hard to ensure the same iptables version to be used inside
and outside the container. A test build is available on docker
hub at geektoor/ipv6nat-devel.

Closes: robbertkl#67
Cc: Phil Sutter <phil@nwl.cc>
Signed-off-by: Sven Michels <michels@redhat.com>
@dragoangel
Copy link

Tested with https://hub.docker.com/r/geektoor/ipv6nat-devel in mailcow/mailcow-dockerized#3940 - this PR resolve issue for me.

OS: CentOS-8
uname -a output:
Linux 4.18.0-240.22.1.el8_3.x86_64 #1 SMP Thu Apr 8 19:01:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Installed Packages
Name : iptables
Version : 1.8.4
Release : 17.el8
Architecture : x86_64
Size : 1.9 M
Source : iptables-1.8.4-17.el8.src.rpm
Repository : @System
From repo : baseos

@robbertkl
Copy link
Owner

Thanks @geektoor, great to have this fixed! 🎉 I'll take a good look + test soon and get this merged + push out a new release.

On non-RH/CentOS systems, where the issue is not present, this fix should not break anything, right?

@dragoangel Thanks for confirming the fix works CentOS 8!

@geektoor
Copy link
Contributor Author

@robbertkl it should not. Its mainly just accepting both possible outputs, the /8 and the /32 netmask. This might happen on other systems as well as soon as the iptables version between host and container are not having the same patch implemented. The backport on CentOS/RHEL made it just visible on CentOS/RHEL, but other combos might also cause this.
I tried to summarize it in the changelog a bit more, but let me know if you want even more technical details :)

@robbertkl robbertkl merged commit 87df418 into robbertkl:master Jul 19, 2021
@dragoangel
Copy link

Thanks :)

@dragoangel
Copy link

@robbertkl can you please tell when your docker image will contain this PR? Thank you in advance. 👍

@robbertkl
Copy link
Owner

Yep, I'm building a new release and was gonna comment here, but you're too quick 😄 Still doing some checks and maybe update some deps, will update when the new release & docker images are up!

@dragoangel
Copy link

Thanks, great

@robbertkl
Copy link
Owner

Just pushed out v0.4.4! Docker images for all architectures are on Docker Hub as :0.4.4 and :latest. Thanks again @geektoor!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Exits with "unable to detect hairpin mode (is the docker daemon running?)"
3 participants