Nmap scan returns all ports open when ran with proxychains through a Linux <-> Windows SSH tunnel

Question

I have been doing some experimenting with SSH dynamic port forwarding between Windows and Linux machines and have ran into a frustrating problem. The issue concerns the behavior of Nmap when running it via proxychains through a tunnel between the opposite OS's.

On the Linux side, I run a Debian distro and have tried with two versions of ssh/sshd, (OpenSSH_8.8p1 Debian-1, OpenSSL 1.1.1o) and (OpenSSH_9.6p1 Debian-3, OpenSSL 3.1.4).

For Windows, I have tried using ssh from both a Windows 10 (OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2) and a Windows 11 (OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3) machine.

I have created dynamic port forwards in the following ways:

1. From Windows, run ssh -vvv -R 9050 user@Linux to connect to an ssh server on the Linux machine and open port 9050 on the Linux machine that dynamically forwards traffic through the Windows machine.
2. From Linux, run ssh -vvv -D 9050 user@Windows to connect to an ssh server on the Windows machine and open port 9050 on the Linux machine that dynamically forwards traffic through the Windows machine.

In both cases I run into the same problem, wherein Nmap scans ran from the Linux machine through proxychains return all ports open on the scanned target. The Nmap syntax I am using is: nmap -Pn -n -sT -p445 --reason <ip>, so no host discovery, no name resolution, full TCP connect scan for port 445, etc. For the purpose of this experiment, port 445 is not open on the target machine, and the target machine is a third machine that is reachable by both machines.

Running Nmap against the target without proxychains performs as expected, correctly returning that port 445 is not open on the target:

nmap -Pn -n -sT -p 445 --reason 192.168.1.160
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-03-21 14:46 EDT
Nmap scan report for 192.168.1.160
Host is up, received user-set (0.000078s latency).

PORT    STATE  SERVICE      REASON
445/tcp closed microsoft-ds conn-refused

Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds

Running the same command through proxychains via the Windows <-> Linux tunnel however returns a false positive:

proxychains nmap -Pn -n -sT -p 445 --reason 192.168.1.160                                                                                          130 ⨯
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.16
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-03-21 14:46 EDT
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  192.168.1.160:445  ...  OK
Nmap scan report for 192.168.1.160
Host is up, received user-set (2.0s latency).

PORT    STATE SERVICE      REASON
445/tcp open  microsoft-ds syn-ack

Nmap done: 1 IP address (1 host up) scanned in 2.05 seconds

I have also repeated this same experiment with Linux <-> Linux SSH dynamic port forwards and did not observe the same results/things worked properly. I have not fully explored the behavior between Windows <-> Windows tunnels, as I would really prefer to use Linux for one end of this.

The SSH output has some info that stands out. This is the output from the successful Linux <-> Linux tunnel Nmap scan, with the highlighted area showing the connection attempt and refusal due to the port being closed:

Compare this with the SSH output from the Windows -> Linux (ssh -R 9050...) tunnel when running the same Nmap command, where several errors occur:

The first error is near the beginning of the highlighted sections:

debug3: socketio_getsockopt - ERROR:10022
debug1: getsockopt TCP_NODELAY: Invalid argument

The TCP_NODELAY flag is being identified as invalid, while the same flag appears to be used in the Linux <-> Linux tunnel without issue. From what I was able to find, error 10022 is a generic socket failure. I found this post as well as this one by researching the invalid argument error, but they don't really seem to apply to this situation.

Other tools, like ssh and smbclient for example, can be ran successfully through the Windows -> Linux tunnel as expected. This problem is to my knowledge isolated to Nmap, but I struggle to understand why / if there is anything I can do about it. UPDATE: The other working tools ALSO produce the same error in the SSH debug output, it just doesn't appear to impact their performance

I did find a Nmap GitHub issue from 2019 regarding all ports returning open which was closed as a 'wontfix' because This is most likely the behavior of your proxy, but it could be caused by Proxychains-ng itself. It is not a bug in Nmap, and Nmap has no control over this behavior. I'm also struggling to find another port scanner that is compatible with socks proxies and isn't a fancy wrapper for Nmap underneath.

As I have been learning, SSH is highly configurable both server and client side, so I'm hoping someone might be able to identify a configuration change that could resolve this behavior. Any help or ideas would be much appreciated.