I need to block traffic to certain websites and domains.
I created a URL Category object and put just one site inside (example.com).
I then created a firewall rule like this:
Source zone: LAN
Source address: any
Dest Zone: WAN
Dest address: any
Service/URL Category: my URL Category Object
(I put it on Allow because for at first I just wanted to check what traffic is hitting this rule).
I immediately noticed a very high hit count on the rule and when I viewed the rule logs I noticed it is allowing loads of traffic that doesn't relate to example.com
I'm affraid if I put this rule to Block it will block my outgoing traffic.
What am I missing
I did some testing in my lab and found that if you have the rule set to action 'Allow', hit count increments for every session that was allowed through the rule, even if the traffic was later proven to not match the URL Category rule.
If you change the action the 'Deny', the hit counter only only shows the sessions that were dropped by the rule.
This should be related to the rule having the action set to 'Allow' and the session being initially allowed on the rule until the URL Category can be determined, so the firewall adds the session to the hit counter.
Thanks for your reply.
I'm not talking just about the hit count. I'm also talking about seeing the traffic in the monitor when clicking on the rule and choosing "Log Viewer".
You're saying the session is initially allowed before the URL can be deteremined, so if I change it to DENY, wouldn't it first deny all traffic before detemining the URL Category?
So, I tried switching it to Deny but it didn't do anything.
The hit count didn't change and in the monitor I can see it doesn't recognize the URL Category, it's registered as "Any".
I also tried using custom EDL URL List instead of URL Category object, but got same result.
What am I missing?
Do you have log at session start enabled? That would explain the logs showing up on your allow rule. I would recommend disabling log at session start.
The initially allowed traffic is for allow rules. When processing traffic, the firewall assumes that the application is set to 'any' until the firewall can determine what they are and processes the traffic under the first security rule that matches L2 - L4 with any application. This is show in the "FW Session setup/Slowpath" in the Day in the Life of a Packet diagram under 'Firewall security policy lookup'.
In your example of the allow rule with URL category defined and the action is set to "Allow', the firewall will match all sessions from L2 to L4 to that rule until the application can be defined. Once the application is defined, the firewall will rematch against the policy to determine if there is a rule to allow that traffic. In this example, that would still be the URL category rule since the rule is setup with any application on any service. Once the URL category is defined, the firewall will rematch against the security policy again to find the first rule to match the new information.
If your rule was set to block, the traffic would be initially allowed on another security rule until the URL category was determined 5-9 packets later. Then on the rematch the firewall will show that the traffic was dropped on your URL Category rule.
My testing shows that it works as intended. If your traffic was allowed after changing that rule to action 'Deny', I would look into the order of the security policy rules and make sure that another rule didn't allow the traffic.
I don't have log at session start, only at session end.
And I checked again, and the traffic is allowed in a rule that is after my block rule.
So that's strange why the fw can't determine the URL category.
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 Live Community as a whole!
The Live Community thanks you for your participation!