- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-17-2014 09:53 AM
Ok I'm pretty sure this has been covered elsewhere however I cannot find anything on it.
Let me give you some background on the config:
Currently using software version 6.0.5
SSL decryption in operation
Trust to Untrust traffic flow direction
Ok so I have a rule called "Trust Web Traffic". This rule allows any trust user to any untrust destination for applications "dns, google-analytics, ssl and web-browsing". While SSL decryption is turned on for my user account, and I then navigate to www.google.com I get an application blocked. I believe this is happening because google redirects the traffic to port 443. In the monitor tab I can see the traffic first appear as port 80 web-browsing THEN change to port 443 ALSO web-browsing. Since this is a non standard port for the application "web-browsing" the traffic is denied.
What is the solution here? I already know if I change the service to ANY it will work however this leaves this rule allowing any protocol for that application which I dont want to do. I've also been told creating a custom app could be the way to go. But seriously google search should be covered in Palo Alto Applipedia.
What is the solution here? While still keeping the rule explicit to the application-default.
Thanks
12-17-2014 10:32 AM
Application-default is always going to be your problem if you have apps using non-standard ports. You can either change the service to any which will allow those applications on any ports or you can try to make a service group with all the ports you expect to see and use a combination of the two.
12-17-2014 02:06 PM
What you can do to keep the application-default might be to just add "SSL" into the application column. This will allow Google to shift over to port 443 and you don't have to loose the rule on the "application-default" option.
12-18-2014 02:14 AM
I don´t think that will work. At least it doesnt in my setup. Adding SSL allows port 443 but only if the application is recognized as SSL. My problem, and Gavins, is that the application is recognized as "web-browsing" but on port 443. One work-around would be to add a separate policy for application "web-browsing" and add service http and https. This way other application are only allowed on their default ports except for web-browsing. This is in theory, I haven´t tried it yet. 🙂
12-18-2014 02:36 AM
Mikael, I have tested your theory and it works. I basically cloned my "Trust Web Traffic" rule which was "ANY trust to ANY Untrust, "web-browsing and ssl", but then I set the service to select and had "service-http and service-https". This I still feel is negating the purpose of the Palo Alto App-ID architecture. We are basically using the firewall in layer 3 mode and allowing ports through regardless of the layer 7 application information.
The answer to this, and please jump in if you disagree, is for Palo Alto to have an application called "google-search" with dynamic TCP port range 80, 443. This would allow the traffic to which to 443 and still identify the traffic at the layer 7 level. This would then allow us to use the application-default option.
Let me know your views on this.
12-18-2014 02:50 AM
Gavin,
I just tried this setup myself and it works fine, as you said. I´m thinking that there are alot of other applications, besides Google-Search, that are identified by PA as web-browsing which use port 443. So adding the application google-search would only solve one problem. What i´d recommend them to do is to either add port 443 as a default port for web-browsing or give the users the ability to add it themselves. I guess this could be done by creating a custom app with the same signature as web-browsing but port with 443 as an addition (again, theory haven´t tried it). I´m not sure if there are any security concerns with adding port 443 though.
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!