palo alto block page not showing

[inderjit21]

Running panos 10.1.8 on vm-300.

a blocked https page gives user -This site cannot be reached rather than palo block page notification.

Is this because ssl decrytpion is not enabled and is required to get block page notification for https url which are supposed to 

be blocked via url filtering.

[BPry]

@inderjit21,

Correct, the response page won't be serviced unless you're decrypting the traffic by default. You can override this setting by running the following command without setting up decryption.

set deviceconfig setting ssl-decrypt url-proxy yes

Keep in mind that this will only work if you aren't in a vwire deployment, ssl decryption is an absolute requirement for that configuration. Keep in mind that your clients will receive an invalid certificate warning unless you take the time to setup a proper Forward Trust certificate to allow the response page to actually be trusted by the clients. 

[YuvalBenAri]

I have SSL decryption setup and working, and also enabled the above command and Response Pages on the interface mgmt profile, but stil receiving ERR_CONNECTION_RESET when going to an https:// URL that has continue action.

Anything else that I'm missing?

[aleksandar.astardzhiev]

Hi  @YuvalBenAri 

You don't need interface mgmt profile with response page for URL Block Page to be presented. Response page in interface mgmt is for captive portal and authentication policies.

Regarding block page:

- Can you confirm that the domain is not blocked  by DNS Security with Anti-Spyware  profile?

-  Can you confirm that URL filtering profile is taking action - is there URL log for that traffic and what is the action in the log?

- Can category/url is causing you issues? Does it some internal domain or private IP?

[YuvalBenAri]

Hi @aleksandar.astardzhiev 

I was following this KB. Which requires to enable response pages on interface.

- It is not blocked.

- Yes. I can see it in URL log as block-continue

- It’s a public domain. chat.openai.com

[aleksandar.astardzhiev]

Hi @YuvalBenAri 

That is interesting... I believe the KB is misleading, in admin docs you can see that response page is for captive portal...ok and admin URL override.

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/networking/configure-interfaces/use-interf...

I can tell for sure that URL block page works without response page on interface mgmt profile as this is how it works for us.

One small details - you said the action is block-continue, this seems like small different from block page, but actually it works differently.

- Block page: As mentioned in the KB you followed, FW will "inject" the block page in response to the user HTTP get request. Which means that the URL in user web browser will remain to the same address that user has entered, but instead of the actual content FW will reply with the block page

- Block-continue: As you can see from the following link, in this case firewall replies with HTTP redirect and redirects the user to its interface, where it will serve the block-continue message and provide the option to the user to continue with his request

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

What could be happening is that firewall is not allowing users to connect to the interface which tries to server the block-continue page. As this traffic will be from the users to the interface pointing to the user, this traffic is considered intra-zone and it should be allowed by the default intra-zone rule, but if you have any deny rules that override it, this could explain the problem.

- Check if users are allowed to reach firewall internal interface

- Open dev tools in your browser, go to network tab (enable persist logs) and try to open the blocked url again. Do you see the 302 redirect? What is the url that is returning connection reset?

- Try to change the action for domain to block and see if will see the block page (use ctr+shift+r to ignore page cache)

[YuvalBenAri]

Hi,

I cannot find any block in logs.

I took packet capture and I am getting a TCP/reset from the firewall following the initial GET request. There is no redirect returned at all.

I currently have a TAC case to investigate this.

Thanks

[aleksandar.astardzhiev]

Hi @YuvalBenAri ,

Try to check with global counters what could be the reason for the TCP RST.

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

Follow the steps in the link to create filter for the firewall IP (that is returning the RST).

- First set the filter

- Second run the global counter with delta and least twice so the output to be empty

- Reproduce the issue

- Run global counter with delta again

- Share the output here.

[YuvalBenAri]

name                                   value     rate severity  category  aspect    description
--------------------------------------------------------------------------------
flow_action_close                          4        1 drop      flow      pktproc   TCP sessions closed via injecting RST
--------------------------------------------------------------------------------
Total counters shown: 1
--------------------------------------------------------------------------------

I realized it might be blocked by intra-zone default rule. I added a rule for trust to trust ANY, but it has no hits at all.

[aleksandar.astardzhiev]

Hi @YuvalBenAri ,

Does your global counter filtered by severity?

Try to run global counter again, but this time use only packet-filter and delta (do not filter by severity).

[YuvalBenAri]

Here is the output without severity filter:

> show counter global filter packet-filter yes delta yes

Global counters:
Elapsed time since last sampling: 3.63  seconds

name                                   value     rate severity  category  aspect    description
--------------------------------------------------------------------------------
pkt_recv                                  22        7 info      packet    pktproc   Packets received
pkt_sent                                  26        8 info      packet    pktproc   Packets transmitted
session_allocated                          4        1 info      session   resource  Sessions allocated
session_installed                          4        1 info      session   resource  Sessions installed
session_discard                            4        1 info      session   resource  Session set to discard by security policy check
session_servobj_timeout_override           8        2 info      session   pktproc   session timeout overridden by service object
flow_pbf_2nd_lookup                        4        1 info      flow      forward   2nd pbf policy lookup on fastpath
flow_qos_pkt_enque                        20        6 info      flow      qos       Packet enqueued to QoS module
flow_action_close                          4        1 drop      flow      pktproc   TCP sessions closed via injecting RST
flow_ip_cksm_sw_validation                16        5 info      flow      pktproc   Packets for which IP checksum validation was done in software
appid_ident_by_simple_sig                  4        1 info      appid     pktproc   Application identified by simple signature
appid_proc                                 4        1 info      appid     pktproc   The number of packets processed by Application identification
dfa_sw                                     4        1 info      dfa       pktproc   The total number of dfa match using software
ctd_run_detector_i                         4        1 info      ctd       pktproc   run detector_i
ctd_fwd_err_tcp_state                      4        1 info      ctd       pktproc   Forward to varrcvr error: TCP in establishment when session went away
ctd_pscan_sw                               4        1 info      ctd       pktproc   The total usage of software for pscan
ctd_appid_reassign                         4        1 info      ctd       pktproc   appid was changed
ctd_url_block_cont                         4        1 info      ctd       pktproc   sessions prompted with block/cont for url filtering
ctd_process                                4        1 info      ctd       pktproc   session processed by ctd
ctd_pkt_slowpath                           4        1 info      ctd       pktproc   Packets processed by slowpath
ha_msg_sent                               28        9 info      ha        system    HA: messages sent
ha_session_setup_msg_sent                  4        1 info      ha        pktproc   HA: session setup messages sent
ha_session_update_msg_sent                24        7 info      ha        pktproc   HA: session update messages sent
proxy_exclude_by_sni                       4        1 info      proxy     pktproc   Number of ssl sessions bypassed proxy because of client hello sni
ssl_ecdh_compute_key_hw                    2        0 info      ssl       offload   The number of ecdh compute key with hw
--------------------------------------------------------------------------------
Total counters shown: 25
--------------------------------------------------------------------------------

[aleksandar.astardzhiev]

Hi @YuvalBenAri ,

Three counters got my attention:

session_discard                            4        1 info      session   resource  Session set to discard by security policy check
flow_action_close                          4        1 drop      flow      pktproc   TCP sessions closed via injecting RST

Those two should be selfexplanatory as traffic to FW interface is being denied by security policy/rule.

But I am surprise to see this one:

ctd_url_block_cont                         4        1 info      ctd       pktproc   sessions prompted with block/cont for url filtering

I am not sure you should see this when filterinng ONLY for traffic between client and FW interface (which will server the block page).

I am wondering if you filter haven't captured some additional sessions - packet capture filter is used to match sessions, those sessions are then tagged for monitoring (packet capture and global counter). If you modify the filter to match other traffic, any session (matching previousl filter) that is still running will still be tagged and monitored.

For that reason after you set the filter untagg any existing session before triggering the traffic - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgDCAS
There should be show command as well to list what sessions are currently tagged (to be completely sure you are capturing only the intersting session and no counters from other sessions are entering your output.

If you still see session to FW interface is still being denied by policy you can try to check session details and see which exact policy has this traffic matched.

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

You could again use source and destination IPs for filtering the sessions. After that take the session ID of the matching session and look at the details for that session.