portproxy | TCP proxy , highjacks HTTP to allow CORS | Proxy library

I cannot reproduce the problem, but here are the steps I took.

1. Copy your compose file into Windows filesystem.
2. Open Windows Powershell, not WSL2 terminal (I think this is your problem, by the fact that you're using sudo)
3. Run docker compose up (which uses the newer Compose V2)
4. Run netstat -ab in the Powershell session to see 0.0.0.0:27017 is indeed listening on the windows host
5. Successfully connect with Robo 3T with the username/password on localhost:27017

Using Docker for Windows with WSL2 Integration enabled

There should be read first the following Microsoft documentation pages:

• WOW64 Implementation Details
• File System Redirector
• Registry Keys Affected by WOW64

There are two system directories on 64-bit Windows with a processor with AMD64 architecture:

1. %SystemRoot%\System32 with 64-bit applications used by 64-bit applications by default.
2. %SystemRoot%\SysWOW64 with 32-bit applications used by 32-bit applications by default.

The system environment variable PATH contains by Windows default %SystemRoot%\System32 as first folder path. If a 32-bit application starts cmd.exe to process a batch file, there is started 32-bit %SystemRoot%\SysWOW64\cmd.exe because of the file system redirector.

cmd.exe is searching for files specified in a batch file just with file name without or with file extension and without path by using the local environment variables PATHEXT and PATH as explained in full details by What is the reason for "X is not recognized as an internal or external command, operable program or batch file"?

wsl.exe belongs to the set of executables which on AMD64 Windows exists only as 64-bit version in %SystemRoot%\System32. There is no 32-bit version in %SystemRoot%\SysWOW64 searched by 32-bit cmd.exe on using %SystemRoot%\System32 in expanded form in local PATH because of file system redirector. For that reason the batch file as posted in the question does not work on being processed by 32-bit cmd.exe on Windows x64.

The solution is taking WOW64 into account with additional code in the batch file:

I have not tried this scenario but you might be able to accomplish this with SSH local port forwarding. The key is if your proxy is blocky localhost connections to port 445.

If you take the output of your WSL command and a verbatim string of what you believe is the same value and compare the actual bytes with Format-Hex, you will see there is a difference.

I'm not familiar with Quarkus, but my "go to answer" for localhost forwarding not working in WSL is to try a wsl --shutdown and, if that works, disable Windows Fast Startup.

But in this case, you also aren't able to access it on the WSL2 instance's eth0 address, so something more might be going on. That could also be explained if the Quarkus boilerplate config is just binding to localhost or 127.0.0.1. You'd need it to bind to 0.0.0.0 in order for both to work.

Update for others looking at this answer in the future: Quarkus automatically binding to 127.0.0.1 or localhost did turn out to be the problem in this case. From @markvgti's research in the comments, the setting for this is to add quarkus.http.host=0.0.0.0 to the application.properties.

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.

I figured it out: portproxy with listen address localhost doesn't work, but 127.0.0.1 does.

The root problem is described in WSL issue #4150. To quote from that thread,

WSL 2 seems to NAT it's virtual network, instead of making it bridged to the host NIC.

There are a number of workarounds described in that issue, for which you've already figured out the first part (the port forwarding). The primary technique seems to be to create a PowerShell script to detect the IP address and create the port forwarding rules that runs upon Windows login. This particular comment near the top of the thread seems to be the canonical go-to answer, although many people have posted their tweaks or alternatives throughout the very long thread.

One downside - I believe the script that is mentioned there needs to be run at logon since the WSL subsystem seems to only want to run when a user is logged in. I've found that attempting to run a WSL service or instance through Windows OpenSSH results in that instance/service shutting down soon after the SSH session is closed, unless the user is already logged into Windows with a WSL instance opened.

I would also propose that, assuming it fits your workflow and if the ROS works on it (it may not, given the device access you need, but not sure), you can simply use WSL1 instead of WSL2 to avoid this. You can try this out by:

1. Backing up your existing distro (from PowerShell or cmd, use wsl --export
2. Import the backup into a new WSL1 instance with wsl --import --version 1

It's possible to simply change versions in place, but I tend to like to have a backup anyway before doing it, and as long as you are backing up, you may as well leave the original in place.

As suggested in the comment information, the IP Address in the ip.txt is probably preceded and/or succeeded by one or more new line (Cr/Lf) characters.

If you use the -Raw parameter, Get-content will return all the lines including newline characters as a single string ([String]). At the other hand, if you do not include the -Raw, Get-content will return all the lines as separate strings ([String[]]), which might cause an issue in your case as well.

To remove all possible white-space characters arround the IP Address, you might use the Trim() method which removes all leading and trailing white-space characters from the current string by default: