Hi, Hopefully you can help me with this. I have an application that works on one of my machines but it doesn't work on my VPS. When I run it on VPS the connection fails and it looks like it is being reset by client. Please take a look at traces from both machines: not working: https://s18.postimg.org/5obwjkz2h/not_working.png working: https://s22.postimg.org/9r49a6w0x/working.png I have a suspicion that has something to do with NAT but according to my hosting provider that's not the case. Any ideas what might cause connection to reset? Many thanks Peter asked 10 Nov '16, 00:11  cr4zy1w4n edited 10 Nov '16, 01:09 |
One Answer:
The screenshot of the "not working" part is showing that the client aborts the connection with a reset after 2 seconds. It's unclear why, because after the handshake it should be the client to send it's SSL handshake, or any kind of request. My guess is that in the packets between those two seconds something happens that leads to the abort, but since you filtered the trace I really can't say what it might be. It would be better to have a capture file to look at if you can provide it (use TraceWrangler to anonymize it, if possible/required), e.g. putting in on CloudShark. answered 10 Nov '16, 02:00  Jasper ♦♦ showing 5 of 8 show 3 more comments |
please find full anonymized trace below https://www.cloudshark.org/captures/e3e4e2413bf2 ip address of remote server that app needs to communicate with is 209.126.122.72
Interesting, the client doesn't do anything apparently, just kills the connection after two seconds. So this seems to be an issue with the application on the client - the network doesn't show any problem that could cause this.
thanks for looking at the trace, indeed something weird is going on. I can copy the application to another client with the same OS and settings and it will work just fine. Worst thing is that app developer claims this is a network problem. I will play with it a bit more just to see if I can work it out. Thanks!
Well, it may be a "network problem" within the network stack behavior of the client. So I'd still say it's a client problem, even if it's not an application problem. But it's not something the network itself does wrong, that much is pretty clear.
Try to find out what the differences between hosts are, e.g. compare the routing tables etc
main difference is IP addressing. Not working host is on public IP and it looks like its behind transparent proxy (can't confirm as hosting provider didn't want to give me any details) working client is on private IP.
You did capture on the client, right? So if the client doesn't send a meaningful packet after the handshake and you're on the client, the transparent proxy seems irrelevant... It would be different if the capture was taken on the server.
Are there any security products that are different? Sometimes AV/Personal Firewalls/Host IDS systems can interfere...
I managed to work it out.. one of the dll files application is using was corrupted and stopped the app from working correctly. Nothing to do with networking whatsoever :) Thanks for your help anyways!
I'd agree with Jasper here. Just looking at the connections to 209.126.122.72, we see the working 3-way handshake, followed by a client Reset after 2 seconds. This would appear to be client timeout.
There's no evidence whatsoever that there is a network problem to that server - because after the handshake we are waiting for the client to make its request. The client application seems to go away after asking for the TCP connection.
If a firewall was involved, we perhaps wouldn't expect to see the successful 3-way handshakes. After that there are no client packets to block.
I notice that the SYN-ACKs have a TTL of 51, meaning that they come from something 13 hops away. Would that be the real server or something else?
I did notice that the client's SYN for the second connection doesn't support Window Scaling whereas the first and third ones do. I have no idea if this has any relevance.
Your RDP connection to 151.80.169.249 does contain frequent "out-of-order" or "overtaken" packets (as indicated by the Selective ACKs). Again, there's no evidence that this has any impact on the RDP performance or on the original problem - but may be something else worth investigating.