UserModeNetworking enabled machine fails to pull any image

[ScrewTSW]

Bug description

On Friday (09.08.2024) any image whatsoever was unable to be pulled exclusively in UserModeNetworking (WSL) enabled machine. I've tested the pull on other machines (rootful default, rootless) and image pulling worked. I've tried to create the UMN machine several times with the same results.

Today (12.08.2024) I've re-created the UserModeNetworking machine again, tested image pull and container creation - worked without problems.

I am suspecting two possibilities:

• Infrastructure instability (less likely)
• Issue with base image

Operating system

Windows 10 22H2

Installation Method

Installer from website/GitHub releases

Version

1.12.0

Steps to reproduce

• Download, install, onboard Podman Desktop
• Create a UserModeNetworking rootful machine (WSL)
• Pull any image

Relevant log output

No response

Additional context

[nichjones1]

@gbraad can you check to see if this is a known gvisor-tap-vsock?

[jeffmaury]

I can reproduce on my machine and I did the following investigation:

• went on WSL distribution for the podman machine and noticed the nameserver is 192.168.127.1
• tried ping 192.168.127.1 from the same shell -> KO
• went to the podman-net-usermode WSL distribution
• ran ps -ef
• noticed a lot of gvproxy.exe defunc processes

Will stay in that configuration and not reboot my machine

[jeffmaury]

I can reproduce: this is a matter of conflict between CRC and podman in usernetworking mode

So if you start podman then crc crc will not start because the port is already taken But if you start crc then podman then no error is reported as gvproxy is running in the user mode networking wsl distribution but the whole DNS setup is broken in the podman machine. Nothing to do on our side as it's between podman and crc