Clarification on App Rule - I thought I understood this

[TonyDeHart]

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:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PLLICA4

[kiwi]

Hi @TonyDeHart ,

Could it be because application defaults is being used ? 

SSL appllication default is port 443.

Kind regards,

-Kim.

[TonyDeHart]

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?

[TomYoung]

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.

Thanks,

Tom

[TonyDeHart]

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.

[TomYoung]

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:

1. Case 1:  SSL traffic is allowed by rule and still alowed when it shifts to sharepoint-online.
2. Case 2:  SSL traffic to www.example.com is allowed temporarily but denied because it never shifts to sharepoint-online.
3. Case 3:  SSL traffic to www.facebook.com is allowed temporarily but denied after it shifts to facebook-base.

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.

Thanks,

Tom

[TonyDeHart]

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.

[TomYoung]

Hi @TonyDeHart ,

The ssl traffic that you see being denied.  Is it port 443 or 3978?

Thanks,

Tom

[TonyDeHart]

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.

[TomYoung]

Hi @TonyDeHart ,

Yes, that is strange.  Looking at the URL I posted with the ports, I would think you would need to allow SSL on 443 as well.

Thanks,

Tom

[TonyDeHart]

Interestingly, to add to this, traffic from other firewalls to Panorama is properly tagged as Panorama traffic and NOT SSL.

Palo support is scratching their head over this too so I now don't feel so bad. If I find out what's going on I'll post it here.

[TonyDeHart]

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.

[TomYoung]

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!

Tom

[TonyDeHart]

Glad it helped!

[dmifsud]

PAN-192930

Fixed an issue where, when the default port was not TCP/443, implicitly used SSL applications were blocked by the Security policy as an SSL application and did not shift to the correct application.