From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=reject dis=none) header.from=kngnt.org Authentication-Results: passt.top; dkim=pass (1024-bit key; secure) header.d=kpnmail.nl header.i=@kpnmail.nl header.a=rsa-sha256 header.s=kpnmail01 header.b=brkMdATr; dkim=pass (2048-bit key; secure) header.d=kngnt.org header.i=@kngnt.org header.a=rsa-sha256 header.s=mail header.b=EHynSc/6; dkim-atps=neutral Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.186]) by passt.top (Postfix) with ESMTPS id 193675A0652 for ; Tue, 23 Dec 2025 08:34:54 +0100 (CET) X-KPN-MessageId: 80e9043b-dfd2-11f0-b0b9-00505699b430 Received: from smtp.kpnmail.nl (unknown [10.31.155.6]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 80e9043b-dfd2-11f0-b0b9-00505699b430; Tue, 23 Dec 2025 08:39:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kpnmail.nl; s=kpnmail01; h=content-type:mime-version:message-id:date:subject:to:from; bh=Ow8TadWp66hEcwJSnZHjfW4zeDa+AWCL+GgdZdvgWRg=; b=brkMdATr76r03mYHCixdCEODJ/TmSSGnBuBtUePN/iiWpy1FNzrCv/35x2tLmCIOZY1kKVp6GwDxI HtYgUWHlgwl2Nx69+XdAIe63SsRmx26XpjPzL2hMaQ0fUdXAU9vvqgmeOWZRoDgC8Pl95DmQkZByAb S8lRddZWfDTlDTyE= X-KPN-MID: 33|eGzVyEJ93HZQIe6bkW39XKKMkLG3yQamrncT6VW9PA0WvTWlvkwfiA4sJQPQEPd TeCi9BSplimJ45l7zG+Ht+yQ30mBPWbOJ0SgLSyTljeg= X-KPN-VerifiedSender: No X-CMASSUN: 33|d0Z0T0q/vOTXJ6tQ/Xz7FElx/oxowO/Hn+XJelzDQakaMJkerybC1Sd0co8mruj 2pPuWywJag0155IQdtqdR5w== X-Originating-IP: 82.169.112.203 Received: from mail.kngnt.org (82-169-112-203.fixed.kpn.net [82.169.112.203]) by smtp.kpnmail.nl (Halon) with ESMTPSA id de0842e6-dfd1-11f0-bff4-00505699772e; Tue, 23 Dec 2025 08:34:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kngnt.org; s=mail; t=1766475291; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ow8TadWp66hEcwJSnZHjfW4zeDa+AWCL+GgdZdvgWRg=; b=EHynSc/6iHdpykT/WFEaEn1B8Fk4Rq7NIH0q0f9eSdQ6h8PgXi2M6fEF1TrClPHMu7IY2W 5O+doT4PY3MCVMJpWwP7GnXUSWZbCaJyuvv1zzBYwLMZCSOBI5DTdIJ7f3Tw8sOPuRHdUL FzEvwfrmRRi6ed6cL0MBlDQn/tNw56Dr/jSWRWJtzC1Xyb7003xckC0erVoPuEuGsSBZrI OrgeZkPIpYtQqp6gFRjJ0YKUM7s1M20CxRAWdPauATFSi4s4AvTvJXyepAVYc/CL2VrASH NUh8kPUdRB2b2OpqiV8KrkTALgDPZWF9jI0TNM767Q59pzQ+FTQ9KXS+MJ4xgw== From: Felix Rubio To: Stefano Brivio Subject: Re: Connecting back to the host through a dummy veth interface Date: Tue, 23 Dec 2025 08:34:50 +0100 Message-ID: <4701571.LvFx2qVVIh@altair> In-Reply-To: <20251222235117.2264ae71@elisabeth> References: <176606116131.2775.3279769610610037541@maja> <2379954.irdbgypaU6@altair> <20251222235117.2264ae71@elisabeth> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Message-ID-Hash: 7UK7YFBYXD5CAOPKWBG256QKQ56DBNQH X-Message-ID-Hash: 7UK7YFBYXD5CAOPKWBG256QKQ56DBNQH X-MailFrom: felix@kngnt.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-user@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: "For passt users: support, questions and answers" Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 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