Re: Connecting back to the host through a dummy veth interface

[Stefano Brivio <sbrivio@redhat.com>]

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 <felix@kngnt.org> wrote:

> 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