commit status warning on rules that are working the way I want them too

[jdprovine]

I have a rule that has webex enabled but dones not have ssl enabled and i keep getting a warning on that rule when i commit that says "Applicaiton 'webex-desktop-sharing requires ssl be allowed? But I don't want to allow ssl, so how can I get rid of these warnings so i can tell when i have a legitimate commit warning?

[Remo]

I hope there is a solution but I asume there isn't ... some applications simply have a dependency to others. So even if it works in most cases there might be some edge cases where the firewall first sees ssl and after some more packets thw app changes to webex. So in these cases it could be that it won't work with allowing only webex...

Hopefully there is a way, cause the commit warnings I have are growing and growing ...

[Mick_Ball]

ssl is a dependency of the webex desktop sharing application...

according to this doc...       https://live.paloaltonetworks.com/t5/Learning-Articles/Tips-amp-Tricks-What-is-Application-Dependenc...

it states...

If you do not allow the application and its dependency through the Palo Alto Networks firewall, then the application will not work.

[Mick_Ball]

sorry, answered after @Remo...

[jdprovine]

@Remo @Mick_Ball

thing is it does work and I would think it shouldn't , for instance this is in the commit warning 

• Application 'google-plus-base' requires 'google-base' be allowed

And this is what it says in the applicatiion info - google-play standard ports 443,5227,80,tcp,udp

Then I look in the traffic and unless I am reading this wrong it is work even though ssl is not allowed so to speak

[jdprovine]

@Mick_Ball @

Actually I think it is working that is why I am surprised, look at my reply to remo

[Remo]

@jdprovine

I know it works, thats why I have endless commit warnings 😛

Exactly like your initial example. You only want to allow webex but not general ssl access to everywhere ...

[jdprovine]

@Remo

Yeah and the impression from the commit warning is that it should not work without ssl but it does, because the ssl port 443 is allowed, from what I see

[jdprovine]

@Remo @Mick_Ball

So I guess I want away to clean up my commit status errors without having to add ssl to a rule that I don't want ssl enabled on. 

[Mick_Ball]

ok so having added the dependencies to the webex desktop sharing policy, the warnings have gone...

is this a problem, will it not only use these dependencies for webex desktop and nothing else...

[jdprovine]

@Mick_Ball

I know that giving it what it wants to make the commit status errors go away but I don't want ssl on those rules at all

[Remo]

@Mick_Ball

No, if you add these dependencies then the firewall also allows these apps independently.

So ...

• Allowing just webex --> working solution but commit warning
• Allowing webex with dependencies --> webex works but also general webaccess and the commit warning is gone

Or ...

• Secure solution --> commit warning
• Insecure solution --> no commit warning

[Mick_Ball]

@jdprovine, @Remo. Sorry... its been a long day.... i feel so stupid.

i thougt i was adding the dependencies into a different section of the policy, not into the same app section of the policy as webex desktop...

i feel this will not be marked as a solution.....

[jdprovine]

@Mick_Ball

No problem Mick you always give it your best, this is just a weird situation 

[hshawn]

OK, we see this all the time. One thing to keep in mind is the application/traffic may work without the dependencies *but* some components of it may not work and you may not notice or the app may fall back onto something else if it fails one piece.

Here is what we try to do and a lot of people forget they can do this:

* Setup your security policy and add the dependencies

* validate the commit does not have any dependenciy warnings

* Scope the policy down to specific destinations (if possible) or use a URL category in the policy, using a URL category will at least make it so users will not hit this policy for all web browsing and hopefully only hit it for the application/URL catgories specified

for example we have exceptions to allow people to hit online file storage junk (box, dropbox,etc) so aside from the user having to be in the proper AD group for the exception the destination also has to be one related to the exception and/or the URL category has to match, otherwise they will hit the standard web traffic policy.

the web-browsing and ssl applications will be a pain no matter what (try locking down slack and have fun)