WSL2 usermode networking is broken since v5.8.0 due to a gvproxy regression

[som1ein]

Issue Description

WSL2 usermode networking no longer works on VPN-enabled networks. The traffic no longer flows through.

The gvproxy shipped since Podman v5.8.0 (PR #28066) has the following bug that breaks argument parsing:

containers/gvisor-tap-vsock#632

The bug been fixed on March 24, 2026 (36 days ago).

I have manually recompiled the gvproxy.exe on Windows from the latest HEAD and verified that this fixes the issue.

Please release a new Podman version for Windows that includes a new gvproxy build that includes this fix.

Thank you.

podman version
Client:       Podman Engine
Version:      5.8.2
API Version:  5.8.2
Go Version:   go1.26.2
Git Commit:   5b263b5f5b48004a87caac44e67349a8266d9ef4
Built:        Tue Apr 14 19:51:05 2026
OS/Arch:      windows/amd64

Server:       Podman Engine
Version:      5.8.2
API Version:  5.8.2
Go Version:   go1.25.9 X:nodwarf5
Git Commit:   5b263b5f5b48004a87caac44e67349a8266d9ef4
Built:        Mon Apr 13 02:00:00 2026
OS/Arch:      linux/amd64

Steps to reproduce the issue

Steps to reproduce the issue

1. Install Podman v5.8.2 on Windows 11 with WSL2 enabled
2. Enable usermode networking for the podman-machine-default
3. Connect to a VPN
4. Try to establish connection from inside WSL2 container to the Internet

Describe the results you received

Host network is not available from inside the container.

Describe the results you expected

Host network is available from inside the container.

podman info output

podman info
Client:
  APIVersion: 5.8.2
  Built: 1776189065
  BuiltTime: Tue Apr 14 19:51:05 2026
  GitCommit: 5b263b5f5b48004a87caac44e67349a8266d9ef4
  GoVersion: go1.26.2
  Os: windows
  OsArch: windows/amd64
  Version: 5.8.2
host:
  arch: amd64
  buildahVersion: 1.43.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: conmon-2.2.1-2.fc43.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.2.1, commit: '
  cpuUtilization:
    idlePercent: 98.59
    systemPercent: 0.68
    userPercent: 0.73
  cpus: 16
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: container
    version: "43"
  eventLogger: journald
  freeLocks: 2048
  hostname: <REDACTED>
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.6.114.1-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 14943346688
  memTotal: 16510951424
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    defaultNetwork: podman
    dns:
      package: aardvark-dns-1.17.1-1.fc43.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.17.1
    package: netavark-1.17.2-1.fc43.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.17.2
  ociRuntime:
    name: crun
    package: crun-1.27-1.fc43.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.27
      commit: a718a92cc9a94955a5a550b6fdec1378c247ec50
      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^20260120.g386b5f5-1.fc43.x86_64
    version: |
      pasta 0^20260120.g386b5f5-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: 0h 3m 43.00s
  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: 0
    paused: 0
    running: 0
    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: 1391411200
  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: 0
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.8.2
  BuildOrigin: 'Copr: packit/containers-podman-28501'
  Built: 1776038400
  BuiltTime: Mon Apr 13 02:00:00 2026
  GitCommit: 5b263b5f5b48004a87caac44e67349a8266d9ef4
  GoVersion: go1.25.9 X:nodwarf5
  Os: linux
  OsArch: linux/amd64
  Version: 5.8.2

Podman in a container

Yes

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

No response

[Honny1]

PTAL @l0rd

[som1ein]

Adding additional details from my investigation:

Environment

Component	Version
Windows	11 Enterprise, build 10.0.26100.8246
WSL	2.7.0.0
WSL kernel	6.6.114.1-microsoft-standard-WSL2
WSLg	1.0.71
WSL networking mode	NAT (networkingMode=nat in .wslconfig)
Podman Client	5.8.2
Podman Server	5.8.2 (Fedora 43, rootful)
Podman machine	podman-machine-default, UserModeNetworking=true
gvproxy (stock, shipped)	v0.8.8
gvforwarder (stock, shipped)	v0.8.8
gvisor-tap-vsock repo	HEAD 4b4ee6f6 (includes fix)
gvproxy (rebuilt from HEAD)	v0.8.9-0.20260429081332-4b4ee6f62b87
Go compiler (for rebuild)	go1.26.2 windows/amd64
VPN	Cisco AnyConnect (active during all tests)

Root Cause

GvproxyConfigure() in cmd/gvproxy/config.go copies all CLI interface flags (qemuSocket, bessSocket, vpnkitSocket) into config.Interfaces except stdioSocket. This means -listen-stdio=accept is parsed but silently ignored.

gvproxy starts and logs "waiting for clients..." but never opens a stdio listener, so the pipe between gvforwarder and gvproxy is dead on arrival.

Symptoms with stock gvproxy v0.8.8

On every clean podman machine start:

1. gvforwarder launches gvproxy.exe with -listen-stdio=accept -ssh-port=-1
2. gvproxy logs "waiting for clients..." but never accepts the stdio connection
3. gvforwarder sends DHCPDISCOVER frames through the pipe — gvproxy never responds
4. First gvproxy child becomes zombie; gvforwarder retries with a second child
5. Second child also never processes data
6. TAP counters show TX > 0 (outbound frames sent), RX = 0 (nothing received)
7. udhcpc broadcasts DHCPDISCOVER indefinitely, never gets an offer

Process state in podman-net-usermode

PID 14: gvforwarder (parent)
PID 22: [gvproxy.exe] <defunct>    ← first child, zombie
PID 28: /init ... gvproxy.exe      ← second child via /init WSL interop
PID 30: udhcpc                     ← DHCP client, endlessly discovering

On Windows, both gvproxy.exe processes remain alive (HandleCount=166, Responding=True) but neither processes pipe data.

gvforwarder stderr log (stock gvproxy v0.8.8)

time="..." level=info msg="Dialing to stdio:/.../gvproxy.exe?listen-stdio=accept&ssh-port=-1…"
time="..." level=info msg="Configuring tap device podman-usermode"
time="..." level=info msg="Starting rx/tx loops"
time="..." level=info msg="waiting for packets..."
udhcpc: started, v1.37.0
udhcpc: broadcasting discover
time="..." level=warning msg="bad log level \"\", falling back to \"info\""
time="..." level=info msg="gvproxy version v0.8.8"
time="..." level=info msg="waiting for clients..."
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
...

Note: zero data comes back from gvproxy. Only outbound writes from gvforwarder.

Verification: debug build with instrumented stdio I/O

To confirm the pipe itself is functional, we built gvproxy and gvforwarder from gvisor-tap-vsock HEAD with debug logging added to pkg/net/stdio/ioconn.go (Read/Write methods log byte counts and first 8 hex bytes to stderr).

Test 1: debug gvforwarder + STOCK gvproxy v0.8.8

[STDIO-DBG FORWARDER] Write: len=344 n=344 err=<nil> 5601ffffffffffff...   ← DHCPDISCOVER sent
[STDIO-DBG FORWARDER] Write: len=344 n=344 err=<nil> 5601ffffffffffff...   ← retry
[STDIO-DBG FORWARDER] Write: len=344 n=344 err=<nil> 5601ffffffffffff...   ← retry
... (zero Read lines — gvproxy never responds)

Result: DHCP never completes. Pipe is one-way - gvforwarder writes, gvproxy ignores.

Test 2: debug gvforwarder + gvproxy built from HEAD

[STDIO-DBG FORWARDER] Write: len=344 n=344 err=<nil> 5601ffffffffffff...   ← DHCPDISCOVER
[STDIO-DBG GVPROXY]   Read:  n=524 err=<nil> 5a00333300000016...           ← gvproxy received
[STDIO-DBG GVPROXY]   Write: len=344 n=344 err=<nil> 5601ffffffffffff...   ← DHCPOFFER
[STDIO-DBG FORWARDER] Read:  n=342 err=<nil> ffffffffffff5a94...           ← gvforwarder received
udhcpc: lease of 192.168.127.2 obtained from 192.168.127.1, lease time 3600

Result: DHCP completes. Bidirectional data flow confirmed.

Test 3: clean gvproxy.exe from HEAD replacing stock v0.8.8

Built gvproxy.exe from HEAD (no debug modifications, clean build) and replaced
the stock binary at C:\...\Programs\Podman\gvproxy.exe.

$ podman machine start podman-machine-default
Starting machine "podman-machine-default"
Starting user-mode networking...
Machine "podman-machine-default" started successfully

gvforwarder log:

time="..." level=info msg="gvproxy version v0.8.9-0.20260429081332-4b4ee6f62b87"
time="..." level=info msg="waiting for clients..."
udhcpc: broadcasting select for 192.168.127.2, server 192.168.127.1
udhcpc: lease of 192.168.127.2 obtained from 192.168.127.1, lease time 3600

End-to-end proxy test (from inside WSL, VPN active):

$ curl -v --max-time 10 -x http://192.168.127.254:3128 http://example.com
*   Trying 192.168.127.254:3128...
* Connected to 192.168.127.254 (192.168.127.254) port 3128
> GET http://example.com/ HTTP/1.1
< HTTP/1.1 200 OK
...
<!doctype html><html lang="en"><head><title>Example Domain</title>...

Result: Full connectivity restored. Traffic flows through gvproxy's NAT (192.168.127.254 → 127.0.0.1) bypassing VPN filtering as designed.

Relevant commits between v0.8.8 and HEAD

Commit	Message
9c1ff57d	fix(gvproxy): propagate --listen-stdio flag into config ← THE FIX
b3cfb4c4	tap: move connLock into disconnect
da3daad9	tap: release connLock before writing to connections
9c0b2d90	tap: move writeLock from txPkt to txBuf
22964b63	tap: move disconnect from txBuf to txPkt
c6a56ecb	Fix support for 'log-file' arg

Conclusion

The gvproxy binary shipped with Podman 5.8.x (v0.8.8) has a bug where -listen-stdio=accept is silently ignored due to a missing config propagation.

This breaks usermode networking entirely on WSL2. The fix has been merged in gvisor-tap-vsock (containers/gvisor-tap-vsock#632, commit 9c1ff57d) but has not been included in any Podman release.

Manually replacing gvproxy.exe with a build from gvisor-tap-vsock HEAD restores full functionality, including DHCP, DNS, and proxy access through the NAT gateway.

[l0rd]

v0.8.8 is the last released version. We need a new version to include it in Podman. @cfergeau are you planning to cut a new release?

[cfergeau]

v0.8.8 is the last released version. We need a new version to include it in Podman. @cfergeau are you planning to cut a new release?

I did not think of wsl/podman when I merged this PR or I would have anticipated this more :-/
I’ll try to make a release tomorrow.

Does podman have automated wsl tests that we could improve to catch this kind of regressions in the future?
I think we’ll eventually get to containers/gvisor-tap-vsock#269 , at least before gvisor-tap-vsock releases.

[l0rd]

Does podman have automated wsl tests that we could improve to catch this kind of regressions in the future?

We don't run automated tests for usermode networking with WSL. The default is UsermodeNetworking: false and we test that. Testing usermode would be straightforward as well, but our WSL e2e tests already take 45+ minutes and are flaky, so there is a tendency to avoid new permutations. That said, the full test suite can be tested locally with usermode networking on a Windows machine if needed.

[cfergeau]

The default is UsermodeNetworking: false and we test that

Ah I missed that part, that it’s a non-default WSL configuration which is broken. This explains why this was not caught earlier. I’ll see what we can do on gvisor-tap-vsock end to test podman+wsl+usermode-networking before making releases.

[Luap99]

We do in fact have a test case for user mode networking
https://github.com/containers/podman/blob/main/pkg/machine/e2e/init_windows_test.go#L25
It is just that it never start the VM or verifies any actual networking so it is rather useless I guess.

And the set test is skipped as well but does not do anything useful either other than checking the inspect setting

podman/pkg/machine/e2e/set_test.go

Lines 178 to 183 in 246016a

	It("set user mode networking", func() {
	if testProvider.VMType() != define.WSLVirt {
	Skip("Test is only for WSL")
	}
	// TODO - this currently fails
	Skip("test fails bc usermode network needs plumbing for WSL")

And then there is the story that WSL is just unusable in our CI to the point where we no longer look at any failures at all there because as @l0rd mentioned it is just to flaky microsoft/WSL#13301

[davgia]

Hi, I think that this issue is linked to #28419.

My configuration is:
rootless
user-networking