Response Page not displayed when using security policy to deny URL category

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

Response Page not displayed when using security policy to deny URL category

L0 Member

Hi There,

 

I have configured a security policy to block a URL category using the Service/URL Category method and my action is deny.

 

This works and the category is denied, however the block response page is not displayed. Instead i get "This site can’t be reached" and "ERR_CONNECTION_RESET".

 

When i block the same category using the URL Filtering Security Profile, the block response page is displayed.

 

This behavior is the same for both encrypted and unencryted pages and also on PAN OS 9.1.7 as well as on 10.0.2.

 

Any idea if this is normal behavior or if this is something that i can fix? 

 

 

Thanks in advance 🙂

 

 

 

Response Page not displayed when using security policy to deny URL category

6 REPLIES 6

L6 Presenter

Can you confirm that you are matching the correct policy that just blocks with the the category, also I think before this rule there should be rules that identify the the app id as web-blowsing or ssl, so check the traffic that the app-id is identified correctly.

 

Please see:

 

 

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/policy/test-policy-rule-traffic-matches.ht...

 

 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClibCAC

 

 

 

 

Can you provide a screenshot of the rule as maybe it also has App ID in the rule and maybe you need "Application Block Page" as this triggered first etc.?

 

 

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-web-interface-help/device/device-response-pages....

Cyber Elite
Cyber Elite

@PerreauLuc,

Assuming that you are attempting to block an HTTPS site, and that you aren't decrypting said traffic which would cause the issue you are describing, this behavior is expected. You would need to following https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFKCA0 to get this functioning. By default, the firewall won't attempt to serve a response page if you aren't decrypting the traffic because it would just lead to a certificate warning. 

L0 Member

Hi all

 

I face the exact same Issue.

I have enabled response pages and tried it with an url category profile using: http://urlfiltering.paloaltonetworks.com/test-malware.

This worked perfectly fine.

 

However: I went on, removed the url profile and added the Service/URL Category "malware", set the rule to deny and I'm presented with a browser message telling me the network connection was interrupted. (no response page)
So either this is by design / technical limitation or it's a bug.

 

PA-220, 10.2.2

find my rule below

MKoehler_0-1666690143359.png

 

I am seeing the same behavior. PA-3250 10.2.3

L6 Presenter

To me it would seem to be operating as designed and expected behavior.

 

With a Security Policy you select targets by some combination of IP, zone, user, service, and/or URL(SNI); and running a deny action you are sending a TCP or UDP reset to the endpoint. It doesn't matter or necessarily operate on HTTP/HTTPS. Therefore the browser just gets a connection closed message, no actual content response.

 

With URL Filtering you are filtering content inside the HTTP/HTTPS connection. So when a block happens you are interrupting the content stream and can return a different content page, vs. just terminating the network connection. 

L4 Transporter

I also have same issue. For https website Iam not getting the response page. Any solution?

 

  • 11535 Views
  • 6 replies
  • 0 Likes
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!