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=HousmeJv; dkim=pass (2048-bit key; secure) header.d=kngnt.org header.i=@kngnt.org header.a=rsa-sha256 header.s=mail header.b=QS5Hnjv9; dkim-atps=neutral Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.185]) by passt.top (Postfix) with ESMTPS id 76C425A0271 for ; Mon, 22 Dec 2025 13:48:05 +0100 (CET) X-KPN-MessageId: d5770d1b-df34-11f0-ad1a-005056999439 Received: from smtp.kpnmail.nl (unknown [10.31.155.8]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id d5770d1b-df34-11f0-ad1a-005056999439; Mon, 22 Dec 2025 13:50:46 +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=B0jeNvehTdcaFhvL7s0VvYamirUMK1Q+X2IF0d8E52I=; b=HousmeJvaRO03YITeCC0B2WQFaAEfXGbqKQV6MpidBDDsZjKPxTWtCnvINwgd5fRw98QXn6/N3EkY pP6nJkXSUruUqsFJ/kLpQyqD9fVI40/sJuo0ZtnJqfUxsjCzfAvfwyyNpY0lNnC/4+JIBYoiZ3eNfM aYcFwOMTr1NZbobc= X-KPN-MID: 33|nGNjTYSU5nltbzsJAk6dxPCxeJc0xhwcD2/I0g76KMeTCXZUwFKagM6KgLbps8n u+bWgcMohw3xpgDHswu/S+RPpgEKXE3ioPCJVTEdAuSU= X-KPN-VerifiedSender: No X-CMASSUN: 33|PulcrmdMJVIjgZvicimt9AXRqTWud1w5iY0/RkwxlnFmGr6ODhEWg+8HOc55P3U 4XrS1haWgs5GFMfddegPAIA== 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 74c24f2f-df34-11f0-9bf7-00505699d6e5; Mon, 22 Dec 2025 13:48:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kngnt.org; s=mail; t=1766407683; 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=B0jeNvehTdcaFhvL7s0VvYamirUMK1Q+X2IF0d8E52I=; b=QS5Hnjv9USTnzerdB/vqGoVRIL/1dSlM8EYWu4U50vANDzb5DfIR9wLkcglNszT3MBncKx dh9Y2qq+fRYnYhHdewQWFqIzkPDM8CPIFFhrCoFM8fB63G9u+SYSHWZ2vJZNONF8Eb2w3n 4pcIb+LCwYMMhdIBa5hjKEJLkNrvlPba2ac98Q1bm+FbAoGo+ujC/Gy0IC1phhcGNw4kfA hpODG8dgvg5+XkjD5PiSBMl9SiLPUrkyx2g2QzbFE4claHlCcNeqvRsRKkv45W2CJa1SFM bvou31DdWwV6EoYQZCVuI6PaV0M7PP1Buuqqa0Wj94rM8r5YvwWzL1UyT3Ld4A== From: Felix Rubio To: Stefano Brivio Subject: Re: Connecting back to the host through a dummy veth interface Date: Mon, 22 Dec 2025 13:48:03 +0100 Message-ID: <2379954.irdbgypaU6@altair> In-Reply-To: <20251221114722.2a613e94@elisabeth> References: <176606116131.2775.3279769610610037541@maja> <5105334.31r3eYUQgx@altair> <20251221114722.2a613e94@elisabeth> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Message-ID-Hash: Z3I4DB3EMIDNG74SR3R6XSIEV3EMHQV6 X-Message-ID-Hash: Z3I4DB3EMIDNG74SR3R6XSIEV3EMHQV6 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: 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 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