Closed Octoberfest7 closed 6 months ago
My apologies; somehow in all of the testing I did, I failed to test creating the tunnel using a different Windows device. For reasons unknown, the particular Win11 VM I was using (latest developer image from MSFT) encountered those issues, while 3 other win10/win11 devices did not. No idea why, but I no longer think this is an issue in OpenSSH.
last time i came across similar problem, it was that my local program running on windows only listening on 0.0.0.0 not on any v6 address, and ssh remote port forward will proxy remote machine requests from ::1, so it reports port closed since I am not listening on it. maybe you can check if there should be similar problems.
Prerequisites
Steps to reproduce
Traffic sent via SSH tunnels opened between Linux and Windows machines seems to be malformed. I have tried two different syntaxes:
I have tested this with the latest Windows OpenSSH version available via winget,
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
, and 'OpenSSH_9.6p1 Debian-3, OpenSSL 3.1.4 24` on the Linux side.My specific use scenario was creating a dynamic port forward between a Windows and Linux machine, and then running tooling like Nmap, ssh, and smbclient through the port opened on the Linux machine using Proxychains.
I first became aware of this issue when Nmap returned all scanned ports as open. Other tools like ssh and smbclient worked as expected, so I initially thought this was an issue with Nmap. However upon further examination, the same behavior is occuring with ALL of the mentioned tools, but only manifesting in a tool-breaking error in Nmap.
The issue can be seen in the debug output from the
ssh -vvv -R 9050 user@Linux
command when a tool is ran via proxy chains (this particular screenshot was Nmap scanning port 445):Contrast with the output when a Linux <-> Linux tunnel is created using the same commands and the same Nmap scan is ran:
The first specific error is:
I further confirmed this was NOT an issue with Proxychains by removing proxychains from the equation and doing a direct port forward, e.g. from Windows
ssh -vvv -R 9050:forwardip:22
and then on Linux using it viassh user@127.0.0.1 -p 9050
. The same error was observed.I then replaced the SSH tunnel with Chisel, which was successfully able to run Nmap using proxychains and output an accurate result.
This post discusses a similar (but different) issue where the same error seen above is encountered, but this time because the tunnel tries to route traffic via IPV6. In the answer, the author discusses that the next line (connect_next...) is actually the pertinent one, as it appears that the TCP_NODELAY argument is flagged as an invalid argument as a result of the attempted connection failing. I did a few Wireshark captures and was able to notice a difference.
In the Windows <-> Linux capture, the initial SYN sent by the Windows device from the tunnel to port 445 on the target machine receives a RST-ACK:
The full wireshark info for the first SYN packet is:
In a Linux <-> Linux capture using Tcpdump, it appears that four SYNs were sent by the proxy for port 445 that went unanswered (which Nmap correctly interprets as the port being closed):
From my cursory, uneducated glance, it appears different TCP options are being used in the initial SYNs sent in each scenario.
Let me know if I can provide more info that would be helpful.
Expected behavior
Actual behavior
Error details
No response
Environment data
Version
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
Visuals
No response