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?