Default Application ID change in 8.0?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Default Application ID change in 8.0?

L3 Networker

We are migrating from some 200's running 7.1.x code to 220's running 8.0.x code. We had a rule that was working fine, allowing any traffic from a server to another server. We didn't define any apps or tcp ports. We have that rule in the new firewall, but it is now being blocked as "unknown-tcp".

 

We added a rule allowing any traffic between the servers over the port they use. It still is blocking it as unknown-tcp.

 

Why did this work in 7.1 but not in 8.0? I've gone through the release notes and there is nothing about application ID changes that would effect this. Is an application override the only way to get this to work?

15 REPLIES 15

Cyber Elite
Cyber Elite

Do you have "application-default" as Service?

Change it to "any" and test.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Application and Service are both set to any. And it is the first rule, as this is a very important connection.

 

 

Can you show screenshot of the rule and screenshot of Monitor > Logs > Traffic where this traffic is blocked?

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

The rule that is the deny rule is the last rule, catch all.

 

Deny.PNG

Can you also share top rule that should permit this traffic.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

It's a pretty simple rule, and worked on 7.1:

 

Rule.PNG

So it stopped working after upgrade?

Can you create new rule and instead of using address groups just add single ip to source and destination. 

Those that you hid in your first screenshot.

To be sure that this source and destination are included in those groups.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

@DPoppleton 

There is a setting where you can disallow any unknown-tcp or unknown-udp traffic; let me see if I can find it. 

 

edit: I can't seem to find it with a quick glance but I'm fairly certain that was/is a thing. In the meantime you could utilize an application-override policy to classify the traffic as another application, or a custom application, and it should match your existing rule. 

We tried that already. A rule with just the server as the source, and the object it was trying to go to as the destination, any application with a service of tcp/50000. Still fell through to the deny rule at the end as unknown-tcp.

@DPoppleton ,

That would lead me to possibly start looking at the address objects that were passed in and seeing if they somehow are the problem. Try testing with a policy that actually specifies the IP of one of the servers and see if you see the same behavior. 

@BPry the destination is a FQDN. I verified that the name resolved in the firewall by using "request system fqdn show" but I was wondering as well if there is failure with that somewhere.

 We have another test window on Monday... I'll let you know how it goes.

@DPoppleton,

Actually FQDN might explain things. What version did you actually upgrade this to? Throughout 8.0 there are a number of times where FQDN objects didn't work as expected. 

It's 8.0.15. I was kind of hoping all the bugs would have been found by now.

  • 4803 Views
  • 15 replies
  • 0 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!