view the urls hitting default interzon policy

[Marsooq_A]

Hi team,

We have a url filtering profile created for monitoring with action of all category as alert. And this profile has been called on default interzone policy (action deny). But nothing is gets logged, we have many traffic hitting default interzone policy and the aim is to monitor urls hitting this policy. Can anyone help on this?

[JoergSchuetter]

Hello @Marsooq_A 

Can you try to

- set action to allow

- set all to "block" on security profile URL filtering

It might be necessary to have SSL decyption active as well.

[OtakarKlier]

Hello,

I never rely on the two default policies. I always have a DENY ALL policy right above them so I can see all traffic getting denied.

Hope that makes sense.

Regards,

[Marsooq_A]

I cannot set the action as allow as we need to deny all the traffic hitting interzone policy. The requirement is , i have placed a policy with destination as specific url category. Somewhat the traffic from source machine hitting the default interzone policy and were i have action set as deny. and my requirement is , what urls that the source machine tried to reach.   

[JoergSchuetter]

Hello @Marsooq_A 

Even if you set action to allow, it will not be allowed (due to the security profile set to block). You can see it similar as having a security policy allowing the access, but the virus filter will block if a virus is found.

[aleksandar.astardzhiev]

Hi @Marsooq_A ,

"url filtering profile created for monitoring with action of all category as alert. And this profile has been called on default interzone policy (action deny)."

No security profile is applied on traffic matching rule with action deny. If you will deny the traffic, why would you bother to perform additional inspection.

For that reason if traffic is hitting the default deny rule, firewall will not perform any additional inspection so it wouldn't be able to identify the URL

It is possible that firewall will initially allow a connection and once it gets some actual data (not just network protocols headers, etc), to perform new policy lookup and this time to not match the original rule and fall to "default-intrerzone". In this case this session will generate at least two log entries - one from the original rule allowed the connection and one from the intrerzone rule.

In your original post you mentioned that you are using URL Filtering profile, but in your latest rely you mentioned that you have configured specific URL as destination criteria in your rule. You need to understand that these two are totally different thinks:

- URL Filter security profile will, filter the URL only after the traffic is first allowed by the rule appling this profile.

- URL in security rule - is providing additional matching criteria. Traffic will be allowed only if it matched the specified URL. And after that this traffic will be subjected to additional inspection, defined from the attached profiles (if any). So in this case is it is very possible that the TCP-handshake to be allowed by this rule and once the actual data pass through the firewall, the detected url to not match the one in the rule so during additional policy lookup, traffic will be droped because it is matching only default-intrerzone. In that case when you check your logs you will see that "session has matched default-interzone", but if you open the logs details, you should see also the log entry of the rule that this traffic has matched on the initial policy lookup.