> Source: [sk105642](https://support.checkpoint.com/results/sk/sk105642)

# sk105642 - Allowed site is blocked on first attempt, then allowed on second attempt

| Property | Value |
|----------|-------|
| Solution ID | sk105642 |
| Date Created | 2015-04-12 |
| Last Modified | 2024-06-03 |
| Technical Level | Advanced |
| Products | Security Gateway |
| Versions | R81.20, R81.10 (EOS), R81 (EOS) |
| OS | Gaia |

## Symptoms

- * When a user browses to what is defined in the Application Control and URL Filtering policy as an allowed site, the user is instead blocked. (Both Application Control and URL Filtering enabled)
* When attempting to access the site immediately after, it is now correctly allowed.
* The UserCheck dialog and the log in Smartview Tracker show that the blocked traffic was categorized as "Web Browser"

## Cause

A combination of the security policy and the engine settings in the Application Control and URL Filtering blades is preventing the first attempt to the allowed site.

There is a very specific scenario in which this issue can happen.

The security policy on the system is defined as a whitelist, allowing certain categories of web traffic only and to block all others. As such the policy will have defined a clean-up rule as the last rule in the Application Control and URL filtering policy dropping all traffic. While this is not the recommended best practices for the use of the blades (see [sk98348](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98348)), the organization's security policy may dictate such strict web control.

Additionally, under Advanced settings for the Application Control and URL Filtering blade, engine settings for "Website categorization mode" are set to "background". **This setting means that initial requests are allowed by the URL Filtering blade until categorization is complete.** Once a site is categorized, it is stored in the cache on the firewall and all subesequent requests for that site will be properly categorized. This setting utilizes fewer resources on the firewall and allows for less latency when browsing to websites that haven't been cached by the firewall yet. It can also allow temporary access to restricted sites until properly categorized.

In this specific scenario however, where the policy defined is highly restricted and engine settings are set to "background", when a user attempts to access a site whose category hasn't been cached by the firewall, the URL Filtering blade does not take any action. The Application Control blade will continue to attempt to match the traffic to the policy based on the application in use. In this case, a specific web browser (i.e. Internet Explorer, Chrome, Firefox, etc.). These applications are categorized in the Application Control blade as "Web Browser." **Since this is not an allowed category according to the policy, the traffic is dropped on the clean-up rule.**

When the user attempts to go to the site a second time, the URL Filtering blade has now had an opportunity to properly categorize the site in question and the traffic now matches on one of the allowed rules for this category.

## Solution

This solution requires authentication. Please log in to view the full solution.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content