SFTP connection issue RST sent intead of ACK

asked 2020-06-10 11:07:08 +0000

updated 2020-06-10 11:13:02 +0000

grahamb gravatar image

Dear All,

I am trying to set up an SFTP connection in one of my software, but it keeps throwing error unable to connect. If I try to set up a different SFTP site, it works without an error. If running wireshark I get the following:

2600 30.950722      10.50.2.11            52.220.123.79         TCP      66     64410 → 22 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

2647 31.213991      52.220.123.79         10.50.2.11            TCP      66     22 → 64410 [SYN, ACK] Seq=0 Ack=1 Win=26883 Len=0 MSS=1460 SACK_PERM=1 WS=128

2648 31.214009      10.50.2.11            52.220.123.79         TCP      54     64410 → 22 [RST] Seq=1 Win=0 Len=0

The other site gives me the following:

35938 211.569592     10.50.2.11            195.144.107.198       TCP      66     64431 → 22 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

35983 211.588596     195.144.107.198       10.50.2.11            TCP      66     22 → 64431 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

35984 211.588626     10.50.2.11            195.144.107.198       TCP      54     64431 → 22 [ACK] Seq=1 Ack=1 Win=65536 Len=0

I can see that the client is dropping the connection, but I am unable to find why. The only difference I can se is that WS and WIN has different values. The full packet log can be found here: https://pastebin.com/YWNqvC5H

From this I cannot find the problem. Can anyone see what could be the problem?

Thank you,

edit retag flag offensive close merge delete

Comments

A pcap file is better than text for analysis for me, and I suspect for most others as well, who use Wireshark as a tool for diagnostic troubleshooting.

Note the timing: in the passing case, the latency is very low from SYN to SYN-ACK. In the failing case, it is on the order of 250ms. Are there any application-layer timeouts? What assumptions, if any, have been regarding connection timing? Application logs could be helpful, too, if this is indeed an application issue.

Bob Jones gravatar imageBob Jones ( 2020-06-10 12:45:48 +0000 )edit

Dear Bob,

Thank you for the info. Here is the pcap file: https://www.dropbox.com/s/zz1ekohhpeh...

I don't think it is a timing issue. I have checked in the application, and SFTP connect timeout is set to 30000ms. In the file, I have tried the connection 3 times, and then again from WinSCP 2 times. WinSCP can connect without any issues. (and timing seems to be the same) The client is a Windows Server 2012 R2. The application is Java based. Wondering if SSL or TLS protocol could be the issue. Application using native windows settings, WinSCP using its own I think.

Thank you,

Nekrolord gravatar imageNekrolord ( 2020-06-10 13:41:39 +0000 )edit

And here is the pcap file for a working connection from the software:

https://www.dropbox.com/s/h4gk6fsoibo...

it is using SSH 2.0 JSch so not native. I am again clueless. :(

Nekrolord gravatar imageNekrolord ( 2020-06-10 13:52:20 +0000 )edit

Hello, to me it looks like it is blocked by a host firewall or even by the host stack. And the main difference between the working and the non working case is the IP ID. In the non working case the IP ID is zero.

This is normally allowed to use, but in that packet Fragmentation is allowed. And therefor it could be possible that the host resests the connection.

To me it looks like the IP ID was manipulated somewhere at the path. As I don´t think that the sender of the SYN,ACK did this.

Christian_R gravatar imageChristian_R ( 2020-06-11 09:54:16 +0000 )edit

I agree to @Christian_R conclusion that something on the way manipulated the IP ID, and that's why the connection is reseted. But I don't think it's the host firewall or the stack because in the first capture, we see the three connection tries by the Java program which failed. The fourth try is WinSCP and it was able establish the connection, although the IP ID in the SYN/ACK is also zero. If the host firewall or network stack is the problem, should it not deny this connection as well? So my guess is that your Java program doesn't like the missing IP ID in the SYN/ACK and therefore resets the connection.

JasMan gravatar imageJasMan ( 2020-06-11 11:32:40 +0000 )edit