1. Incomplete
The incomplete application value generally indicates that the firewall did not observe a complete TCP three-way handshake or that the connection ended without sufficient application data for identification.
Example:
-
Client sends a TCP SYN.
-
Firewall creates a session.
-
Server does not respond with SYN-ACK.
-
Session eventually times out.
-
Traffic log displays incomplete.
Possible causes include network connectivity issues, server unavailability, asymmetric routing, or dropped handshake packets.
2. Insufficient-Data
The insufficient-data application value indicates that the firewall observed some application payload but did not receive sufficient information to identify the application conclusively.
Example:
-
TCP three-way handshake completes.
-
Client sends a small amount of application data.
-
The connection terminates before App-ID can identify the application.
-
Traffic log displays insufficient-data.
This can occur with short-lived connections, keepalive traffic, or prematurely terminated application sessions.
3. Unknown-TCP
The unknown-tcp application value indicates that App-ID could not match the observed TCP traffic to a known application.
Possible causes include:
-
Proprietary or custom applications
-
Unsupported application protocols
-
Application payloads that do not match available signatures
-
Unusual or nonstandard protocol behavior
Unlike insufficient-data, unknown-tcp may indicate that the firewall observed traffic but could not recognize its application characteristics.
4. Unknown-UDP
The unknown-udp application value indicates that the firewall could not identify the application associated with UDP traffic.
Because UDP does not use a TCP-style three-way handshake, application identification depends on the observed protocol characteristics, payload, and available signatures.
Possible causes include proprietary UDP protocols, unrecognized payloads, and unsupported applications.
5. Unknown-P2P
The unknown-p2p application value indicates traffic matching generic peer-to-peer detection heuristics without identifying a specific P2P application.
Further investigation may be necessary to determine the actual application.
6. Not-Applicable
The not-applicable application value indicates that application identification was not applicable to the traffic being logged.
This is commonly observed when traffic is denied or dropped before sufficient application identification can occur.
For example, a security policy may deny traffic based on source, destination, protocol, or service before the firewall receives application payload.
Important: A security policy denial does not necessarily result in not-applicable in every scenario. The application field depends on the information available when the traffic is processed and logged.
Troubleshooting
Step 1: Review Traffic Logs
Navigate to:
Monitor > Logs > Traffic
Examine the following fields:
-
Application
-
Action
-
Rule
-
Session End Reason
-
Source and Destination IP
-
Source and Destination Port
-
Bytes Sent and Received
-
Packets Sent and Received
Step 2: Inspect the Firewall Session
Use the CLI:
show session all filter source <source-ip>
show session all filter destination <destination-ip>
show session id <session-id>
Review session state, application identification, policy rule, and packet counters.
Step 3: Verify TCP Connectivity
Capture packets on the firewall and check:
-
Whether SYN, SYN-ACK, and ACK are observed
-
Whether application payload is exchanged
-
Whether TCP RST or FIN packets terminate the connection
-
Whether packets are missing in either direction
Step 4: Investigate Unknown Applications
For persistent unknown-tcp or unknown-udp traffic:
-
Verify that Applications and Threats content is current.
-
Capture representative application traffic.
-
Analyze the protocol and payload using Wireshark.
-
Check whether a supported App-ID already exists.
-
Consider creating a custom App-ID signature if the application is proprietary and you can develop a suitable signature.
Additional Information
Application identification and security policy enforcement are related but separate processes.
The application value alone does not establish why a session was denied, dropped, reset, or aged out.
Always correlate the Application field with the Action, Rule, Session End Reason, and packet capture evidence before determining the root cause.