DOTW: TCP Resets from Client and Server aka TCP-RST-FROM-Client

[jdelio]

Hello everyone,

In this week's Discussion of the Week, I want to take time to talk about TCP-RST-FROM-CLIENT and TCS-RST-FROM-SERVER.

This is a link the discussion in question.

This discussion has to do with a user seeking clarity on two different "reasons" that the session has ended in this user's logs:

• tcp-rst-from-client
• tcp-rst-from-server

Now, these are things that anyone with a Palo Alto Networks firewall has probably seen in their logs on a daily basis.

See the log view below for what this looks like in your logs:

Detailed log view showing the reset for the reason

This type of reason to end the session is perfectly normal behavior.

It is something that is "to be expected" as long as the traffic in question is working correctly. 

Details

Here is more of a technical explanation of what "normal" is.

Normally, these tcp-rst-from-client sessions are ended after receiving the full data from the server (in question).

The client then sends the Fin ACK, then closes the executable being used.

On executable close, the socket associated to it is also closed. The OS sends an RST packet automatically afterwards.

This TCP RST packet also ends the session, so the end reason is set to tcp-rst-from-client.

As long as the download was ok, everything is fine.

The reason for this abrupt close of the TCP connection is because of efficiency in the OS.

A TCP RST (reset) is an immediate close of a TCP connection. This allows for the resources that were allocated for the previous connection to be released and made available to the system. The receiver of a RST segment should also consider the possibility that the application protocol client at the other end was abruptly terminated and did not have a chance to process the data that was sent to it.

The Palo Alto Networks firewall sends a TCP Reset (RST) only when a threat is detected in the traffic flow. In all other cases, the RST will not be sent by the firewall.

Summary

It is great that we know why this is happening, but if the traffic is not working correctly, then this is where we have to start digging into the logs, performing packet captures, and getting our hands dirty to see what is really happening behind the scenes. 

More Info

For a start on performing packet captures, please see the following article talking about this: Getting Started: Packet Capture

For more detailed information about Packet Flow or "A Day in the Life of a Packet," showing exactly how traffic flows through the firewall, please see: Packet Flow Sequence in PAN-OS

Thanks for taking time to read my blog.
If you enjoyed this, please hit the Like (thumbs up) button, and don't forget to subscribe to the LIVEcommunity Blog area.

As always, we welcome all comments and feedback in the comments section below.

Stay secure,
Joe Delio
End of line