Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support accessing Podman services from Windows LAN #19890

Open
ThomasVitale opened this issue Sep 7, 2023 · 13 comments
Open

Support accessing Podman services from Windows LAN #19890

ThomasVitale opened this issue Sep 7, 2023 · 13 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. machine windows issue/bug on Windows

Comments

@ThomasVitale
Copy link

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
Copy link

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

@benoitf benoitf transferred this issue from containers/podman-desktop Sep 7, 2023
@benoitf benoitf added the windows issue/bug on Windows label Sep 7, 2023
@mheon
Copy link
Member

mheon commented Sep 7, 2023

@n1hility PTAL

@ThomasVitale
Copy link
Author

ThomasVitale commented Sep 8, 2023

@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
Copy link
Member

n1hility commented Sep 8, 2023

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?

@n1hility n1hility added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 8, 2023
@ThomasVitale
Copy link
Author

@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
Copy link

github-actions bot commented Oct 9, 2023

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

@ThomasVitale
Copy link
Author

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

@rhatdan
Copy link
Member

rhatdan commented Oct 19, 2023

@ThomasVitale is this something you can work on?

@ThomasVitale
Copy link
Author

@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
Copy link
Member

rhatdan commented Oct 28, 2023

Go for it.

@n1hility
Copy link
Member

n1hility commented Nov 1, 2023

@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
Copy link

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
Copy link
Author

@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)

@Luap99 Luap99 added the machine label Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. machine windows issue/bug on Windows
Projects
None yet
Development

No branches or pull requests

8 participants