- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
10-31-2019 11:25 AM
Hi All,
I have a doubt regarding aged-out feature in palo alto firewall.
We are getting logs with allowed traffic towards different ports like port 23, 1433 etc.
The device action is allow and in reason aged-out.
I want to know that whether the traffic is really allowed or not.
This is making too much confusion and kindly help me with this doubt.
And also how to find the allowed traffic in palo alto firewall.
Thanks and Regards,
Sameer Ahammed
11-04-2019 12:56 AM
This is the expected behaviour when the destination host does not reply to the specific session initiation.
Let's say that you see traffic going from host A to host B, passing through the firewall: A -> Fw -> B. The firewall is allowing the traffic from A to B (Action: allow), but no reply is going back from B to A, so the firewall can't see some "real" application and is telling you that it hasn't got enough data (Application Protocol: incomplete) and the session is being terminated for timeout (Reason: aged-out). Talking about causes, there might be many, but the most probable is that B does not expose the service A is asking for, and B's local firewall (not the PAN, the OS one) is set up not to reply for closed ports (IIRC this should be the default for Windows). To sum it up: A asks for a service, Fw lets the request pass, B drops it.
There might be other causes, asymmetrical routing being the worst one I'd say, i.e. B's reply for an open service goes on a different path, and this messes up things badly. Without further details we can't tell you more.
10-31-2019 02:42 PM
If you see allow as the action then the traffic is being allowed through. This simply means the firewall didn't see a RST or FIN flag and the session aged off the session table.
"I want to know that whether the traffic is really allowed or not."
The traffic was allowed. However both telnet and SQl should be sending normal TCP communications and you shouldn't be seeing aged-out. Verify that your routing is actually configured correctly on the firewall.
10-31-2019 10:33 PM
Thank You @BPry
The scenario is, we are observing allowed traffic towards port 1433 from the logs and we got the policy in the firewall by which it is getting allowed from the logs.
But when we checked the policy in the firewall, we have not observed any service or application configured for allowing the same in the rule.
Here the device action is allowed and the reason is aged-out.
Kindly help me with this
Thanks and Regards,
Sameer Ahammed
11-01-2019 07:03 AM
Can you share the security policy configuration that the log says this traffic is matching.
11-03-2019 08:32 PM
Hi @BPry
PFB table for the rule which is configured.
Destination Port: 1433
Device Action: allow
Reason: aged-out
SourceZone: Outside
DestinationZone: Outside
Rule Name: Outside-Inbound
Transport Protocol: TCP
Application Protocol: incomplete
This is from the logs.
Regards,
Sameer Ahammed
11-04-2019 12:56 AM
This is the expected behaviour when the destination host does not reply to the specific session initiation.
Let's say that you see traffic going from host A to host B, passing through the firewall: A -> Fw -> B. The firewall is allowing the traffic from A to B (Action: allow), but no reply is going back from B to A, so the firewall can't see some "real" application and is telling you that it hasn't got enough data (Application Protocol: incomplete) and the session is being terminated for timeout (Reason: aged-out). Talking about causes, there might be many, but the most probable is that B does not expose the service A is asking for, and B's local firewall (not the PAN, the OS one) is set up not to reply for closed ports (IIRC this should be the default for Windows). To sum it up: A asks for a service, Fw lets the request pass, B drops it.
There might be other causes, asymmetrical routing being the worst one I'd say, i.e. B's reply for an open service goes on a different path, and this messes up things badly. Without further details we can't tell you more.
02-11-2021 12:28 PM
Just wanted to let everyone know that a Blog has been written to help address this:
DOTW: Aged-Out Session End in Allowed Traffic Logs
06-29-2021 06:26 PM
what about NTP UDP/123, as it is connectionless, AGED-OUT means destination is not replying? or it is a normal behavior for UDP packets?
06-30-2021 12:56 AM
I think you can't infer that from the traffic log alone, and an allowed ntp session will terminate with an "aged-out" in the traffic log whether the ntp server responded or not. You could set up a packet capture with filters for the client and server IPs, and UDP/123, to check if there's a reply coming back. If you inspect the single firewall session from traffic log, you'll only get how many bytes are received and sent by the firewall itself, but not their direction (i.e. you won't get "the client sent a X bytes request and got a Y bytes response", so that if Y>0 the server replied with something).
04-07-2022 07:47 AM
Yes, it is normal for UDP 🙂
07-15-2022 10:28 PM
Hi Team,
If I am doing telnet from one server and telnet is working fine but in firewall I can see the traffic is aged out.
I need to know if any traffic is getting aged out, then it should not allow the traffic but how the traffic is going.
Please help me on this.
07-18-2022 02:27 PM
An aged-out response really just means the firewall never saw a tcp-fin and the session aged-out without a graceful termination. As long as you have a rulebase entry allowing the traffic, the traffic will be allowed through the firewall.
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!