About pulukas

Can you confirm that "rematch sessions" is checked and remove it if it is? I do think this is the issue.  With rematch we clear all your current sessions and force the new policy set to apply immediately.  With sip we are then losing this connection to the original session that the ALG maintains. Without rematch all your current SIP sessions are untouched and will end naturally with session completion. ... View more

The important note here is that incomplete and insufficient sessions are permitted when you use this type of rule construction. So once we want to identify and block by application we do have to accept that short packet counts before the application is identified will be permitted. the only question is where will those sessions log.  You cannot drop them before identification. In the case you outline now the PA is using the first match logic to log the traffic.  As we look at the rule set they are processed from top down and first match stops processing.  So using this logic PA is logging your incomplete/insufficient data sessions are hitting the application based rule. ... View more

It sounds like what you are running into is session rematch on commit.  I am pretty sure this is the default setting and it sounds like you would prefer to turn this off. Device tab > Setup > Session sub tab Uncheck "Rematch Sessions" What this setting does is force all sessions to be evaluated again when the security policy is changed.  For complex sessions in progress (like sip) you can see the behavior you describe. The advantage of having this session is slightly higher security.  Whenever policies are changes all sessions are immediately checked again so any in progress session that would no longer be permitted is stopped right away instead of allowing it to play out to the natural conclusion of the session. ... View more

URL filtering is strictly based on the url content.  So you would also need to add the ip address as a url. For ip based black lists we usually maintain a security rule at the top of the rulebase to stop the current bad ip list and country blocks as more efficient for this than the url filter. ... View more

Another possibility is they disagree with your reclassification request.  If the issue is important or urgent you can open a case to get more specific answers. ... View more

In both cases the incomplete sessions are allowed through the firewall the the question from the PA logging engine is where to mark those sessions in the logs. In the first case, you clearly cannot log them with rule 2 because this is a final deny all policy, and we allowed the packets so they must log on rule 1. In the second case we have a final permit all policy.  So there is a clear match of permit for these incomplete sessions and no need to show that the application block rule is permitting the traffic.  This traffic is allowed by rule 2 even if the application block rule did not exist.  So we log the sessions on rule 2 as a better match. The important note here is that application based rules are not as instantaneous as port based rules.  There needs to be some actual packet data to determine the application match that may take some time to occur.  As a result application based block rules do permit small amounts of packets on the flow before stopping the traffic once correctly identified.  The PA logging is set up to give you visibility to these permitted partial flows in the rules. ... View more

The changes sound correct.  Have you  committed the changes on both Panorama and the device? ... View more

Also confirm that the security policies permit the download as outlined here. PAN-DB Error: URL Database Download Failed ... View more

Have a look at the Packet Flow process chart in this document. Packet Flow in PAN-OS The App Cache is a short cut to preliminarily identify a connection as an application prior to getting that identification from the actual packet content inspection match.  This verdict can be updated by the actual stream as the session develops as seen in the flow check.  Anything logged as unknown and incomplete has not be identified by any engine as of the end of the session. With application identification on random port services like bittorrent really do have no choice but to behave in this fashion.  The PA must see enough of the traffic to positively identify the traffic.  So these initial few packet streams must be allowed until the bittorrent can be identified and the session dropped. ... View more

These sessions are potential matches for the block torrent rule so the PA must keep track of them until the application is confirmed as torrent or not. If they do become recognized as torrent they will drop at that point.  But all the previous packets until classified as torrent were permitted. In your case the sessions ended before classification as any application could occur so they are logged as unknown or incomplete ended sessions. ... View more

I'm not familiar with the Cisco implementation.  But I think you are referring to configuration of administrative distance to create preferences for links.  You can verify how these are seen by the Palo Alto with the commands in this tech note. Verifying Equal Cost Paths in OSPF General OSPF setup instructions How to Configure OSPF ... View more

I think the best place to start for this type of report is Monitor tab > botnet report. ... View more