This is a static archive of our old Q&A Site. Please post any new questions and answers at

Connection being reset


I have a device on my network trying to connect to a remote server but is failing to do so. I have taken the device off-site and it will connect, so I believe I have an issue with my firewall but can't pin point my issue. I am seeing a lot of TCP Retransmissions and TCP Dup Acks in my capture.

This device connected properly before but now is unable to. Any help would be appreciated.

Thank you

asked 26 Jan '15, 13:50

Speaker's gravatar image

accept rate: 0%

2 Answers:


In your capture file the content of the TCP session is not SSL, what kind of protocol is it? Do you have a NextGen firewall that does protocol inspection? Then most likely it is blocking the packets from your device as it is not SSL.

You will need to add a new outgoing rule for your device where you disable protocol inspection or better yet, make it inspect the traffic as the protocol that it is using.

answered 26 Jan '15, 15:36

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%


It looks like is the client (on your network/?/) and is the off-site server.

Assuming that is the case, it looks like this capture may have been taken from some intermediary device, since the TTL for packets from is 62.

First thing to note, is that it looks like the incoming packets from are not being passed to the actual client.

Note the pattern that begins with frame#4

frame#4 >> Seq=1106885107 Ack=496659091 Len=16

frame#5 >> Seq=496659091 Ack=1106885123 Len=0 (ACK for segment in frame #4)

frame #6 >> Seq=496659091 Ack=1106885123 Len=28 (expecting ACK# 496659119)

frame #7-10 [Server Retransmission of frame #6]

frame #11 >>
Seq=1106885123 Ack=496659091 Len=16
Note that the ACK# is no different than frame#4 (also note the 2.3 sec delta between frame #4 and this frame). This implies that the client has not received any server frames since frame #5. The data is not readable, but it is possible that this is an application keepalive from the server (hence the 2+ sec delay and sequence incrementation).

frame #12 >>
Seq=496659119 Ack=1106885139 Len=0 (ACK for segment in frame #11)

frame #13 >> Seq=1106885123 Ack=496659091 Len=16 (Retransmission of frame #11 ~230ms later (looks like an RTO)) This suggests, again, that server segments are not being forwarded to the client.

frame #14 >> Seq=496659119 Ack=1106885139 Len=0 (ACK for frame #11 with SACK options) SLE=1106885123 SRE=1106885139 (Suggests that server never saw frame #4 (missing segment )

frame #15 >> Seq=1106885123 Ack=496659091 Len=16 (Retransmission of frame #11 - Already ACK'd twice by the server (looks like another RTO)

It appears that RTO driven retransmissions of this frame continue in frames 18, 20, 23, 26, and 29. Each time, the server continues to ACK the segment, with the later segments also including SACK options to indicate that the server never saw frame #4.

At first glance, it appears that a device is not forwarding the traffic from the server to the client.

(didn't have time to dig out the details of why the RST is occurring, exaclty, but I hope this helps)

answered 26 Jan '15, 16:22

Qwert's gravatar image

accept rate: 0%