Understanding Palo Alto Session End Reasons

incomplete

ℹ️ Definition & Protocol

This session end reason applies only to TCP traffic . It signifies that the firewall observed the beginning of a TCP connection attempt (usually the initial SYN packet), but the full three-way handshake (SYN, SYN/ACK, ACK) did not complete successfully from the firewall's perspective.

🤔 Common Causes

• No SYN/ACK Response Seen:
  • The firewall forwarded the client's initial SYN packet towards the server.
  • However, the firewall never saw the corresponding SYN/ACK packet coming back from the server.
  • Possible Reasons: Server is down, unreachable, or refusing the connection; a network device (including another firewall) between the PANW firewall and the server blocked the SYN/ACK; Security Policy on the PANW firewall itself blocked the return SYN/ACK (less likely if the initial SYN was allowed by policy).
• No Final ACK Seen:
  • The firewall saw the client's SYN and the server's SYN/ACK.
  • However, the firewall never saw the client's final ACK required to establish the connection.
  • Possible Reasons: Client issue (application crashed, host issue); network path problem preventing the ACK from reaching the server via the firewall; an intermediate device blocked the ACK; **asymmetric routing** where the client's ACK took a different path bypassing the firewall.
• Asymmetric Routing during Handshake: A frequent cause where different parts of the 3-way handshake traverse different network paths. If the firewall doesn't see all three necessary packets (SYN, SYN/ACK, ACK) due to asymmetry, it logs the session as incomplete .

unknown-tcp

ℹ️ Definition & Protocol

This reason applies only to TCP traffic . It indicates that the TCP three-way handshake completed successfully (the firewall saw SYN, SYN/ACK, and ACK), establishing a session. However, the session later terminated in a way that was not a graceful TCP close (FIN/ACK exchange) and wasn't simply due to aging out from inactivity (which is usually logged as aged-out ).

Most commonly, this means the firewall observed a TCP Reset (RST) packet ending the session, or the session timed out unexpectedly after the handshake.

🤔 Common Causes

• TCP RST Packet Observed: This is the most frequent cause.
  • Possible Reasons: An application on either the client or server forcefully closed the socket; the Operating System sent a RST due to issues (e.g., receiving data for a non-existent connection); an intermediate network device (like another firewall or load balancer) injected a RST; the Palo Alto Networks firewall itself sent a RST due to a policy action (e.g., Threat Prevention block set to 'reset', URL filtering block action) *after* the session was initially allowed and established.
• Unexpected Session Timeout (Post-Handshake):
  • If a TCP session becomes idle *after* the handshake completes and reaches its configured TCP timeout value without the firewall seeing any FIN or RST packets just prior, it might be logged as unknown-tcp . However, aged-out is the more specific reason for simple inactivity timeouts.
• TCP State/Sequence Anomalies: Less commonly, if the firewall detects significant inconsistencies in TCP sequence numbers or unexpected flags after the connection is established, it might terminate the session and log it as unknown-tcp .

unknown-udp

ℹ️ Definition & Protocol

This reason applies to connectionless protocols, primarily UDP and often ICMP as well. Since these protocols lack a formal handshake or closing procedure like TCP, this reason signifies that the firewall created a session based on the initial packet(s) but subsequently stopped seeing traffic matching that session within the configured UDP (or ICMP) inactivity timeout period . The session simply expired.

🤔 Common Causes

• Normal Application Behavior & Timeout: This is frequently expected and normal. Many UDP applications (e.g., DNS, NTP, some real-time protocols) send short bursts of data. After the exchange, if no more packets arrive within the UDP timeout window (default is often 30 seconds), the firewall cleans up the session and logs unknown-udp .
• Application Finished/Closed: The application on the client or server simply finished its task and stopped sending data.
• Network Path Issues: Packet loss preventing subsequent UDP packets for the flow from reaching the firewall.
• Asymmetric Routing: If the return UDP traffic takes a different path and bypasses the firewall, the firewall only sees traffic in one direction. Eventually, the session state for the flow it *can* see will time out due to inactivity, resulting in unknown-udp .