topic Seeson end reason aged out in General Topics

Seeson end reason aged out

KotreshaMC — Thu, 02 Jun 2016 10:09:51 GMT

HI friends,

We have created interzone rule looks like below

<entry name="Rule1>
<profile-setting>
<profiles>
<url-filtering>
<member>default</member>
</url-filtering>
<virus>
<member>default</member>
</virus>
<spyware>
<member>Sinkhole</member>
</spyware>
<vulnerability>
<member>VP Profile</member>
</vulnerability>
<file-blocking>
<member>Wildfire</member>
</file-blocking>
</profiles>
</profile-setting>
<to>
<member>A</member><member>B</member>
</to>
<from>
<member>A</member> <member>B</member> <member>c</member>
</from>
<source>
<member>*.*.*.*</member><member>*.*.*.*</member><member>*.*.*.*</member><member>*.*.*.*</member>
</source>
<destination>
<member>*.*.*.*</member><member>*.*.*.*</member><member>*.*.*.*</member>

</destination>

<source-user>
<member>any</member>
</source-user>
<category>
<member>any</member>
</category>
<application>
<member>icmp</member>
<member>nagios</member>
<member>ntp</member>
<member>ping</member>
<member>snmp</member>
<member>snmp-trap</member>
</application>

the rule is triggering perfectly but it's showing aged out and in application field it showing insufficient-data custumer saying he is not getting respone can anyboady help how to solve this??

and i have checked ping from FW CLI to detination in above rule it's successfull and getting response but still in firewall it's showing aged out????? is this someting PAN needs to worry about??

Kindly suggest

Re: Seeson end reason aged out

reaper — Thu, 02 Jun 2016 11:23:29 GMT

To make the rule truly interzone you'd need to set the type to interzone also:

<rule-type>interzone</rule-type>

The rule itself looks ok, but the behavior you're reporting sounds like there might be a network issue. if you look into the details of the traffic logs, can you see packets reported in both directions ?

insufficient data is usually reported when there is asymmetric flow which ping will not report as request and reply are independent, but will impact TCP severely

You can set up packetcaptures to make sure packets are going out and being received as expected. Some more details like traffic log and a topology could be helpful too

kRe: Seeson end reason aged out

KotreshaMC — Thu, 02 Jun 2016 11:35:09 GMT

Hi thanks for the response,

yeah we have included that interzone rule but forgot to mention here.

we checked PCAP also but found that no response and traffic details also bytes received is showing 0.

Re: kRe: Seeson end reason aged out

reaper — Thu, 02 Jun 2016 11:57:41 GMT

if packets are leaving the firewall as expected but none are returning, the next step is to go check at the remote end if packets are being received properly and where the reply is going

is the source IP part of a NAT policy, does the host have a route for it, does the next hop router have proper routing for it etc

Re: kRe: Seeson end reason aged out

KotreshaMC — Thu, 02 Jun 2016 12:11:47 GMT

How can we confirm it's leaving the firewall??

Re: kRe: Seeson end reason aged out

kiwi — Thu, 02 Jun 2016 12:18:10 GMT

Hi,

You can perform PCAPs on the firewall in 4 different stages :

-receive

-transmit

-drop

-firewall

The transmit stage is what the firewall sends out.

Check the following article on how to configure PCAPs :

Getting-Started-Packet-Capture

Hope it helps,

-Kim

Re: kRe: Seeson end reason aged out

reaper — Thu, 02 Jun 2016 12:19:18 GMT

a good indication is if the traffic log contains a 'packet sent' count. you should be able to use thelog details to ascertain if NAT is being applied by looking at the 'NAT Source IP' column

for some more info regarding packetcaptures (these will also help identify 'sent' and 'received' packets), please check out this article: Getting Started: Packet Capture

Re: kRe: Seeson end reason aged out

KotreshaMC — Thu, 02 Jun 2016 13:22:02 GMT

NAT IP is not applied for this and can packet sent count is 1 can be considered for succeful leaving of firewall?

Re: kRe: Seeson end reason aged out

reaper — Thu, 02 Jun 2016 13:47:09 GMT

yes

the SYN packet goes out and then an ACK needs to come back, if the ACK is never returned the session will timeout waiting for reply

Re: kRe: Seeson end reason aged out

KotreshaMC — Thu, 02 Jun 2016 13:55:06 GMT

But i can see IP protocol as UDP, i dont think in this case we receive ACK.

Re: kRe: Seeson end reason aged out

reaper — Thu, 02 Jun 2016 14:39:52 GMT

in case of UDP it becomes a little more tricky because there is no ACK, then you will need to rely more on what you see in the pcap from the firewall, the pcap on the final destination and any pcaps you can make in between

Re: kRe: Seeson end reason aged out

ABlumhard — Tue, 15 Jan 2019 20:12:30 GMT

but if you see bytes (not 0). doesn't that mean traffic IS occurring?

Re: kRe: Seeson end reason aged out

gwesson — Tue, 15 Jan 2019 21:28:44 GMT

All UDP sessions will show their session end reason as "Aged Out" if the traffic is allowed through the firewall. UDP doesn't have a concept of an explicit close, so if it's not dropped because of a threat or policy deny, "aged out" is the only possible end reason. That much is common, you won't have to worry about that.

As for the application showing "Insufficient-data", that just means that not enough packets have been seen by the firewall to accurately identify the app itself.

Take a look at the session output from the CLI (show session id 12345678). You should see the client-to-server (c2s) and reverse (s2c) flows which will show your IPs as well. Check to ensure that the correct NAT addresses (if needed) and make sure that the firewall's routing table (show routing route) is correct to be able to route the traffic in both directions.

If you'd like, paste the result of one of those aged out sessions here. Also, hit the "insert code" icon, you can paste the results in a cleaner format for viewing on these forums, like below.

Here's an example I took from my own firewall that has the same details (IPs changed for privacy). You can see that only 1 packet in each direction was seen, which wasn't enough to identify the application. The end reason is also aged-out, because it's UDP (protocol 17):

> show session id 13736

Session           13736

        c2s flow:
                source:      192.168.1.1 [Trust]
                dst:         1.2.3.4
                proto:       17
                sport:       32047           dport:      8814
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown
                qos node:    ethernet1/1, qos member N/A Qid 0

        s2c flow:
                source:      1.2.3.4 [Internet]
                dst:         123.222.111.333
                proto:       17
                sport:       8814            dport:      29065
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown

        start time                           : Tue Jan 15 13:22:33 2019
        timeout                              : 30 sec
        total byte count(c2s)                : 201
        total byte count(s2c)                : 219
        layer7 packet count(c2s)             : 1
        layer7 packet count(s2c)             : 1
        vsys                                 : vsys1
        application                          : insufficient-data  (insufficient)
        rule                                 : Exclude Logging
        service timeout override(index)      : False
        session to be logged at end          : False
        session in session ager              : False
        session updated by HA peer           : False
        address/port translation             : source
        nat-rule                             : Default Outbound NAT(vsys1)
        layer7 processing                    : enabled
        URL filtering enabled                : True
        URL category                         : any
        session via syn-cookies              : False
        session terminated on host           : False
        session traverses tunnel             : False
        captive portal session               : False
        ingress interface                    : ethernet1/2
        egress interface                     : ethernet1/1
        session QoS rule                     : N/A (class 4)
        end-reason                           : aged-out