host.containers.internal unreachable from rootless bridge containers: shared rootless-netns pasta missing --map-host-loopback

[fecet]

host.containers.internal unreachable from rootless bridge containers: shared rootless-netns pasta missing --map-host-loopback

Issue Description

Podman writes 169.254.1.2 host.containers.internal into every container's
/etc/hosts and passes --map-guest-addr=169.254.1.2 to the shared
rootless-netns pasta, but never passes the outbound counterpart
--map-host-loopback=169.254.1.2. The host.containers.internal contract is
half-wired:

• inbound (host → container at 169.254.1.2): handled by --map-guest-addr
• outbound (container → host via 169.254.1.2): not handled — packets to
  169.254.1.2 fall through to the default route and die

For rootless bridge containers (the common case for any custom network) this
makes host.containers.internal unreachable, despite podman's own
/etc/hosts entry promising it works.

Reproducer

# host: any TCP service on loopback
python3 -m http.server 9100 &

# fresh rootless container on a podman-created bridge network
podman run --rm --network=podman docker.io/alpine \
  wget -qO- --timeout=3 http://host.containers.internal:9100/

# actual:   wget: download timed out
# expected: directory listing from the python server

/etc/hosts inside the container correctly contains:

169.254.1.2     host.containers.internal host.docker.internal

The shared rootless-netns pasta launched by podman has:

/usr/bin/pasta --config-net --pid ... --dns-forward 169.254.1.1 \
  -t none -u none -T none -U none --quiet \
  --netns /run/user/$UID/containers/networks/rootless-netns/rootless-netns \
  --map-guest-addr 169.254.1.2

--map-host-loopback is missing. pasta has full support for the flag; podman
just doesn't pass it.

Workaround (confirms the root cause)

# ~/.config/containers/containers.conf
[network]
pasta_options = ["--map-host-loopback=169.254.1.2"]

Then stop all rootless containers using the shared rootless-netns so the
long-running pasta exits, and let the next container spawn re-launch pasta
with the new argv. Verify:

ps -eo cmd | grep -F /usr/bin/pasta
# /usr/bin/pasta --config-net --map-host-loopback=169.254.1.2 ... --map-guest-addr 169.254.1.2

host.containers.internal:<port> then reaches host services from bridge
containers as the /etc/hosts entry implies.

Suggested Fix

In the rootless-netns pasta launcher
(containers/common/libnetwork/pasta/pasta_linux.go createPastaArgs), add
--map-host-loopback symmetrically with the existing --map-guest-addr
default. The two are both halves of the same host.containers.internal
contract and should never be split.

Rough sketch:

if len(mapGuestAddrIPs) == 0 {
    cmdArgs = append(cmdArgs, mapGuestAddrOpt, mapGuestAddrIpv4)
    mapGuestAddrIPs = append(mapGuestAddrIPs, mapGuestAddrIpv4)
}
// outbound counterpart: without this the /etc/hosts entry podman writes for
// host.containers.internal is unreachable from bridge containers
if !containsArg(cmdArgs, "--map-host-loopback") {
    cmdArgs = append(cmdArgs, "--map-host-loopback", mapGuestAddrIpv4)
}

The IP picked should track host_containers_internal_ip so a custom contract
IP stays consistent across /etc/hosts, --map-guest-addr, and
--map-host-loopback.

Environment

component	version
podman	5.8.2
netavark	1.17.2
pasta	2026_05_07.1afd4ed
kernel	7.0.6-1-cachyos
distro	CachyOS (Arch-based)

Related Issues

• Host unreachable from container with bridge network on Podman v5 #22653 — Host unreachable from container with bridge network on Podman v5
  (closed). Same user-visible symptom; the discussion settled on
  "rootlessport vs pasta" as a design trade-off, but that frame only applies
  to inbound port mapping. The outbound path for bridge containers actually
  goes through pasta already — the workaround above is direct proof.
• host.containers.internal non functional when host address changes #24970 — host.containers.internal non functional when host address changes
  (open). Same area; same broken contract.
• rootlessport is still used instead of pasta when running a container connected to a bridge network. #26581 — rootlessport is still used instead of pasta when running a
  container connected to a bridge network (closed as expected). About
  inbound port mapping only; doesn't cover the outbound side this issue is
  about.
• Alternate port_handler that keeps the source ip for user-defined rootless networks #8193 — long-term tracker for rootless port-handler redesign. Largely
  orthogonal: that's about inbound. This issue is one missing flag on the
  outbound side that doesn't require any redesign.

[amyssnippet]

@fecet thanks for the reporting this issue.

i verified the behaviour and looked into the pasta init logic, createPastaArgs() indeed conditionally sets --map-guest-addr 169.254.1.2 for out-of-the-box host.containers.internal support, but completely omits the --map-host-loopback counterpart, breaking the outbound packet flow from the bridge containers as you described.

because the pasta_linux.go file is maintained in the containers/common repository and vendored into podman and the fix needs to be submitted there first.

[amyssnippet]

will soon fix this patch and open a pr which will fix it.

[Luap99]

@fecet please note https://github.com/containers/podman/blob/main/LLM_POLICY.md

The host loopback must not be reachable from within a container, this has nothing to do with inbound vs outbund differences. The --map-guest-addr option is mapped to the pasta ip which uses the default interface on the host as default.
So you will need to bind your services there not just on loopback. If you do want --map-host-loopback then you have to specify that user explicitly.