Let me answer your latest three email separately, because actually
there are valid open questions in all of them (and yes, we need
https://bugs.passt.top/show_bug.cgi?id=144 and some "howto" section
beyond man pages and Podman documentation, but it won't be for this year
either...)
On Sun, 21 Dec 2025 16:17:37 +0100
Felix Rubio
Ciao, Stefano
I have just discovered how little I know about rootless networking in containers: I thought that when using host.containers.internal I was really connecting back to the loopback interface (127.0.0.1).
Indeed, this works - Terminal 1, user 1: podman run --rm -ti -p 8089:80 traefik/whoami - Terminal 2, user 2: podman run --rm -ti alpine /bin/sh -c "apk add curl; curl host.containers.internal:8089"
As I have a smtp server listening on that interface, port 25, I have run this experiment, which does not work: podman run --rm -ti alpine /bin/sh -c "apk add busybox-extras; telnet host.containers.internal 25" telnet: can't connect to remote host (169.254.1.2): Connection refused
Because it's probably binding to localhost (something in 127.0.0.1/8 or ::1 or both), but the destination of this connection attempt is not a loopback address.
I only seem to be able to connect, using rootless pasta, to ports that are published by other containers. In case any container gets compromised connections from that container could only be established to services run by other containers, then?
...or other hosts. But there's a way to override that. From pasta(1), emphasis mine: --map-host-loopback addr Translate addr to refer to the host. Packets from the guest to addr will be redirected to the host. ** On the host such packets will appear to have both source and destination of 127.0.0.1 or ::1. ** ...and yes, I guess we should rephrase this as well, but with this option you would be able to connect to services that bind to loopback addresses (too). Podman doesn't enable this by default (it would be a bad default for security) so you would need to issue something like 'podman run --net=pasta:--map-host-loopback,169.254.1.2 ...'.
Similarly... Could I create another "network of pods" by using map-guest-addr with another ip (say 169.254.1.3) and the pods in 169.254.1.2 and 169.254.1.3 would not be able to talk to each other?
It all depends on what ports are exposed and what interface and address they are bound to, on the host. But yes, you could do something like that. Eventually, *after* https://bugs.passt.top/show_bug.cgi?id=140 is done, we might consider implementing proper inter-container communication with a single instance of pasta. That would make things easier... but we're not quite there yet.
So the solution for my use case is then to bind e.g., port 1636 to both 10.255.255.1 and to 169.254.1.2, so that external connections to it can get through, but also connections from other rootless pods?
You could do that, yes. -- Stefano