This is a copy from this site https://rajivccie.blogspot.com/2018/05/paloalto-traffic-error-logs.html so all credit goes to the author. Keeping it here as a backup in case the site goes down.
=====================
aged-out
=====================
1)Generally Session aging is an operation to identify expired sessions and remove them from ager and flow lookup table and return to free session pool. It can be triggered by timer event or packet arrival event. A session is considered expired if
• Session state is CLOSING, in this state session is subject to immediate expiration.
At various phases during packet processing, a session may close due to causes such as:
Session denied or time out
Dropped packets due to threat various treat conditions
Reset by any of end hosts
2)The purpose of introducing the session tracker feature is to provide precise reasons for mitigation actions taken on particular sessions.
3)There are multiple tracker stage statuses, such as:
======================
SESSION END REASON
=======================
Aged out – Occurs when a session closes due to aging out
TCP FIN – Occurs when a TCP FIN is used to close half or both sides of a connection
TCP RST – client – Occurs when the client sends a TCP reset to the server
TCP RST – server – Occurs when the server sends a TCP reset to the client
appid policy lookup deny – Occurs when a session matches a security policy with a deny or drop action
mitigation tdb – Occurs when a session ends due to a threat detection
resource limit – Occurs when a session is set to drop due to a system resource limitation such as exceeding the number of out of order packets allowed per flow or the global out of order packet queue. Many other reasons will roll up to this reason.
host service – Traffic destined for firewall but service not allowed or enabled
4)TCP Session Timeout:
Maximum length of time that a TCP session remains open without a response, after a TCP session is in the Established state (after the handshake is complete and/or data transmission has started). Default is 3600 seconds; range is 1-1599999 seconds.
You can change the timeout value from Device > Setup > Session > Session Timeouts > TCP
5) Here TCP 3 way handshake was breaking down due to an invalid response from the server. The order of the handshake should be syn > syn-ack > ack but instead we saw syn > ack > rst.
We can try clearing the sessions to the server and see if this helps though if we receive the same thing it is likely an issue with the server and or the application. Since we will need to reset the sessions after you are out of normal production hours we will wait for your followup.
======================
APPLICATION REASON
======================
Incomplete means that either the three-way TCP handshake did not complete or the three-way TCP handshake did complete but there was no data after the handshake to identify the application. In other words that traffic being seen is not really an application. For example, if a client sends a server a syn and the Palo Alto Networks device creates a session for that syn, but the server never sends a SYN ACK back to the client, then that session is incomplete.
Insufficient data means not enough data to identify the application. So for example, if the three-way TCP handshake completed and there was one data packet after the handshake but that one data packet was not enough to match any of our signatures, then user will see insufficient data in the application field of the traffic log.
Unknown-tcp means the firewall captured the three-way TCP handshake, but the application was not identified. This may be due to the use of a custom application for which the firewall does not have signatures.
Unknown-udp consists of unknown udp traffic.
unknown-p2p
Unknown-p2p matches generic P2P heuristics.
Not-applicable means that the Palo Alto device has received data that will be discarded because the port or service that the traffic is coming in on is not allowed, or there is no rule or policy allowing that port or service.
For example, if there was only one rule on the Palo Alto device and that rule allowed the application of web-browsing only on port/service 80, and traffic (web-browsing or any other application) is sent to the Palo Alto device on any other port/service besides 80, then the traffic is discarded or dropped and you’ll see sessions with “not-applicable” in the application field.
Action – Action indicates an allowed traffic. Deny would indicate a block.
if the final action is Allowed then please check below Session_end_Reason to confirm if the traffic is completely allowed or blocked.
| Action | Final Action | reason |
| allow | Allowed | session was allowed by policy |
| deny | Blocked | session was denied by policy |
| drop | Blocked | session was dropped silently |
| drop ICMP | Blocked | session was silently dropped with an ICMP unreachable message to the host or application |
| reset-both | Blocked | session was terminated and a TCP reset is sent to both the sides of the connection |
| reset-client | Allowed | session was terminated and a TCP reset is sent to the client |
| reset-server | Allowed | session was terminated and a TCP reset is sent to the server |
App– Firewall can identify applications based on various aspects of the traffic.
You can find complete list of applications from HERE
If the application is not identified, then it can be because of following reasons
| App | Final Action | reason |
| Incomplete | Allowed | The three-way TCP handshake did not complete Properly. |
| Insufficient data | Allowed | The three-way TCP handshake did complete but there was no data after the handshake to identify the application. |
| Unknown-tcp | Allowed | The three-way TCP handshake completed, but the application was not identified. This may be due to the use of a custom application or port numbers |
| Unknown-udp | Allowed | The UDP application was not identified. This may be due to the use of a custom application or port numbers |
| Not-applicable | Blocked | Blocked by Firewall, as there is no rule or policy allowing that port or service. |
Session_end_Reason– This indicates why a session ended. The reasons are below:
| Session End Reason? | Final Action | Description? |
| threat | Blocked | The firewall detected a threat associated with a reset, drop, or block (IP address) action. |
| policy-deny | Blocked | The session matched a security rule with a deny or drop action. |
| tcp-rst-from-client | Allowed | The client sent a TCP reset to the server. |
| tcp-rst-from-server | Allowed | The server sent a TCP reset to the client. |
| tcp-fin | Allowed | One host or both hosts in the connection sent a TCP FIN message to close the session. |
| tcp-reuse | Allowed | A session is reused, and the firewall closes the previous session. |
| aged-out | Allowed | The session aged out. |
| resources-unavailable | Blocked | The session dropped because of a system resource limitation. For example, the session could have exceeded the number of out-of-order packets allowed per flow or the global out-of-order packet queue. |
| decrypt-error | Blocked | This occurs if we configure SSL Decryption and the Firewall blocks if it detects certificate expiry, unsupported cipher suites. |
| decrypt-cert-validation | Blocked | This occurs if we configure SSL Decryption, Firewall blocks if the server certificate produces a fatal error alert of type bad_certificate, unsupported_certificate, certificate_revoked, access_denied, or no_certificate_RESERVED |
| decrypt-unsupport-param | Blocked | This occurs if we configure SSL Decryption, , Firewall blocks if the session produces a fatal error alert of type unsupported_extension, unexpected_message, or handshake_failure. |
| decoder | Allowed | |
| The decoder detects a new connection within the protocol (such as HTTP-Proxy) and ends the previous connection. | ||
| n/a | Allowed | This value applies when the traffic log type is not end |