Very good article indeed...
based on the following
Date and time of the messageMessage type (session-init or session-close)Source address and port numberDestination address and port numberIP informationSession index (sid)Policy index (pid)Bytes sent and receivedSession duration
Is it possible to segregate session-init / session-close from deny and permit policies?
Based on this output... it wouldn't seem as if it isnt but IMA newb so...
It would be nice to seperate the two into two files, one for policy default-permit, and one for policy default-deny scenarios.
user@host> show log messages | match RT_FLOW_SESSION
Dec 23 15:01:41 test RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP RST: 19
2.168.10.60/3933->172.24.60.143/80 junos-http 172.24.30.178/8280->172.24.60.143/
80 interface-nat None 6 http-out trust untrust 7188 8(2698) 5(525) 2
EDIT: I acutally found that this is pretty easy as the RT_FLOW_SESSION_DENY is the flag for a policy that is defined as a deny / log... Just not the implicit deny at the end of all policy chains.