- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-03-2017 09:53 AM
I have a test url category with only one url. i have applied this url category to a test policy, not using a profile but directly in the policy under "service/url category".
when i browse to the site it uses the correct policy to allow the request...
however... any other traffic that cannot be decrypted is showing in the traffic logs as url category "Any" and this is also allowed via my test policy.
am i missing something here?.....
Mick.
08-03-2017 11:36 AM
Check your traffic log to see if there's any actual bi-directional traffic hitting it. If there are only a few packets, it's not actually matching that policy in a real way.
When a TCP connection first starts out, the 3-way handshake can't have the concept of a URL category so that much is allowed on your test rule as it could belong to that custom category. Once the Client Hello (or whatever else the traffic is, like an HTTP GET or some other protocol entirely), then the firewall has enough information to know it doesn't belong to that custom category, marking the session as Discard.
Since the initial packets were allowed via your test rule, the firewall logs that as the rule.
08-03-2017 10:39 AM
If you don't decrypt traffic then HTTP GET goes inside encrypted payload and Palo identifies site based on name on the certificate. So check what name cert has on it.
08-03-2017 10:53 AM
Raido, thanks for your reply. I was aware of non decrypted procedure on palo and can assure you that the cert name of these sites does not match the url in the custom category.
i cannot understand why firstly these allowed sites are catagorised as "url category ANY" and secondly why they are allowed through the policy where the url cat is "test" not "any".
mick.
08-03-2017 11:31 AM
Additional information: rhe firewall does know the exact fqdn (in almost every case), because in the TLS hanshake there is the SNI attribute where the fqdn is sent in cleartext.
08-03-2017 11:36 AM
Check your traffic log to see if there's any actual bi-directional traffic hitting it. If there are only a few packets, it's not actually matching that policy in a real way.
When a TCP connection first starts out, the 3-way handshake can't have the concept of a URL category so that much is allowed on your test rule as it could belong to that custom category. Once the Client Hello (or whatever else the traffic is, like an HTTP GET or some other protocol entirely), then the firewall has enough information to know it doesn't belong to that custom category, marking the session as Discard.
Since the initial packets were allowed via your test rule, the firewall logs that as the rule.
08-03-2017 11:41 AM
Gwesson, wow... Thanks.... Good point. I will check in the morning and update.
mick.
08-04-2017 02:07 AM
Gwesson, thankyou for your time and explanation. you are correct in your explanation. I changed the logging to "session end" and now see no traffic passing through the test policy (of course it actually still is but only for the reason that you explained earlier).
I can't thank you enough.
Mick.
05-10-2019 11:54 AM
Does this URL category (URL column and URL Profile) match initially on other rules as well, say for instance if you have a couple of rules that allow ssl/web browsing, and are being decrypted, and one has custom URL category column, and one has simply a profile?
05-11-2019 11:11 AM
Traffic will always match only one rule. Even if there could be multiple matches, the first rule that matches will be applied. Only adding the URL category directly into the rule is a matching criteria, not the URL profile.
05-11-2019 12:17 PM
Great explanation!
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!