How TCP Works - FINs vs Resets

This video explains the difference between the orderly (FIN) and abortive (Reset) release in TCP with Wireshark. You can follow along with the video using this trace file hosted on Cloudshark -
www.cloudshark...
Like/Share/Subscribe for more Wireshark content!
== More Training from Chris ==
▶Getting Started with Wireshark - bit.ly/udemywi...
▶Getting Started with Nmap - bit.ly/udemynmap
== Live Wireshark Training ==
▶TCP/IP Deep Dive Analysis with Wireshark - bit.ly/virtual...
== Private Wireshark Training ==
Let's get in touch - packetpioneer....

[@jnelly3426]

This is good stuff. I found your KZbin channel by chance, and I’m glad I did. Your explanations are clear and concise.

[@ChrisGreer]

Thanks for watching and commenting! Please subscribe.

[@ryan-bo2xi]

This is just pure class ... Fabulous !

[@carlosalonzo6677]

thank you so much for pointing out the reset at the end of the tcp communication (FIN).

[@ChrisGreer]

Sure thing Carlos - glad that helped!

[@BrunoVernay]

Short and nice. The link to the capture returns a 404? Could it be available again or elsewhere ?

[@ramber1021]

Hi Chris , Thanks for posting the video, I have a question, how did we know that TTL 64 suggests packet was unrouted and the FIN was sent by the firewall.

[@ChrisGreer]

Hello Dheeraj - 64 is one of the starting TTL values that an IP stack uses when transmitting a packet. Routers will progressively decrement this number as they pass the packet on the way to the target. If we receive the packet before this is decremented, we know that the packet has not been routed yet. I go into this in deeper detail in this video - kzbin.info/www/bejne/qmaye5imnd6qbqs

[@ramber1021]

Thanks for your reply, I really appreciate it. I also checked your other video, where you have explained this in detail :).

[@PADARIAD]

@@ChrisGreer , Whenever i try on my own network, I always see 245 or 128 - i have never seen 64 so far! my question is, how come it starts at 64 i mean, did you set it up that way? i understand that it decreases hop by hop but what gives you the idea that the initial start time for TTL is 64 in your case. (sorry if it's a noob question) P.S - i have watched the video but still have same QQ

[@ChrisGreer]

@@PADARIAD Typically, when a system sends out an IP packet, it starts with a TTL of 255, 128, or 64. It really depends on the OS or the stack settings as to which value is used. So if you see one of those numbers, you are looking at an unrouted packet. So in the trace file I saw the resets coming back for each SYN attempt from an unrouted source. The device sending them was on the network. So the MAC source revealed who the true sender was. Hope that helps.

[@PADARIAD]

@@ChrisGreer thanks sir! You the best, it makes sense now.

[@vikramkhatri111]

Can you do a video on SSL handshake process and IPSEC VPN steps in detail ?

[@miamibeach9434]

You have great way of explaining. Thanks a lot Chris 😁

[@shriloo]

Thanks for the informative video. The capture file given in the description returns a 404

[@sushantjoshi7030]

hello Chris, I dont think it will be sending TCP RST if the port no 22 is not opened for that particular ip. Instead it will be retransmitting it ...you can capture a packet and test it yourself :)

[@Mr22harshit]

Hey chris can u provide some info on tcp reset o ??? it will be super helpful.

[@ciscosubu]

Hi Chris . This is SUBU . Nice video and nice explanation as always . Highly appreciate if you shed more light on RESET from server due to TCP-SYN -sequence number out of window . on the firewalls , we have this no-sequence-check" . recently came across an issue when TCP transaction is happening between 2 SRX juniper FW's , witnessed packet drops . Server or client sending RESET during TCP-3 way handshake or post TCP 3 way handshake due to Sequence number checks . these elements could you please talk about for more clarity . will be of great help . Thanks .

[@HiindU]

Hey Chris, this one was nice. A question though - if reset comes from some intermediate firewall and TTL decreases to 54 then shouldn't the source IP should change as Firewall 's IP?

[@cj90210x]

Another excellent video. Thank you for sharing!

[@gaz1978]

Another awesome video many thanks for the effort

[@andrewohanian5132]

Hey Chris, at 6:27, is there a specific reason a server chooses to "ungracefully" abort the connection with a RST vs. a FIN? It is doing this to more quickly clear the TCP session on its end or something similar? Or just different ways different OS/TCP stacks handle closing connections?

[@ChrisGreer]

Hey Andrew, great question. So you hit the nail on the head with both points. Sometimes it is the TCP stack dumping connections, either because of a capacity issue, or because the application is telling it to. Or that is how the OS/stack is configured to handle that particular connection case. Gracefully is always best, but graceful is not always the case!

[@pixaim69]

I have encountered an application which always RST the connection instead of FIN by design. It works well most of the time however intermittently the RST packet doesn't reach the server and it results in a half open connection. I have made suggestions to both sides to handle better the issue.

[@coolbreeze1262]

That's helped thanks ! For asking n responding .. I am stuck in a case and trying to understand if this RST after FIN can cause an issue

[@subhamthemusicalguy8851]

Subscribed your channel and forwarded to my group.You are doing an awesome work

[@ChrisGreer]

Thank you so much!!

[@passionzhere]

on what base you are saying it was the firewall, can you please explain more?

[@dono42]

He goes into this a little more in another video. Link: kzbin.info/www/bejne/rpW0aqadpdCljpo

[@PantheraTK]

@@dono42 Thank you so much

[@daphenom]

THank you for this very informative video! Question, when you do your packet captures, do you run them on the client, server, or firewall? or all 3 of them? I just want to know which one will have a more complete capture since sometimes firewalls drop packets and the client/server doesn't see it being dropped. Thanks in advance!

[@ChrisGreer]

Hey Ceejay - great question. The answer is that it just depends on what I have access to. I would love to have all three, just because the more points of view the better - even if one of them has some loss. However typically I can't get all three, so I start at the client first, then move to server, then somewhere on the infrastructure for a last capture. Hope that helps!

[@rohankademani6406]

This content is gold

[@ChrisGreer]

Thanks for the comment Rohan

[@worldwide1376]

How did you know that the firewall sent the reset in packet 2

[@ChrisGreer]

Greetings! - We look at the TTL Value. It is not decremented (usually starts at 255, 128, or 64). This means the reset originated at the firewall, we just have to check the source MAC to validate that.

[@worldwide1376]

@@ChrisGreer That's awesome, thank you for the insight. Cheers!

[@bskarpa]

What if you see multiple resets back to back?

[@moisesandre]

Excellent!!! As usual :-)

[@ChrisGreer]

Moisés André Nisenbaum thanks for the comment!

[@samiul008]

Hi Chris :) I suppose the trace file has been moved from the link you shared...can you please share the new link for the trace?

[@ChrisGreer]

Ooh I will fix that.

[@samiul008]

@@ChrisGreer Thanks a lot. I have been learning so much from your tutorials and going to take the WCNA exam in February if all goes well :)

[@Aachille5]

TTL is clear to me 😀

[@ChrisGreer]

Good! Keep on sniffin'

[@VivekBhatiaVivek]

Hi Chris, the PCAP file is 404.

[@rechiecebreros2350]

you did not explain how you know it was the firewall who sent the rst

[@dono42]

He goes into a little more details in another video. Link: kzbin.info/www/bejne/rpW0aqadpdCljpo

[@RicardoDiaz21129]

Thank you 🙏

[@jean-philippeferron]

The wireshark file isn't available anymore.

[@ChrisGreer]

Thanks for the heads up - let me get that fixed for you guys. 👍

[@ChrisGreer]

www.cloudshark.org/captures/c6411c0a4588 Please give this link a try.

[@jean-philippeferron]

@@ChrisGreer Works!

[@mcgirishnetwork]

Very informative

[@ChrisGreer]

Thanks for the comment!

[@shadowbrokerbroker1680]

Would i also get a RST if the Firewall is blocking the port?

[@ChrisGreer]

Hi @jason - typically not. The firewall doesn't want to give out info on what it is and is not blocking. If it returned a reset, it would be easier to fingerprint and find a way in for attackers.

[@srinivasgattu6842]

While this is clear and I may be encountering the same thing in my server, what's the best way we can make it automatically retry without abandoning the transaction. As firewall is not in my control the best way could be to make it auto retry.

[@ChrisGreer]

You would have to dig pretty deep into the stack settings in order to config that. It would have quite a few dependencies - OS, Stack, configuration settings.... etc.

[@m.adnankhan8245]

very informative.

[@ChrisGreer]

Glad you think so!

[@brightorb1]

how did you know that 64 TTL is a reply from the firewall???

[@ChrisGreer]

That number means the packet was unrouted. So the MAC source is the original sender.

[@brightorb1]

@@ChrisGreer is it because this number is the max ttl from a linux machine?

[@markopopoland]

Excellent

[@md9936]

Could we classify colors as Red = firewall and so on?

[@PantheraTK]

3:56 - How can you tell that it came from a Firewall? Is the TTL for Firewalls always 64? Also, if it came from a Firewall, why doesnt the Source IP indicate that?

[@ChrisGreer]

Good questions. The 64 means the packet was unrouted. Almost all devices start with a TTL of either 64, 128, or 255, depending on the OS and TCP stack versions. The reset has to come "from" the same IP that the SYN was sent to, otherwise the client station will not reset the connection. You can't SYN one IP, then have a different IP come back with a reset. So the firewall is spoofing the original destination IP.

[@PantheraTK]

@@ChrisGreer And by unrouted do you mean that it came straight from the Layer 3 gateway to the place where packets were being captured? And with regards to the firewall spoofing, the firewall intentionally spoofs this traffic to show the source as being the original source? Muddies my understanding of source/destination addresses a bit. Do any other devices do this? How can we tell what a devices true source is?

[@PantheraTK]

@@ChrisGreer Thank you for the reply btw, found out about you recently, time to watch more of your videos!

[@webschool2637]

the pcap file is 404, why?

[@rheagalsim7497]

The trace file has a 404 error. Please try to upload the file again, thanks in advance!

[@ChrisGreer]

Hello Rhea - I'm looking into it, thanks!

[@alzain55a]

Many thanks your the best

[@ChrisGreer]

Glad it helped Mohamed!

[@juanjoseaguero6539]

Great!!

[@manjunathg5643]

very useful, thanks