Clarification on App Rule - I thought I understood this

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Clarification on App Rule - I thought I understood this

L4 Transporter

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

 

20 REPLIES 20

Community Team Member

Hi @TonyDeHart ,

 

Could it be because application defaults is being used ? 

SSL appllication default is port 443.

 

Kind regards,

-Kim.

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.

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?

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

L4 Transporter

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.

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

L4 Transporter

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.

Cyber Elite
Cyber Elite

Hi @TonyDeHart ,

 

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

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

L4 Transporter

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.

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

L4 Transporter

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.

L4 Transporter

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.

 

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

Glad it helped!

L3 Networker
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.
Sr. Technical Support Engineer, Strata
  • 5400 Views
  • 20 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!