- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
12-18-2015 09:09 AM
12-18-2015 01:24 PM - edited 12-18-2015 01:25 PM
Lets assume you have 2 applications in one rule "web-bworsing" and "ssl".
If you use application-default as service then web-browsing runs on 80 and ssl runs on 443 only.
If you create 2 new services tcp-80 and tcp-443 (there are preconfigured services actually for http and https) and change application-default to those 2 services then web-browsing can run on 80 and 443 and same with ssl - can run on 80 and 443.
Basically there are AND between columns and OR between rows in single policy.
12-21-2015 03:46 PM
I have/had the same issue. Two rules, one inbound and one outbound allowed the App ID's "ssl" and "web-browsing". On the 17/18th they broke because they were being denied on port 80 App ID "soap".
Changing the rules to ports (80/443) fixed the problem. Final solution was to go back to App ID and allow "ssl", "web-browsing" and "soap".
Is there a good way to be notified when this kind of change (App ID change?) happens?
Thanks!
12-22-2015 06:40 AM
12-22-2015 06:46 AM
12-22-2015 11:14 AM
We had the same issue. The fix was also allowing SOAP on the security policy, in addition to web-browsing. We also rolled the app and content update back to version 544-3039 (from 12/8/2015) and only allowed web-browsing as the app. This fixed it, too, confirming the problem was how SOAP was identified in version 545. I opened a case with Palo Alto to see if there was any further detail about what was changed. Turns out they consider what they changed as a fix because SOAP traffic wasn't being properly ID'd before as that and was showing up as web-browsing.
What this'll probably end up causing though for us in the long run is disabling automatic updates like this in production and testing them out in a non-production environment first. Honestly surprised this sort of thing hasn't happened to us before.
Good ideas to write allow policies based on port as a "safeguard." However, doesn't that allow any app on the defined port to get through? I guess it's a tradeoff between security and functionality...
01-05-2016 11:22 AM
"However, doesn't that allow any app on the defined port to get through?"
Yes it does. This is one of the big reasons we got rid of our ASA's and moved to the PAN products. We try to use App ID for every Security rule and we are proabably 90% there.
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!