Session end reason: tcp-fin and aged-out?

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

Session end reason: tcp-fin and aged-out?

L2 Linker

Hi all,


I am using PA-850. I am having the problem. sometimes the internet is blocked. and I see in the monitor, the sesson end is: tcp-fin and aged-out. but after refresh some times, then I can access to internet.


Please help to advise how to fix it. please let me know if you need more information for this issue


L6 Presenter

TCP-FIN is a normal way to end a TCP session and doesn't indicate an error.

Aged-out is as normal way for UDP session to end. But make sure packets are flowing in both way in this case, check sent/received packets count.

Hi Santonic,


I checked and see that, session end reason aged-out: packets sent and packets recived is same numbers

but session end reason tcp-fin: sent and recviced is different.


please help to advise.

That's all normal. That doesn't indicate any errors.



Aged-out doesn't mean failed to get a further response as well..? For some reason, the other end is not responding to my query, after a certain amount of time, the session will age out and terminated. The reason could be my IP is been block listed, or some network path issue in-between. 




L0 Member



I am the Jr. Network Admin of a Private School in Dobbs Ferry, NY and we are experiencing this exact issue.  Our traffic is fine for our users until suddenly they are unable to get to any external webpages and the Traffic Monitor shows the session application as "incomplete" and end reason of "Aged-out" despite being TCP.  After anywhere from 5-15 minutes, it seems to clear up and be fine, only to happen to another subnet/user(s) again and again.  Our packet captures show "flow_fwd_l3_noarp 12 0 drop flow forward Packets dropped: no ARP" and nothing we have done seems to fix it. We have confirmed there are no Security or NAT policies that are blocking the traffic and that the counters on the network facing interfaces increase for "no arp found" and "packets dropped by flow state" increase when the problem occurs.  The external interfaces affected show only increasing counters for "packets dropped by flow state."  


It has been on and off for about 3 months and Palo Support has not gotten us anywhere in terms of solutions.  Hoping you or someone else who has experienced this can offer some guidance!



Great thread ! Got lot of value from it.

L1 Bithead


If you have the issue again, get on the CLI and use:

show arp all

to see if you have an entry for your device's default route next hop. If it's not in the ARP table, you may be having a physical or layer 2 issue where the firewall is not able to forward to your Internet provider's upstream device because it doesn't have a MAC for it.

  • 7 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!