[Windows/WSL] Container port mapping accessible from Windows host but inaccessible from inside the Podman machine (localhost)

[jiaruihuang]

Issue Description

I created a Podman machine using WSL on Windows. When I run a container and map the ports (-p), the service is accessible from the Windows host via localhost. However, when I SSH into the Podman machine (WSL), the service is not accessible via localhost using curl.

The ss -nltp command inside the machine shows that conmon is listening on 0.0.0.0:9090, but connections from inside the machine fail.

Steps to reproduce the issue

1. Create a WSL Podman machine (rootful).
2. Run an Nginx container with port mapping:

   podman run -d --rm -p 9090:80 docker.io/nginxdemos/hello

3. Access from Windows Host:
   • Open browser on Windows to http://localhost:9090.
   • Result: Success (page loads).
4. Access from inside the Podman machine:
   • Login: podman machine ssh
   • Run: curl http://localhost:9090
   • Result: Fails (Connection timed out).

Describe the results you received

curl http://localhost:9090 inside the WSL/Podman machine fails despite the port appearing to be open.

Describe the results you expected

The service should be accessible from both the Windows host and the localhost inside the Podman machine itself.

podman info output

Client:
  APIVersion: 5.7.1
  Built: 1765378491
  BuiltTime: Wed Dec 10 22:54:51 2025
  GitCommit: f845d14e941889ba4c071f35233d09b29d363c75
  GoVersion: go1.25.5
  Os: windows
  OsArch: windows/amd64
  Version: 5.7.1
host:
  arch: amd64
  buildahVersion: 1.42.2
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.13-2.fc43.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.13, commit: '
  cpuUtilization:
    idlePercent: 99.3
    systemPercent: 0.44
    userPercent: 0.25
  cpus: 8
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: container
    version: "43"
  eventLogger: journald
  freeLocks: 2042
  hostname: Alex-MGV14
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.6.87.2-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 2858127360
  memTotal: 4106457088
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.17.0-1.fc43.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.17.0
    package: netavark-1.17.0-1.fc43.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.17.0
  ociRuntime:
    name: crun
    package: crun-1.25.1-1.fc43.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.25.1
      commit: 156ae065d4a322d149c7307034f98d9637aa92a2
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20250919.g623dbf6-1.fc43.x86_64
    version: |
      pasta 0^20250919.g623dbf6-1.fc43.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: unix:///run/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: true
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 4294967296
  swapTotal: 4294967296
  uptime: 10h 5m 38.00s (Approximately 0.42 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 4
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.additionalImageStores:
    - /usr/lib/containers/storage
    overlay.imagestore: /usr/lib/containers/storage
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 1081101176832
  graphRootUsed: 2440343552
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 5
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.7.1
  BuildOrigin: 'Copr: packit/containers-podman-27732'
  Built: 1765238400
  BuiltTime: Tue Dec  9 08:00:00 2025
  GitCommit: f845d14e941889ba4c071f35233d09b29d363c75
  GoVersion: go1.25.4 X:nodwarf5
  Os: linux
  OsArch: linux/amd64
  Version: 5.7.1

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

Environment:

• OS: Windows (WSL2)
• Podman Machine Init config: --rootful=true --user-mode-networking=false

Configuration files:

.wslconfig (Windows side):

[network]
networkingMode=Mirrored
hostAddressLoopback=true
localhostForwarding=true

/etc/containers/containers.conf (Inside Podman Machine):

[engine]
firewall_driver="iptables"

Additional information

Inside podman machine ssh:

[root@Alex-MGV14 ~]# ss -nltp
State     Recv-Q    Send-Q        Local Address:Port        Peer Address:Port    Process
LISTEN    0         4096                0.0.0.0:9090             0.0.0.0:*        users:(("conmon",pid=62865,fd=5))

It seems that while the port binding works for Windows integration (likely due to WSL2 mirrored networking/forwarding), the loopback routing inside the WSL VM itself is not functioning correctly for this port. The conmon process is listening on 0.0.0.0, which typically implies it should be accessible locally.

[ninja-quokka]

I don't think this is something we support, what is your use case for needing this?

[jiaruihuang]

I don't think this is something we support, what is your use case for needing this?

My specific use case is as follows:

1. I need to expose a container service from my development environment to an internet client for quick prototype verification.
2. The client logs in to Teleport to access specific app services I provide.
3. I want to provide my development environment (on my personal Windows PC) directly as one of these Teleport app services.
4. Since I develop on Windows using Podman, and the Teleport server component cannot be installed on Windows (it requires Linux), I plan to install the Teleport binary inside the Podman machine and join it to my Teleport cluster.
5. This Teleport instance installed inside the machine needs to be configured with the URI of the service to proxy. I wanted to use http://localhost:9090 to point to my container service:

app_service:
  enabled: "yes"
  debug_app: false
  mcp_demo_server: false
  apps:
  - name: devdemo
    uri: http://localhost:9090
    public_addr: ""
    insecure_skip_verify: false
    use_any_proxy_public_addr: false

Since http://localhost:9090 is not accessible from inside the Podman machine, I cannot onboard the service to my Teleport cluster this way.

I have currently found a workaround: I run a Teleport container and use http://host.containers.internal:9090 to join the cluster. This works and the client has successfully accessed the service.

I raised this issue to clarify if this is by design in the Podman machine, or if there is a misconfiguration in my setup. I want to understand if accessing local ports from inside the VM is an expected behavior that should be supported, or if this is a limitation/issue specific to my configuration.