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

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.

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

L2 Linker

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.

 

Bildschirmfoto 2019-09-24 um 10.51.52.png

Bildschirmfoto 2019-09-24 um 10.52.21.png

 

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.

1 accepted solution

Accepted Solutions

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

 

Bildschirmfoto 2019-09-25 um 09.07.19.png

 

WEIRD PROBLEM

 

Bildschirmfoto 2019-09-25 um 09.06.23.png

View solution in original post

3 REPLIES 3

Cyber Elite
Cyber Elite

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. 

Help the community: Like helpful comments and mark solutions

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.

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

 

Bildschirmfoto 2019-09-25 um 09.07.19.png

 

WEIRD PROBLEM

 

Bildschirmfoto 2019-09-25 um 09.06.23.png

  • 1 accepted solution
  • 4864 Views
  • 3 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!