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

On Mon, 22 Dec 2025 13:48:03 +0100

Felix Rubio wrote:

...

Ok, things are starting to get clear. The problem was, I think, between

...

desk and the keyboard.

The chair! I think it was the chair. :)

...

* 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.

Yes, it's expected, because 10.255.255.1 is not a loopback address.

...

The reason for me asking is that all I have read points in the direction

...

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

It's rather not identified as "loopback".

...

connect to services bound to it? On the LDAP side, the logs show that

Damn... I knew I had to get rid of that chair... xD My setup is a bit complex: I am running a k3s cluster with some services outside it, but running on the same host. The purpose is to have some central services common to all the applications I am running (e.g., authentication) running on these rootless containers. This way I can take down the whole cluster without loosing services that are required by other parties... at the expense of properly protecting them. The reason for using a dummy interface is because then I can implement simple, wide rules, stating that this interface can only receive connections from the k3s cluster or to specific ports, and that connections from that interface can only be established to the cluster or to specific ports. I am doing this because, should a malicious actor manage to run code on those services or break outside of the container, they would be able to establish connections outside anywhere. I know I can use an existing interface for all this, but then I would have to be way more careful about how these firewall rules are implemented... whereas using this dummy interface I can deny by default and only allow as required. Stefano, thank you very much for your answers. I really appreciate the time you took writting them. Regards! Felix On Monday, 22 December 2025 23:51:17 Central European Standard Time Stefano Brivio wrote: the 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.

You don't need a whole new interface for that, by the way. You could just add that address to an existing interface, assuming that the LDAP server lets you bind to a specific address and not just a specific interface.

-- Felix Rubio