SFTP connection issue RST sent intead of ACK
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,
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.
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,
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. :(
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.
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 Good spot with working connections. I do not believe at the moment that the IP ID is really an issue. Yes it might be an issue in the application. Maybe you can spot, the reason in the log files.
Unless the app is using raw sockets, would the ip.id field even be available to the application to evaluate? Is the program using it's own TCP/IP stack?
@Bob Jones Also a good point. The Java program should not care about the IP part unless Java or the SSH implementation "JSCH v0.1.54" its using its own IP stack.
But as @Christian_R already mentionend, the only obvious difference between the working and the non-working case with the Java client is the IP ID field. If he's right with his assumption that a device on the way has manipulated the IP field, and due to the fact that the destination of the non-working scenario is in Shanghai, I guess the "Great Firewall Of China" did it. Would be interessting to know, if the issue also appears with other SSH servers in CN.