With Debian 12 support sunset, module developers are moving from slirp4netns to Pasta, Podman's default rootless network. ldapproxy listens only on 127.0.0.1, so a container on the default Pasta network cannot reach it. The current workaround is --network pasta:--map-gw,-a,10.0.2.0,-g,10.0.2.2, which maps the gateway address to the host's loopback interface. That exposes every loopback service on the node to the container, not just ldapproxy, and those connections look local to the services receiving them.
The purpose of this feature is to let LDAP client modules reach ldapproxy with Pasta's default configuration, without exposing the host's loopback interface. The same approach also gives module developers one consistent rule for reaching node services from a container.
Proposed solution
- Change ldapproxy's nginx stream listeners from
127.0.0.1:<port> to all IPv4 addresses (listen <port>;).
- IPv4 only: clients use
127.0.0.1 or host.containers.internal (169.254.1.2), both IPv4. A [::] listener would also stop nginx from starting on nodes with IPv6 disabled.
- The ldapproxy ports (20000+) remain closed by the node firewall.
- Nothing changes for existing modules. The advertised address stays
127.0.0.1, and current workarounds (--map-gw with the 10.0.2.x addressing, or slirp4netns) keep working.
- Document the rule in the developer manual: to reach the node from a container, use
host.containers.internal. For example, connect to ldapproxy at host.containers.internal:<port>, and use --add-host <fqdn>:host-gateway for apps behind Traefik on the same node.
Alternative solutions
- Document
--network pasta:--map-gw,-a,10.0.2.0,-g,10.0.2.2 as the standard. This works, but exposes the host's loopback interface to the container.
--network pasta:-T,<port> forwards a single port to the host's loopback. It limits the exposure, but each module must know and configure the ldapproxy ports.
Additional context
Verified on Rocky 9.7, Podman 5.6, passt 2025_05: host.containers.internal / host-gateway resolves to 169.254.1.2 and reaches node services on the default Pasta network and on custom bridge networks.
See also
With Debian 12 support sunset, module developers are moving from slirp4netns to Pasta, Podman's default rootless network. ldapproxy listens only on
127.0.0.1, so a container on the default Pasta network cannot reach it. The current workaround is--network pasta:--map-gw,-a,10.0.2.0,-g,10.0.2.2, which maps the gateway address to the host's loopback interface. That exposes every loopback service on the node to the container, not just ldapproxy, and those connections look local to the services receiving them.The purpose of this feature is to let LDAP client modules reach ldapproxy with Pasta's default configuration, without exposing the host's loopback interface. The same approach also gives module developers one consistent rule for reaching node services from a container.
Proposed solution
127.0.0.1:<port>to all IPv4 addresses (listen <port>;).127.0.0.1orhost.containers.internal(169.254.1.2), both IPv4. A[::]listener would also stop nginx from starting on nodes with IPv6 disabled.127.0.0.1, and current workarounds (--map-gwwith the 10.0.2.x addressing, or slirp4netns) keep working.host.containers.internal. For example, connect to ldapproxy athost.containers.internal:<port>, and use--add-host <fqdn>:host-gatewayfor apps behind Traefik on the same node.Alternative solutions
--network pasta:--map-gw,-a,10.0.2.0,-g,10.0.2.2as the standard. This works, but exposes the host's loopback interface to the container.--network pasta:-T,<port>forwards a single port to the host's loopback. It limits the exposure, but each module must know and configure the ldapproxy ports.Additional context
Verified on Rocky 9.7, Podman 5.6, passt 2025_05:
host.containers.internal/host-gatewayresolves to169.254.1.2and reaches node services on the default Pasta network and on custom bridge networks.See also