host.containers.internal does not resolve host loopback services

[th0th14m]

Issue Description

I have a service "A" running on 127.0.0.1:8000 and services "B" and "C" based on compose files that need to access service A.
Services B and C share a network created with podman network create shared and can communicate with each other.
Using host.containers.internal:8000 services B and C cannot connect to service A.
If I instead bind service A to 0.0.0.0:8000, then service B and C are able to connect to host.containers.internal:8000.
This is not a permanent option, since now service A is exposed on all interfaces.

Steps to reproduce the issue

Working example but service A is exposed:

# in one session create a simple webserver
echo "something" > index.html
python3 -m http.server # this binds to 0.0.0.0
# in another session
podman run --rm -it alpine sh
- apk add curl
- curl host.containers.internal:8000 # connects successfully
- curl 169.254.1.2:8000 # connects successfully
- curl 10.0.2.2:8000 # gateway IP found using ip route, error could not connect to server
- exit

Failing example, but that I would expect to work

# in one session create a simple webserver
echo "something" > index.html
python3 -m http.server -b 127.0.0.1
# in another session
podman run --rm -it alpine sh
- apk add curl
- curl host.containers.internal:8000 # error could not connect to server
- curl 169.254.1.2:8000 # same error
- curl 10.0.2.2:8000 # gateway IP found using "ip route", same error
- exit

Working example with service A bound to 127.0.0.1:8000 but not compatible with compose files:

# in one session create a simple webserver
echo "something" > index.html
python3 -m http.server -b 127.0.0.1
# in another session
podman run --rm --network=pasta:--map-gw -it alpine sh
- apk add curl
- curl host.containers.internal:8000 # error could not connect to server
- curl 169.254.1.2:8000 # same error
- curl 10.0.2.2:8000 # connects successfully
- exit

Describe the results you received

The first working example exposes the service on all interfaces, which is unwanted.
The second working example would be an acceptable workaround but I have to manually retrieve the gateway address on every system. And after many hours of searching I was unable to find a way to set "map-gw" for the shared network or somewhere in the compose files.

Describe the results you expected

My expectation was that I can bind a service to 127.0.0.1 and access it within a podman container using host.containers.internal, or as a workaround that I can set map-gw for the shared network either using podman network cli or in the compose files.

podman info output

The above steps to reproduce have been tested on a fully updated NixOS 25.11 amd64 with podman 5.7.0
and on a fully updated Ubuntu 24.04 amd64 VM with podman 4.9.3.
The results on both systems were identical.

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

The Ubuntu 24.04 system was running in VirtualBox.

Additional information

No response

[Luap99]

That is by design, exposing services on localhost by default to all container could be a security issue.

As such this name should not resolve to such address.

If you want to do this you can use --network pasta:--map-host-loopback,169.254.1.3 --add-host host.containers.internal:169.254.1.3 for example.

Both options can be set ion compose files, the --network cli option just maps to network_mode, i.e.
https://github.com/containers/podman/blob/8ca8362c64bf2f01c599fd5e37856f0654a65c29/test/compose/slirp4netns_opts/docker-compose.yml#L4

[th0th14m]

Thank you very much for your fast reply and explanation.
I agree that exposing loopback could be a security issue and understand why it is not default.

Maybe you can move this from issues into discussions then?

I tested your suggested solution like this:

# in one session create a simple webserver
echo "something" > index.html
python3 -m http.server -b 127.0.0.1
# in another session
podman run --rm --network=pasta:--map-host-loopback,169.254.1.3 --add-host host.containers.internal:169.254.1.3 -it alpine/curl curl host.containers.internal:8000

This worked perfectly well.

Then I created a compose file like this:

services:
  alp:
    image: alpine/curl
    command: sleep infinity
    extra_hosts:
      - "host.containers.internal:169.254.1.3"
    network_mode: "pasta:--map-host-loopback,169.254.1.3"

and ran it with podman compose up -d.
Then podman exec alp_alp_1 curl host.containers.internal:8000 which was able to connect to service A.

Connecting this compose file with my existing shared network to service B and C however does not work.
The new compose file looked like this:

services:
  alp:
    image: alpine/curl
    command: sleep infinity
    extra_hosts:
      - "host.containers.internal:169.254.1.3"
    network_mode: "pasta:--map-host-loopback,169.254.1.3"
    networks:
      - shared

networks:
  shared:
    external: true

Starting with podman compose up -d gives the error "networks and network_mode must not be present in the same service"

Is also tried a compose file like this:

services:
  alp:
    image: alpine/curl
    command: sleep infinity
    extra_hosts:
      - "host.containers.internal:169.254.1.3"
    networks:
      - loop
      - shared

networks:
  loop:
    network_mode: "pasta:--map-host-loopback,169.254.1.3"
  shared:
    external: true

The podman compose up -d command did not throw errors.
When I run the same podman exec alp_alp_1 curl host.containers.internal:8000 command from the first compose file, curl just waits without ever connecting.
Moving network_mode down from "loop" into "shared" results in the same. As far as I can tell from the podman documentation network_mode is not supported in such a network definition as above.

How could I create a loop network that maps the host loopback, or map the host loopback in my external shared network?

Thank you in advance

[th0th14m]

After some more searching I was still not able to resolve this problem.
I think an intuitive way to add the host loopback in a compose file would be:

services:
  alp:
    ...
    extra_hosts:
      - "host.containers.loopback:host-loopback"

Similar to how I am able to map the host gateway:

services:
  alp:
    ...
    extra_hosts:
      - "host:host-gateway"

I've also thought about creating an additional interface on my host to which service A is bound, but I have not been able to find a way to make this interface visible in the compose file.

[th0th14m]

Finally I have partial success.
This solution is not perfect, but I am now able to access service A bound to 127.0.0.1:8000 in a compose file that is attached to the shared network.
For me this is now good enough, since no critical services are exposed on my host loopback.

Setup:

# in one session create a simple webserver
echo "something" > index.html
python3 -m http.server -b 127.0.0.1

# in another session
# edit or create the file ~/.config/containers/containers.conf with the following content
[network]
default_rootless_network_cmd = "pasta"
pasta_options = ["--map-host-loopback", "169.254.1.3"]

# Now create the shared network as normal
podman network create shared

# create compose.yml with following contents:
services:
  alp:
    image: alpine/curl
    command: sleep infinity
    extra_hosts:
      - "host.containers.internal:169.254.1.3"
    networks:
      - shared

networks:
  shared:
    external: true

Start the service with podman compose up -d.
Now when running podman exec alp_alp_1 curl host.containers.internal:8000 the connection to service A succeeds.

Why is this solution not optimal?
A more optimal solution would allow me to map host-loopback only for a specific service or network.
Setting the pasta option in the containers.conf exposes the host-loopback on all podman services that are connected to a pasta based network.
Maybe it is possible to restrict the network or service by editing/creating a different network/service specific conf file, but I was unable to find information on that and won't investigate further since the above solution is good enough for me.

[Luap99]

If you use custom networks then there is exactly one pasta process involved, see #22943 (comment)

So either it has that option or not.