[BUG] --map-guest-addr target resolved once at startup; host network change kills the mapping silently and permanently
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
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
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
Yuxi, thanks for the report.
I think David and Paul already covered the main points here, but I have
a couple of details:
On Sat, 25 Jul 2026 09:28:14 -0700
Yuxi Liu
Expected -------- One of: 1. pasta re-resolves the mapping target when the host's addresses change, or
This is the plan, essentially. For the moment:
2. the mapped route fails loudly (RST) instead of silently, or
...we will reset the connection if our connect() attempt fails, or at least that should be the intention, and I'm fairly sure it works. So the route to the destination (via your default gateway, I suppose) is actually valid, packets are forwarded, but they just end up nowhere on your host, correct? If that's not the case, then it's something we should fix.
3. the man page warns that the mapping dies permanently on host network change.
This would be a welcome change for the moment anyway, it might take months before we get to 1., so feel free to submit a patch for the man page if you have a moment. Note that there's a pending patch being reviewed for --map-guest-addr, at: https://archives.passt.top/passt-dev/20260727040946.105277-1-david@gibson.dr... so you would probably need to integrate your changes with it. At the same time the additional note could form its own paragraph at the end. I routinely fix up trivial conflicts while merging changes, so, if it's its own paragraph, you don't really need to take care of them.
Laptops are a mainstream platform for rootless podman. A silent, permanent route death on every wifi change is a serious defect for them.
Absolutely. We have a ton of reports about those use cases, see: https://github.com/podman-container-tools/podman/discussions/22737#discussio... as well. The implementation is in progress but by no means trivial. Let us know if you want to contribute to it, by the way. -- Stefano
participants (4)
-
David Gibson
-
Paul Holzinger
-
Stefano Brivio
-
Yuxi Liu