TCP RESET Application Server

asked 2019-10-24 03:38:44 +0000

xlinux
1 ●2

updated 2019-10-24 05:07:03 +0000

Hi Best Brains n the World, I need your help with this issue, im not the best wireshark person or anywhere near it, I had done my best to interpret it but im Stuck like Duck!

Situation: We use application (Mix of Web based and GUI Menu) in all our offices (remote and local) and works fine except our main site in NZ. The application works partially right until they get to certain part then the application times out – RESET page is NOT displayed i.e. error Navigation error “This Page cannot be displayed”

http://s000.tinyupload.com/index.php?...

I ran wireshark and the capture file is attached, my discovery are as per below • The connection gets reset from the server side IP .53 • I noticed every time the connection reset the TTL is 59 (TTL starts at 64) this is 5 HOPS away from {this is where im confused is it 5 HOPS away from the starting point i.e. where the capture is happening from (Client machine where I ran application from) or is it 5 HOPS away from the Application server IP .53}

Kindly assist me with the issue as to why the CONNECTION RESET is happening

Note: If the NZ users use VPN connection to connect to our head office where the application server resides the application works perfectly fine.

I cannot upload the . pcapngfile because I need 60 points but im NEW first time, there must be away for newbies, How can I upload the file if im newbie surely newbies should be give 100pts to start with then deducted as per use.

. pcapng file location is below

https://1drv.ms/u/s!Ao8vnFdQUxjmgiNpX...

Thanks for your time and effort.

edit retag flag offensive close merge delete

add a comment

answered 2019-10-24 05:47:27 +0000

SYN-bit

18344 ●9 ●301 ●255 https://SYN-b.it

Kindly assist me with the issue as to why the CONNECTION RESET is happening

Wireshark can not tell you WHY the TCP RST is sent, but it can make a guess at WHO is sending the TCP RST. As you mentioned, the IP TTL of the TCP RST is 59, that seems to be 5 hops away from the capture point (it looks like the capture was made on the client 172.27.168.47 is that correct?). The HTTP respponses that the client did get from the server 160.220.36.53 have a TTL of 122, that seems to be 6 hops away from the capture point.

This combined leads to the conclusion that the first hop from the server towards the client is the device sending the TCP RST packets. As the TCP RST packets only occur on a specific URL, it seems there is a next-gen firewall, a web application firewall or maybe an IPS/IDS that is hitting a rule, which might be a false positive.

Comments

Hi Syn-Bit thanks for your time and effort, yes capture is made from workstation 168.47 yes TTL of 122 looks successful communication as there are 6 hops between them and hence TTL 122.

This is the real question is which device the sending the TCP RST, and this is where i was not sure because when i pointed out the info to the Network team (first hop from the server towards the client), they basically laughed at me and said that the device is just layer 3 switch and has NO FW rules, NO IPS/IDS or any NO ACL related rules, so then i pointed the Hop/device nearest the client PC and this is Router managed by our Service provider.

I am not sure if you analysed the capture file but what i really need is for someone to look at it and give m conclusive evidence ...(more)

xlinux ( 2019-10-25 01:29:51 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

TCP RESET Application Server

1 Answer

Comments

Your Answer

Question Tools

Stats

TCP RESET Application Server edit

1 Answer

Comments

Your Answer

Question Tools

Stats

TCP RESET Application Server