topic Re: Application Blocked instead of URL Block in General Topics

Application Blocked instead of URL Block

rjdahav163 — Thu, 06 Sep 2018 16:18:28 GMT

I have implemented URL Filtering. However for http pages, I see Application Blocked page as agains URL Block page.

Anyone experienced same phenomenon?

BR,

Re: Application Blocked instead of URL Block

Remo — Thu, 06 Sep 2018 19:17:22 GMT

@rjdahav163

Do you have a rule above the URL filtering rule that blocks specific apps?

Or do you specify apps (web-browsing, ssl, ...) in your URL filtering rule?

Re: Application Blocked instead of URL Block

BPry — Thu, 06 Sep 2018 20:15:21 GMT

@rjdahav163,

It's likely not a 'phenomenon' as you called it (love that word by the way). You likely are running into a proper application block for some reason, whether it's because an application deny policy already exists, or as @Remo already mentioned you added the application into the URL Filtering deny policy.

Re: Application Blocked instead of URL Block

rjdahav163 — Fri, 07 Sep 2018 08:59:20 GMT

@Remo

In the Security Policy I use applications ssl and web-browsing and Ports tcp/80 and tcp/443.

The Security Policy action is Allow.

Then there is a URL Filtering Profile attached to the security rule, with some URLs allowed and the rest all categories blocked.

The allowed URLs work.

For some of the blocked URLs I see my custom Block Page.

For some of the blocked URLs (predominantly using http) I see the Application Blocked Page instead of my Custom URL Block Page.

I cant pinpoint the problem 😞

Re: Application Blocked instead of URL Block

rjdahav163 — Fri, 07 Sep 2018 09:03:27 GMT

@BPry

No there is no Deny Policy at all. I am implementing the blocking based on URL Filtering Profile. Please read my above post (reply to @Remo ).

BR,

Re: Application Blocked instead of URL Block

Remo — Fri, 07 Sep 2018 09:29:08 GMT

@rjdahav163

In your traffic logs: which rule gets hit with these sessions that show the application block page? Is it the interzone-default-deny rule?

Re: Application Blocked instead of URL Block

rjdahav163 — Fri, 07 Sep 2018 11:01:11 GMT

@Remo

No there is no deny rule. In traffic logs I see the security rule which allows the connection being hit. And nothing in URL filtering logs.

UPDATE: When I use "www" , I see Application block page and when I access URL without www, then I see my custom URL Block Page.

For example: When I access,

http://www.google.com ----> Application Block Page

http://google.com ----> Custom URL Block Page

Any Idea why?

Re: Application Blocked instead of URL Block

Remo — Fri, 07 Sep 2018 11:15:39 GMT

@rjdahav163

Even if you don't configure a deny rule yourself, there is a default rule at the end of the policy which is configured by default and cannot be deleted - you can only overwrite it. This default rule at the end is set to no log by default. Right now I assume the application block page comes from there because the action is set to deny and you don't see it in the logs because of the no-log setting. Change that rule or configure your own clean up rule with action drop at the end of the ruleset and try again.

The connection to www.google.com probably is identified as google-base so it does not hit your URL filtering rule while the connection to google.com the firewall identifies as ssl/web-browsing so it hits your URL filtering rule so the URL block page is shown.

Re: Application Blocked instead of URL Block

rjdahav163 — Fri, 07 Sep 2018 12:32:10 GMT

@Remo

Bingo! Thanks!

It was exactly the issue:

When I used www, the application that is recognized is different. So as you mentioned in case of www.google.com, it is google-base and so it hits the default deny rule and so I see application block page.

Re: Application Blocked instead of URL Block

DPoppleton — Fri, 07 Sep 2018 12:32:29 GMT

There are many websites that are defined as applications, so allowing just web browsing and ssl will still block these applications. You have to add them as allowed applications.

Everytime new content updates come out I always pay close attention to these. We get a lot of "I can't get to this website anymore" tickets, so we try to be proactive in allowing the new definitions.