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

[Felix Rubio <felix@kngnt.org>]

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:
> On Mon, 22 Dec 2025 13:48:03 +0100
> 
> Felix Rubio <felix@kngnt.org> wrote:
> > Ok, things are starting to get clear. The problem was, I think, between 
the
> > 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 
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
> 
> It's rather not identified as "loopback".
> 
> > 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.
> 
> 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