- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
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:
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:
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.
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.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Subject | Likes |
---|---|
5 Likes | |
4 Likes | |
3 Likes | |
3 Likes | |
3 Likes |
User | Likes Count |
---|---|
13 | |
4 | |
4 | |
3 | |
2 |