Hello,

with

	root@happy:~# cat /etc/containers/systemd/cloud.pod
	[Pod]
	PodName=cloud
	PublishPort=[::1]:9000:9000
	[Install]
	WantedBy=multi-user.target default.target
	root@happy:~# cat /etc/containers/systemd/nextcloud.container
	[Container]
	ContainerName=nextcloud
	Image=docker.io/nextcloud:fpm
	Pod=cloud.pod
	Volume=/srv/nextcloud:/var/www/html:Z
	Volume=/etc/localtime:/etc/localtime:ro

I get

	root@happy:~# ss -ltpn
	State  Recv-Q Send-Q                           Local Address:Port  Peer Address:PortProcess
	...
	LISTEN 2      4096                                     [::1]:9000          [::]:*    users:(("conmon",pid=937,fd=5))
	...

but I cannot connect to the respective processes in the container
according to strace attached to the php-fpm processes.

	podman run -it nextcloud bash
	apt update
	apt install netcat-openbsd
	netcat ::1 9000

works fine however.

Also if I change `[::1]` to `127.0.0.1` in
/etc/containers/systemd/cloud.pod it works as expected.

I cannot reproduce the issue using

	podman pod create --publish '[::1]:9000:9000' test
	podman run --pod test docker.io/nextcloud:fpm

as user.

Best regards
Uwe

forwarded 1133420 https://github.com/containers/netavark/issues/790
tags 1133420 + wontfix
thanks

Uwe,

The behavior described is a known architectural limitation stemming from how
the Linux kernel handles IPv6 loopback routing, rather than a defect in the
package.

For IPv4, the kernel provides net.ipv4.conf.all.route_localnet=1, which allows
127.0.0.1 traffic to be routed via NAT to a bridge interface. The kernel lacks
an equivalent capability for IPv6. Packets attempting to route ::1 traffic off
the loopback interface are strictly dropped due to anti-spoofing constraints.
Consequently, native IPv6 NAT on ::1 fails in rootful mode, which relies on
netavark and bridge networking.

Upstream has confirmed this behavior in containers/netavark#790. Because the
kernel does not support IPv6 port forwarding via ::1, it cannot be implemented
via standard firewall rules. I am marking this bug as forwarded and wontfix
accordingly, please refer to the referenced bug for further details.

This architectural difference explains why your rootless test
succeeded. Rootless Podman utilizes a userland proxy (slirp4netns or pasta)
instead of kernel NAT, which bypasses the kernel's routing restrictions
entirely.

To resolve the issue for your Nextcloud Quadlet, you can choose one of the
following configurations:

1. Force a Userland Proxy

Bypass the standard bridge and use a userland proxy for the rootful pod. Add
the `Network` directive to `cloud.pod`:

```
[Pod]
PodName=cloud
Network=pasta
PublishPort=[::1]:9000:9000
```

2. Migrate to Rootless

Move the .pod and .container files to ~/.config/containers/systemd/ and manage
them via a user-level systemd daemon.

3. Bind to a ULA or Global Address

If the host has a Unique Local Address (ULA) or global IPv6 address assigned to
a dummy or physical interface, binding to that instead of ::1 will allow the
standard netavark NAT to work as expected.

Let me know if that makes sense!
-rt

forwarded 1133420 https://github.com/containers/netavark/issues/790
tags 1133420 + wontfix
thanks

Uwe,

The behavior described is a known architectural limitation stemming from how
the Linux kernel handles IPv6 loopback routing, rather than a defect in the
package.

For IPv4, the kernel provides net.ipv4.conf.all.route_localnet=1, which allows
127.0.0.1 traffic to be routed via NAT to a bridge interface. The kernel lacks
an equivalent capability for IPv6. Packets attempting to route ::1 traffic off
the loopback interface are strictly dropped due to anti-spoofing constraints.
Consequently, native IPv6 NAT on ::1 fails in rootful mode, which relies on
netavark and bridge networking.

Upstream has confirmed this behavior in containers/netavark#790. Because the
kernel does not support IPv6 port forwarding via ::1, it cannot be implemented
via standard firewall rules. I am marking this bug as forwarded and wontfix
accordingly, please refer to the referenced bug for further details.

This architectural difference explains why your rootless test
succeeded. Rootless Podman utilizes a userland proxy (slirp4netns or pasta)
instead of kernel NAT, which bypasses the kernel's routing restrictions
entirely.

To resolve the issue for your Nextcloud Quadlet, you can choose one of the
following configurations:

1. Force a Userland Proxy

Bypass the standard bridge and use a userland proxy for the rootful pod. Add
the `Network` directive to `cloud.pod`:

```
[Pod]
PodName=cloud
Network=pasta
PublishPort=[::1]:9000:9000
```

2. Migrate to Rootless

Move the .pod and .container files to ~/.config/containers/systemd/ and manage
them via a user-level systemd daemon.

3. Bind to a ULA or Global Address

If the host has a Unique Local Address (ULA) or global IPv6 address assigned to
a dummy or physical interface, binding to that instead of ::1 will allow the
standard netavark NAT to work as expected.

Let me know if that makes sense!
-rt