Re: [BUG] --map-guest-addr target resolved once at startup; host network change kills the mapping silently and permanently

[Paul Holzinger <pholzing@redhat.com>]

On 27/07/2026 03:47, David Gibson wrote:
> On Sat, Jul 25, 2026 at 09:28:14AM -0700, Yuxi Liu wrote:
>> Hello,
>>
>> Bug report against pasta, as used by rootless podman for
>> host.containers.internal.
>>
>> What happens
>> ------------
>> Rootless container, default pasta networking (podman passes
>> --no-map-gw --map-guest-addr 169.254.1.2), on a laptop. The laptop
>> moves to a different network (hotel wifi, home, office). From that
>> moment, every connection from the container to 169.254.1.2 times out.
>> Forever. General outbound from the container keeps working, so the
>> failure looks like the host service died. The host service is fine and
>> answers on the host the whole time. Only recreating the container
>> fixes the route.
>>
>> Why it happens
>> --------------
>> --map-guest-addr forwards mapped traffic to the host's external
>> address (commit 57b7bd2). pasta resolves that address once, at
>> startup, and never again. After the host moves networks, pasta still
>> connect()s to the launch-time address. Nobody owns that address
>> anymore, the SYNs vanish, and no error is logged anywhere.
>>
>> pasta already runs a live netlink monitor in its event loop
>> (RTMGRP_NEIGH, neighbour events). Host address changes are the one
>> thing it reads once at startup and never watches afterward. Re-reading
>> the current address needs no privilege: getifaddrs() works for any
>> process.
> Right.  This is a known limitation.  We're working on it, but it's
> fairly difficult to fix correctly, because it interacts with a bunch
> of other features.  This is largely tracked by this bug:
>      https://bugs.passt.top/show_bug.cgi?id=141
And tracked for podman here already as well:
https://github.com/podman-container-tools/podman/issues/24970
>
>> Reproduce
>> ---------
>> 1. Laptop on wifi network A. Run a rootless podman container with the
>> default pasta network. Have any service listening on the host,
>> say port 8191.
>> 2. In the container: curl
>> https://www.google.com/url?q=http://host.containers.internal:8191&source=gmail&ust=1785083212577000&sa=E
>> -> answers.
>> 3. Move the laptop to wifi network B.
>> 4. Same curl -> timeout. Stays dead until the container is recreated.
>>
>> Versions: passt 0.0~git20250503.587980c-2 (Ubuntu 25.10),
>> podman 5.4.2.
>>
>> Expected
>> --------
>> One of:
>> 1. pasta re-resolves the mapping target when the host's addresses
>> change, or
>> 2. the mapped route fails loudly (RST) instead of silently, or
>> 3. the man page warns that the mapping dies permanently on host
>> network change.
>>
>> Laptops are a mainstream platform for rootless podman. A silent,
>> permanent route death on every wifi change is a serious defect for
>> them.
>>
>> Workaround
>> ----------
>> --map-guest-addr none --map-host-loopback 169.254.1.2 (via podman:
>> --network=pasta:--map-guest-addr,none,--map-host-loopback,169.254.1.2).
>> Mapped traffic then arrives on the host as 127.0.0.1, which the host
>> owns on every network. This changes source semantics (connections
>> appear to come from loopback), which is acceptable when you control
>> both sides.
> Right, for your use case, --map-host-loopback seems like a good
> workaround.  Even when we implement a netlink monitor,
> --map-guest-addr (or its future equivalent) can't really work when the
> laptop is not on any external network, because there is no external
> host address to direct traffic to.
>
-- 
Paul Holzinger