- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
06-02-2016 10:52 AM
I have a rule matching for ms-update app-id, but when looking at logs I see sessions hitting the rule that have an imcomplete application.
How is this possible?
06-03-2016 12:14 AM
a single session will actually go through the security policy twice
When a new session is initiated, the SYN packet does not contain a lot of information that can be used for AppID, so it will be parsed against the security policy based on the 5 tuples: source zone, source subnet, destination zone, destination subnet, destination port
in the security policy the configured applications will be ignored in this stage (as we don't know the app yet) and sessions wil be matched based on the destination port (this is why setting 'application-default' in the service is important!)
if a rule is matched that allows the 5 tuples, the handshake is allowed through and a session is created in the session table
if then after the handshake nothing happens, the session will timeout and be discarded, the application will be set as incomplete because it never continued.
however, because the session was created, we still want to have a log entry in the traffic log to indicate the session was there, but because it never managed to reach the next stage where AppID could be applied, it was never matched against a different policy so it will be logged as a hit on the first policy that simply let the session be created
hope this makes sense
Tom
06-03-2016 12:12 AM
hi bdugger,
That behavior is explained in this article :
Not-Applicable-Incomplete-Insufficient-Data-in-the-Application
Incomplete means that either the three-way TCP handshake did not complete or the three-way TCP handshake did complete but there was no data after the handshake to identify the application.
06-03-2016 12:14 AM
a single session will actually go through the security policy twice
When a new session is initiated, the SYN packet does not contain a lot of information that can be used for AppID, so it will be parsed against the security policy based on the 5 tuples: source zone, source subnet, destination zone, destination subnet, destination port
in the security policy the configured applications will be ignored in this stage (as we don't know the app yet) and sessions wil be matched based on the destination port (this is why setting 'application-default' in the service is important!)
if a rule is matched that allows the 5 tuples, the handshake is allowed through and a session is created in the session table
if then after the handshake nothing happens, the session will timeout and be discarded, the application will be set as incomplete because it never continued.
however, because the session was created, we still want to have a log entry in the traffic log to indicate the session was there, but because it never managed to reach the next stage where AppID could be applied, it was never matched against a different policy so it will be logged as a hit on the first policy that simply let the session be created
hope this makes sense
Tom
06-03-2016 07:21 AM
Thanks for the quick response Tom!
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!