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?
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-finAlso 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.
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?
