From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 0E4B05A026F for ; Wed, 28 Jun 2023 14:01:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687953680; 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=WtZTyb6xCy5fdzaBQ3oAhLiBmzNWg/K5cupsbS7H9v0=; b=e4Xu0tAbfwERChVWuutKfs4knsgVZWQJauNunCu6O5pedIi+VQDH6rH1TdYnzFJbmwcncJ 29lE5xhJMvWjd75x/a9NEYoCOOVtrFeLqlyC014QN7+zrIw+w7nA1i5dcwdXhVV/2iGnIl fCA95XMEQkEEShWk2GayuJ+gbaNi4ZU= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-86-dZE4JbyKOtKfQXAI1KqwxQ-1; Wed, 28 Jun 2023 08:01:14 -0400 X-MC-Unique: dZE4JbyKOtKfQXAI1KqwxQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 662413810D40; Wed, 28 Jun 2023 12:01:12 +0000 (UTC) Received: from elisabeth (unknown [10.39.208.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79CFF111F3B0; Wed, 28 Jun 2023 12:01:11 +0000 (UTC) Date: Wed, 28 Jun 2023 14:01:05 +0200 From: Stefano Brivio To: "jklaiho@iki.fi" Subject: Re: Pasta-networked rootless Podman container gets Connection Refused with the host's public IP Message-ID: <20230628140105.1aebe140@elisabeth> In-Reply-To: References: Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 7EHJ4AZTQHEUHYMQMMGY2XY3GYAAJDFJ X-Message-ID-Hash: 7EHJ4AZTQHEUHYMQMMGY2XY3GYAAJDFJ X-MailFrom: sbrivio@redhat.com 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, Paul Holzinger 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: Hi JK, On Wed, 28 Jun 2023 11:02:55 +0300 "jklaiho@iki.fi" wrote: > Hi; I previously asked this on the Podman mailing list, but I'm not > sure if the issue in question is a feature of Podman or Passt (or > both), and I got no replies from the Podman list, so I figured I'd > try here as well. I actually saw an answer to that, did you miss this perhaps? https://lists.podman.io/archives/list/podman@lists.podman.io/message/AAL6OMIB2CD4RHEXHDAAWZM4PYJNZXB2/ Anyway, in more detail: > We're running some rootless Podman containers set up to use Pasta > 2023_03_29.b10b983 for networking. One of the containers needs to > access the host machine port 443 with its public IP address, but this > causes a Connection Refused error. Any other public IP is accessible > normally. > > This is specific to the containers; the host has no problem accessing > itself with the public IP. > > The containers are set up with systemd generators (quadlet), with > networking configured very simply: > > "Network=pasta:-t,auto,-T,auto" > > Podman has a --map-gw option useable with Pasta that seemed like it > might help, but it didn't. That would help you (minus the issue you hit) if you wanted to connect to the parent network namespace ("host") using another address, namely the address of the default gateway (only option at the moment, we plan to make it configurable) -- but not the public address. > "Network=pasta:--map-gw,-t,auto,-T,auto" fails like this at container > startup: > > Error: failed to start pasta: > Port forwarding mode 'none' conflicts with previous mode The problem here comes from the fact that the Podman integration already passes "-t none" by default, and the override here doesn't quite work, because pasta doesn't accept overriding options on its command line. Paul (Cc'ed) plans to send a patchset to fix this in pasta itself. > "Network=pasta:-t,auto,-T,auto,--map-gw" started the container fine, > but did not fix the Connection Refused error. Apparently --map-gw > just isn't the right option here. "-T auto" is yet a different thing: that would map ports from your container to the "host" via loopback addresses (127.0.0.1 or ::1). > I don't know if the inability to contact the public IP is a feature > of Podman or Pasta, but I'm hoping you're able to at least narrow it > down for me. > > Is there a workaround on the Pasta side? I think the issue you're facing is that, by default, your container gets the same set of addresses as _one interface_ (the first one with a default route) on the host. Then you use one of those addresses to connect... but you already have that address in the container, so the container will try to connect to itself (hence the connection refused). There are two options I see: - you could change the address you use to connect to the HTTPS service on the host -- if you're in the container, you can use the address of the default gateway as reported by ip -4 route show / ip -6 route show (with --map-gw), or 127.0.0.1/::1 (with -T auto, or -T 443) - you could change the address of your container. You can specify address and default gateway with -a / -g (currently, only once for IPv4, and once for IPv6). Or you can select another interface on the host which pasta uses to source addresses and routes. For that, on the version of the passt package you're using, you're limited to "-i", which simply specifies the interface from which address and default gateways are sourced. Later versions implement a distinction between that "template" interface and outbound interfaces (--outbound-if4, --outbound-if6). I hope this helps. If you're facing issues with this, it would help if you could share addressing and routing information from your host and container (you can obfuscate by translating addresses consistently to TEST-NET subnets for IPv4, such as 192.0.2.0/24 and 198.51.100.0/24, or 2001:db8::/32 for IPv6). By the way of package versions, I requested just yesterday the first upload of an updated version after the Debian 12 release (I'm a maintainer without upload rights): https://qa.debian.org/cgi-bin/vcswatch?package=passt which should be synchronised to Ubuntu in a while (I think it's a couple of weeks after that). -- Stefano