Default Application ID change in 8.0?

[DPoppleton]

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?

[Raido_Rattameister]

Do you have "application-default" as Service?

Change it to "any" and test.

[DPoppleton]

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

[Raido_Rattameister]

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

[DPoppleton]

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

[Raido_Rattameister]

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

[DPoppleton]

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

[Raido_Rattameister]

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.

[BPry]

@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. 

[DPoppleton]

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.

[BPry]

@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. 

[DPoppleton]

@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.

[DPoppleton]

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

[BPry]

@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. 

[DPoppleton]

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