- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
12-15-2022 07:25 PM
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.
12-15-2022 07:47 PM
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.
05-20-2023 05:53 AM
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?
05-20-2023 12:08 PM
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?
05-20-2023 03:14 PM
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
05-21-2023 08:40 AM
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.
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)
05-22-2023 02:55 AM
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
05-22-2023 02:39 PM
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.
05-23-2023 02:51 AM
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.
05-24-2023 04:57 AM
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).
05-24-2023 05:48 AM
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
--------------------------------------------------------------------------------
05-31-2023 03:26 AM
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.
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!