Firewall lets the initial HTTP GET/POST request through even if URL filtering is configured

• After the TCP 3-way handshake, HTTP GET/POST request is sent out of the firewall intermittently for websites falling under Block Categories.
• Per the URL Filtering logs, it shows the URL was blocked.
   

• Security Policy configured based on service tcp/80 and tcp/443 with URL Filtering Policy applied.
• Required Categories are set to block

1. Firewall allows TCP 3-way handshake.
2. GET/POST request received on the Firewall.
3. If the firewall does not have a category for the URL in DP, the GET/POST packet request is allowed to go through while the firewall is still trying to resolve the URL category.
4. By the time server responds, the firewall already has the category, and the response is blocked, and block response page is served to the user.

• This behavior is by design; however, customers can configure 'hold-client-request' to block the request until Advanced URL Filtering either finds the URL category or times out. More details can be found in the below doc:
  https://docs.paloaltonetworks.com/advanced-url-filtering/administration/configuring-url-filtering/url-filtering-best-practices
• Here's what happens if hold-client-request is set to "yes":
  • If the URL category is not available, the first packet is *not* transmitted to the server. (This is different from 8.1, where the first packet is always transmitted to the server, even if the URL category is not available). 
  • All subsequent packets (client or server) are held in DP, i.e., not transmitted from the firewall until URL categorization for the first packet is received and the processing of the first packet is completed and transmitted out.
• Command to set the hold-client-request from CLI:
  

  set deviceconfig setting ctd hold-client-request <yes/no>

   

Please refer to the below KB article for more details:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PPjOCAW