Seeson end reason aged out

[KotreshaMC]

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 

[reaper]

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

[KotreshaMC]

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.

[reaper]

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

[KotreshaMC]

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

[kiwi]

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

[reaper]

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

[KotreshaMC]

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

[reaper]

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

[KotreshaMC]

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

[reaper]

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

[ABlumhard]

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

[gwesson]

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