About acc6d0b3610eec313831f7900fdbd235

Correct, you need to first get a copy of your Root CA and Intermediate CA. The Intermediate CA is not actually mandatory unless you have one. Then click in the Import button. Map to each one of the certificates, and click in OK. It will upload, and if everything is correct the certificate chain should be formed with no problems. ... View more

Hi @Farzana In order to fix this issue, you need to upload a copy of your Root CA and and Intermediate CA to the firewall.   This should fix the issue.   ... View more

@OMatlock I agree with @Brandon_Wertz 's comment.   Unfortunately, you cannot configure the HA to only alert with no failover action, which in my opinion makes sense, because the whole idea of having an HA is to avoid traffic interruption in case one of the devices in the HA pair fails. The way you are describing what you intend to achieve, you want some sort of cold standby where a failover is performed manually if you understand it as necessary.   From a link monitoring perpsective if you only care about the physical connectivity such as cable being pulled or similar event, that's ok although most administrators would like to have physical and logial monitoring, in case either one of those go wrong.   From a monitoring perspective, as @Brandon_Wertz mentioned, your best bet is a NMS tool like Solarwinds, but it will only provide you the alert, and not take any action, which means that if you don't configure the HA to failover, your users will have no access until you manually perform a failover, so my recommendation is that you configure the HA for automatic failover between the pair and use link monitoring and and monitoring group.   Finally, in order to avoid unecessary failovers, I would include in the Link Monitoring and Monitoring Group only the physical interfaces and IP addresses that are critical to me. Meaning, only the components that I really care about having a failover event triggered. For example, if you don't want a failover to be triggered because your 3rd party is down, then I would suggest to not include the interface supporting them in any of the Link Monitoring or Monitoring Group.   I hope it makes sense. My two cents.     ... View more

@LucaMarchiori Because most search engines encrypt their search results, you must enable SSL forward proxy decryption so that the firewall can inspect the search traffic and detect the safe search settings.   https://www.paloaltonetworks.com/documentation/60/pan-os/newfeaturesguide/content-inspection-features/url-filtering-safe-search-enforcement https://www.paloaltonetworks.com/documentation/61/pan-os/pan-os/url-filtering/safe-search-enforcement.html https://researchcenter.paloaltonetworks.com/2015/01/firewall-pro-tip-enforce-safe-search-without-blocking-search-results/   I don't think DNS Proxy will resolve this challenge for you, at least not based on my own experience.   I hope this helps. ... View more

@dan731028 I would say so. Try to remove the entire chain and re-adding it. In my experience, this was the only thing that caused this type of error to occur.  ... View more

Ok Got it. So, there are two ways you can do this, the first way is by creating a Custom URL Category, and then setting that to block inside your URL filtering profile. The second way, would be to add the URLs you want to block to the Block List inside your existing URL filtering profile.   First Example - Custom URL Category: Step 1:                                       Step 2:                               Second Example - URL Filtering Block List                       One important thing to note in the above example, is that if you specify for example www.yahoo.com/ it means that anything added after "/" will also be a match, and hence will be blocked. In this situation it is not a wildcard block, but specific blocks. Now if you want to block anything related to the domains themselves, then yu have to use something like *.yahoo.com, so anything that matches the domain will be blocked completed, but you still have to use one of the methods I have described above.   I hope this helps.   Willian ... View more

Hi @OMatlock   As you already know, the failover action can be based on failure of ANY link or path, or ALL failures of the links or paths defined within the group. In the link monitoring example shown below, a Link Group is defined to monitor the critical links that make up the WAN, data center, and critical end user networks.   In your example, with both interfaces e1/1 and 1/2 belonging to the same Link monitoring group, and the condition set to "ANY", it means the either one of the links that fails, will trigger a failover condition. Now if you set the condition to "ALL", a failover condition will only be triggered if both e1/1 and e1/2 fail concurrently.       A quick question for you: What are e1/1 and e1/2 used for respectively? i.e e1/1 --> Untrust and e1/2 --> Trust?   There is also a design question to be analyzed such as: Do you have single or multiple ISPs in place?   https://live.paloaltonetworks.com/twzvq79624/attachments/twzvq79624/documentation_tkb/543/2/HA_Failover_Optimization-RevC.pdf   I'll wait for your answer to my question below, then I can elaborate a little bit more from a logical design perspective.   Thank you   Willian   ... View more

Hi @Bin Just a quick question. When you say "Block all URLs", can you clarify exactly what you mean?   When using wildcards in the URLs, you must follow these rules:   Do not include HTTP and HTTPS when defining URLs. For example, enter www.acme.com or acme.com instead of https://www.acme.com. Entries in the block list must be an exact match and are case-insensitive. For example: If you want to prevent a user from accessing any website within the domain acme.com, you would also add *.acme.com   These additional two articles may be of help to you URL Filtering -Block and Allow Lists https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/url-filtering/block-and-allow-lists   DotW: URL Wildcard Pattern https://live.paloaltonetworks.com/t5/Featured-Articles/DotW-URL-Wildcard-Pattern/ta-p/136449   I hope this helps.   Willian ... View more

Hi @dan731028 I faced this problem a few times in the past, and in my particular case it was associated with the certificate chain I was using for GlobalProtect. For example: If I only upload the certificate but not the Root and Intermediate certificate, Panorama returns this error although it does not actually indicate that it is the issue. So, I wanted to ask if you have uploaded any certificates to Panorama or to one of your templates, that do not have the root or intermediate certs chained.   Willian ... View more

Hi @pulukas Yes the firewall sub-interface ae2.4010 has an IP address assigned. That was my expectation based on all the implementations I have done, I never had to add a static route to a subnet to which the firewall is directly connected. The firewall is in full Layer 3. All other sub-interfaces, are working just fine and I did not have to add static routes for those. ... View more

Hi @OMatlock   Here are a few tips from the field that may be of assistance to you.   Control Link (HA1) Monitor Hold Time To monitor the health of the Primary HA1 interface, an additional “Monitor Hold Time” timer is used to detect a failed Primary HA1 condition. If three heartbeats or hello messages are missed between the HA devices, the HA1 Monitor Hold Time will be consulted to determine the amount of time the HA device should wait before declaring a failed Primary HA 1 connection. The default is 3000 ms. Once a failed Primary HA1 condition has occurred, the units will log the appropriate information into the system logs and failover to the Backup HA1 or Management interface—depending on how the HA1 backup is configured. Recommendation: If you have a Backup HA1 interface configured, lowering this value will allow a faster failover to the backup HA1 links. Leaving the value at the default of 3000 ms is recommended for most HA implementations. The range for the HA1 Monitor Hold Time is 1000 to 60000 ms. I personally cut this time in half and put 1500 ms instead.   Passive Link State Auto Configuration (A/P) An important fact to consider when designing an Active/Passive HA architecture is the traffic forwarding links on the passive device defaults to a “Shutdown” state. In the shutdown state, upstream and downstream devices connected to the passive device will not see a valid path until the passive firewall becomes active. The Passive Link State Auto Configuration feature allows you to bring up the passive device’s traffic forwarding links to reduce the failover time. It does this by bringing the interfaces on the firewall to a “link up” state, but blocks inbound and outbound traffic to the interfaces until the passive unit becomes active. This helps to reduce failover times by eliminating the need to go through port learning and negotiation phases right after a failover to the passive device and can reduce failover times by approximately one to two seconds. The Passive Link State Auto Configuration setting is enabled under Device > High Availability > Election Settings. The Passive Link State defaults to “Shutdown” and should be set to “Auto” to facilitate faster failover times and to force the link status of the neighboring devices to be in the “link up” state. When the Passive Link State is set to “Auto”, the HA device in the “passive” state will not forward traffic or respond to ARP requests. I like this option, because we are able to avoid the gratuitous ARP delay with up and downstream devices.   If you set the passive link state to "Shutdown", you will notice that the standby appliance will have all its ports in in shutdown state; hence, delaying the failover due to the ARP responses.   For more details, refer to the following link: https://live.paloaltonetworks.com/twzvq79624/attachments/twzvq79624/documentation_tkb/543/2/HA_Failover_Optimization-RevC.pdf   As for your DNAT rules, the only advise I always give to my clients is to ensure that they do not have Proxy-ARP configured in the upstream switch or router. If they do, I always advise to either change it accordingly a few minutes prior to the cutover start time and then clear the MAC address table, or in some cases completely remove it if at all possible. In some cases because the upstream switch or router is not managed by the client, they will need to open a case with their ISP, which may delay your cutover window, so, having this figured out beforehand is always best practice.   Another advise as well, is to open a proactive case with Palo Alto eTAC support, informing basic details of the activity that you will be performing. This helps to speed up support if you call out of the blue because you are having issues or questions, so you don't have to explain things from the very beginning. That was an advise from one of the Palo Alto SEs in my region, and I have been very successful in doing so. Of course in 90% of the time you never even ended up calling them, but better safe than sorry.   I hope it helps.   Willian ... View more

Hey @Alex_Samad     Just one observation. Have you committed the changes to Panorama after adding the devices to Managed Devices?   If not, I advise you to do that, as adding devices is considered a Panorama change; hence, needs a commit to the Panorama level to take effect.   After that, try the import process again, and you should be able to see the devices listed there.   Just one comment, I typically add devices to Panorama, and then do most of the network and device configurations through the templates, so it is easy to control. I then create a device group, and add all my policies into it, and then push everything templates and device group changes to the appliance from Panorama. This way I don't need to import the firewall after into the management center.   If these are existing firewalls that have never been managed via Panorama, then yes, the process you are mentioning makes a lot of sense.   https://www.paloaltonetworks.com/documentation/70/pan-os/newfeaturesguide/panorama-features/firewall-configuration-import-into-panorama ... View more