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.

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

Port on local loopback not reachable over ipv6 when using dual-stack network #790

Closed
ivanov17 opened this issue Aug 29, 2023 · 4 comments
Closed

Port on local loopback not reachable over ipv6 when using dual-stack network #790

ivanov17 opened this issue Aug 29, 2023 · 4 comments

Comments

@ivanov17
Copy link

ivanov17 commented Aug 29, 2023 •
edited

I have a problem that has been bothering me for a long time.

I'm using dual stack networks with rootfull Podman and sometimes I need to bind some container ports to localhost. I don't get any errors when binding them, but I can't communicate over ipv6 with ports bound to both [::1] and 127.0.0.1.

The same thing happens when I bind a port to both 0.0.0.0 and [::], the port on the local loopback is not reachable over ipv6.

When I'm trying to use e.g. curl to communicate with such a port, it simply doesn't respond until the connection times out.

It looks like this:

# curl --insecure --location --verbose [::1]:80
*   Trying ::1:80...
* connect to ::1 port 80 failed: Connection timed out
* Failed to connect to ::1 port 80: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to ::1 port 80: Connection timed out

At the same time, communication over ipv4 is successfull:

# curl --insecure --location 127.0.0.0:80
<html><body><h1>503 Service Unavailable</h1>
No server is available to handle this request.
</body></html>

The issue is similar to #636 and I was expecting Netavark 1.6.0 that have #638 fix to be able to solve it, but unfortunately not.

I am currently using CentOS Stream 9 and the latest versions of Podman and Netavark available in the distribution.

# /usr/bin/podman --version
podman version 4.6.1

# /usr/libexec/podman/netavark --version
netavark 1.7.0

# /usr/bin/firewall-cmd --version
1.2.5

# cat /etc/firewalld/firewalld.conf | grep FirewallBackend
FirewallBackend=nftables

I'm willing to provide any logs and configuration files you might need.
@Luap99
Copy link
Member

Luap99 commented Sep 11, 2023

The kernel does not support ipv6 port forwarding via ::1 so it is impossible to implement this via firewall rules.

In order to support this we would need a user space proxy, please follow containers/podman#14491 instead for that.

@Luap99 Luap99 closed this as not planned Won't fix, can't repro, duplicate, stale Sep 11, 2023
@ivanov17
Copy link
Author

ivanov17 commented Sep 11, 2023 •
edited

Thank you for your reply, at least now I understand a little more what's going on.

Can this be considered a kernel bug? Or is this specific to the ipv6 implementation? Maybe this should be reported to the kernel developers?

@Luap99
Copy link
Member

Luap99 commented Sep 11, 2023

I don't have a specific link but my understanding is that is a deliberate decision to not support ipv6 loopback NAT in the kernel, it may not even be possible in the protocol? For ipv4 we have to explicitly enable this via the route_localnet sysctl but there is no such thing for ipv6 so the only way to implement is to use a user space proxy.

@ivanov17
Copy link
Author

Thanks for the explanation. I did a little searching on the net, and found a discussion of the issue on ServerFault. The answer states that this is an RFC requirement:

any incoming packet with the loopback destination address has been received from outside MUST be dropped by RFC 4291 2.5.3

I'm looking forward to the proxy implementation. Thank you for your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ivanov17 @Luap99