Support accessing Podman services from Windows LAN

[ThomasVitale]

Is your enhancement related to a problem? Please describe

When running Podman Desktop on Windows, containers running in the Podman machine are accessible from the Windows host from localhost. However, because of how WSL2 works (see details), those services are not accessible when using the PC domain name or IP address (e.g. ..local).

Windows requires to run the CLI netsh interface portproxy for each port we want to access via PC domain name or IP address.

The forward needs to be towards the WSL2 IP address, which is dynamic and changes on each reboot. So every time a Windows machine is started, before being able to consume Podman service, the Windows proxy need to be reconfigured.

Describe the solution you'd like

I would like Podman Desktop to transparently take care of setting up the proxy in Windows to allow accessing Podman containers from the PC domain name or IP address. That's something that Docker Desktop does.

Describe alternatives you've considered

No real alternative here. Would it be possible to implement a Podman exception that intercepts container events and configures the proxy dynamically?

Additional context

No response

[jeffmaury]

Looks like a Podman upstream issue. Did you try with the latest user networking mode ?

[mheon]

@n1hility PTAL

[ThomasVitale]

@jeffmaury Thanks for your comment. I tried with a Podman machine configured with user networking, but the result was the same. Calling <machine-name>.<domain-group>.local:8080 or <machine-ip>:8080 doesn't work from the Windows host, but localhost:8080 does.

[n1hility]

Currently, even when using user-mode networking, port forwarding is still done by the WSL port mirroring. We could explore disabling WSL port mirroring, and handling this in gvproxy when user-mode is enabled, which would result in the bind being on the Windows host. However, I think the feature request as suggested is also a good idea to support port proxy registration.

@ThomasVitale as a workaround you could do a script in a startup task that establishes this on login, is that what you are currently doing?

[ThomasVitale]

@n1hility thanks for your answer. It would be great if Podman could do that out of the box!

The workaround I'm investigating right now is a PowerShell script scheduled to run at PC startup (for example, using the Windows Task Scheduler). The script would clear the previous proxy configuration (netsh interface portproxy reset) and add new forward rules. So far, I haven't found any way to do that on a range of ports, meaning that you need to know which ports the containers will expose in advance and run a command for each of them (e.g. netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=8080 connectaddress=<wsl-ip>).

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[ThomasVitale]

Can we remove the stale status from this issue and keep it open?

[rhatdan]

@ThomasVitale is this something you can work on?

[ThomasVitale]

@rhatdan I'm definitely available to help with this issue. I'm not very familiar with this specific area, but if I can get some guidance and support, I'm available to give it a try.

[rhatdan]

Go for it.

[n1hility]

@ThomasVitale FYI there is a new feature in WSL called mirrored mode networking that is in preview builds that we are likely to take advantage (perhaps requiring) once it hits stable. In addition to providing a capability like our user-mode networking feature, it also supports exposing ports to the outside world, since it mirrors network interfaces. I mention this in case you prefer to wait on that.

[lbouriez]

By any chance, did anyone found a solution :) ? We were exploring the idea to use podman on our VMs instead of Docker-compose but we are blocked here, cannot expose our services outside the VMs :(

[ThomasVitale]

@n1hility I had missed your message, sorry. Thanks a lot for the info, that looks really promising! I haven't had much luck with my experiments trying to use the windows proxy (beyond hacky scripts). I'll try investigating if the new mirrored mode in WSL2 solves the issue for Podman. I'll write here my findings as soon as I get to try that out.

@lbouriez the only workaround I found is explicitly configuring the proxy via the netsh interface portproxy as described here: https://github.com/containers/podman/issues/19890#issuecomment-1711727349

[marco4net]

@n1hility I had missed your message, sorry. Thanks a lot for the info, that looks really promising! I haven't had much luck with my experiments trying to use the windows proxy (beyond hacky scripts). I'll try investigating if the new mirrored mode in WSL2 solves the issue for Podman. I'll write here my findings as soon as I get to try that out.

@lbouriez the only workaround I found is explicitly configuring the proxy via the netsh interface portproxy as described here: #19890 (comment)

One important point for the portproxy command: Make sure that one (!) IP is provided in the command. In my case, multiple network interfaces are present in the Podman WSL2 machine.

Having multiple IP causes an issue when relying on the Microsoft documentation examples that instruct to use $(wsl hostname -I) like in this sample to expose port 8000 for Paperless-ngx:

netsh interface portproxy add v4tov4 listenport=8000 listenaddress=0.0.0.0 connectport=8000 connectaddress=$(wsl hostname -I)

This causes also the aforementioned issue that services are only exposed to localhost instead of all IP for the Windows LAN. Rather use in Powershell with administrator rights:

$wslIP = $(wsl hostname -I).Split(" ")[0];netsh interface portproxy add v4tov4 listenport=8000 listenaddress=0.0.0.0 connectport=8000 connectaddress=$wslIP