Sudden issues with address objects in policy rules- behaves as if 0.0.0.0/0 is set

[pan219]

Since about 4 days I am experiencing a critical problem in relation to policy rules with address objects and suspect an update to address/region objects has caused this mess as I am experiencing this issue with:

- manually added address objects

- predefined country regions

- dynamic address groups (based on tags- even if the address group is empty it is treated by the FW as if every host is in the group, like 0.0.0.0/0)

Those rules have been working flawlessly for months.

 I am running 9.0.3-h3 on this lab device and already have a opened a support case.

The following pictures describe the problem best. The only change I have made was creating an address object (yet unused) named 0.0.0.0/0 with the same network range which should not cause the problem at all, except if there is a unknown bug...

I already have confirmed via CLI that it is not a problem with the web gui (contents of address objects, region etc.). I also recreated affected rules which does not solve the problem.

After those exceptions I have set a catch-all rule for decryption of any other traffic. Problem is, traffic does not make to the catch-all since the rule erroneously catches everything when address objects are assigned.

[S.Cantwell]

I am running same version of software on PAN-220, and do not experience this same issue.

It is hard to confirm/prove that a policy with destination address of RU would be affected traffic destined to Netherlands or EU.

Because the rule name is blocked out, I will need to take your word for it, but that is not how the FW works.  😛

If you have a case opened with TAC, better to let them resolve if it is indeed, and undocumented bug/anomaly in the software.

Keep us posted. 

[pan219]

The rule name being blanked out is the exact same rule which blocks the traffic in the log which makes no sense at all. It really must be some weird bug I am experiencing (not the first time since I am always running the newest version on this lab device with multiple configuration changes frequently...)

The problem always appears when address objects are involved, be it in security policy or decryption policy. Ticket is open with TAC since 5 days now

I'll keep you posted on this as the sudden nature of this issue really can freak one out running in production environment. I wouldn't have noticed it this fast if it wasn't for the first security policy rule which blocks all traffic based on membership of an dynamic address group which at the time the FW was blocking everything has contained 0 members but it blocked all traffic.

[pan219 · Accepted solution]

wow..I really think I found the solution to this weird problem. it is reproducible (for me at least).

It somehow is related to the address object being named 0.0.0.0 with netwmask 0.0.0.0/0 which caused this issue even though it wasn't used anywhere in relation to where the problem occurred. I use the address object at 3 locations:

- hairpin nat rule ntp
- hairpin nat rule dns

- global protect gateway split tunnel access route inclusion

I had already created a new address object on the journey of troubleshooting and replaced it in the two nat rules which was no success. I now have gone the same route but this time replaced the object also in the global protect gateway split tunnel access route inclusion and the problem disappeared.

Object name 0.0.0.0 (network range 0.0.0.0/0) caused the problems if it is placed in split tunnel inclusions

Object name ALL (network range 0.0.0.0/0) works as expected.

so the problem is related to the name which is pretty weird.

NO PROBLEM

WEIRD PROBLEM