I recently moved a firewall into being managed by Panorama. I setup an Application rule specifying the application as PANORAMA which includes the ports necessary (I assumed) for Panorama communications but the firewall could not be added successfully until I allowed port 3978 traffic.
The logs showed 3978 being recognized as SSL initially and being denied as it wasn't getting included in the rule. What I don't understand or I guess I misunderstand, why isn't SSL allowed under that rule until the service is recognized as Panorama? SSL is implicitly allowed under the PANORAMA application so I thought it was allowed initially under that rule on the ports the application supports.
What am I missing?
I thought I understood it based on this article but this isn't how it seems to be working:
Hi @TonyDeHart ,
Could it be because application defaults is being used ?
SSL appllication default is port 443.
I guess I was assuming APPLICATION-DEFAULTS needs to be set to make sure it is using the correct ports for the applications as listed. I assume it is failing because of that since SSL wouldn't fail otherwise but if I add SSL and don't specify a port or application default then SSL can run on any port. Do I just need a separate rule for SSL on that specific PORT then? What's the point of the implicit applications then?
Hi @TonyDeHart ,
I had the same question. Is your ssl traffic on port 443 or 3978? If it is on 3978, it should not be blocked and should application shift to panorama. If it is on 443, then it is a separate app that will need to be allowed by rule. I believe your current rule will only allow ssl on 3978 until it shifts.
PANW does not tells us what apps are required between Panorama and the managed NGFW, but they do give us this list of ports -> https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/firewall-administration/reference-port-num....
There is a separate tcp/443 listed which seems to indicate to me that ssl needs to be added to the list of applications in your rule.
I guess my question has more to do with why the Implied App isn't actually used in this case. If I have a rule that specifies PANORAMA as an application and SSL is implicit to that I don't understand why SSL isn't allowed automatically and needs to be explicitly allowed in the rule itself.
Hi @TonyDeHart ,
SSL is only implicitly allowed until the NGFW identifies the application as panorama. Here are explanations of the cases from the URL you posted:
This is the desired behavior as we do not want a L7 rule allowing also panorama to allow all ssl. We want it to allow only the selected application.
So why doesn't CASE 1 apply here? It is SSL traffic and then shifts to PANORAMA was my assumption here. Not doubting your answer just trying to understand as that was how I was reading it - the SSL is implicitly allowed until identified and what I see in the logs is this initial SSL communications on 3978 and then the shift to PANORAMA.
It is on port 3978 but now that I've sat on this a while and looked at the logs again, it appears there may be legitimate SSL traffic on 3978 as not all the traffic is identified as Panorama. Some it appears to be remaining as SSL over the long term. When I had initially set this up the SSL was switching over to Panorama so I assume it was ALL identified a Panorama but there appears to be a good deal of both here. Just seems strange to me that Panorama's own traffic wouldn't be identified as just that and not generically as SSL.
After some conversation with Palo support it turns out there are situations now with 10.2 and above that Panorama traffic is NOT identified as Panorama and is only identified as SSL traffic. According to Palo Alto support, this requires that SSL on 3978 be EXPLICITLY allowed for communications with Panorama. Supposedly, this was originally identified as a bug some time ago but for technical reasons has to be this way. A rule with SSL/PANORAMA on port 3978 is necessary.
Hi @TonyDeHart ,
I just had a customer upgrade his Panorama to 10.2 and this change in App-ID BROKE his existing rule which only had the panorama App-ID. We had to create a new rule allowing ssl on tcp/3978. The NGFW was also upgraded to 10.2.
It was working before, but the upgrade broke the connectivity to the remote NGFWs. I quickly looked through the 10.2 known issues, and I did not find this bug.
Thank you for the info!
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!