I have an app that executes in windows and sends/receives packets to/from port 8899.
Im trying to sniff those packets from my WSL, so i installed scapy and tried to execute this command : sniff(filter="port 8899", count=1) on my WSL 2.
The problem is that, Scapy (on WSL 2) isn't detecting any traffic on that port :/
And im pretty sure that the problem doesn't come from my windows app. Using Wireshark on Windows, i can see the packets on that port.
I tried to forward this port on windows using these commands :
netsh interface portproxy add v4tov4 listenport=8899 listenaddress=0.0.0.0 connectport=8899 connectaddress=172.22.25.227
New-NetFireWallRule -DisplayName 'WSL 2' -Direction Outbound -LocalPort "8899" -Action Allow -Protocol TCP
New-NetFireWallRule -DisplayName 'WSL 2' -Direction Inbound -LocalPort "8899" -Action Allow -Protocol TCP
But it still not working :/
Can anyone help me out please?
WSL2 is running on a virtual network interface (vNIC) using the Virtual Machine Platform (a subset of Hyper-V functionality). This vNIC is NAT'd behind a virtual router which is also supplied by the Virtual Machine Platform.
So sniffing traffic on the vNIC isn't going to see any traffic on the Windows host, unless it's specifically intended for the vNIC.
You have the right intentions in trying to port forward, but ultimately this isn't going to work either. Port forwarding would redirect all traffic intended for 8899 on the Windows host to a service running in WSL2. So I would expect that those port forwarding commands may be either failing (if the app was already running on that port) or preventing your Windows app from listening on that port.
I can't think of a good way to sniff Windows traffic from WSL at the moment (but it may come to me later).
While the WSL1 network actually does use the Windows NIC, the problem there is that this is done with an adaptation layer. WSL1 "translates" Linux kernel syscalls to Windows APIs. And it does a great a job of doing this, but it only goes skin-deep.
If you are using Windows Professional, you might be able to use Hyper-V to change the vNIC to bridged. Some people have had success with this. Many more have not. It's a risk vs. reward -- At best, it works. At worst, you need to reinstall Windows to recover WSL networking. It's never been worth the risk for me, personally, so I can't offer any guidance on how to do it.