Help analyzing TCP connection sequence

edit

The only thing weird in this case is that 172.24.9.13 does not wait for the ACK to be received, but sends a RST straight after the FIN/ACK

I've seen this a lot of times, for example for Google Chrome

You are very welcome. One additional note on the use of ACK. When the ACK bit is set, it means the acknowledgement number field is significant. That is true for all packets except:

1. the initial SYN (in which case there was no sequence number to acknowledge)
2. some RST packets also do not have the ACK bit set (although I can't remember in which cases)

@Packet_vlad : OK, I need to capture some Chrome traffic. Thanks!

• RST must have ACK set if it's intended to close an established TCP session. The second endpoint will check this ACK # for validity (a form of 'connection close attack' protection).
• RST may be clear (no ACK flag) if this is a reply to SYN (service refusal).

As for the question this is kinda strange ASA treats pure ACK packet as a new connection. Not an expert in ASAs, but as I know to treat connection as 'new' a firewall has to observe SYN flag whereas ACK packets match 'established' rule.

Alright, thanks once again. I need to focus a bit on the ACK's since it's not yet 100% clear to me to see what packet(s) are beeing "ACK"-ed but i believe there are some tutorials on the internet explaining the Seq and ACK numbers and so.

@Packet_vlad You are right, a ASA would normally only allow TCP traffic if he see's the initial [SYN] from the right way. Except, in my case: we have a TCP-State Bypass policy for our source (172.24.0.43).

@EricSnijders Ah, ok, thanks for clarification!

@EricSnijders As for packet #2267: this is an ACK emitted by server for [FIN,ACK] packet #2265.

It has ACK# 5733 (FIN has Seq 5732, FIN packet length is 1 Byte, FIN packet has to be ACK'ed). The question is - why the server sent it if there was [RST,ACK] #2266? My opinion is: the server sent it BEFORE it got and interpreted [RST,ACK] #2266.

But at the time the client has already marked connection as closed, so when it receives this ACK #2267, it says 'go away, my port 17240 is closed now'.

In general you'll always see FIN and ACK together, because it signals the end from one side of the conversation and all packets after the first SYN are always ACKing opposite packets. At least I can't remember ever seeing a FIN on its own except when packets have been manipulated by scan/attack tools

@Packet_vlad Alright, that makes sense. But could you also say that in this case it's pretty harsh for 172.24.9.13 to send the [RST] right after he sends it's own [FIN,ACK]? If i'm right, it doesn't allow the server (172.24.0.43) with much time to send it's [ACK] on the [FIN,ACK]? What would've happened if packets #2266 and #2267 were flipped in order? Would the TCP connection be closed "gracefully" in that case?

@EricSnijders I think I was too hasty in my analysis. Would it be possible for you to share this tracefile somewhere and paste the link here? I'd like to look at the exact sequence of events which is not possible from a screenshot unfortunately.

@SYN-bit No problem. Unfortunately i've already deleted this trace but since this behaviour is happening regularly, i could create a new capture. I'll try to do it asap!

How can you delete such an interesting trace? ;-)

BTW Looking at the timing of the packets I believe it is the ASA sending the RST packets and I would like to verify that theory by looking at the ip.id and ip.ttl fields

@SYN-bit Capture is already running again. Now i just need to hope the customer is still working and generating a packet like this. Will get back as soon as i have something!

Sake: this is very good assumption. Check also Win size in RSTs - it is different (0 and 14336).

I cannot understand one more thing: server in #2262 has Seq = 3105, but the client in #2264 ACKs...3020. What is the reason for that? Then: #2265, client's [FIN,ACK]: 3020, but instantly [RST,ACK]: 3105.

Looks like some factor we don't take into account.

What do you think - maybe #2264 is not for #2262 [FIN,ACK] but for some packet before? Whereas #2266 [RST,ACK] is a response to #2262 [FIN,ACK].

Apparently this trace is more complex than it seems to be.)

@Packet_vlad & @SYN-bit The capture is still running but as i was afraid: the customer is already off so i don't think i'll capture any traffic today. I'll keep the capture running. I'm expecting this traffic somewhere tomorrow morning. I'll try to capture a bit more than just 1 connection. Hopefully the behaviour will be the same in every connection. I'll make sure to provide you with the .pcap.

I really appreciate both your help. Unfortunately i don't understand the Seq, Ack and Win numbers yet but i would definity like to learn. Seems like i got some interesting stuff here :)! Thanks again guys, you'll hear back from me tomorrow morning.

Yes, the ACK #3020 in frame #2264 triggered me. Analyzing the 3-way-handshake made me realize we are capturing somewhere in the middle (but closer to the server) as there is 2,3 ms delta between SYN and SYN/ACK and 11,2 ms delta between SYN/ACK and ACK. So anything that responds within 2 ms must be from a system closer to the capture point. Also the FIN from the client seems to not ack the "Encrypted Alert", but only the (assumingly) last byte of the HTTPS response. So, looking at the full IP and TCP headers should make this more clear...

@SYN-bit &@Packet_vlad Morning guys! Took me some time but i captured a example. You can download the .pcap here: https://packettotal.com/cache/a8859d7... If it's any helpfull, i can also provide a .pcap where the "reverse" rule on our Firewall is NOT triggered (from the same client/server IP's). In other words: a connection that seems to be going as it should. Just let me know if that would be usefull. I'm looking forward to your findings, hope i can keep up with you guys!

Btw: this capture is from our firewall, so indeed not directly on our "server".