Aged Out in allowed traffic logs

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

Aged Out in allowed traffic logs

L1 Bithead

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

1 accepted solution

Accepted Solutions

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.

View solution in original post

11 REPLIES 11

Cyber Elite
Cyber Elite

@ahmdsmr,

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. 

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

@ahmdsmr,

Can you share the security policy configuration that the log says this traffic is matching. 

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

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.

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 

LIVEcommunity team member
Stay Secure,
Joe
Don't forget to Like items if a post is helpful to you!

L0 Member

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?

 

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).

Yes, it is normal for UDP 🙂

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.

@PPradhan,

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. 

  • 1 accepted solution
  • 188649 Views
  • 11 replies
  • 0 Likes
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!