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=hCoqnflt; dkim=pass (2048-bit key; secure) header.d=kngnt.org header.i=@kngnt.org header.a=rsa-sha256 header.s=mail header.b=iSCZGEpR; dkim-atps=neutral Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.185]) by passt.top (Postfix) with ESMTPS id 5BF0E5A065C for ; Sun, 21 Dec 2025 09:58:06 +0100 (CET) X-KPN-MessageId: 8ba12227-de4b-11f0-ad1a-005056999439 Received: from smtp.kpnmail.nl (unknown [10.31.155.6]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 8ba12227-de4b-11f0-ad1a-005056999439; Sun, 21 Dec 2025 10:00:49 +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=4/jXHJJ+wU62Qcp4EMMIJsbLCr80iCTCG0pSD/jASgs=; b=hCoqnfltQa9OBfn0F+kPRm9U/7ELlOoVqmb9UoaSBxVrRGte+p5nA6JF0DmIOz+d2fGSys9B+iZwz jAHAyI6v5bxQEOb9zGj6H/AKk45qx3i1pBubGlV+Lkv434Mim8m4uaOVqhcHkvUPU4z66dJoTAA+Gz Y1R6JnhDrtgB+oTw= X-KPN-MID: 33|nFRZhquWZ9bRFxaTUdih6utLzIj0yDQ5yWoPRrYNgR/7Enp7dNqd02kQcitAnPa eT9THrgvI7XU+tIHltlAa/R/XEiHsL0oDLKRQkXTcP1s= X-KPN-VerifiedSender: No X-CMASSUN: 33|/k6QKYj0b0BTIflbj0JQ4z15AbNUYHI7wLJTs6UzHeJjyFpxTHtuXDXj7YEBvl2 nUBRjgTh938gBVIrDgZgVrFQLBbyXAyjIoPGcmOnGi1k= 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 29ee3a51-de4b-11f0-bff4-00505699772e; Sun, 21 Dec 2025 09:58:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kngnt.org; s=mail; t=1766307485; 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=4/jXHJJ+wU62Qcp4EMMIJsbLCr80iCTCG0pSD/jASgs=; b=iSCZGEpRhx0bsOcU0L9JVs6xB17L8SpRG2O0If9/7P+v2FX26IfHjXRl6p564ux2beQcvH dIhkdpMho9Hei65Zz9/17bnqxdnofLxwuPRjRj2/O6GT5s2dIKTAGmVphvOs0GV7/C52ve gXALDVXgBcK/oJB9duXbBNhGX5DueO1QqfAKseCPpAaKYA3+d1OOp5MVM9jR4bTFRIxE06 fJ5VF/W8wcoJGTVzPhyHOlrJUI+wHe5g/BXQz6O2269mfC3KlL3gqXiK25j5Hc/KLSsJ+H 1StU7SzxgkcpkAYOMSNFdhKzM64KGosWIDm6+wSCsLLGLKjiUs1NbGuP0lIGFQ== From: Felix Rubio To: Stefano Brivio Subject: Re: Connecting back to the host through a dummy veth interface Date: Sat, 20 Dec 2025 15:28:43 +0100 Message-ID: <5105334.31r3eYUQgx@altair> In-Reply-To: <20251220151224.1cc7c5cc@elisabeth> References: <176606116131.2775.3279769610610037541@maja> <20251220151224.1cc7c5cc@elisabeth> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Message-ID-Hash: OGSPPRXB5ORKFPTLBYH65AW2CHVXIBS2 X-Message-ID-Hash: OGSPPRXB5ORKFPTLBYH65AW2CHVXIBS2 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: 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 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