URL Allow List filters are not functioning as documented.

[allens]

URL filter is great when working with Categories, but when an exception is published in the allow list there are catches and exceptions.:smileyconfused:

We block-continue Streaming Media, which contains Youtube, which we want to allow users access to without a block.

I create an allow exception *.youtube.com/* and commit, open a new browser, clear the cache, and go to www,youtube.com to see that B&C is still in effect.

So I added www.youtube.com and youtube.com in addition, and then it worked.

I did the same thing for dropbox, but it uses HTTPS and the session would be dropped every time I went to www.dropbox.com - which in turn redirected me to https://dropbox.com

In order to get that working, I had to go against the documention in the dialog box and add https:// to the dropbox.com.

still haven't got the dropbox desktop application to work, even with *.dropbox.com in the allow list.

This is an exercise in frustration!

[craymond]

You might want to read the following Document on URL categorization that has a description on how the PAN parses URL filters.

https://live.paloaltonetworks.com/docs/DOC-3264

[NGS_SOC]

If you need allowing a domain with its subdomain you must allow them

domain.*

*.domain.*

*.*domain.*

*.*.*domain.*

etc

This works for web-browsing, if the traffic is ssl you need to terminate it (decryptin) in order to gain full compatibility. If not only the domain.* is visible.

In case of known application (as dropbox)  I suggest you not to use Url, use application identification, always go beyond Url Profile.

[mikand]

Reading that technote it really sounds odd that PA has chosen this behaviour.

The common thing in the market is to separate "domain.com" from "*.domain.com" but this also means that "*.domain.com" would match "sub1.sub2.domain.com".

That is to fully block for example youtube by url filter you need two url-rules:

1) youtube.com (this covers http(s)://youtube.com/*)

2) *.youtube.com (this covers http(s)://sub1.youtube.com/* but also http(s)://sub1.sub2.youtube.com/* and so on)

Could perhaps someone from PaloAlto enlighten us on this subject?

The point of using url-filtering and not entirely rely on appid is what happend last xmas:

http://researchcenter.paloaltonetworks.com/2012/12/app-id-cache-pollution-response/

http://researchcenter.paloaltonetworks.com/2013/01/app-id-cache-pollution-update/

The point here is that next time appid is failing (because it most likely will otherwise there wouldnt have to be any updates for the app-db 😃 the url-filtering in the same security policy (specially if its a whitelisting rule) might save you...

That is compare a security rule which only has "appid:facebook" with one that has both "appid:facebook" AND "url:facebook.com||*.facebook.com" (or whatever domains they use nowadays).