- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-28-2013 05:41 PM
Folks.
The latest content update (pushed today, my time) gave me the following warning in the task when I installed it
VSYS1: Rule 'Outbound_Traffic' application dependency warning: Application 'gmail-base' requires 'smtp' to be allowed, but 'smtp' is denied by rule 'Outbound_Bad'
WTF? Since when does GMail require SMTP? The local installations don't use SMTP - they connect to GMail over HTTP/HTPS, and the GMail back-end servers do the SMTP stuff. Why does Palo Alto now think GMail requires SMTP? I should add that I have checked the release notes for this content release and they mention *nothing* about there being a change to the gmail-base app signature.
I'm not allowing SMTP outbound from everything, because the idiots who run crap like iJunk get my outbound address into blackholes by using misconfigured junk which identifies itself as "localhost.localdomain" in the SMTP EHLO sessions - yet I need GMail for regular use.
Anyone know what the hell is going on here? Impressed I am not.
Cheers
08-05-2013 11:21 PM
vsys1: Rule 'new' application dependency warning:
Application 'gmail-base' requires 'smtp' be allowed, but 'smtp' is denied in Rule 'rule3'
(Module: device)
same with us
08-06-2013 07:08 AM
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.
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.
08-06-2013 02:58 PM
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.
08-09-2013 01:38 PM
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.
We just deployed our first PAN device at an office after installing previous PAN devices at our data centers. it is indeed much more difficult to deploy in an office setting. I was also shocked to see all those apps show up, and on non-standard ports like SSL on 444 and 8200, webmail on 993, and of course web-browsing on 8080. I was hoping to get to a default deny rule after observing traffic for a few weeks. Not sure if and when that will happen.
08-11-2013 11:57 AM
Which PANOS are you running?
Because even if 5.x is supposed to somewhat fix the dependency hell (inspired by the Microsoft dll hell? 😉 it seems that not all dependencies are being taken care of by the 5.x release.
Another issue with this "magic" auto dependency in the background is for how many packets should it allow traffic before the auto depedent appid is being blocked?
For example smtp for the case of gmail should only be valid if the domain is .google.com (and whatever other domains google uses nowadays). It would be really bad if the auto depedency suddently, silently, allows any smtp to the rest of the world while you as an admin think you have only allowed gmail as appid... (sure, a workaround might be to add custom urldb that only allows this rule if the http host request matches but still).
08-19-2013 09:56 PM
mikand wrote:
Which PANOS are you running?
5.0.6 at the moment.
I just put up with the dependency warning. What else can you do?
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!