@drewdown wrote: I get the whole concept and I am using app-ids on the permit statement and denying everything else across this environment so its not that. What I didn't get is that if I did that and didn't allow whatever traffic pattern was being matched it would be dropped. I assumed, albeit incorrectly, that if I allowed 80/443 and curl uses 80/443 and there is no 'curl' app-id it would be allowed. You're still missing a bit when it comes to the concept. If you allow 'web-browsing", then it will only allow traffic that matches the "web-browsing" application. Doesn't matter what generates the traffic (CURL, wget, telnet with manually entered HTTP commands, a web browser, something else), if it matches the "web-browsing" application pattern, then it will be allowed through. Once it has identified the traffic, then it looks at the ports that are being used and checks those against the Service part of the Security Policy. If it's set to "application-default", then (for web-browsing) it has to be on port 80. If the traffic is on any other port, even if it matches the web-browsing pattern, it will be blocked. If you set the Service to some other port (say 8080), then it has to match that as well. (web-browsing on port 443 is only matched/shown for firewalls doing SSL decryption; otherwise it shows up as "ssl") So, if you are using curl to connect through the firewall and it's not matching the web-browsing application, then it's not generating traffic that matches the web-browsing application pattern. When using AppID, the port used only matters when the traffic matches the AppID already. The AppID doesn't "allow all traffic on those ports", it only allows "traffic that matches this pattern, on these ports". Easy way to look at is, if you don't care about the application, leave it at "ANY" and filter based solely on protocol and port.
... View more