Connection being reset

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.

It looks like 98.100.152.162 is the client (on your network/?/) and 23.99.129.46 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 98.100.152.162 is 62.

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

Note the pattern that begins with frame#4

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

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

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

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

frame #11 98.100.152.162 >> 23.99.129.46
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 23.99.129.46 >> 98.100.152.162
Seq=496659119 Ack=1106885139 Len=0 (ACK for segment in frame #11)

frame #13 98.100.152.162 >> 23.99.129.46 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 23.99.129.46 >> 98.100.152.162 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 98.100.152.162 >> 23.99.129.46 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)