Need to understand session time-outs

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.

Need to understand session time-outs

L4 Transporter

We hare seeing some oracle session being aged-out. When i checked session info tim-out it says 120sec. But the application time-out itself is for 14400 sec . Where does this value of 120 sec come from.

 

 

Session         2071980

        c2s flow:
                source:      x.x.x.x [SERVER2]
                dst:         y.y.y.y
                proto:       6
                sport:       36082           dport:      1521
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown

        s2c flow:
                source:      y.y.y.y [DBASE]
                dst:         x.x.x.x
                proto:       6
                sport:       1521            dport:      36082
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown

        Slot                                 : 1
        DP                                   : 0
        index(local):                        : 2071980
        start time                           : Wed Sep 11 11:25:47 2019
        timeout                              : 120 sec
        total byte count(c2s)                : 500
        total byte count(s2c)                : 3353
        layer7 packet count(c2s)             : 4
        layer7 packet count(s2c)             : 14
        vsys                                 : vsys2
        application                          : oracle  
        session to be logged at end          : True
        session in session ager              : False
        session updated by HA peer           : False
        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                    : ae2.20
        egress interface                     : ae2.21
        session QoS rule                     : N/A (class 4)
        end-reason                           : aged-out

Also below are 2 session on port 443 and both have different time-outs

Session         2105535

        c2s flow:
                source:      f.f.f.f [CAPUGUEST]
                dst:         m.m.m.m
                proto:       6
                sport:       54046           dport:      443
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown
                qos node:    ae1.100, qos member N/A Qid 0

        s2c flow:
                source:      m.m.m.m [EXTERNAL]
                dst:         g.g.g.g
                proto:       6
                sport:       443             dport:      63335
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown
                qos node:    ae1.149, qos member N/A Qid 0

        Slot                                 : 1
        DP                                   : 0
        index(local):                        : 2105535
        start time                           : Wed Sep 11 12:20:02 2019
        timeout                              : 30 sec

 

Session         2071235

        c2s flow:
                source:      a.a.a.a [EXTERNAL]
                dst:         b.b.b.b
                proto:       6
                sport:       35585           dport:      443
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown
                qos node:    ae1.8, qos member N/A Qid 0

        s2c flow:
                source:      j.j.j.j [DMZN]
                dst:         a.a.a.a
                proto:       6
                sport:       443             dport:      35585
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown
                qos node:    ae1.100, qos member N/A Qid 0

        Slot                                 : 1
        DP                                   : 0
        index(local):                        : 2071235
        start time                           : Wed Sep 11 11:39:18 2019
        timeout                              : 15 sec

 

 

 

1 accepted solution

Accepted Solutions

Howdy again

 

So, based on the comments that I will paraphrase....

"server is waiting for database to respond and it seems some sessions never complete and age-out for some reason."  this seems to be an issue between Client and Server communication.  By definiition tcp-fin—One host or both hosts in the connection sent a TCP FIN message to close the session.

 

So, what i am reading/interpreting is that a server is waiting on a DB to respond, and it is not... So if the DB sent the FIN, then it again seems to be a communication issue between the 2 machines, but not caused the the FW.  The FW will do a RST packet, you will see it as a drop or a deny, etc.

 

As I mentioned yesterday INIT means that the session is being closed, resources released, end of session etc.

This happens when the FW logs and end of session.

What I see is a proper TCP-FIN from a client DB machine, and the FW appropriately responds by updating the session browser, showing that the session is done, resources released etc.

 

Take a look my 2 screen captures.  Take note at the time stamp of the first, and notice you do not see it in the second one.

Why, because there is no more session in the session browser.

 

Everything from the FW perspective is as expected.    Why does one of machines (appears to be the DB)  send a FIN? 

 

first.pngsecond.png

Help the community: Like helpful comments and mark solutions

View solution in original post

3 REPLIES 3

Cyber Elite
Cyber Elite

Howdy

 

There could be a few things I see.

 

All of your sessions show INIT as the Session State.

 

Have you seen this connection ever work?  Do you ever see any of the other Session states?

 

Session State Stable / Transient Details

InitStableSession stays in free pool, initial state or is freed and returned to free pool
OpeningTransientSession is allocated from free pool and has yet to be installed into flow lookup table and ager
ActiveStableSession is in flow lookup table and packet matched this flow will be inspected and forwarded
DiscardStableSession is in flow lookup table but set to state DISCARD due to deny rule in security policy, or detected threat, packet matched will be discarded
ClosingTransientSession is set to be expired immediately but has not been removed from aging process nor removed from flow lookup table, packet matched will disregard the match and enqueue to create new session
ClosedTransientSession is expired and removed from aging process, but not from flow lookup table.packet matched will disregard the match and enqueue to create new session
FreeTransientSession has been removed from aging process and flow lookup table, but not returned to free pool

 

 

To answer the question about the 120 secs...

TCP Half Closed
Maximum length of time, in seconds, between receiving the first FIN and receiving the second FIN or a RST (range is 1 to 604,800; default is 120).
 
 

 

Sounds like there is an app/server issue, because the C or the S sends the FIN packets, not the FW.

 

Help the community: Like helpful comments and mark solutions

@SCantwell_IM 

Yes connection works most of the time between these 2. We are seeing stale connections(if that is the right word) on the application side increase gradually. And the suspect are these age-out sessions, as server is waiting for database to respond and it seems some sessions never complete and age-out for some reason. If you see below session is shown as in init state but the end reason is tcp-fin. Woul not that imply that session has succesully completed.

		Session         3305164

        c2s flow:
                source:      x.x.x.x [SERVER2]
                dst:         y.y.y.y
                proto:       6
                sport:       41358           dport:      1521
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown

        s2c flow:
                source:      y.y.y.y [DBASE]
                dst:         x.x.x.x
                proto:       6
                sport:       1521            dport:      41358
                state:       INIT            type:       FLOW
                src user:    unknown
                dst user:    unknown

        Slot                                 : 1
        DP                                   : 0
        index(local):                        : 3305164
        start time                           : Thu Sep 12 14:13:06 2019
        timeout                              : 15 sec
        total byte count(c2s)                : 3951
        total byte count(s2c)                : 5231
        layer7 packet count(c2s)             : 17
        layer7 packet count(s2c)             : 14
        vsys                                 : vsys2
        application                          : oracle
        rule                                 : ORACLE-to-DBASE
        service timeout override(index)      : False
        session to be logged at end          : True
        session in session ager              : False
        session updated by HA peer           : False
        layer7 processing                    : enabled
        URL filtering enabled                : True
        URL category                         : any
        session via prediction               : True
        use parent's policy                  : False
        session via syn-cookies              : False
        session terminated on host           : False
        session traverses tunnel             : False
        captive portal session               : False
        ingress interface                    : ae2.20
        egress interface                     : ae2.21
        session QoS rule                     : N/A (class 4)
        tracker stage firewall               : TCP FIN
        end-reason                           : tcp-fin

Also i noticed cli session ino shows state as init while in GUI the state column shows as active but on expanding that also shows as init.

 

image.png

Howdy again

 

So, based on the comments that I will paraphrase....

"server is waiting for database to respond and it seems some sessions never complete and age-out for some reason."  this seems to be an issue between Client and Server communication.  By definiition tcp-fin—One host or both hosts in the connection sent a TCP FIN message to close the session.

 

So, what i am reading/interpreting is that a server is waiting on a DB to respond, and it is not... So if the DB sent the FIN, then it again seems to be a communication issue between the 2 machines, but not caused the the FW.  The FW will do a RST packet, you will see it as a drop or a deny, etc.

 

As I mentioned yesterday INIT means that the session is being closed, resources released, end of session etc.

This happens when the FW logs and end of session.

What I see is a proper TCP-FIN from a client DB machine, and the FW appropriately responds by updating the session browser, showing that the session is done, resources released etc.

 

Take a look my 2 screen captures.  Take note at the time stamp of the first, and notice you do not see it in the second one.

Why, because there is no more session in the session browser.

 

Everything from the FW perspective is as expected.    Why does one of machines (appears to be the DB)  send a FIN? 

 

first.pngsecond.png

Help the community: Like helpful comments and mark solutions
  • 1 accepted solution
  • 4658 Views
  • 3 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!