I think you should open a support case to have this investigated (and then update this thread with the result). Personally I dont see any problem with adding url filtering to narrow the rule down to what is actually being allowed (but I can agree with you that allowing "twitter" should include urls aswell - at least when used in a allow rule, while a deny rule could perhaps ignore the url in order to be as wide as possible). People with a SPI-only firewall have the same problem (they open up TCP80 but have no clue if its really HTTP which is going through that hole). However if urls would be included in the appid (I guess they already are in some way) you would have a higher probability of false positives, or rather complete misses. You can compare this with facebook which I think not only uses *.facebook.com but also *.fb.com and other sites. By defining appid as the flow itself and not destination used I think you as the administrator have a better option to also include (if you wish) url filtering to also filter on destination (same as appid on its own doesnt necessary act on destination ip, if you want to block something towards a specific ip address you must manually set this up in your security rule in the destination ip column). Your deny rules can be setup this way: D1) Deny appid:<filter subcat:social-networking> D2) Deny url-category: Social Network while your allow will look something like: A1) Allow appid:twitter,web-browsing url-filter:*.twitter.com, twitter.com dont forget to also enable ssl termination so you dont miss HTTPS traffic.
... View more
