DOTW: Aged-Out Session End in Allowed Traffic Logs

[kiwi]

In this week's Discussion of the Week, I would like to take some time to go over Aged-Out Session End, because it's a pretty popular topic in our discussions area on LIVEcommunity.

Below is the link to said discussion and I added some extra links that cover the same topic:

https://live.paloaltonetworks.com/t5/general-topics/session-end-reason-tcp-fin-and-aged-out/td-p/245...

https://live.paloaltonetworks.com/t5/general-topics/aged-out-in-allowed-traffic-logs/m-p/295534

https://live.paloaltonetworks.com/t5/general-topics/seeson-end-reason-aged-out/td-p/78997

In these discussions, the different users were all looking for some clarification on the session end reason "aged-out."

This type of end reason could actually be perfectly normal behavior depending on the type of traffic.

It is something that is to be expected for services using the UDP protocol. For example, services like DNS, DHCP, NTP and SNMP use UDP and can be considered unreliable because the protocol doesn't offer a guarantee that the data is actually delivered correctly, which is an advantage with services using TCP .

Similarly a simple PING can also return an aged-out session end. As you might know (or not), PING doesn't use TCP or UDP . It uses ICMP which is also a stateless protocol like UDP .

So for these kind of services or protocols, it could be considered normal behavior to have a session end reason "aged-out."

For services using TCP however, having a session end "aged-out" might not be considered normal and further investigation is required. The reasons can be many. Here are just a few examples:

• The destination server might not have an open port on the requested service
• The receiving end might return traffic over a different path (asymmetric routing)
• Your access can be blocked by a remote FW or access list
• There might simply be a network path issue in-between

This often goes hand-in-hand with application showing as ' Incomplete ' in the traffic logs.

In that case, you might want to first check if your packets are correctly leaving the firewall. You can do a PCAP to make sure. Also a good indication is the 'Packets Sent' count in the traffic log. You can check the 'Packets Sent' in the traffic log details or you can add up the columns, as displayed below.

Once you've confirmed that packets are correctly leaving the firewall, you should check the behavior (if you can) on the remote end. Is your request even reaching the remote end and if so, how is it being handled? Is it being blocked and is the server sending a response back? Is traffic returned using a different path?

More Info

Getting Started: Packet Capture

Session Tracker Feature

Why do some traffic report as aged-out in traffic log

Not-Applicable, Incomplete, Insufficient Data in the Application Field

Thanks for taking time to read this blog.
Don't forget to hit the Like (thumbs up) button and to subscribe to the LIVEcommunity Blog area .

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

Kiwi out!