CrashCart wrote:
Gmail-base has a dependency on smtp. If you are on v5, smtp should be automatically included as a dependency with gmail-base by PAN OS if you don't specify it. Any smtp traffic related to gmail would be caught by your rule. The dependency warning appears to be a bug.
Yeah, another one. Ho hum.
It looks like you have a default allow rule and then only block "bad" apps. By default the firewall will block any traffic so you really don't need that rule. Instead you could just add a rule to merely log what was blocked. But since you specified the smtp app, it is triggering the dependency warning.
Not true. My rulebase is setup this way for a reason. I have three rules for "general" (user) passage through the firewall (specific purpose rules not included - there are a number of them). 1) Approved apps - known_good - allow 2) Unapproved apps - known_bad - deny 3) Everything else - overflow - allow, but report daily to the administrator (me). I cannot go to a "default-closed" environment because of the nature of our business - you'd be surprised how many apps come through the "overflow" report - apps recognised, but on non-standard ports (web browsing on 8080 is a classic example, SSL on 995 another) which do not match the first rule because that rule is configured "application default" on the service identifier. This way, I don't stop my users from working (believe me, if I blocked web browsing on 8080, the brown sticky stuff would hit the rotating air distribution blades as nobody would be able to access resources at one of our biggest clients), but I look at the reports daily and add any "new" apps which don't have a business purpose to the known_bad application group and get them blocked, similarly any "new" apps which *do* have a business purpose to the "known_good" group and get them out of the report. SMTP is specifically denied in the "known_bad" group except from approved nodes (our outbound mail relay) because of pieces of crap like iPhones which just pretend to be SMTP servers and connect to other SMTP servers, identifying themselves as "localhost.localdomain" - which promptly results in my outbound IP address being dumped in black holes, which means I can't send mail out - not a good thing.
... View more