Help analyzing TCP connection sequence

asked 2019-05-08 06:49:03 +0000

EricSnijders
3 ●1 ●2 ●3

Hi all, I'm trying to understand the complete flow of a TCP sequence and i think our application is sometimes not closing TCP sessions right but i'm not 100% sure.

Please see the following: image description

My concerns are with the closing stage of the TCP connection.

Packet #2262 is a [FIN,ACK] but shouldn't there be a [FIN] from the other side first?
Packet #2265 shows the same but the other way around
I can't place those random [ACK]'s at #2264 and #2267.

Why am i asking? This is a capture from our firewall. Apparently, something in this connection is triggering a "new connection" on our firewall. I'm suspecting it has something to do with this TCP connection not being closed gracefully and [ACK]'s coming after the [FIN,ACK]'s but i'm not 100% sure.

Would be great to get some help!

Thanks in advance,

Eric

edit retag flag offensive close merge delete

add a comment

answered 2019-05-08 09:12:16 +0000

SYN-bit

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

Hi Eric,

Packet #2262 is a [FIN,ACK] but shouldn't there be a [FIN] from the other side first?

Either side may close the connection by sending a FIN/ACK. This tells the other side that it won't send any more data.

Packet #2265 shows the same but the other way around

This is where the other side sends it's own FIN/ACK to indicate that it too will not send any more data. This means the connection is (almost) closed.

I can't place those random [ACK]'s at #2264 and #2267.

Both FIN/ACK packets need to be acknowledged, as both sides need to know their FIN/ACK was correctly received. This is accomplished by adding a "phantom" byte to the FIN/ACK packets. So even that there is no data in the FIN/ACK packets, it gets treated as if there was 1 byte of data. That's why you see the ACK's in frame #2264 and #2267

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. This means the session will be removed from the TCP session table immediately (both on the endpoints as well as session based devices in the path between them). My bet is that the ACK in frame #2267 is now seen as a new session by the firewall, because it already removed the session from its sessiontable when it received the RST of frame #2266.

What kind of OS and Application is running on 172.24.9.13?

edit flag offensive delete link

Comments

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

Packet_vlad ( 2019-05-08 09:22:46 +0000 )edit

Hi SYN-Bit, First of all: Wow, thank you so very much for this! Lately i've been going deeper and deeper in the nitty-gritty stuff about (TCP) connections so this is really helpful. I really thought ending TCP connections was started with a [FIN] but now i understand that it could be a [FIN,ACK] right away.

And exactly how you explain it: chances are pretty big our firewall (Cisco ASA) see's the [RST] and removes it from his connection table as well. If that's the case, it makes sense that #2267 is seen as "new" (which in this case is allowed by our firewall since there is a permit rule to investigate this).

About 172.24.9.13. In this case it is our customer, so the OS and/or Application might differ. I can only control 172.24.0.43 which is running RHEL and running ...(more)

EricSnijders ( 2019-05-08 09:30:32 +0000 )edit

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:

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

SYN-bit ( 2019-05-08 13:33:43 +0000 )edit

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

SYN-bit ( 2019-05-08 13:34:21 +0000 )edit

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.

Packet_vlad ( 2019-05-08 13:50:53 +0000 )edit

see more comments

Help analyzing TCP connection sequence

1 Answer

Comments

Your Answer

Question Tools

Stats

Help analyzing TCP connection sequence edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Help analyzing TCP connection sequence