Policy Object: Addresses
Focus
Focus
Network Security

Policy Object: Addresses

Table of Contents

Policy Object: Addresses

Reuse and reference an address or group of addresses across policy rules, filters, or other functions without having to manually add the address or addresses each time.
Where Can I Use This?
What Do I Need?
  • NGFW (Cloud Managed)
  • NGFW (PAN-OS & Panorama Managed)
  • Prisma Access (Cloud Management)
  • Prisma Access (Panorama Managed)
Check for any license or role requirements for the products you're using:
  • Prisma Access
    license or AIOps for NGFW license
An address object is a set of IP addresses that you can manage in one place and then use in multiple policy rules, filters, and other functions. An address object can include either IPv4 or IPv6 addresses (a single IP address, a range of addresses, or a subnet), an FQDN, or a wildcard address (IPv4 address followed by a slash and wildcard mask). An address object of type IP Netmask, IP Range, or FQDN can specify IPv4 or IPv6 addresses. An address object of type IP Wildcard Mask can specify only IPv4 addresses.
There are four types of address objects:
  • IP Netmask
    - IP address or a network must be entered using slash notation to indicate the IPv4 network or the IPv6 prefix length. For example, 192.168.18.0/24 or 2001:db8:123:1::/64.
  • IP Range
    - the IPv4 or IPv6 range of addresses must be separated by a hyphen.
  • FQDN
    - For example, paloaltonetworks.com. This is easy to use because DNS provides the FQDN resolution to the IP addresses instead of you needing to know the IP addresses and manually updating them every time the FQDN resolves to new IP addresses.
  • - This is useful if you define private IPv4 addresses to internal devices and your addressing structure assigns meaning to certain bits in the address.
It's important to understand that in policy rules, the set of IPv4 addresses is treated as a subset of the set of IPv6 addresses. However, the set of IPv6 addresses isn't a subset of the set of IPv4 addresses. An IPv4 address can match a set or range of IPv6 addresses; but an IPv6 address cannot match a set or range of IPv4 addresses.
In all policy types, the keyword
any
for a source or destination address means any IPv4 or IPv6 address. The keyword
any
is equivalent to ::/0. If you want to express "any IPv4 address", specify 0.0.0.0/0.
During policy matching, an IPv4 address is converted into an IPv6 prefix where the first 96 bits are 0. An address of ::/8 means, match the rule if the first 8 bits are 0. All IPv4 addresses will match ::/8, ::/9, ::/10, ::/11, ... ::/16, ... ::/32, ... through ::/96.
If you want to express "any IPv6 address, but no IPv4 addresses", you must configure two rules. The first rule denies 0.0.0.0/0 to deny any IPv4 address (as the source or destination address), and the second rule has ::/0 to mean any IPv6 address (as the source or destination address), to satisfy your requirement.
Use of Address Object Type
: Create an address object to group IP addresses or to specify an FQDN, and then reference the address object in a policy rule, filter, or other function to avoid having to individually specify multiple IP addresses in the rule, filter, or other function. You can reference the same address object in multiple policy rules, filters, or other functions without needing to specify the same individual addresses in each use. For example, you can create an address object that specifies an IPv4 address range and then reference the address object in a Security policy rule, a NAT policy rule, and a custom report log filter. You create an address object using the web interface or CLI. Changes require a commit operation to make the object a part of the configuration.
  • You can reference an address object of type
    IP Netmask
    ,
    IP Range
    , or
    FQDN
    in a policy rule for Security, Authentication, NAT, NAT64, Decryption, DoS Protection, Policy-Based Forwarding (PBF), QoS, Application Override, or Tunnel Inspection; or in a NAT address pool, VPN tunnel, path monitoring, External Dynamic List, Reconnaissance Protection, ACC global filter, log filter, or custom report log filter.
  • You can reference an address object of type
    IP Wildcard Mask
    only in a Security policy rule.

More on IP Wildcard Mask

Now let's talk about using a wildcard address object in a Source Address or Destination Address of a Security policy rule. When you assign private IPv4 addresses to internal devices, you can use an IP addressing structure that assigns meaning to certain bits in the address. For example, the first three bits in the third octet of an IP address signify the device type. This structure helps you easily identify details about a device, such as device type or location, based on the IP address of the device. You can use this same IP addressing structure in Security policy rules for easier deployment. You create an address object that uses a wildcard address (IP address and wildcard mask separated by a slash, such as 10.1.2.3/0.127.248.0). A wildcard address can identify many source or destination addresses in a single Security policy rule, which is especially helpful for data centers serving many devices. You won’t have to manage an unnecessarily large number of address objects to cover all the matching IP addresses or use less restrictive Security policy rules than you need due to IP address capacity constraints.
For example, suppose you use the IPv4 addressing scheme shown in the following figure where the first octet represents your organization (bits 00001010 are fixed). In the second octet, the first four bits designate the country where the network device is located (1000 indicates the U.S.) and the last four bits indicate the region (0100 indicates the northeast). In the third octet, the first four bits are zeros and the last four bits indicate device type (0001 indicates cash register and 0011 indicates printer). The last octet indicates the ID number of the networking device.
Based on that structure, the IP address of cash register number 156 in the northeastern U.S. would be 10.132.1.156:
You can use an address object of type
IP Wildcard Mask
to support such an addressing structure in a Security policy rule. You apply a wildcard mask to an IPv4 source or destination address to specify which addresses are subject to the rule. In a Palo Alto Networks wildcard mask, a zero bit indicates that the bit being compared must match the bit in the IP address that is covered by the zero. A one bit in the mask is a wildcard or “ignore” bit, meaning the bit being compared need not match the bit in the IP address. For example, the following snippets of an IP address and wildcard mask illustrate how they yield four matches:
Not all vendors use a one as a wildcard bit and a zero as a matching bit.
In the example, cash registers have an IPv4 address with the third octet 00000001 and printers have an IPv4 address with the third octet 00000011. Suppose you want to apply a Security policy rule to all cash registers and printers having any ID number from 0 to 255. To get that result, you need a wildcard mask; the third octet of the wildcard mask must be 2 and the device ID (the fourth octet) must be 255. The address object to specify all cash registers and printers in the northeastern U.S. would use wildcard address 10.132.1.2/0.0.2.255:
Thus, a single Security policy rule that uses an address object with wildcard address 10.132.1.2/0.0.2.255 as the destination address matches the addresses of 512 devices (256 cash registers + 256 printers), which is an efficient way to apply a rule to many devices. The wildcard mask must begin with at least one zero (0), such as 0.0.2.255.
Consider the following when you use an address object of type
IP Wildcard Mask
in a Security policy rule:
  • A source or destination address that uses an address object of type
    IP Wildcard Mask
    doesn’t support the
    Negate
    option.
  • Your environment oesn’t consider wildcard addresses when doing shadow matching, which means you won’t be warned if a Security policy rule using an address object of type
    IP Wildcard Mask
    overlaps a subsequent rule or is overlapped by a rule higher on the list.
  • If an address matches rules that have overlapping wildcard masks, the match to the longest prefix in the wildcard mask is chosen, as shown in the following figure:
The behavior in the preceding bullet is the default behavior. However, there are use cases where you want to have broad rules that allow some sources access to generic applications (such as Ping, Traceroute, and web-browsing), but have narrower rules that allow a subset of these sources access to different applications (such as SSH, SCP) in addition to the generic applications. In earlier releases, such a deployment did not work because only the match to the rule with the longest prefix in the wildcard mask was processed and other rules were not considered.
Beginning with
PAN-OS 10.2.1
, you can enable
Wildcard Top Down Match Mode
so that if a packet with an IP address matches prefixes in Security policy rules that have overlapping wildcard masks, the first fully matching rule in top-down order is chosen (instead of choosing the matching rule with the longest prefix in a wildcard mask). A packet is found to match the prefix in rules that use overlapping wildcard masks; then those rules that fully match all address bits based on masking are chosen, keeping in mind the ones in the mask indicate wildcard or “ignore” bits. Then other rule criteria, such as application and zones, are examined. During the other rule criteria examination, the first of those rules (in top-down order) that match the criteria is chosen. No other rules are evaluated.
The
Wildcard Top Down Match Mode
means that more than one rule has the potential to be enforced on different packets (not just the rule with the longest matching prefix). Place your more specific rules toward the top of the list. For example, you can allow a smaller range of matching addresses (a longer wildcard mask) to access certain applications, and also, in a subsequent rule allow a larger range of IP addresses (a shorter wildcard mask) to access a different (more generic) set of applications. You can enable
Wildcard Top Down Match Mode
by selecting
Device
Setup
Management
and editing the Policy Rulebase Settings.
The following example has
Wildcard Top Down Match Mode
enabled and three Security policy rules, each specifying a source IP address with wildcard mask address object, and the wildcard masks overlap:
In this example, Client A with source IP address 10.143.8.1 (0000 1010 1000 1111 0000 1000 0000 0001) fully matches Rule 1, Rule 2, and Rule 3; the first match is to Rule 1 (top-down order). Assuming other rule criteria match, the packet from Client A is subject to the Rule 1 action.
Client B with source IP address 10.160 2.1 (0000 1010 1010 0000 0000 0010 0000 0001) does not fully match the address in Rule 1 and does not match the prefix in Rule 2. Client B’s address fully matches Rule 3, which is the first matching rule in top-down order. Assuming other rule criteria match, the packet from Client B is subject to the Rule 3 action. Thus we see the benefit of
Wildcard Top Down Match Mode
, that both Rule 1 and Rule 3 can be in effect on different packets.

Recommended For You