usbipd: warning: A third-party firewall may be blocking the connection; ensure TCP port 3240 is allowed.

[pilcherd]

I have installed a clean WSL v2 ubuntu today. Windows 11 release branch all updates.

uname -r 5.10.102.1-microsoft-standard-WSL2

I installed usbipd-win 2.2.0 via MSI. Windows service is running.

I have a terminal window open so WSL is alive.

I installed ubuntu USB/IP client tools per https://github.com/dorssel/usbipd-win/wiki/WSL-support#usbip-client-tools

When I run "usbipd wsl attach --busid=5-1" I get the error:

usbipd: warning: A third-party firewall may be blocking the connection; ensure TCP port 3240 is allowed. usbip: error: tcp connect usbipd: error: Failed to attach device with BUSID '5-1'.

Since other posts here about this imply the firewall is blocking, I turned off my Windows firewall completely and re-ran. Same error.

Do you have any other troubleshooting steps?

Thanks

[dorssel]

third-party firewall

That means: not Microsoft & not usbipd-win.

Please turn back on Window firewall, as usbipd-win has installed a nice rule (as stated in the README). You need to find out what other software is blocking the port and fix that.

[pilcherd]

third-party firewall

That means: not Microsoft & not usbipd-win.

Please turn back on Window firewall, as usbipd-win has installed a nice rule (as stated in the README). You need to find out what other software is blocking the port and fix that.

I checked the firewall rule before testing with the firewall off for one test. And added another inbound allow rule when it didn't work, without the local subnet restriction as the WSL2 ip appears in a different subnet.

No third party firewall/security software on this machine. We are running Microsoft Endpoint Protection which monitors things but has few settings enabled relating to the firewall other than for public networks.

[dorssel]

without the local subnet restriction as the WSL2 ip appears in a different subnet

Your host and the WSL instance are in the same subnet.

settings enabled relating to the firewall other than for public networks

That may be the problem. Unfortunately, Windows regards the WSL network connection as public.

If this is the problem, then I should have said "not Windows, not usbipd-win", as Microsoft Endpoint Protection obviously is Microsoft.

[Knio]

I also kept getting this error. I do not and never have had a 3rd party firewall.

After much debugging, I figured out that the auto-installed windows firewall rule was for the temporary install path of usbip, ie C:\Users\Me\appdata\blah\temp\blah\usbipd.exe and not the correct path of the service that was running, ie C:\Program Files\usbipd-win\usbipd.exe

Once I manually deleted and re-added with the correct path, I can now connect (well, I've gotten past the tcp error anyway.. *)

Seems like there's a bug in the installer when locating the exe path.

* OK I still get this the firewall error when doing usbipd wsl attach .. from the windows host, however, from within the WSL2 guest I can at least connect to the socket using usbip attach -r 10.0.0.10 -b 11-4

[dorssel]

@Knio Interesting. How did you install usbipd-win? (winget or msi). What version did you install? Did you update from version x to y? You say:

temporary install path of usbip, ie C:\Users\Me\appdata\blah\temp\blah\usbipd.exe

The installer does not use a "temporary install path", it is fixed to %ProgramFiles% (unless you have specifically overridden that using the command line installer msiexec.exe). Did you ever compile/run from code, or always used the released installer?

And about the *. Does usbipd wsl attach actually not work, or does it work and you just got this additional warning?

[Knio]

1) This was a fresh install using usbipd-win_2.2.0.msi on Microsoft Windows [Version 10.0.19043.1526]. No upgrade and I didn't compile anything. Unfortunately I didn't write write down the actual path but there was a definitely in appdata

2) Tried again. it eventually times out, and the guest does not see any devices:

C:\Windows\system32>usbipd wsl attach --busid 11-4 -d Ubuntu-20.04
usbipd: warning: A third-party firewall may be blocking the connection; ensure TCP port 3240 is allowed.
usbip: error: tcp connect
usbipd: error: Failed to attach device with BUSID '11-4'.

However it does put the device into the 'Shared' state after that, and then I can connect with -r

[dorssel]

@Knio Thank for the report. Earlier you said:

I can at least connect to the socket using usbip attach -r 10.0.0.10 -b 11-4

but for wsl attach you get

usbip: error: tcp connect

What are the (exact) IP configurations of both the host and the WSL instance? It puzzles me why wsl attach does not work, but manual attach does. It looks as if WSL and the host can reach each other via 2 different IP addresses...

[Knio]

My windows host is 10.0.0.10 assigned from a normal home NAT DHCP; I have no idea how WSL2 networking works, but it's a fresh Ubuntu-20.04 WSL2 guest.

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether de:97:f4:fc:78:b9 brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 8a:09:24:84:c9:f3 brd ff:ff:ff:ff:ff:ff
4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:d2:c7:92 brd ff:ff:ff:ff:ff:ff
    inet 172.23.43.103/20 brd 172.23.47.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fed2:c792/64 scope link
       valid_lft forever preferred_lft forever

(From windows) I can see that the service is listening:

C:\Windows\system32>netstat -an | grep 3240
  TCP    0.0.0.0:3240           0.0.0.0:0              LISTENING
  TCP    [::]:3240              [::]:0                 LISTENING

(From windows) and even connect to it:

C:\Windows\system32>python
Python 3.9.5 (tags/v3.9.5:0a7dcbd, May  3 2021, 17:27:52) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket()
>>> s.connect(('10.0.0.10', 3240))
>>> s.send(b'asdf\n')
5
>>> s.send(b'asdf\n')
5
>>> s.send(b'asdf\n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

So it kinda seems like the client binary is blocked, or this is some other problem with how it communicates with wsl?

[dorssel]

@Knio Your WSL has address 172.23.43.103/20, which is normal. Your host must also have an IP in this subnet. That is what usbipd is using. When you manually attach using 10.0.0.10, then it is normal that the default firewall rule will block it, since it is not in the same subnet.

So that explains the difference: usbipd is trying to attach to 172.... and manually you use 10....

Question is: why is 172.... not working. What is the hosts network configuration?

[Knio]

I think you got it. the 172. interface is just blocked. TLDR seems to be https://github.com/microsoft/WSL/issues/4139

C:\Windows\system32>ipconfig

Windows IP Configuration

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::104:8fd5:a7ea:599e%12
   IPv4 Address. . . . . . . . . . . : 10.0.0.10
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.0.1

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::1958:c36e:a370:826d%31
   IPv4 Address. . . . . . . . . . . : 172.23.32.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

And with -r 172.23.32.1 it fails, and I get this:

C:\Windows\system32>tail LogFiles\Firewall\pfirewall.log -F
#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2022-04-13 16:46:31 DROP TCP 172.23.43.103 172.23.32.1 49002 3240 60 S 220737188 0 64240 - - - RECEIVE
2022-04-13 16:46:32 DROP TCP 172.23.43.103 172.23.32.1 49002 3240 60 S 220737188 0 64240 - - - RECEIVE
2022-04-13 16:46:34 DROP TCP 172.23.43.103 172.23.32.1 49002 3240 60 S 220737188 0 64240 - - - RECEIVE
2022-04-13 16:46:38 DROP TCP 172.23.43.103 172.23.32.1 49002 3240 60 S 220737188 0 64240 - - - RECEIVE

[dorssel]

@Knio That makes sense. But why is the default WSL host address not accepting? Probably because you had this odd firewall rule. Can you try a 'repair' install of usbipd-win? Or else a re-install? Does it reproduce?

The firewall rule is created by the MSI installer, which is a standard WiX extension: https://github.com/dorssel/usbipd-win/blob/87876c919dc294610c3ffb7aeb21b8424fd92971/Installer/Server.wxs#L18-L26

This is something I haven't seen failing before...

[Knio]

So, 1) running the msi again and doing a "repair" operation didn't fix anything, but.. 2) doing a full uninstall and reinstall and it works now. ¯\_(ツ)_/¯ Thanks for all your help here...

[dorssel]

@Knio Thanks for testing. It appears to be a known WiX issue: https://github.com/wixtoolset/issues/issues/5675 Still don't know why the rule was screwed up initially, but it makes sense now that a repair (or update) won't fix the issue. Since a reinstall did fix it, I will consider it a fluke. Not much can be done about it, maybe the soon to be released WiX 4 may fix it. I consider your (sub-)issue closed now.

@pilcherd If you haven't solved this issue by now, could you try a reinstall? Or can we close this issue?

[Knio]

Thanks again. Hopefully this thread is at least helpful for other people debugging.

[EDLLT]

Any human being who faces this issue again the FIX is so simple, this thing got me pulling my hair OUT tryna fix it

First try to turn your firewall off, disconnect from the internet temporarily while doing so and check if it works, if it does then you gotta add a rule(you can search that up in google)

If that still doesn't work then turn your VPN off, my god damn VPN was causing all of these issues and I was pulling my hair out

If the above doesn't work then open task manager(ESC + SHIFT + CTRL) , click the performance tab, open resource monitor and click the Network tab Then in the "TCP Connections" tab look for any program that has the same port, in this case 3240 that's running, once you find it goto Task Manager find the same process name and terminate it(assuming that you couldn't close it safely)

Hopefully no one would face this issue again

[andrewpriddis]

None of the above solutions have worked for me. Any updates?

[dorssel]

@siddirp What OS are you using, 10 or 11? Are you using any additional security software besides Windows firewall and Windows Defender? Have you checked that the firewall rule (as mentioned in the Readme) was correctly installed? Can you ping between your Windows host and the WSL instance, on their shared subnet?

All of these problems have been traced back to either of these causes.

[andrewpriddis]

Windows 11 Pro version 22H2. OS Build 22610.1. Do I need the Insiders build or anything like that? I do not have any security software except what came with the OS. I'm not savvy at Firewall work, but I didn't see usbipd in the inboud or outbound rules. Is that where I am supposed to look? Is there another name I should look for? I can ping both ways.

[dorssel]

I suggest a repair install or uninstall/reinstall of usbipd-win. Someone else reported that the firewall rule wasn't installed properly and that a reinstall fixed it. Everything else looks fine.

[andrewpriddis]

I have tried that several times, several versions....

[dorssel]

Please check again if the firewall rule exists. It should be under incoming rules. What happens if you try to manually run usbip attach on WSL? Does the connection time out?

[andrewpriddis]

Ok, I feel really dumb. I had just reset Windows to a fresh state. I had been using usbipd-win for quite a while and was so confused why it wasn't working after this reset. It turns out some 3rd party anti-virus stuff WAS installed and I had no idea. Sorry for all the bother!

[myusrn]

I have a repaved as of yesterday win11 22h2 install that my company's device mgmt story adds carbon black and defender for endpoint antivirus/antimalware services to. The firewall rule is present with correct path to the usbipd program executable that sets up tcp/3240 listener on windows side of things.

from windows 11 22h2 powershell 7.2.6 admin prompt i see

PS C:\Users\myusername> netstat -an | findstr 3240
  TCP    0.0.0.0:3240           0.0.0.0:0              LISTENING
  TCP    [::]:3240              [::]:0                 LISTENING
PS C:\Users\myusername>

from wsl ubuntu 20.04 bash prompt i see

myusername@mywsldistro:~$ nmap 127.0.0.1 -p 3240
Starting Nmap 7.80 ( https://nmap.org ) at 2022-08-20 10:17 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00025s latency).

PORT     STATE  SERVICE
3240/tcp closed triomotion

Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
myusername@mywsldistro:~$

Question - Do we know at this point that it is carbon black, defender for endpoint, etc. antivirus/antimalware software that creates this unexpected usbipd: warning: A third-party firewall may be blocking the connection; ensure TCP port 3240 is allowed. result? If so i don't have permissions to temporarily stop those antivirus/antimalware software packages when i need to use usbipd, is their another workaround?

[dorssel]

@myusrn The standard way of jailbreaking a locked down system is to "tunnel out and reverse proxy". Start the sshd service on the client (if not already running). From the Windows host ssh into the client with:

ssh <username>@<client-IP> -R 3240:127.0.0.1:3240

Then, on the client you can just use "127.0.0.1" as "remote host". E.g. usbip list -r 127.0.0.1.

[myusrn]

@dorssel Thanks for the optional workaround to try. Is "client" in this case referring to the wsl distro that i want to project the physical host usb thumb drive into and "host" is the windows host that wsl distro is running on?

After running usbipd list -r 127.0.0.1, presumably on windows host that the wsl distro is running on, do i then use usbipd.exe wsl attach --busid #-## -r 127.0.0.1 to project the usb thumb drive into the wsl distro instead of usbipd.exe wsl attach --busid #-## --distribution Ubuntu ?

[dorssel]

Yes it is

[myusrn]

When i execute usbipd.exe list -r 127.0.0.1 on windows 11 host i get an unrecognized command or argument result. Do i need to install a version other that usbipd-win, 2.3.0 to get support for that switch?

(admin) PS C:\Users\myusername> usbipd list -r 127.0.0.1
Unrecognized command or argument '-r'.
Unrecognized command or argument '127.0.0.1'.

usbipd-win 2.3.0

Description:
  Lists all USB devices that are available for being attached to a WSL instance.

Usage:
  usbipd wsl list [options]

Options:
  -?, -h, --help  Show help and usage information

(admin) PS C:\Users\obrien>

[dorssel]

You're mixing server and client. You need to run usbip list -r 127.0.0.1 (without the 'd' in usbip) on the client side.

[myusrn]

Thanks for additional clarifications and details. Yes i was overlooking the difference between when i use windows host 'usbipd.exe' and when i use wsl distro client 'usbip' utility.

After establishing ssh connection from windows host to wsl distro, with tunnel reverse proxy setting enabled [ ssh <wsl username>@<wsl ipaddr> -R 3240:127.0.0.1:3240 ] to jailbreak locked down system, i then executed the usbip list --remote 127.0.0.1 command which showed expected results but the usbip attach --busid #-## --remote 127.0.0.1 command and get a Device not found and Device in error state respectively for two different usb thumb drives i attempted to mount into wsl distro.

Perhaps those error messages relate to a well understood additional configuration step i overlooked or need to apply?

Note that my windows host has a usb thumb drive read-only policy. This hasn't affected other scenarios where i project usb thumb drives into a virtualized environment for read-write access, e.g. virtual machine console < usb device > | connect / disconnect from host.

myusername@mywsldistro:~$ usbip list --remote 127.0.0.1
Exportable USB devices
======================
 - 127.0.0.1
       1-15: SanDisk Corp. : Ultra Fit (0781:5583)
           : USB\VID_0781&PID_5583\4C530001040715103121
           : (Defined at Interface level) (00/00/00)
           :  0 - Mass Storage / SCSI / Bulk-Only (08/06/50)

       1-16: SanDisk Corp. : unknown product (0781:55a9)
           : USB\VID_0781&PID_55A9\01011079E7BD1B40E24364F52F6612E986FAA6BA498E25375B019EAB019AAED5171400000000000000000000C0BD85A1FF955000A9558107CBA68826
           : (Defined at Interface level) (00/00/00)
           :  0 - Mass Storage / SCSI / Bulk-Only (08/06/50)

myusername@mywsldistro:~$ usbip attach --busid 1-15 --remote 127.0.0.1
usbip: error: Attach Request for 1-15 failed - Device not found

myusername@mywsldistro:~$ usbip attach --busid 1-16 --remote 127.0.0.1
usbip: error: Attach Request for 1-16 failed - Device in error state

[dorssel]

@myusrn Ah ... SanDisk. See https://github.com/dorssel/usbipd-win/wiki/Tested-Devices. Here's the report, and some hints to maybe get them to work: https://github.com/dorssel/usbipd-win/issues/425. But in essence: SanDisk flash drives behave weird and usually don't work with USBIP.

[myusrn]

@dorssel Thanks for the pointers to likely reasons behind this error result. In addition to my SanDisk Ultra Fit 32gb Usb3.0 and SanDisk Ultra Dual Drive 128gb Usb3.1g1 devices that generated those results i had an older SanDisk Cruzer Facet 16gb Usb2.0 available to try and it produced similar result.

I don't currently have a laptop or dock Usb2.0 port to test if having the port vs the device restrict the Usb protocol version to 2.0 would make a difference with any of these devices. Sounds like one should pickup one of the tested Usb 3.x drive devices and vet setup with that first.

[BayerGL]

For those who use VPN, the simple solution for me was allowing local network traffic. For example, in Mullvad I had to go to "Settings -> VPN settings" and turn on "Local network sharing" toggle.

[martigr]

I face the same problem. I found a solution that works for me. I use the following workaround:

1. Stop the usbipd service.
2. Disable WSL2 and Hyper-V Ethernet adapters.
3. Re-enable the Ethernet adapters.
4. Start the usbipd service.

After that, the USB devices can be attached to the WSL2 again.

I created the following script to automate the process:

disable-wsl2-usbipd.ps1:

# Stop the usbipd service
Stop-Service -Name usbipd

# Disable the WSL network adapters
netsh interface set interface "vEthernet (WSL)" disable
netsh interface set interface "vEthernet (Default Switch)" disable

enable-wsl2-usbipd.ps1:

# Enable the WSL network adapters
netsh interface set interface "vEthernet (WSL)" enable
netsh interface set interface "vEthernet (Default Switch)" enable

# Wait for 2 seconds
Start-Sleep -Seconds 2

# Start the usbipd service
Start-Service -Name usbipd

[dorssel]

@martigr That's an interesting find. I think you should report it to https://github.com/microsoft/WSL/issues. usbipd itself simply opens a listening socket on "any interface". Your report indicates that for some reason the new WSL interface switch (which is created only after starting WSL) doesn't pick up the existing sockets and firewall rules. I think that is a WSL issue.