About PavelK

Hello @lakshmipathimurugan   thank you for the post.   The behavior you described is expected. The below KBs describe what URL category "any" means:   https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008UP1CAM&lang=en_US%E2%80%A9&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm08CAC   If your ultimate goal is to block Facebook, then I would create 2 security policies. One policy to block application: facebook-base and another to block URL category: social-networking. In this way either of the policy will be hit to deny Facebook related traffic regardless it is detected as application or URL category.   With your current policy: "Block Streaming Media-App Based" the issue I am seeing, to block this traffic, Firewall has to decode application as "facebook-base" and have enough information to categorize URL category as "social-networking". If Firewall can't categorize URL category, this policy will not be hit.   If your goal is to go more granular and block only some of the Facebook application, you will have to enable decryption.   Kind Regards Pavel ... View more

Hello @Sujanya   thank you for the post!   From this error, it looks like that HA configuration in Template is incomplete. Either HA1 or HA2 links do not have assigned interface. I would recommend to go through Template configuration and review HA part.   Kind Regards Pavel ... View more

Hello @m.hughes1   thank you for the post!   Exporting configuration from PA-3050 and importing it to PA-5220 will most likely fail because of interface, hw differences. The workaround would be to export configurations from both Firewalls, then manually edit XML file from PA-3050 to match format of PA-5220, then import it to PA-5220. Since you mentioned that existing PA-3050 is managed by Panorama and new Firewall that will be replacement will also be managed by Panorama, you do not have to configure anything locally except of basic configuration to bring Firewall online to be registered in Panorama. Basically instead of importing configuration, you can push all configuration from Panorama's Device Group and Template Stack.   Regarding Panorama part, since existing Firewall and new one have the same function and configuration, I would personally recommend to clone existing, Template Stack, then edit it to accommodate configuration differences in HA and interfaces in new template. Regarding Device Group, I do not see any reason why not to place new Firewall into the same Device Group as existing Firewall.   As a next step, I would push the configuration from Panorama to PA-5220 while keeping all cables except of HA and management disconnected to prevent IP address duplication. On the day of migration, I would disconnect PA-3050 and cable PA-5220 to bring it online and complete Firewall migration.   As a final step, I would remove PA-3050 from Panorama and cleaned up unused configuration.   If I misinterpreted any part of your question or you would like to deep dive, do not hesitate to reply and ask. Such kind of migration is hard to tackle in a single reply.   Kind Regards Pavel ... View more

Hello @Carson1998   thank you for the post!   I am not sure whether it is just me, however I do not see any screen shots. Would you mind uploading them again? Also, you should aim at least for PAN-OS 9.1 for upgrade as 9.0 is EoL.   Kind Regards Pavel ... View more

Hello @Greg_Majersky   thank you for the post!   If you mean newly registered domains (NRD) / DGA, then PAN-DB has a URL filtering category called: "newly-registered-domain". You can set the action to block to block these URLs.   If you have DNS Security subscription, then you can block these domains as well: https://live.paloaltonetworks.com/t5/blogs/new-strategically-aged-domain-detection-for-dns-security/ba-p/459627   If you are referring to different URL categories or different case, could you please share more details about issue you are facing? Ideally, if you can share a few samples of these URLs.   Kind Regards Pavel ... View more

Thank you for reply @ElliotM   Yes, this is my understanding. It is possible to set regular data plane interfaces to HA type and add it to HA Link Monitoring, however based on my tests shutting this interface down does not trigger a failover. I was testing it with PA-220 where I used interfaces 1/7 and 1/8 for HA.   Kind Regards Pavel ... View more

Hello @hchoi871101   the video you referred to is covering Firewall part of the configuration. You still have to configure Panorama side.   Make sure, you set up log collector. If you have not done it, please refer to this documetation: https://docs.paloaltonetworks.com/panorama/10-1/panorama-admin/manage-log-collection/manage-collector-groups/configure-a-collector-group   Make sure that Firewall is assigned to log collector group. Navigate to: Panorama > Collector Groups > [Collector Group Name] > Device Log Forwarding > Devices > Modify > Then add Firewall and click ok. After you complete this change, commit to Panorama and also push this to collector group by going to: Commit > Push to devices > Edit > Collect Groups > Select Collector Group and click OK.    After these steps, you will be able to see all the logs that Firewall is sending under Monitor > Logs.   In the case, you still not see logs, make sure that both Firewall and Panorama have the same time / time zone set.   Kind Regards Pavel ... View more

Hello @ElliotM   If one of the interface that is configured for HA goes down, it will not cause failover event because these interfaces are not tracked, however as a best practice you should have a backup link for HA1 as well as for HA2 interfaces.   If HA1 interface goes down without HA1 backup to be configured, it might cause split brain when both Firewalls go into active state: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000004OPJCA2&lang=en_US%E2%80%A9   If HA2 interface goes down without HA2 backup to be configured, the state information between Firewalls will not be in sync.   Here is HA Best Practice KB: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm5ZCAS   If you want to exempt an interface from failover tracking, I would remove it from link interface monitoring.   Kind Regards Pavel ... View more

Thank you for reply @JoHyeonJae   I can't answer this with certainty. In any case, I would recommend to upgrade PAN-OS to the version that has this fix or newer, then observe this issue again. The symptom of this bug is random log loss while sending logs to 3rd party system causing difference in logs between Firewall and 3rd party SIEM. If you are hitting serios syslog drop count after reaching certain log rate, then the issue might be something else. Opening a ticket to support might be appropriate in this case.   Kind Regards Pavel   ... View more

Thank you for reply @JoHyeonJae   this fix is applied to sending queue which is processing all the logs irrespectively what policy has generated it.   Kind Regards Pavel ... View more

Thank you for reply @Doyenadmin   The MTU issue is there regardless you apply permit access list or not. When the permit access list is not applied, it is masking the issue. What I think is happening is as follows: The initial TCP 3 way handshake initiated by your PC is completed. These packets are small and do not carry any data, then your PC send SSL client Hello and Firewall replies with Server hello. The packet size is large as it contains all SSL related information. The size of this packet is exceeding MTU between Firewall and your PC while the DF bit is set. The node that is dropping this packet is sending back to Firewall ICMP Type 3 Code 4 to lower MTU using its own interface IP address as a source and this is part where the issue with permitted IP addresses comes in. The Firewall accepts only source IP addresses that you allow and intermediate node that is asking for lowering MTU is not in the permitted IP address list. In nutshell, if you knew the IP address of this node and put it in the permit list, then you would not have to lower MTU. With the list in place, this is breaking PMTU Discovery. This kind of issue is typically something with ISP that is out of your control.   Kind Regards Pavel  ... View more

Hello @Katakuri2025   thanks for the post.   From my point of view in modern network the concept of port security is obsolete regardless you have Prisma Access deployed or not. Port security has many limitations from management as well as scalability point of view. Regular 802.1X or MAB authentication would be better alternative unless there is some limitation from end point preventing you to use it, then port security would be last resort. If you have already deployed Prisma Access with features you described, then with adoption of this concept even 802.1X could go away unless you are in strictly regulated business.   Kind Regards Pavel     ... View more