Cli shows undecided and GUI shows incomplete

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Cli shows undecided and GUI shows incomplete

Cyber Elite
Cyber Elite

Need to know why CLI and GUI show this behaviour?

MP

Help the community: Like helpful comments and mark solutions.
1 accepted solution

Accepted Solutions

The answers so far have explained reasons for the app to show as Incomplete.

 

If I read it correctly, I think the question is more along the lines of "Why does the CLI show 'undecided' for the application but the GUI shows 'incomplete' for the same session?"

 

The answer to that is based on the state of the session:

- If the session is not yet completed, the application identification may still happen since there's still packet flow, so the firewall shows it as undecided.

- When the session ends, you should see it switch from undecided to incomplete. Since the session's done, there's no chance the app will get identified later. 

 

If you're looking at traffic logs, that session is complete and thus the firewall can definitively state that the application ID never completed.

View solution in original post

11 REPLIES 11

Cyber Elite
Cyber Elite

@MP18,

Because not enough traffic has passed through to actually allow the firewall to do any app-id analyses. Once enough traffic has actually passed they will be updated with the identified app-id. 

Hello,

In my experience, an incomplete usually signifies either a routing issue or the remote server is blocking/not allowing the connection.

 

Regards,

The answers so far have explained reasons for the app to show as Incomplete.

 

If I read it correctly, I think the question is more along the lines of "Why does the CLI show 'undecided' for the application but the GUI shows 'incomplete' for the same session?"

 

The answer to that is based on the state of the session:

- If the session is not yet completed, the application identification may still happen since there's still packet flow, so the firewall shows it as undecided.

- When the session ends, you should see it switch from undecided to incomplete. Since the session's done, there's no chance the app will get identified later. 

 

If you're looking at traffic logs, that session is complete and thus the firewall can definitively state that the application ID never completed.

but in this case we have no routing issue.

As we see send and receive bytes.

MP

Help the community: Like helpful comments and mark solutions.

You got it

Much appreicated.

MP

Help the community: Like helpful comments and mark solutions.

Following up with your response.

This is the issue I'm having with a VM-300 firewall running on an ESXi server.

I have a firewall rule allowing web-browsing, and the client can access the access sites via http, however the app-id is not properly identify in the logs as "web-browisng", it show it as "incomplete".

Why would the firewall not identify the app-id if enough sessions have passed the firewall Data Plane? The HTTP site loads with no issues.

 

Any guidance is appreciated.

Please read answer  from Bry

MP

Help the community: Like helpful comments and mark solutions.

MP18,

 

I just read BPry response, however I'm able to browse the website, which is not encrypted, I open diferent links inside the website, and they load with no issues, but when I check the traffic logs it doesn't identify the traffic as "web-browsing".

 

What I did notice is the FW is not having issue identifying UDP traffic as DNS, or even ICMP traffic. The issue seems to be related to traffic using TCP. I get the same behavior when browsing to HTTPS sites, it shows the app-id as incomplete as well.

I'm using an ESXi host, and a VM-300 with 8.1.3. I'm confused about this app-id behivor. 

Do you think doing a flow basic will reveal where the issue is?

 

Any guidance is appreciated.

give me example of website which you see this behaviour?

normally incomplete means PA do not see enough data to identify the application.

 

Sometimes it is also due to the tcp 3 way handshake did not complete.

MP

Help the community: Like helpful comments and mark solutions.

MP18,

 

Everything is working fine now. After double checking my config, I made a basic network mistake, on the trust interface I added the 172.16.1.2 without the /24 block.  Once I added the subnet the FW  was able to identify all traffic passing thru the interface.

 

I guess since the interface was only able to see limited traffic it wasn't able to make an app-id identification. I noticed a great deal of drop packages with the show  counter global, and other commands. Eiher way I learned a lot with this excercise. 

 

Thanks for taking the time and assist Guys like me.

 

Stay secure all!

Thanks for sharing with us.

We all leran from each other here.

MP

Help the community: Like helpful comments and mark solutions.
  • 1 accepted solution
  • 6978 Views
  • 11 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!