Why do Sessions Show Application "Undecided" When in ACTIVE State but have an App When Moved to DISCARD State?
49769
Created On 03/30/19 02:33 AM - Last Modified 12/04/24 09:22 AM
Question
Why do some sessions show the application as "undecided" when they are in an ACTIVE state but show an application after moving to the DISCARD state?
Environment
In certain instances, you might see that the sessions show up as "undecided" when the session state is ACTIVE. Then, they later show up with an application name.
Here's an example of when the session is in the ACTIVE STATE:
> show session id 74569901 Session 74569901 c2s flow: source: 10.1.1.1 [Internal_Clients] dst: 192.168.1.1 proto: 6 sport: 28156 dport: 80 state: ACTIVE type: FLOW src user: unknown dst user: unknown s2c flow: source: 192.168.1.1 [Internal_Servers] dst: 10.1.1.1 proto: 6 sport: 80 dport: 28156 state: ACTIVE type: FLOW src user: unknown dst user: unknown Slot : 1 DP : 2 index(local): : 7461037 start time : Wed Jul 18 09:39:00 2018 timeout : 90 sec time to live : 6 sec total byte count(c2s) : 1238 total byte count(s2c) : 144 layer7 packet count(c2s) : 3 layer7 packet count(s2c) : 2 vsys : vsys3 application : undecided <<<<<
Once the session has moved into the DISCARD state:
> show session id 74569901 Session 74569901 c2s flow: source: 10.1.1.1 [Internal_Clients] dst: 192.168.1.1 proto: 6 sport: 28156 dport: 80 state: DISCARD type: FLOW src user: unknown dst user: unknown offload: Yes s2c flow: source: 192.168.1.1 [Internal_Servers] dst: 10.1.1.1 proto: 6 sport: 80 dport: 28156 state: DISCARD type: FLOW src user: unknown dst user: unknown offload: Yes Slot : 1 DP : 2 index(local): : 7461037 start time : Wed Jul 18 09:39:00 2018 timeout : 90 sec time to live : 6 sec total byte count(c2s) : 1238 total byte count(s2c) : 144 layer7 packet count(c2s) : 3 layer7 packet count(s2c) : 2 vsys : vsys3 application : web-browsing
Answer
In these cases, we need to first figure out why the session went into the discard state.
If the application is being blocked by the security policy, this is expected behavior as long. As App-ID is unable to determine the exact application, a session may be allowed through the firewall as undecided until the application is identified, at which time the security rules are re-evaluated and an appropriate action is taken, which could be to discard the session.
> show session id 74569901 Session 74569901 c2s flow: source: 10.1.1.1 [Internal_Clients] dst: 192.168.1.1 proto: 6 sport: 28156 dport: 80 state: DISCARD type: FLOW src user: unknown dst user: unknown offload: Yes s2c flow: source: 192.168.1.1 [Internal_Servers] dst: 10.1.1.1 proto: 6 sport: 80 dport: 28156 state: DISCARD type: FLOW src user: unknown dst user: unknown offload: Yes Slot : 1 DP : 2 index(local): : 7461037 start time : Wed Jul 18 09:39:00 2018 ****cut for brevity**** session QoS rule : N/A (class 4) tracker stage firewall : appid policy lookup deny end-reason : policy-deny
Another cause could be resource contention.
When the system is taxed to the point that there are not enough resources to complete App-ID, before ending Layer-7 inspection, the firewall does an App-ID lookup, which uses port based information, but this may not be an accurate application identified.
The "tracker stage firewall" will identify if the session ended due to resource contention.
> show session id 74569901
Session 74569901
c2s flow:
source: 10.1.1.1 [Internal_Clients]
dst: 192.168.1.1
proto: 6
sport: 28156 dport: 80
state: DISCARD type: FLOW
src user: unknown
dst user: unknown
offload: Yes
s2c flow:
source: 192.168.1.1 [Internal_Servers]
dst: 10.1.1.1
proto: 6
sport: 80 dport: 28156
state: DISCARD type: FLOW
src user: unknown
dst user: unknown
offload: Yes
Slot : 1
DP : 2
index(local): : 7461037
start time : Wed Jul 18 09:39:00 2018
****cut for brevity****
session QoS rule : N/A (class 4)
tracker stage firewall : resource limit <<<<<<<<<<<<
tracker stage l7proc : appid bypass