This is an age old discussion around application behavior... a couple things to consider, not all applications behave the same and I'm sure we all have war stories of sending a TCP-RST caused an application to blow up 🙂 so, no perfect answers for everything which is why if there is no traffic seen during the defined session timeout period it will be aged out and future traffic not starting with the appropriate TCP handshake will be dropped. If the FW terminates a session then the reason it does so should be captured in the log at session end as described in this thread, see https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/monitoring/use-syslog-for-monitoring/syslog-field-descriptions/traffic-log-fields for a run down (PANOS 8.1) of how the log is broken down. It is a little cryptic, but there is a parameter tracked for "aged out" of a session as a "reason" for session end. As to what can I do? The first thing to check is to see if there is an App-ID for the application, Application Research Center would be the place to start. If not, then you could create a custom App-ID for that specific flow and manage the timeout and other characteristics. If all of that is too much to do right now then depending on your version of PANOS you can create a custom Service Object and manage the timeout value, https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-web-interface-help/objects/objects-services.html. This Service object could then be used in the specific security rule for that source(s)/destination(s) requiring the different timeout and/or other characteristics. In general, changing the default UDP/TCP timeout is not a good idea as that becomes pervasive across everything which is probably not desired nor is it generally good security hygiene... hth
... View more