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

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

[Stefano Brivio]

Hi Felix,

On Thu, 18 Dec 2025 13:32:36 +0100
Felix Rubio <felix@kngnt.org> wrote:

> Hi everybody,
> 
> I am trying to run a number of rootless podman pods and containers by different 
> users, while still being able to talk to each other. To this end I am creating 
> a dummy veth interface and publishing all the exposed ports there (this works: 
> I can communicate from other host services with those containers), and I am 
> also trying to set that dummy veth interface as the default gateway for the 
> pods/containers (with the expectation that then they will be able to reach 
> each other). However, this is not working... and I am pretty lost.
> 
> For example, I am running the following command, trying to connect a ldap 
> client container to a ldap server container, unsuccessfully.
> 
> podman run --rm --dns=10.255.255.1 --network=pasta:--outbound-
> if4=cluster_dns0,--gateway=10.255.255.1 --add-host=ldap.host.internal:host-gateway sh -c "ip add && ip route && ldapwhoami -H ldaps://
> ldap.host.internal:1636"
> 
> Is this something impossible to do, or am I doing something wrong?

Sorry, I'm a bit swamped at the moment, and I plan to get back to you
in a bit, but meanwhile, I think the dummy veth trick is unnecessarily
complicated.

I think you could simply connect "to the host" and redirect from there
to the containers by means of mapped ports. See:

  https://blog.podman.io/2024/10/podman-5-3-changes-for-improved-networking-experience-with-pasta/

for a couple of details. But I'll try to come up with a full example
next.

-- 
Stefano

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

[Felix Rubio]

Hey Stefano,

Thank you for your answer! I know I can run rootful containers, and that then 
I can access the host's network ns. However, this exposes a number of 
potential issues:
* In case the an attacker manages to break out of the container, gets root
* That enables connecting back to the host loopback, but then from that 
container any service listening to the loopback can be reached as well.

The reason for looking for a way of binding those services to 10.255.255.1 (so 
that only exposed services will be in that interface) and running fully 
rootless, if works, provides a more secure system... in general.

About the mapped ports, I am a bit lost: for what I have tested, running 
rootless disables the possibility to connect back to the host, right?

Regards, and thank you!
Felix

On Saturday, 20 December 2025 15:12:24 Central European Standard Time Stefano 
Brivio wrote:
> Hi Felix,
> 
> On Thu, 18 Dec 2025 13:32:36 +0100
> 
> Felix Rubio <felix@kngnt.org> wrote:
> > Hi everybody,
> > 
> > I am trying to run a number of rootless podman pods and containers by 
different
> > users, while still being able to talk to each other. To this end I am 
creating
> > a dummy veth interface and publishing all the exposed ports there (this 
works:
> > I can communicate from other host services with those containers), and I 
am
> > also trying to set that dummy veth interface as the default gateway for 
the
> > pods/containers (with the expectation that then they will be able to reach
> > each other). However, this is not working... and I am pretty lost.
> > 
> > For example, I am running the following command, trying to connect a ldap
> > client container to a ldap server container, unsuccessfully.
> > 
> > podman run --rm --dns=10.255.255.1 --network=pasta:--outbound-
> > if4=cluster_dns0,--gateway=10.255.255.1 --add-
host=ldap.host.internal:host-gateway sh -c "ip add && ip route &&
> > ldapwhoami -H ldaps:// ldap.host.internal:1636"
> > 
> > Is this something impossible to do, or am I doing something wrong?
> 
> Sorry, I'm a bit swamped at the moment, and I plan to get back to you
> in a bit, but meanwhile, I think the dummy veth trick is unnecessarily
> complicated.
> 
> I think you could simply connect "to the host" and redirect from there
> to the containers by means of mapped ports. See:
> 
>   https://blog.podman.io/2024/10/podman-5-3-changes-for-improved-networking-experience-with-pasta/
> 
> for a couple of details. But I'll try to come up with a full example
> next.


-- 
Felix Rubio

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

[Stefano Brivio]

On Sat, 20 Dec 2025 15:28:43 +0100
Felix Rubio <felix@kngnt.org> wrote:

> Hey Stefano,
> 
> Thank you for your answer! I know I can run rootful containers, and that then 
> I can access the host's network ns. However, this exposes a number of 
> potential issues:
> * In case the an attacker manages to break out of the container, gets root
> * That enables connecting back to the host loopback, but then from that 
> container any service listening to the loopback can be reached as well.

Sure. That's the whole point behind pasta(1) and rootless containers
with Podman / rootlesskit. I certainly won't be the one suggesting that
you'd run anything as root. :)

> The reason for looking for a way of binding those services to 10.255.255.1 (so 
> that only exposed services will be in that interface) and running fully 
> rootless, if works, provides a more secure system... in general.

Indeed.

> About the mapped ports, I am a bit lost: for what I have tested, running 
> rootless disables the possibility to connect back to the host, right?

Hah, I see now. No, that's not the case. You can run rootless
containers and connect to the host from them, in two ways:

1. disabled by default in Podman's pasta integration, not what you want:
   via the loopback interface, see -U / -T in 'man pasta' and
   --host-lo-to-ns-lo for the other way around.

   In that case, packets appear to be local (source address is
   loopback) in the other namespace ("host" or initial namespace for
   packets from a container, and container for packets from host).

   This gives you better throughput but making connections appear as if
   they were local is risky (cf. CVE-2021-20199), so it's disabled by
   default, and not what I'm suggesting (at least in general)

2. what you get as default in Podman: using pasta's --map-guest-addr.

   The current description of this option in pasta(1) isn't great, hence
   https://bugs.passt.top/show_bug.cgi?id=132, but the idea is that you
   will reach the host from the container with a non-loopback address,
   as if the connection was coming from another host (which should
   represent the expected container usage).

So here's an example:

$ podman run --rm -ti -p 8089:80 traefik/whoami
2025/12/21 10:42:16 Starting up on port 80

[in another terminal]
$ podman run --rm -ti fedora curl host.containers.internal:8089
Hostname: ab94f49b5042
IP: 127.0.0.1
IP: ::1
IP: **.***.*.***
IP: ****:***:***:***::*
IP: ****::****:****:****:****
RemoteAddr: 169.254.1.2:46592
GET / HTTP/1.1
Host: host.containers.internal:8089
User-Agent: curl/8.15.0
Accept: */*

...doesn't that work for you? Note that you'll need somewhat recent
versions of pasta (>= 2024_08_21.1d6142f) and Podman (>= 5.3).

-- 
Stefano

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

[Felix Rubio]

Something more: I see that pasta is binding to 0.0.0.0. This means that, while 
allows other pods to connect to the published port of a container through 
169.254.1.2, it also enables that port to be reachable from the network.

Is there any way to prevent that?

Regards!
Felix

On Sunday, 21 December 2025 11:47:22 Central European Standard Time Stefano 
Brivio wrote:
> On Sat, 20 Dec 2025 15:28:43 +0100
> 
> Felix Rubio <felix@kngnt.org> wrote:
> > Hey Stefano,
> > 
> > Thank you for your answer! I know I can run rootful containers, and that 
then
> > I can access the host's network ns. However, this exposes a number of
> > potential issues:
> > * In case the an attacker manages to break out of the container, gets root
> > * That enables connecting back to the host loopback, but then from that
> > container any service listening to the loopback can be reached as well.
> 
> Sure. That's the whole point behind pasta(1) and rootless containers
> with Podman / rootlesskit. I certainly won't be the one suggesting that
> you'd run anything as root. :)
> 
> > The reason for looking for a way of binding those services to 10.255.255.1 
(so
> > that only exposed services will be in that interface) and running fully
> > rootless, if works, provides a more secure system... in general.
> 
> Indeed.
> 
> > About the mapped ports, I am a bit lost: for what I have tested, running
> > rootless disables the possibility to connect back to the host, right?
> 
> Hah, I see now. No, that's not the case. You can run rootless
> containers and connect to the host from them, in two ways:
> 
> 1. disabled by default in Podman's pasta integration, not what you want:
>    via the loopback interface, see -U / -T in 'man pasta' and
>    --host-lo-to-ns-lo for the other way around.
> 
>    In that case, packets appear to be local (source address is
>    loopback) in the other namespace ("host" or initial namespace for
>    packets from a container, and container for packets from host).
> 
>    This gives you better throughput but making connections appear as if
>    they were local is risky (cf. CVE-2021-20199), so it's disabled by
>    default, and not what I'm suggesting (at least in general)
> 
> 2. what you get as default in Podman: using pasta's --map-guest-addr.
> 
>    The current description of this option in pasta(1) isn't great, hence
>    https://bugs.passt.top/show_bug.cgi?id=132, but the idea is that you
>    will reach the host from the container with a non-loopback address,
>    as if the connection was coming from another host (which should
>    represent the expected container usage).
> 
> So here's an example:
> 
> $ podman run --rm -ti -p 8089:80 traefik/whoami
> 2025/12/21 10:42:16 Starting up on port 80
> 
> [in another terminal]
> $ podman run --rm -ti fedora curl host.containers.internal:8089
> Hostname: ab94f49b5042
> IP: 127.0.0.1
> IP: ::1
> IP: **.***.*.***
> IP: ****:***:***:***::*
> IP: ****::****:****:****:****
> RemoteAddr: 169.254.1.2:46592
> GET / HTTP/1.1
> Host: host.containers.internal:8089
> User-Agent: curl/8.15.0
> Accept: */*
> 
> ...doesn't that work for you? Note that you'll need somewhat recent
> versions of pasta (>= 2024_08_21.1d6142f) and Podman (>= 5.3).


-- 
Felix Rubio

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

[Felix Rubio]

Ok, things are starting to get clear. The problem was, I think, between the 
desk and the keyboard.

* I have everything on a VM that I configure with Ansible. I have just taken 
everything down and started from scratch

* I still have my containers without any ad-hoc network. They are binding only 
to network interface 10.255.255.1, which is a dummy ethernet.

* My error was that I am running an LDAP server in one of these containers, 
and I was checking if it was working with a ldapwhoami. The client was 
replying that could not reach the server, which triggered all subsequent 
investigation, but the real cause was that the certificate offered by the server 
was not trusted by the client, and the latter broke the connection (without 
giving a more proper message - facepalm).

Once fixed the problem with the certificates, everything seems to work. This 
means that:
 * I have a dns server in 10.255.255.1 that resolves ldap.host.internal to 
10.255.255.1
 * ldap server rootless container is listening to 10.255.255.1:1636
 * ldap client is in another rootless container, and can reach directly 
ldap.host.internal:1636.

... Is this last point expected? the ldap server is started through podman as 
a regular user, without any network options... nothing fancy.

The reason for me asking is that all I have read points in the direction that 
from a rootless container I should not be able to loopback to the host... but 
maybe this dummy interface is not identified as "the host" and therefore I can 
connect to services bound to it? On the LDAP side, the logs show that these 
connections are coming from the same 10.255.255.1. That would be actually 
convenient, because then I can put firewall rules in place that prevent 
connecting from that dummy ethernet back to the host at all.

Thank you very much, and sorry for the initial confusing messages.
Felix

On Sunday, 21 December 2025 11:47:22 Central European Standard Time Stefano 
Brivio wrote:
> On Sat, 20 Dec 2025 15:28:43 +0100
> 
> Felix Rubio <felix@kngnt.org> wrote:
> > Hey Stefano,
> > 
> > Thank you for your answer! I know I can run rootful containers, and that 
then
> > I can access the host's network ns. However, this exposes a number of
> > potential issues:
> > * In case the an attacker manages to break out of the container, gets root
> > * That enables connecting back to the host loopback, but then from that
> > container any service listening to the loopback can be reached as well.
> 
> Sure. That's the whole point behind pasta(1) and rootless containers
> with Podman / rootlesskit. I certainly won't be the one suggesting that
> you'd run anything as root. :)
> 
> > The reason for looking for a way of binding those services to 10.255.255.1 
(so
> > that only exposed services will be in that interface) and running fully
> > rootless, if works, provides a more secure system... in general.
> 
> Indeed.
> 
> > About the mapped ports, I am a bit lost: for what I have tested, running
> > rootless disables the possibility to connect back to the host, right?
> 
> Hah, I see now. No, that's not the case. You can run rootless
> containers and connect to the host from them, in two ways:
> 
> 1. disabled by default in Podman's pasta integration, not what you want:
>    via the loopback interface, see -U / -T in 'man pasta' and
>    --host-lo-to-ns-lo for the other way around.
> 
>    In that case, packets appear to be local (source address is
>    loopback) in the other namespace ("host" or initial namespace for
>    packets from a container, and container for packets from host).
> 
>    This gives you better throughput but making connections appear as if
>    they were local is risky (cf. CVE-2021-20199), so it's disabled by
>    default, and not what I'm suggesting (at least in general)
> 
> 2. what you get as default in Podman: using pasta's --map-guest-addr.
> 
>    The current description of this option in pasta(1) isn't great, hence
>    https://bugs.passt.top/show_bug.cgi?id=132, but the idea is that you
>    will reach the host from the container with a non-loopback address,
>    as if the connection was coming from another host (which should
>    represent the expected container usage).
> 
> So here's an example:
> 
> $ podman run --rm -ti -p 8089:80 traefik/whoami
> 2025/12/21 10:42:16 Starting up on port 80
> 
> [in another terminal]
> $ podman run --rm -ti fedora curl host.containers.internal:8089
> Hostname: ab94f49b5042
> IP: 127.0.0.1
> IP: ::1
> IP: **.***.*.***
> IP: ****:***:***:***::*
> IP: ****::****:****:****:****
> RemoteAddr: 169.254.1.2:46592
> GET / HTTP/1.1
> Host: host.containers.internal:8089
> User-Agent: curl/8.15.0
> Accept: */*
> 
> ...doesn't that work for you? Note that you'll need somewhat recent
> versions of pasta (>= 2024_08_21.1d6142f) and Podman (>= 5.3).


-- 
Felix Rubio

Connecting back to the host through a dummy veth interface

[Felix Rubio]

Hi everybody,

I am trying to run a number of rootless podman pods and containers by different 
users, while still being able to talk to each other. To this end I am creating 
a dummy veth interface and publishing all the exposed ports there (this works: 
I can communicate from other host services with those containers), and I am 
also trying to set that dummy veth interface as the default gateway for the 
pods/containers (with the expectation that then they will be able to reach 
each other). However, this is not working... and I am pretty lost.

For example, I am running the following command, trying to connect a ldap 
client container to a ldap server container, unsuccessfully.

podman run --rm --dns=10.255.255.1 --network=pasta:--outbound-
if4=cluster_dns0,--gateway=10.255.255.1 --add-host=ldap.host.internal:host-gateway sh -c "ip add && ip route && ldapwhoami -H ldaps://
ldap.host.internal:1636"

Is this something impossible to do, or am I doing something wrong?

Thank you very much for any help you can provide!

-- 
Felix
Felix Rubio