Auto Zone Assign - IP range object as source IP

[markru114]

Hi All,

I have recently encountered a very strange issue in Expedition project when trying to make auto-zone assign. 

Quick background:
- In expedition project I have a config migrated from checkpoint
- we have around 15 direcly connected interfaces - all with IP somewhere in the range from 10.3.64.0 to 10.3.128.255, and 1 uplink from another range.
- Virtual router collecting all the interfaces of the firewall has a single default route via this uplink. All other interfaces are added as connected.
- Some of my security rules are having source address field based on the address-group object that matches following 2 address objects:
---- IP range address object (10.3.64.0 - 10.6.255.255)
---- Specific IP (host address object) outside of the firewall (to get there we follow a default route via uplink interface)

OBSERVATIONS:

Now,when I make auto-zone assign to calculate both source/destination zone (no NAT rules, and I am referring to this specific VR from my config), I am expecting to see ALL the zones under the source address, but I only see an uplink one.

When I then modified address-group as follows:

(WAS ALREADY THERE)---- IP range address object (10.3.64.0 - 10.6.255.255)
(WAS ALREADY THERE)---- Specific IP (host address object) outside of the firewall (to get there we follow a default route via uplink interface)
(THE NEW ONE I AM ADDING NOW)----- IP range address object (10.3.64.0 - 10.3.255.255)

After this, auto-zone assign resolves and puts all the zones from all interfaces as a source zone inside my security policies. Is anyone away on what is the exact code logic when evaluating zone assignements. The new range I have added is clearly within the already existing one, however it was not matched earlier.

Is this some bug or there are some undocumented limitations of the range objects that I am not aware of? Have anyone seen similar behavior?

Thanks a lot for any hints.

[lychiang]

@markru114 For checkpoint , Zone will be auto calculated based on route file and the connected interface , if you have the subnet 10.3.64.0 - 10.3.255.255 that's specified in the static route , then when you import the checkpoint config and static route file, expedition should auto calculate the zone for you.  Or you could add static route entry after import , and re-do autozone , it should also work.  If you have two route entries, expedition will evaluate both route statement and choose the most restrict one , for example, if you have below two static routes:

Destination Gateway Genmask Flags MSS Window irtt Iface
10.3.64.0 10.3.0.1 255.255.255.0 UGH 0 0 0 eth1-04 
10.3.0.0 10.2.0.1 255.255.0.0 UGH 0 0 0 eth1-03

Then Expedition will auto assign zone for any source or destination that fall under 10.3.64.0/24 to eth1-04 

[markru114]

Hi @lychiang , I fully agree with what you are saying, but it my case the problem revolves around CONNECTED INTERFACES. For some strange reason the network object used inside security policy that definitely covers the subnet used on the CONNECTED interface -  it doesn't add the zone of this connected interface. 

Let me know if my original problem description is clear on it, or I should re-word it.

[lychiang]

@markru114 Autozone should also consider connected interface, can you please open a TAC case to share the checkpoint config , after case is opened, please write an email to fwmigrate@paloaltonetworks.com mentioned about your case#. Thank you!

[markru114]

Hi @lychiang ,

I have done it in the last days. Let me know once you find out what is happening there in the background.

Thanks!