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

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

[Yuxi Liu]

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

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.

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.

Best regards,
Yuxi Liu

[-- Attachment #2: Type: text/html, Size: 2953 bytes --]

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

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

> 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.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Paul Holzinger]

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