usbipd.exe does not utilize default network route when running alongside 'wsl-vpnkit'

[ValentinTwin1206]

Hi @dorssel,

I am running usbipd-win inside a company VPN. To gain full network access, I have to additionally use the wsl-vpnkit.

Alongside wsl-vpnkit, I observed that usbipd.exe consistently uses the standard eth0 network interface, even though wsl-vpnkit sets up the wsltap tun/tap interface as the primary network route. Since WSL2 guests cannot reach the standard WSL gateway, the USB device cannot be forwarded..

Luckily, attaching an USB device directly with the Linux client usbip always works fine:

/var/run/usbipd-win$ sudo ./usbip attach -r "192.168.127.254" -b "1-14"

How to reproduce

First, I bootstrap the wsl-vpnkit WSL2 distro in a separate terminal:

PS C:\> wsl -d wsl-vpnkit --cd app wsl-vpnkit
+ VPNKIT_GATEWAY_IP=192.168.127.1
+ VPNKIT_HOST_IP=192.168.127.254
+ VPNKIT_LOCAL_IP=192.168.127.2
+ TAP_MAC_ADDR=5a:94:ef:e4:0c:ee
+ VMEXEC_PATH=/app/wsl-vm
+ GVPROXY_PATH=/app/wsl-gvproxy.exe
+ TAP_NAME=wsltap
+ CHECK_HOST=example.com
+ CHECK_DNS=1.1.1.1
+ DEBUG=0
+ set +x
+ WSL2_TAP_NAME=eth0
+ WSL2_GATEWAY_IP=10.255.255.254
+ '[' 0 -eq 0 ]
+ set +x
starting vm and gvproxy...
INFO[0000] waiting for packets...

Inside my Ubuntu-22.04 WSL2 distro, you can observe that the wsltap interface is set as the default route:

$ ip route show default
default via 192.168.127.1 dev wsltap

However, when running usbipd.exe attach the logs state that the eth0 interface is used to connect with the Windows host. This action fails since this route is not reachable with our VPN client:

PS C:\>usbipd attach -b "1-14" --wsl
usbipd: info: Using WSL distribution 'MyUbuntu-22.04' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Using IP address 172.25.32.1 to reach the host.

I am not a C# expert, but have seen that WSL.cs parses /proc/net/fib_trie to get the unicast IPv4 address. I think you parse the first entry and not the default one?

Thanks in advance!
Best Valentin

[dorssel]

WSL networking code and firewall detection was updated in 4.4.0. Closing this issue. Please open a new issue (which will have different information reported) if you encounter similar symptoms.