Application = insufficient-data?

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Application = insufficient-data?

L2 Linker

We have some outgoing UDP traffic that shows up in the traffic log with "insufficient-data" in the application field. The problem is that this traffic is being allowed through the firewall because it's being matched to a rule that allows FTP traffic through. What does the firewall mean by "insufficient data", and why does it think it's FTP traffic, when FTP uses TCP, not UDP? Any ideas?




Accepted Solutions

L5 Sessionator

"Insufficient data" means that the packet is too small to be identified.  It may be hitting the first rule where the service is set to "any" , which happens to be your ftp allow policy.

View solution in original post


L5 Sessionator

"Insufficient data" means that the packet is too small to be identified.  It may be hitting the first rule where the service is set to "any" , which happens to be your ftp allow policy.


We are seeing this also.  It onlyh appears on an FTP rule.

I think this is misbehaviour on the part of PA, since we are allowing FTP and only FTP, yet if the Application is not determinable PA's logic just passes it anyway?  This behaviour is inappropriate and dangerous.  Why not just drop it?

I want to have that clarified too, please.

When the firewall gets a packets related to any application. The firewall will take 7-14 packets (depending on the applications ) roughly to identify what kind of application. So during these first initial packets the firewall does not what the application is and it is trying to identify the application, as a result these initial packets will show up as insufficient data. But after these packets initial packets the firewall will be able to determine the application and will match the according security rules. Normally you will see these insufficient data packets hitting the first rule on the firewall ( if the rule is blocking/allowing traffic based on applications). Here is the reason for this

For example you have a rule at the top of your rule list as below.

Rule named as "DENY_FB" to deny all the traffic which is of application "facebook".

Now assume now your are sending gmail traffic to the firewall. Since the firewall does not what the application is, it does not what to do with this. This traffic could be facebook or anything else. so it will match the top rule until it identifies the application and during this time it logs this as insufficient data. Once it determines the application it will no longer match the top rule it will match the correct rule.

I understand that but it still doesn't explain what it does with these insufficient-data packets before it is able to identify them. Regarding to my logs, all of these packets are allowed. So whatever rule it hits, those packets are forwarded? Why doesn't it block them until identified? Huge security risk.

Most likely because various protocols ("applications") are similar to other protocols and by that more packets must be let through before the NGFW can make a positive identification (with low false positive rate).

As a start you need at least 2 packets in one direction and 1 in the other just for the tcp handshake to complete.

On top of that identifying a general web-browsing should be fairly easy because the request should look like:


and some other headers.

Thats one of the reasons for why you should never use "service:any" but rather "service:application-default" or even better specify which PROTO/PORT you wish to allow.

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!