Reusable Objects

The following topics describe how to manage reusable objects in the Firepower System:
• Introduction to Reusable Objects, on page 2
• The Object Manager, on page 4
• Network Objects, on page 10
• Port Objects, on page 12
• Tunnel Zones, on page 13
• Application Filters, on page 14
• VLAN Tag Objects, on page 14
• Security Group Tag Objects, on page 15
• URL Objects, on page 16
• Geolocation Objects, on page 17
• Interface Objects: Interface Groups and Security Zones, on page 18
• Time Range Objects, on page 20
• Variable Sets, on page 21
• Security Intelligence Lists and Feeds, on page 35
• Sinkhole Objects, on page 46
• File Lists, on page 47
• Cipher Suite Lists, on page 51
• Distinguished Name Objects, on page 52
• PKI Objects, on page 54
• Key Chain Objects, on page 69
• DNS Server Group Objects, on page 71
• SLA Monitor Objects, on page 72
• Prefix Lists, on page 73
• Route Maps, on page 74
• Access List, on page 77
• AS Path Objects, on page 79
• Community Lists, on page 80
• Policy Lists, on page 81
• VPN Objects, on page 82
• Address Pools, on page 95
• FlexConfig Objects, on page 96
• RADIUS Server Groups, on page 96

Reusable Objects
1
 Reusable Objects
Introduction to Reusable Objects

Introduction to Reusable Objects

For increased flexibility and web interface ease-of-use, the Firepower System uses named objects, which are
reusable configurations that associate a name with a value. When you want to use that value, use the named
object instead. The system supports object use in various places in the web interface, including many policies
and rules, event searches, reports, dashboards, and so on. The system provides many predefined objects that
represent frequently used configurations.
Use the object manager to create and manage objects. Many configurations that use objects also allow you to
create objects on the fly, as needed. You can also use the object manager to:
• View the policies, settings, and other objects where a network, port, VLAN, or URL object is used; see
Viewing Objects and Their Usage, on page 5.
• Group objects to reference multiple objects with a single configuration; see Object Groups, on page 6.
• Override object values for selected devices or, in a multidomain deployment, selected domains; see
Object Overrides, on page 7.

After you edit an object used in an active policy, you must redeploy the changed configuration for your changes
to take effect. You cannot delete an object that is in use by an active policy.

Note An object is configured on a managed device if, and only if, the object is used in a policy that is assigned to
that device. If you remove an object from all policies assigned to a given device, the object is also removed
from the device configuration on the next deployment, and subsequent changes to the object are not reflected
in the device configuration.

Object Types
The following table lists the objects you can create in the Firepower System, and indicates whether each object
type can be grouped or configured to allow overrides.

Object Type Groupable? Allows Overrides?

Network yes yes

Port yes yes

Interface: no no
• Security Zone
• Interface Group

Tunnel Zone no no

Application Filter no no

VLAN Tag yes yes

Security Group Tag (SGT) no no

Reusable Objects
2
Reusable Objects
Introduction to Reusable Objects

Object Type Groupable? Allows Overrides?

URL yes yes

Geolocation no no

Time Range no no

Variable Set no no

Security Intelligence: Network, DNS, and URL lists and no no

feeds

Sinkhole no no

File List no no

Cipher Suite List no no

Distinguished Name yes no

Public Key Infrastructure (PKI): yes no

• Internal and Trusted CA
• Internal and External Certs

Key Chain no yes

DNS Server Group no no

SLA Monitor no no

Prefix List: IPv4 and IPv6 no yes

Route Map no yes

Access List: Standard and Extended no yes

AS Path no yes

Community List no yes

Policy List no yes

FlexConfig: Text and FlexConfig objects no yes

Objects and Multitenancy

In a multidomain deployment, you can create objects in Global and descendant domains with the exception
of Security Group Tag (SGT) objects, which you can create only in the Global domain. The system displays
objects created in the current domain, which you can edit. It also displays objects created in ancestor domains,
which you cannot edit, with the exception of security zones and interface groups.

Reusable Objects
3
 Reusable Objects
The Object Manager

Note Because security zones and interface groups are tied to device interfaces, which you configure at the leaf
level, administrators in descendant domains can view and edit zones and groups created in ancestor domains.
Subdomain users can add and delete interfaces from ancestor zones and groups, but cannot delete or rename
the zones/groups.

Object names must be unique within the domain hierarchy. The system may identify a conflict with the name
of an object you cannot view in your current domain.
For objects that support grouping, you can group objects in the current domain with objects inherited from
ancestor domains.
Object overrides allow you to define device-specific or domain-specific values for certain types of object,
including network, port, VLAN tag, and URL. In a multidomain deployment, you can define a default value
for an object in an ancestor domain, but allow administrators in descendant domains to add override values
for that object.

The Object Manager

You can use the object manager to create and manage objects and object groups.
The object manager displays 20 objects or groups per page. If you have more than 20 of any type of object
or group, use the navigation links at the bottom of the page to view additional pages. You can also go to a
specific page or click Refresh ( ) to refresh your view.
By default, the page lists objects and groups alphabetically by name. You can filter the objects on the page
by name or value.

Editing Objects
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Choose an object type from the list; see Introduction to Reusable Objects, on page 2.

Step 3 Click Edit ( ) next to the object you want to edit.

If View ( ) appears instead, the object belongs to an ancestor domain and has been configured not to allow overrides,
or you do not have permission to modify the object.

Step 4 Modify the object settings as desired.

Step 5 If you are editing a variable set, manage the variables in the set; see Managing Variables, on page 32.
Step 6 For objects that can be configured to allow overrides:
• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9. You can change this setting only for objects that belong to the current domain.

Reusable Objects
4
 Reusable Objects
Viewing Objects and Their Usage

• If you want to add override values to this object, expand the Override section and click Add; see Adding Object
Overrides, on page 9.

Step 7 Click Save.

Step 8 If you are editing a variable set, and that set is in use by an access control policy, click Yes to confirm that you want to
save your changes.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Viewing Objects and Their Usage

You can view usage details of objects on the Object Management page. The network, port, VLAN, and URL
object types are the only object types that provide this functionality.

Note In a multidomain deployment, you can view objects from any other domain. However, to find usage of objects
in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Choose one of the following object types:
• Network
• Port
• VLAN Tag
• URL

Step 3 Click Find Usage ( ) next to the object.

The Object Usage window displays a list of all the policies, objects, and other settings where the object is in use. Click
any of the listed items to know more about the object usage. For policies and some other settings where the object is used,
you can click the corresponding links to visit the respective UI pages.

Filtering Objects or Object Groups

In a multidomain deployment, the system displays objects created in the current and ancestor domains, which
you can filter.

Step 1 Choose Objects > Object Management.

Reusable Objects
5
 Reusable Objects
Object Groups

Step 2 Enter your filter criteria in the Filter field.

The page updates as you type to display matching items.
You can use the following wildcards:
• The asterisk (*) matches zero or more occurrences of a character.
• The caret (^) matches content at the beginning of a string.
• The dollar sign ($) matches content at the end of a string.

Object Groups
Grouping objects allows you to reference multiple objects with a single configuration. The system allows you
to use objects and object groups interchangeably in the web interface. For example, anywhere you would use
a port object, you can also use a port object group.
You can group network, port, VLAN tag, URL, and PKI objects. Network object groups can be nested, that
is, you can add a network object group to another network object group up to 10 levels.
Objects and object groups of the same type cannot have the same name. In a multidomain deployment, the
names of object groups must be unique within the domain hierarchy. Note that the system may identify a
conflict with the name of an object group you cannot view in your current domain.
When you edit an object group used in a policy (for example, a network object group used in an access control
policy), you must re-deploy the changed configuration for your changes to take effect.
Deleting a group does not delete the objects in the group, just their association with each other. Additionally,
you cannot delete a group that is in use in an active policy. For example, you cannot delete a VLAN tag group
that you are using in a VLAN condition in a saved access control policy.

Grouping Reusable Objects

In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
You can group objects in the current domain with objects inherited from ancestor domains.

Step 1 Choose Objects > Object Management.

Step 2 If the object type you want to group is Network, Port, URL, or VLAN Tag:
a) Choose the object type from the list of object types.
b) Choose Add Group from the Add [Object Type] drop-down list.
Step 3 If the object type you want to group is Distinguished Name:
a) Expand the Distinguished Name node.
b) Choose Object Groups.
c) Click Add Distinguished Name Group.
Step 4 If the object type you want to group is PKI:
a) Expand the PKI node.

Reusable Objects
6
 Reusable Objects
Object Overrides

b) Choose one of the following:

• Internal CA Groups
• Trusted CA Groups
• Internal Cert Groups
• External Cert Groups

c) Click Add [Object Type] Group.

Step 5 Enter a unique Name.
Step 6 Choose one or more objects from the list, and click Add.
You can also:

• Use the filter field Search ( ) to search for existing objects to include, which updates as you type to display matching
items. Click Reload ( ) above the search field or click Clear ( ) in the search field to clear the search string.

• Click Add ( ) to create objects on the fly if no existing objects meet your needs.

Step 7 Optionally for Network, Port, URL, and VLAN Tag groups:
• Enter a Description.
• Check the Allow Overrides check box to allow overrides for this object group; see Allowing Object Overrides, on
page 9.

Step 8 Click Save.

What to do next
• If an active policy references your object group, deploy configuration changes; see Deploy Configuration
Changes.

Object Overrides
An object override allows you to define an alternate value for an object, which the system uses for the devices
you specify.
You can create an object whose definition works for most devices, and then use overrides to specify
modifications to the object for the few devices that need different definitions. You can also create an object
that needs to be overridden for all devices, but its use allows you to create a single policy for all devices.
Object overrides allow you to create a smaller set of shared policies for use across devices without giving up
the ability to alter policies when needed for individual devices.
For example, you might want to deny ICMP traffic to the different departments in your company, each of
which is connected to a different network. You can do this by defining an access control policy with a rule
that includes a network object called Departmental Network. By allowing overrides for this object, you can
then create overrides on each relevant device that specifies the actual network where that device is connected.
In a multidomain deployment, you can define a default value for an object in an ancestor domain and allow
administrators in descendant domains to add override values for that object. For example, a managed security

Reusable Objects
7
 Reusable Objects
Managing Object Overrides

service provider (MSSP) might use a single Firepower Management Center to manage network security for
multiple customers. Administrators at the MSSP can define an object in the Global domain for use in all
customers' deployments. Administrators for each customer can log into descendant domains to override that
object for their organizations. These local administrators cannot view or affect the override values of other
customers of the MSSP.
You can target an object override to a specific domain. In this case, the system uses the object override value
for all devices in the targeted domain unless you override it at the device level.
From the object manager, you can choose an object that can be overridden and define a list of device-level or
domain-level overrides for that object.
You can use object overrides with the following object types only:
• Network
• Port
• VLAN tag
• URL
• SLA Monitor
• Prefix List
• Route Map
• Access List
• AS Path
• Community List
• Policy List
• PKI Enrollment
• Key Chain

If you can override an object, the Override column appears for the object type in the object manager. Possible
values for this column include:
• Green checkmark — indicates that you can create overrides for the object and no overrides have been
added yet
• Red X — indicates that you cannot create overrides for the object
• Number — represents a count of the overrides that have been added to that object (for example, "2"
indicates two overrides have been added)

Managing Object Overrides

Step 1 Choose Objects > Object Management.

Step 2 Choose from the list of object types; see Introduction to Reusable Objects, on page 2.

Step 3 Click Edit ( ) next to the object you want to edit.

Reusable Objects
8
 Reusable Objects
Allowing Object Overrides

If View ( ) appears instead, the object belongs to an ancestor domain and has been configured not to allow overrides,
or you do not have permission to modify the object.

Step 4 Manage the object overrides:

• Add—Add object overrides; see Adding Object Overrides, on page 9.
• Allow—Allow object overrides; see Allowing Object Overrides, on page 9.

• Delete—In the object editor, click Delete ( ) next to the override you want to remove.
• Edit—Edit object overrides; see Editing Object Overrides, on page 10.

Allowing Object Overrides

Step 1 In the object editor, check the Allow Overrides check box.
Step 2 Click Save.

What to do next
Add object override values; see Adding Object Overrides, on page 9.

Adding Object Overrides

Before you begin

Allow object overrides; see Allowing Object Overrides, on page 9.

Step 1 In the object editor, expand the Override section.

Step 2 Click Add.
Step 3 On Targets, choose domains or devices in the Available Devices and Domains list and click Add.
Step 4 On the Override tab, enter a Name.
Step 5 Optionally, enter a Description.
Step 6 Enter an override value.
Example:
For a network object, enter a network value.

Step 7 Click Add.

Step 8 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Reusable Objects
9
 Reusable Objects
Editing Object Overrides

Editing Object Overrides

You can modify the description and the value of an existing override, but you cannot modify the existing
target list. Instead, you must add a new override with new targets, which replaces the existing override.

Step 1 In the object editor, expand the Override section.

Step 2 Click Edit ( ) next to the override you want to modify.

Step 3 Optionally, modify the Description.
Step 4 Modify the override value.
Step 5 Click Save to save the override.
Step 6 Click Save to save the object.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Network Objects
A network object represents one or more IP addresses. You can use network objects and groups in various
places in the system’s web interface, including access control policies, network variables, identity rules,
network discovery rules, event searches, reports, and so on.
When you configure an option that requires a network object, the list is automatically filtered to show only
those objects that are valid for the option. For example, some options require host objects, while other options
require subnets.
A network object can be one of the following types:
Host
A single IP address.
IPv4 example:
[Link]

IPv6 example:
2001:DB8::0DB8:800:200C:417A or 2001:DB8:0:0:0DB8:800:200C:417A

Range
A range of IP addresses.
IPv4 example:
[Link]-[Link]

IPv6 example:
2001:db8:0:cd30::1-2001:db8:0:cd30::1000

Reusable Objects
10
 Reusable Objects
Creating Network Objects

Network
An address block, also known as a subnet.
IPv4 example:
[Link]/27

IPv6 example:
2001:DB8:0:CD30::/60

Note Security Intelligence ignores IP address blocks using a /0 netmask.

FQDN
A single fully-qualified domain name (FQDN). FQDN resolution in only IPv4 address, only IPv6 address,
and both IPv4 and IPv6 addresses are supported.
For example:
[Link]

Note • FQDNs must begin and end with a digit or letter. Only letters, digits, and hyphens are allowed as
internal characters in an FQDN.
• You can use FQDN objects only in access control rules and prefilter rules. The rules match the IP
address obtained for the FQDN through a DNS lookup. The first instance of the FQDN resolution
occurs when the FQDN object is deployed in an access control policy. To use an FQDN network
object, ensure you have configured the DNS server settings in DNS Server Group Objects, on page
71 and the DNS platform settings in Configure DNS.

Group
A group of network objects or other network object groups.
For example:
[Link]
[Link]
[Link]

You can create nested groups by adding one network object group to another network object group. You
can nest up to 10 levels of groups.

Creating Network Objects

Step 1 Choose Objects > Object Management.

Step 2 Choose Network from the list of object types.
Step 3 Choose Add Object from the Add Network drop-down menu.

Reusable Objects
11
 Reusable Objects
Port Objects

Step 4 Enter a Name.

In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Optionally, enter a Description.

Step 6 In the Network field, select the required option and enter an appropriate value; see Network Objects, on page 10.
Step 7 (FQDN objects only) Select the DNS resolution from the Lookup drop-down menu to determine whether you want the
IPv4, IPv6, or both IPv4 and IPv6 addresses associated with the FQDN.
Step 8 Manage overrides for the object:
• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
• If you want to add override values to this object, expand the Override section and click Add; see Adding Object
Overrides, on page 9.

Step 9 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Port Objects
Port objects represent different protocols in slightly different ways:
TCP and UDP
A port object represents the transport layer protocol, with the protocol number in parentheses, plus an
optional associated port or port range. For example: TCP(6)/22.
ICMP and ICMPv6 (IPv6-ICMP)
A port object represents the Internet layer protocol plus an optional type and code. For example:
ICMP(1):3:3.

You can restrict an ICMP or IPV6-ICMP port object by type and, if applicable, code. For more information
on ICMP types and codes, see:
• [Link]
• [Link]

Other
A port object can represent other protocols that do not use ports.
The Firepower System provides default port objects for well-known ports. You cannot modify or delete these
default objects. You can create custom port objects in addition to the default objects.
You can use port objects and groups in various places in the system’s web interface, including access control
policies, identity rules, network discovery rules, port variables, and event searches. For example, if your

Reusable Objects
12
 Reusable Objects
Creating Port Objects

organization uses a custom client that uses a specific range of ports and causes the system to generate excessive
and misleading events, you can configure your network discovery policy to exclude monitoring those ports.
When using port objects, observe the following guidelines:
• You cannot add any protocol other than TCP or UDP for source port conditions in access control rules.
Also, you cannot mix transport protocols when setting both source and destination port conditions in a
rule.
• If you add an unsupported protocol to a port object group used in a source port condition, the rule where
it is used does not take affect on the managed device when the configuration is deployed.
• If you create a port object containing both TCP and UDP ports, then add it as a source port condition in
a rule, you cannot add a destination port, and vice versa.

Creating Port Objects

Step 1 Choose Objects > Object Management.

Step 2 Choose Port from the list of object types.
Step 3 Choose Add Object from the Add Port drop-down list.
Step 4 Enter a Name.
Step 5 Choose a Protocol.
Step 6 Depending on the protocol you chose, constrain by Port, or choose an ICMP Type and Code.
You can enter ports from 1 to 65535. Use a hyphen to specify a port range. You must constrain the object by port if you
chose to match All protocols, using the Other drop-down list.

Step 7 Manage overrides for the object:

• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
• If you want to add override values to this object, expand the Override section and click Add; see Adding Object
Overrides, on page 9.

Step 8 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Tunnel Zones
A tunnel zone represents certain types of plaintext, passthrough tunnels that you explicitly tag for special
analysis. A tunnel zone is not an interface object, even though you can use it as an interface constraint in some
configurations.
For detailed information, see Tunnel Zones and Prefiltering.

Reusable Objects
13
 Reusable Objects
Application Filters

Application Filters
System-provided application filters help you perform application control by organizing applications according
to basic characteristics: type, risk, business relevance, category, and tags. In the object manager, you can
create and manage reuseable user-defined application filters based on combinations of the system-provided
filters, or on custom combinations of applications. For detailed information, see Application Conditions
(Application Control).

VLAN Tag Objects

Each VLAN tag object you configure represents a VLAN tag or range of tags.
You can group VLAN tag objects. Groups represent multiple objects; using a range of VLAN tags in a single
object is not considered a group in this sense.
You can use VLAN tag objects and groups in various places in the system’s web interface, including rules
and event searches. For example, you could write an access control rule that applies only to a specific VLAN.

Creating VLAN Tag Objects

Step 1 Choose Objects > Object Management.

Step 2 Choose VLAN Tag from the list of object types.
Step 3 Choose Add Object from the Add VLAN Tag drop-down list.
Step 4 Enter a Name.
Step 5 Enter a Description.
Step 6 Enter a value in the VLAN Tag field. Use a hyphen to specify a range of VLAN tags.
Step 7 Manage overrides for the object:
• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
• If you want to add override values to this object, expand the Override section and click Add; see Adding Object
Overrides, on page 9.

Step 8 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Reusable Objects
14
 Reusable Objects
Security Group Tag Objects

Security Group Tag Objects

A Security Group Tag (SGT) object specifies a single SGT value. You can use SGT objects in rules to control
traffic with SGT attributes that were not assigned by Cisco ISE. You cannot group or override SGT objects.
Related Topics
Autotransition from Custom SGTs to ISE SGTs
Custom SGT Conditions
ISE SGT vs Custom SGT Rule Conditions

Creating Security Group Tag Objects

You can create these objects in the global domain only. To use the object on Classic devices, you must have
the Control license. For Smart Licensed devices, any license will do.

Before you begin

• Disable ISE/ISE-PIC connections. You cannot create custom SGT objects if you use ISE/ISE-PIC as an
identity source.

Step 1 Click Objects > Object Management.

Step 2 Click Security Group Tag from the list of object types.
Step 3 Click Add Security Group Tag.
Step 4 Enter a Name.
Step 5 Optionally, enter a Description.
Step 6 In the Tag field, enter a single SGT.
Step 7 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Related Topics
Autotransition from Custom SGTs to ISE SGTs
Custom SGT Conditions
ISE SGT vs Custom SGT Rule Conditions

Reusable Objects
15
 Reusable Objects
URL Objects

URL Objects

Important For best practices for using this and similar options in Security Intelligence configurations and for URL rules
in access control and QoS policies, see Manual URL Filtering Options.

A URL object defines a single URL or IP address, whereas a URL group object can define more than one
URL or address. You can use URL objects and groups in various places in the system’s web interface, including
access control policies and event searches.
When creating URL objects, keep the following points in mind:
• If you do not include a path (that is, there is no / character in the URL), the match is based on the server’s
hostname only. The hostname is considered a match if it comes after the :// separator, or after any dot in
the hostname. For example, [Link] matches [Link] and [Link], but it does not match
[Link].
• If you include one or more / character, the entire URL string is used for a substring match, including the
server name, path, and any query parameters. However, we recommend that you do not use manual URL
filtering to block or allow individual web pages or parts of sites, as servers can be reorganized and pages
moved to new paths. Substring matching can also lead to unexpected matches, where the string you
include in the URL object also matches paths on unintended servers or strings within query parameters.
• The system disregards the encryption protocol (HTTP vs HTTPS). In other words, if you block a website,
both HTTP and HTTPS traffic to that website is blocked, unless you use an application condition to
target a specific protocol. When creating a URL object, you do not need to specify the protocol when
creating an object. For example, use [Link] rather than [Link]
• If you plan to use a URL object to match HTTPS traffic in an access control rule, create the object using
the subject common name in the public key certificate used to encrypt the traffic. Also, the system
disregards subdomains within the subject common name, so do not include subdomain information. For
example, use [Link] rather than [Link].
However, please understand that the subject common name in the certificate might be completely unrelated
to a web site’s domain name. For example, the subject common name in the certificate for [Link]
is *.[Link] (this of course might change at any time). You will get more consistent results if you
use the SSL Decryption policy to decrypt HTTPS traffic so that URL filtering rules work on decrypted
traffic.

Note URL objects will not match HTTPS traffic if the browser resumes a TLS session
because the certificate information is no longer available. Thus, even if you
carefully configure the URL object, you might get inconsistent results for HTTPS
connections.

Reusable Objects
16
 Reusable Objects
Creating URL Objects

Creating URL Objects

Step 1 Choose Objects > Object Management.

Step 2 Choose URL from the list of object types.
Step 3 Choose Add Object from the Add URL drop-down list.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Optionally, enter a Description.

Step 6 Enter the URL or IP address.
Step 7 Manage overrides for the object:
• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
• If you want to add override values to this object, expand the Override section and click Add; see Adding Object
Overrides, on page 9.

Step 8 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Geolocation Objects
Each geolocation object you configure represents one or more countries or continents that the system has
identified as the source or destination of traffic on your monitored network. You can use geolocation objects
in various places in the system’s web interface, including access control policies, SSL policies, and event
searches. For example, you could write an access control rule that blocks traffic to or from certain countries.
To ensure that you are using up-to-date information to filter your network traffic, Cisco strongly recommends
that you regularly update your Geolocation Database (GeoDB).

Creating Geolocation Objects

Step 1 Choose Objects > Object Management.

Step 2 Choose Geolocation from the list of object types.
Step 3 Click Add Geolocation.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Reusable Objects
17
 Reusable Objects
Interface Objects: Interface Groups and Security Zones

Step 5 Check the check boxes for the countries and continents you want to include in your geolocation object. Checking a
continent chooses all countries within that continent, as well as any countries that GeoDB updates may add under that
continent in the future. Unchecking any country under a continent unchecks the continent. You can choose any combination
of countries and continents.
Step 6 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Interface Objects: Interface Groups and Security Zones

Interface objects segment your network to help you manage and classify traffic flow. An interface object
simply groups interfaces. These groups may span multiple devices; you can also configure multiple interface
objects on a single device.
There are two types of interface objects:
• Security zones—An interface can belong to only one security zone.
• Interface groups—An interface can belong to multiple interface groups (and to one security zone).
You can use interface groups in Firepower Threat Defense NAT policies, prefilter policies, and QoS
policies.

Although tunnel zones are not interface objects, you can use them in place of security zones in certain
configurations; see Tunnel Zones and Prefiltering.
All interfaces in an interface object must be of the same type: all inline, passive, switched, routed, or ASA
FirePOWER. After you create an interface object, you cannot change the type of interfaces it contains.
The Interface Objects page of the object manager lists the security zones and interface groups configured on
your managed devices. The page also displays the type of interfaces in each interface object, and you can
expand each interface object to view which interfaces on which devices belong to each object.

Note Create inline sets before you add security zones for the interfaces in the inline set; otherwise security zones
are removed and you must add them again.

Model-Specific Notes and Warnings

During initial configuration of a 7000 or 8000 Series device, the system creates security zones based on the
detection mode you selected for the device. For example, the system creates a Passive zone in passive
deployments, while in inline deployments the system creates External and Internal zones. When you register
the device to the Firepower Management Center, those security zones are added to the FMC.

Reusable Objects
18
 Reusable Objects
Creating Security Zone and Interface Group Objects

Interface Objects and Multitenancy

In a multidomain deployment, you can create interface objects at any level. An interface object created in an
ancestor domain can contain interfaces that reside on devices in different domains. In this situation, subdomain
users viewing the ancestor interface object configuration in the object manager can see only the interfaces in
their domain.
Unless restricted by role, subdomain users can view and edit interface objects created in ancestor domains.
Subdomain users can add and delete interfaces from these interface objects. They cannot, however, delete or
rename the interface objects. You can neither view nor edit interface objects created in descendant domains.

Creating Security Zone and Interface Group Objects

Tip You can create empty interface objects and add interfaces to them later. To add an interface, the interface
must have a name. You can also create security zones (but not interface groups) while configuring interfaces
in Devices > Device Management.

Before you begin

• Understand the usage requirements and restrictions for each type of interface object. See Interface
Objects: Interface Groups and Security Zones, on page 18.
• Carefully determine the interface objects you need. You cannot change an existing security zone to an
interface group or vice-versa; instead you must create a new interface object.

Step 1 Choose Objects > Object Management.

Step 2 Choose Interface from the list of object types.
Step 3 Click Add > Security Zone or Add > Interface Group.
Step 4 Enter a Name.
Step 5 Choose an Interface Type.
Step 6 From the Device > Interfaces drop-down list, choose a device that contains interfaces you want to add.
When you create or edit a security zone, the Device > Interfaces drop-down list displays the cluster names for high
availability devices. Choose the cluster that contains the interfaces you want to add.

Step 7 Choose one or more interfaces.

Step 8 Click Add to add the interfaces you chose, grouped by device.
Step 9 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Reusable Objects
19
 Reusable Objects
Time Range Objects

Time Range Objects

Use time range objects to define time periods that you will use to determine when rules apply.

Creating Time Range Objects

If you want a policy to apply only during a specified time range, create a time range object, then specify that
object in the policy. Note that this object works on FTD devices only.
You can specify time range objects only in policy types listed at the bottom of this topic.

Step 1 Choose Objects > Object Management.

Step 2 Choose Time Range from the list of object types.
Step 3 Click Add Time Range.
Step 4 Enter values.
Observe the following guidelines:
• If you see a red error box around the object name you have entered, mouse over the Name field to see naming
restrictions.
• All times are in UTC.
• Enter times using a 24-hour clock. For example, enter 1:30 PM as 13:30.
• To specify a single continuous range, such as typical weekend hours (Fridays at 5pm through Mondays at 8am,
including evenings and nights), choose Range Type Range.
• To specify part of multiple days, such as Monday through Friday from 8am to 5pm (excluding evenings, nights, and
early mornings every day), choose Range Type Daily Interval.
• You can specify up to 28 time periods in a single object.
• To specify multiple noncontiguous times of day or different hours for different days, create multiple recurring
intervals. For example, to apply a policy at all times other than standard working hours, create a single time range
object with the following two recurring intervals:
• A Daily Interval for Monday through Friday from 5pm through 8am, and
• A Range recurring interval for Friday at 5pm through Monday at 8am.

Step 5 Click Save.

What to do next
In a VPN group policy object, specify the time range object using the Access Hours field. For details, see
Configure Group Policy Objects, on page 88 and Group Policy Advanced Options, on page 92.

Reusable Objects
20
 Reusable Objects
Variable Sets

Variable Sets
Variables represent values commonly used in intrusion rules to identify source and destination IP addresses
and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions,
adaptive profile updates, and dynamic rule states.

Tip Preprocessor rules can trigger events regardless of the hosts defined by network variables used in intrusion
rules.

You use variable sets to manage, customize, and group your variables. You can use the default variable set
provided by the system or create your own custom sets. Within any set you can modify predefined default
variables and add and modify user-defined variables.
Most of the shared object rules and standard text rules that the Firepower System provides use predefined
default variables to define networks and port numbers. For example, the majority of the rules use the variable
$HOME_NET to specify the protected network and the variable $EXTERNAL_NET to specify the unprotected (or
outside) network. In addition, specialized rules often use other predefined variables. For example, rules that
detect exploits against web servers use the $HTTP_SERVERS and $HTTP_PORTS variables.
Rules are more effective when variables more accurately reflect your network environment. At a minimum,
you should modify default variables in the default set. By ensuring that a variable such as $HOME_NET correctly
defines your network and $HTTP_SERVERS includes all web servers on your network, processing is optimized
and all relevant systems are monitored for suspicious activity.
To use your variables, you link variable sets to intrusion policies associated with access control rules or with
the default action of an access control policy. By default, the default variable set is linked to all intrusion
policies used by access control policies.
Adding a variable to any set adds it to all sets; that is, each variable set is a collection of all variables currently
configured on your system. Within any variable set, you can add user-defined variables and customize the
value of any variable.
Initially, the Firepower System provides a single, default variable set comprised of predefined default values.
Each variable in the default set is initially set to its default value, which for a predefined variable is the value
set by the Cisco Talos Intelligence Group (Talos) and provided in rule updates.
Although you can leave predefined default variables configured to their default values, Cisco recommends
that you modify a subset of predefined variables.
You could work with variables only in the default set, but in many cases you can benefit most by adding one
or more custom sets, configuring different variable values in different sets, and perhaps even adding new
variables.
When using multiple sets, it is important to remember that the current value of any variable in the default set
determines the default value of the variable in all other sets.
When you select Variable Sets on the Object Manager page, the object manager lists the default variable set
and any custom sets you created.
On a freshly installed system, the default variable set is comprised only of the default variables predefined
by Cisco.

Reusable Objects
21
 Reusable Objects
Variable Sets in Intrusion Policies

Each variable set includes the default variables provided by the system and all custom variables you have
added from any variable set. Note that you can edit the default set, but you cannot rename or delete the default
set.
In a multidomain deployment, the system generates a default variable set for each subdomain.

Caution Importing an access control or an intrusion policy overwrites existing default variables in the default variable
set with the imported default variables. If your existing default variable set contains a custom variable not
present in the imported default variable set, the unique variable is preserved.

Related Topics
Managing Variables, on page 32
Managing Variable Sets, on page 31

Variable Sets in Intrusion Policies

By default, the Firepower System links the default variable set to all intrusion policies used in an access control
policy. When you deploy an access control policy that uses an intrusion policy, intrusion rules that you have
enabled in the intrusion policy use the variable values in the linked variable set.
When you modify a custom variable set used by an intrusion policy in an access control policy, the system
reflects the status for that policy as out-of-date on the Access Control Policy page. You must re-deploy the
access control policy to implement changes in your variable set. When you modify the default set, the system
reflects the status of all access control policies that use intrusion policies as out-of-date, and you must re-deploy
all access control policies to implement your changes.

Variables
Variables belong to one of the following categories:
Default Variables
Variables provided by the Firepower System. You cannot rename or delete a default variable, and you
cannot change its default value. However, you can create a customized version of a default variable.
Customized Variables
Variables you create. These variables can include:
• customized default variables
When you edit the value for a default variable, the system moves the variable from the Default
Variables area to the Customized Variables area. Because variable values in the default set determine
the default values of variables in custom sets, customizing a default variable in the default set
modifies the default value of the variable in all other sets.
• user-defined variables
You can add and delete your own variables, customize their values within different variable sets,
and reset customized variables to their default values. When you reset a user-defined variable, it
remains in the Customized Variables area.
User-defined variables can be one of the following types:

Reusable Objects
22
 Reusable Objects
Predefined Default Variables

• network variables specify the IP addresses of hosts in your network traffic.

• port variables specify TCP or UDP ports in network traffic, including the value any for either
type.

For example, if you create custom standard text rules, you might also want to add your own user-defined
variables to more accurately reflect your traffic or as shortcuts to simplify the rule creation process.
Alternatively, if you create a rule that you want to inspect traffic in the “demilitarized zone” (or DMZ)
only, you can create a variable named $DMZ whose value lists the server IP addresses that are exposed.
You can then use the $DMZ variable in any rule written for this zone.
Advanced Variables
Variables provided by the Firepower System under specific conditions. These variables have a very
limited deployment.

Predefined Default Variables

By default, the Firepower System provides a single default variable set, which is comprised of predefined
default variables. The Cisco Talos Intelligence Group (Talos) uses rule updates to provide new and updated
intrusion rules and other intrusion policy elements, including default variables.
Because many intrusion rules provided by the system use predefined default variables, you should set
appropriate values for these variables. Depending on how you use variable sets to identify traffic on your
network, you can modify the values for these default variables in any or all variable sets.

Caution Importing an access control or an intrusion policy overwrites existing default variables in the default variable
set with the imported default variables. If your existing default variable set contains a custom variable not
present in the imported default variable set, the unique variable is preserved.

The following table describes the variables provided by the system and indicates which variables you typically
would modify. For assistance determining how to tailor variables to your network, contact Professional
Services or Support.

Table 1: System-Provided Variables

Variable Name Description Modify?

Defines known AOL Instant Messenger (AIM) servers, and is used in Not required.
$AIM_SERVERS
chat-based rules and rules that look for AIM exploits.

Defines Domain Name Service (DNS) servers. If you create a rule that Not required in current rule set.
$DNS_SERVERS
affects DNS servers specifically, you can use the $DNS_SERVERS variable
as a destination or source IP address.

Defines the network that the Firepower System views as the unprotected Yes, you should adequately define
$EXTERNAL_NET
network, and is used in many rules to define the external network. $HOME_NET and then exclude
$HOME_NET as the value for
$EXTERNAL_NET.

Defines non-encrypted ports used in intrusion rules that detect files in Not required.
$FILE_DATA_PORTS
a network stream.

Reusable Objects
23
 Reusable Objects
Predefined Default Variables

Variable Name Description Modify?

Defines the ports of FTP servers on your network, and is used for FTP Yes, if your FTP servers use ports
$FTP_PORTS
server exploit rules. other than the default ports (you can
view the default ports in the web
interface).

Defines the data channel ports where the packet decoder extracts the Not required.
$GTP_PORTS
payload inside a GTP (General Packet Radio Service [GPRS] Tunneling
Protocol) PDU.

Defines the network that the associated intrusion policy monitors, and Yes, to include the IP addresses for
$HOME_NET
is used in many rules to define the internal network. your internal network.

Defines the ports of web servers on your network, and is used for web Yes, if your web servers use ports
$HTTP_PORTS
server exploit rules. other than the default ports (you can
view the default ports in the web
interface).

Defines the web servers on your network. Used in web server exploit Yes, if you run HTTP servers.
$HTTP_SERVERS
rules.

Defines Oracle database server ports on your network, and is used in Yes, if you run Oracle servers.
$ORACLE_PORTS
rules that scan for attacks on Oracle databases.

Defines the ports you want the system to scan for shell code exploits, Not required.
$SHELLCODE_PORTS
and is used in rules that detect exploits that use shell code.

Defines the ports of SIP servers on your network, and is used for SIP Not required.
$SIP_PORTS
exploit rules.

Defines SIP servers on your network, and is used in rules that address Yes, if you run SIP servers, you
$SIP_SERVERS
SIP-targeted exploits. should adequately define
$HOME_NET and then include
$HOME_NET as the value for
$SIP_SERVERS.

Defines SMTP servers on your network, and is used in rules that address Yes, if you run SMTP servers.
$SMTP_SERVERS
exploits that target mail servers.

Defines SNMP servers on your network, and is used in rules that scan Yes, if you run SNMP servers.
$SNMP_SERVERS
for attacks on SNMP servers.

Identifies a legacy advanced variable that appears only when it existed No, you can only view or delete this
$SNORT_BPF
on your system in a Firepower System software release before Version variable. You cannot edit it or
5.3.0 that you subsequently upgraded to Version 5.3.0 or greater. recover it after deleting it.

Defines database servers on your network, and is used in rules that Yes, if you run SQL servers.
$SQL_SERVERS
address database-targeted exploits.

Defines the ports of SSH servers on your network, and is used for SSH Yes, if your SSH servers use ports
$SSH_PORTS
server exploit rules. other than the default port (you can
view the default ports in the web
interface).

Reusable Objects
24
 Reusable Objects
Network Variables

Variable Name Description Modify?

Defines SSH servers on your network, and is used in rules that address Yes, if you run SSH servers, you
$SSH_SERVERS
SSH-targeted exploits. should adequately define
$HOME_NET and then include
$HOME_NET as the value for
$SSH_SERVERS.

Defines known Telnet servers on your network, and is used in rules that Yes, if you run Telnet servers.
$TELNET_SERVERS
address Telnet server-targeted exploits.

Provides a general tool that allows you to configure one or more features No, only as instructed in a feature
$USER_CONF
not otherwise available via the web interface. description or with the guidance of
Support.
Conflicting or duplicate $USER_CONF configurations will halt the system.

Network Variables
Network variables represent IP addresses you can use in intrusion rules that you enable in an intrusion policy
and in intrusion policy rule suppressions, dynamic rule states, and adaptive profile updates. Network variables
differ from network objects and network object groups in that network variables are specific to intrusion
policies and intrusion rules, whereas you can use network objects and groups to represent IP addresses in
various places in the system’s web interface, including access control policies, network variables, intrusion
rules, network discovery rules, event searches, reports, and so on.
You can use network variables in the following configurations to specify the IP addresses of hosts on your
network:
• intrusion rules—Intrusion rule Source IPs and Destination IPs header fields allow you to restrict packet
inspection to the packets originating from or destined to specific IP addresses.
• suppressions—The Network field in source or destination intrusion rule suppressions allows you to
suppress intrusion event notifications when a specific IP address or range of IP addresses triggers an
intrusion rule or preprocessor.
• dynamic rule states—The Network field in source or destination dynamic rule states allows you to detect
when too many matches for an intrusion rule or preprocessor rule occur in a given time period.
• adaptive profile updates—When you enable adaptive profile updates, the adaptive profiles Networks
field identifies hosts where you want to improve reassembly of packet fragments and TCP streams in
passive deployments.

When you use variables in the fields identified in this section, the variable set you link to an intrusion policy
determines the variable values in the network traffic handled by an access control policy that uses the intrusion
policy.
You can add any combination of the following network configurations to a variable:
• any combination of network variables, network objects, and network object groups that you select from
the list of available networks
• individual network objects that you add from the New Variable or Edit Variable page, and can then add
to your variable and to other existing and future variables
• literal, single IP addresses or address blocks

Reusable Objects
25
 Reusable Objects
Port Variables

You can list multiple literal IP addresses and address blocks by adding each individually. You can list
IPv4 and IPv6 addresses and address blocks alone or in any combination. When specifying IPv6 addresses,
you can use any addressing convention defined in RFC 4291.

The default value for included networks in any variable you add is the word any, which indicates any IPv4
or IPv6 address. The default value for excluded networks is none, which indicates no network. You can also
specify the address :: in a literal value to indicate any IPv6 address in the list of included networks, or no
IPv6 addresses in the list of exclusions.
Adding networks to the excluded list negates the specified addresses and address blocks. That is, you can
match any IP address with the exception of the excluded IP address or address blocks.
For example, excluding the literal address [Link] specifies any IP address other than [Link], and
excluding 2001:db8:ca2e::fa4c specifies any IP address other than 2001:db8:ca2e::fa4c.
You can exclude any combination of networks using literal or available networks. For example, excluding
the literal values [Link] and [Link] includes any IP address other than [Link] or [Link].
That is, the system interprets this as “not [Link] and not [Link],” which matches any IP address
other than those listed between brackets.
Note the following points when adding or editing network variables:
• You cannot logically exclude the value any which, if excluded, would indicate no address. For example,
you cannot add a variable with the value any to the list of excluded networks.
• Network variables identify traffic for the specified intrusion rule and intrusion policy features. Note that
preprocessor rules can trigger events regardless of the hosts defined by network variables used in intrusion
rules.
• Excluded values must resolve to a subset of included values. For example, you cannot include the address
block [Link]/24 and exclude [Link]/24.

Port Variables
Port variables represent TCP and UDP ports you can use in the Source Port and Destination Port header
fields in intrusion rules that you enable in an intrusion policy. Port variables differ from port objects and port
object groups in that port variables are specific to intrusion rules. You can create port objects for protocols
other than TCP and UDP, and you can use port objects in various places in the system’s web interface, including
port variables, access control policies, network discovery rules, and event searches.
You can use port variables in the intrusion rule Source Port and Destination Port header fields to restrict
packet inspection to packets originating from or destined to specific TCP or UDP ports.
When you use variables in these fields, the variable set you link to the intrusion policy associated with an
access control rule or policy determines the values for these variables in the network traffic where you deploy
the access control policy.
You can add any combination of the following port configurations to a variable:
• any combination of port variables and port objects that you select from the list of available ports
Note that the list of available ports does not display port object groups, and you cannot add these to
variables.
• individual port objects that you add from the New Variable or Edit Variable page, and can then add to
your variable and to other existing and future variables

Reusable Objects
26
 Reusable Objects
Advanced Variables

Only TCP and UDP ports, including the value any for either type, are valid variable values. If you use
the new or edit variables page to add a valid port object that is not a valid variable value, the object is
added to the system but is not displayed in the list of available objects. When you use the object manager
to edit a port object that is used in a variable, you can only change its value to a valid variable value.
• single, literal port values and port ranges
You must separate port ranges with a dash (-). Port ranges indicated with a colon (:) are supported for
backward compatibility, but you cannot use a colon in port variables that you create.
You can list multiple literal port values and ranges by adding each individually in any combination.

Note the following points when adding or editing port variables:

• The default value for included ports in any variable you add is the word any, which indicates any port
or port range. The default value for excluded ports is none, which indicates no ports.

Tip To create a variable with the value any, name and save the variable without adding
a specific value.

• You cannot logically exclude the value any which, if excluded, would indicate no ports. For example,
you cannot save a variable set when you add a variable with the value any to the list of excluded ports.
• Adding ports to the excluded list negates the specified ports and port ranges. That is, you can match any
port with the exception of the excluded ports or port ranges.
• Excluded values must resolve to a subset of included values. For example, you cannot include the port
range 10-50 and exclude port 60.

Advanced Variables
Advanced variables allow you to configure features that you cannot otherwise configure via the web interface.
The Firepower System currently provides only only one advanced variable, the USER_CONF variable.

USER_CONF
USER_CONF provides a general tool that allows you to configure one or more features not otherwise available
via the web interface.

Caution Do not use the advanced variable USER_CONF to configure an intrusion policy feature unless you are
instructed to do so in the feature description or by Support. Conflicting or duplicate configurations will halt
the system.

When editing USER_CONF, you can type up to 4096 total characters on a single line; the line wraps
automatically. You can include any number of valid instructions or lines until you reach the 8192 maximum
character length for a variable or a physical limit such as disk space. Use the backslash (\) line continuation
character after any complete argument in a command directive.
Resetting USER_CONF empties it.

Reusable Objects
27
 Reusable Objects
Variable Reset

Variable Reset
You can reset a variable to its default value on the variable set new or edit variables page. The following table
summarizes the basic principles of resetting variables.

Table 2: Variable Reset Values

Resetting this variable type... In this set type... Resets it to...

default default the rule update value

user-defined default any

default or user-defined custom the current default set value

(modified or unmodified)

Resetting a variable in a custom set simply resets it to the current value for that variable in the default set.
Conversely, resetting or modifying the value of a variable in the default set always updates the default value
of that variable in all custom sets. When the reset icon is grayed out, indicating that you cannot reset the
variable, this means that the variable has no customized value in that set. Unless you have customized the
value for a variable in a custom set, a change to the variable in the default set updates the value used in any
intrusion policy where you have linked the variable set.

Note It is good practice when you modify a variable in the default set to assess how the change affects any intrusion
policy that uses the variable in a linked custom set, especially when you have not customized the variable
value in the custom set.

You can hover your pointer over the Reset icon in a variable set to see the reset value. When the customized
value and the reset value are the same, this indicates one of the following:
• you are in the custom or default set where you added the variable with the value any
• you are in the custom set where you added the variable with an explicit value and elected to use the
configured value as the default value

Adding Variables to Sets

Adding a variable to a variable set adds it to all other sets. When you add a variable from a custom set, you
must choose whether to use the configured value as the customized value in the default set:
• If you use the configured value (for example, [Link]/16), the variable is added to the default set
using the configured value as a customized value with a default value of any. Because the current value
in the default set determines the default value in other sets, the initial, default value in other custom sets
is the configured value (which in the example is [Link]/16).
• If you do not use the configured value, the variable is added to the default set using only the default
value any and, consequently, the initial, default value in other custom sets is any.

Reusable Objects
28
 Reusable Objects
Example: Adding User-Defined Variables to Default Sets

Example: Adding User-Defined Variables to Default Sets

The following diagram illustrates set interactions when you add the user-defined variable Var1 to the default
set with the value [Link]/24.

You can customize the value of Var1 in any set. In Custom Set 2 where Var1 has not been customized, its
value is [Link]/24. In Custom Set 1 the customized value [Link]/24 of Var1 overrides the default
value. Resetting a user-defined variable in the default set resets its default value to any in all sets.
It is important to note in this example that, if you do not update Var1 in Custom Set 2, further customizing or
resetting Var1 in the default set consequently updates the current, default value of Var1 in Custom Set 2,
thereby affecting any intrusion policy linked to the variable set.
Although not shown in the example, note that interactions between sets are the same for user-defined variables
and default variables except that resetting a default variable in the default set resets it to the value configured
by Cisco in the current rule update.

Example: Adding User-Defined Variables to Custom Sets

The next two examples illustrate variable set interactions when you add a user-defined variable to a custom
set. When you save the new variable, you are prompted whether to use the configured value as the default
value for other sets. In the following example, you elect to use the configured value.

Note that, except for the origin of Var1 from Custom Set 1, this example is identical to the example above
where you added Var1 to the default set. Adding the customized value [Link]/24 for Var1 to Custom
Set 1 copies the value to the default set as a customized value with a default value of any. Thereafter, Var1
values and interactions are the same as if you had added Var1 to the default set. As with the previous example,
keep in mind that further customizing or resetting Var1 in the default set consequently updates the current,
default value of Var1 in Custom Set 2, thereby affecting any intrusion policy linked to the variable set.
In the next example, you add Var1 with the value [Link]/24 to Custom Set 1 as in the previous example,
but you elect not to use the configured value of Var1 as the default value in other sets.

Reusable Objects
29
 Reusable Objects
Nesting Variables

This approach adds Var1 to all sets with a default value of any. After adding Var1, you can customize its
value in any set. An advantage of this approach is that, by not initially customizing Var1 in the default set,
you decrease your risk of customizing the value in the default set and thus inadvertently changing the current
value in a set such as Custom Set 2 where you have not customized Var1.

Nesting Variables
You can nest variables so long as the nesting is not circular. Nested, negated variables are not supported.

Valid Nested Variables

In this example, SMTP_SERVERS, HTTP_SERVERS, and OTHER_SERVERS are valid nested
variables.

Variable Type Included Networks Excluded Networks

SMTP_SERVERS customized default [Link] —

HTTP_SERVERS customized default [Link] —

OTHER_SERVERS user-defined [Link]/24 —

HOME_NET customized default [Link]/24 SMTP_SERVERS

OTHER_SERVERS HTTP_SERVERS

An Invalid Nested Variable

In this example, HOME_NET is an invalid nested variable because the nesting of HOME_NET is
circular; that is, the definition of OTHER_SERVERS includes HOME_NET, so you would be nesting
HOME_NET in itself.

Variable Type Included Networks Excluded Networks

SMTP_SERVERS customized default [Link] —

HTTP_SERVERS customized default [Link] —

OTHER_SERVERS user-defined [Link]/24 —

HOME_NET

Reusable Objects
30
 Reusable Objects
Managing Variable Sets

Variable Type Included Networks Excluded Networks

HOME_NET customized default [Link]/24 SMTP_SERVERS

OTHER_SERVERS HTTP_SERVERS

An Unsupported Nested, Negated Variable

Because nested, negated variables are not supported, you cannot use the variable NONCORE_NET
as shown in this example to represent IP addresses that are outside of your protected networks.

Variable Type Included Networks Excluded Networks

HOME_NET customized default [Link]/16 —

[Link]/16
[Link]/16

EXTERNAL_NET customized default — HOME_NET

DMZ_NET user-defined [Link]/16 —

NOT_DMZ_NET user-defined — DMZ_NET

NONCORE_NET user-defined EXTERNAL_NET —

NOT_DMZ_NET

Alternative to an Unsupported Nested, Negated Variable

As an alternative to the example above, you could represent IP addresses that are outside of your
protected networks by creating the variable NONCORE_NET as shown in this example.

Variable Type Included Networks Excluded Networks

HOME_NET customized default [Link]/16 —

[Link]/16
[Link]/16

DMZ_NET user-defined [Link]/16 —

NONCORE_NET user-defined — HOME_NET

DMZ_NET

Managing Variable Sets

To use variable sets, you must have the Threat license (for FTD devices) or the Protection license (all other
device types).

Reusable Objects
31
 Reusable Objects
Creating Variable Sets

In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Choose Variable Set from the list of object types.
Step 3 Manage your variable sets:
• Add — If you want to add a custom variable set, click Add Variable Set; see Creating Variable Sets, on page 32.

• Delete — If you want to delete a custom variable set, click Delete ( ) next to the variable set, then click Yes. You
cannot delete the default variable set or variable sets belonging to ancestor domains.
Note Variables created in a variable set you delete are not deleted or otherwise affected in other sets.

• Edit — If you want to edit a variable set, click Edit ( ) next to the variable set you want to modify; see Editing
Objects, on page 4.
• Filter — If you want to filter variable sets by name, begin entering a name; as you type, the page refreshes to display
matching names. If you want to clear name filtering, click Clear ( ) in the filter field.
• Manage Variables — To manage the variables included in variable sets, see Managing Variables, on page 32.

Creating Variable Sets

Step 1 Choose Objects > Object Management.

Step 2 Choose Variable Set from the list of object types.
Step 3 Click Add Variable Set.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Optionally, enter a Description.

Step 6 Manage the variables in the set; see Managing Variables, on page 32.
Step 7 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Managing Variables
You must have the Threat license (for FTD devices) or the Protection license (all other device types).

Reusable Objects
32
 Reusable Objects
Managing Variables

In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Choose Variable Set from the list of object types.

Step 3 Click Edit ( ) next to the variable set you want to edit.

If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.

Step 4 Manage your variables:

• Display — If you want to display the complete value for a variable, hover your pointer over the value in the Value
column next to the variable.
• Add — If you want to add a variable, click Add; see Adding Variables, on page 34.

• Delete — Click Delete ( ) next to the variable. If you have saved the variable set since adding the variable, click
Yes to confirm that you want to delete the variable.
You cannot delete the following:
• default variables
• user-defined variables that are used by intrusion rules or other variables
• variables belonging to ancestor domains

• Edit — Click Edit ( ) next to the variable you want to edit; see Editing Variables, on page 34.
• Reset — If you want to reset a modified variable to its default value, click Reset next to a modified variable. If reset
is dimmed, one of the following is true:
• The current value is already the default value.
• The configuration belongs to an ancestor domain.

Tip Hover your pointer over an active reset to display the default value.

Step 5 Click Save to save the variable set. If the variable set is in use by an access control policy, click Yes to confirm that you
want to save your changes.
Because the current value in the default set determines the default value in all other sets, modifying or resetting a variable
in the default set changes the current value in other sets where you have not customized the default value.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Reusable Objects
33
 Reusable Objects
Adding Variables

Adding Variables
You must have the Threat license (for FTD devices) or the Protection license (all other device types).

Step 1 In the variable set editor, click Add.

Step 2 Enter a unique variable Name.
Step 3 From the Type drop-down list, choose either Network or Port.
Step 4 Specify values for the variable:
• If you want to move items from the list of available networks or ports to the list of included or excluded items, you
can choose one or more items and then drag and drop, or click Include or Exclude.
Tip If addresses or ports in the included and excluded lists for a network or port variable overlap, excluded
addresses or ports take precedence.

• Enter a single literal value, then click Add. For network variables, you can enter a single IP address or address block.
For port variables you can add a single port or port range, separating the upper and lower values with a hyphen (-).
Repeat this step as needed to enter multiple literal values.

• If you want to remove an item from the included or excluded lists, click Delete ( ) next to the item.
Note The list of items to include or exclude can be comprised of any combination of literal strings and existing
variables, objects, and network object groups in the case of network variables.

Step 5 Click Save to save the variable. If you are adding a new variable from a custom set, you have the following options:
• Click Yes to add the variable using the configured value as the customized value in the default set and, consequently,
the default value in other custom sets.
• Click No to add the variable as the default value of any in the default set and, consequently, in other custom sets.

Step 6 Click Save to save the variable set. Your changes are saved, and any access control policy the variable set is linked to
displays an out-of-date status.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Editing Variables
You must have the Threat license (for FTD devices) or the Protection license (all other device types).
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
You can edit both custom and default variables.
You cannot change the Name or Type values in an existing variable.

Reusable Objects
34
 Reusable Objects
Security Intelligence Lists and Feeds

Step 1 In the variable set editor, click Edit ( ) next to the variable you want to modify.

If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.

Step 2 Modify the variable:

• If you want to move items from the list of available networks or ports to the list of included or excluded items, you
can select one or more items and then drag and drop, or click Include or Exclude.
Tip If addresses or ports in the included and excluded lists for a network or port variable overlap, excluded
addresses or ports take precedence.

• Enter a single literal value, then click Add. For network variables, you can enter a single IP address or address block.
For port variables you can add a single port or port range, separating the upper and lower values with a hyphen (-).
Repeat this step as needed to enter multiple literal values.

• If you want to remove an item from the included or excluded lists, click Delete ( ) next to the item.
Note The list of items to include or exclude can be comprised of any combination of literal strings and existing
variables, objects, and network object groups in the case of network variables.

Step 3 Click Save to save the variable.

Step 4 Click Save to save the variable set. If the variable set is in use by an access control policy, click Yes to confirm that you
want to save your changes. Your changes are saved, and any access control policy the variable set is linked to displays
an out-of-date status.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Security Intelligence Lists and Feeds

Security Intelligence functionality requires the Threat license (for FTD devices) or the Protection license (all
other device types).
Security Intelligence lists and feeds are collections of IP addresses, domain names, and URLs that you can
use to quickly filter traffic that matches an entry on a list or feed.
• A list is a static collection that you manage manually.
• A feed is a dynamic collection that updates on an interval over HTTP or HTTPS.

Security Intelligence lists/feeds are grouped into:

• DNS (Domain names )
• Network (IP addresses)

Reusable Objects
35
 Reusable Objects
Security Intelligence Lists and Feeds

• URLs

System-Provided Feeds
Cisco provides the following feeds as Security Intelligence objects:
• Security Intelligence feeds updated regularly with the latest threat intelligence from Talos:
• Cisco-DNS-and-URL-Intelligence-Feed (under DNS Lists and Feeds)
• Cisco-Intelligence-Feed (for IP addresses, under Network Lists and Feeds)

You cannot delete the system-provided feeds, but you can change the frequency of (or disable) their
updates.
• Cisco-TID-Feed (under Network Lists and Feeds)
This feed is not used in the Security Intelligence tab of the access control policy.
Instead, you must enable and configure Threat Intelligence Director to use this feed, which is a collection
of TID observables data.
Use this object to set how frequently this data is published to TID elements.
For more information, see Threat Intelligence Director.

Predefined Lists: Global Block Lists and Global Do Not Block Lists
The system ships with predefined global Block lists and Do Not Block lists for domains (DNS), IP addresses
(Networks), and URLs.
These lists are empty until you populate them. To build these lists, see Global and Domain Security Intelligence
Lists, on page 37.
By default, access control and DNS policies use these lists as part of Security Intelligence.

Custom Feeds
You can use third-party feeds, or use a custom internal feed to easily maintain an enterprise-wide Block list
in a large deployment with multiple Firepower Management Center appliances.
See Custom Security Intelligence Feeds, on page 43.

Custom Lists
Custom lists can augment and fine-tune feeds and the Global lists.
See Custom Security Intelligence Lists, on page 44.

Where Security Intelligence Lists and Feeds Are Used

• IP address and address blocks—Use Block and Do Not Block lists in access control policies, as part of
Security Intelligence.
• Domain Names—Use Block and Do Not Block lists in DNS policies, as part of Security Intelligence.

Reusable Objects
36
 Reusable Objects
How to Modify Security Intelligence Objects

• URLs—Use Block and Do Not Block lists in access control policies, as part of Security Intelligence.
You can also use URL lists in access control and QoS rules, whose analysis and traffic handling phases
occur after Security Intelligence.

How to Modify Security Intelligence Objects

To add or delete entries on a Block list, Do Not Block list, feed, or sinkhole object:

Object Type Edit Capabilities Requires Redeploy After Edit?

Custom Block and Do Not Block Upload new and replacement lists Yes
lists using the object manager.

Default (but custom-populated) Add entries using the context menu No

Block lists and Do Not Block lists: or delete entries using the object
Global, descendant, and manager.
domain-specific

System-provided Intelligence Feeds Disable or change update frequency No

using the object manager.

Custom feeds Fully modify using the object No

manager.

Sinkhole Fully modify using the object Yes

manager.

Global and Domain Security Intelligence Lists

Firepower Management Center ships with empty Global Block and Do-Not-Block lists to which you can
instantly add URLs, domains, and IP addresses from events on your network at any time. These lists allow
you to use Security Intelligence to always block particular connections, or to exempt particular connections
from blocking by Security Intelligence, allowing them to be evaluated by other threat detection processes that
you have configured.
For example, if you notice a set of routable IP addresses in intrusion events associated with exploit attempts,
you can immediately block those IP addresses. Although it may take a few minutes for your changes to
propagate, you do not have to redeploy.
By default, Access control and DNS policies use these Global lists, which apply to all security zones. You
can opt not to use these lists on a per-policy basis.

Note These options apply to Security Intelligence only. Security Intelligence cannot block traffic that has already
been fastpathed. Similarly, adding an item to a Security Intelligence Do Not Block list does not automatically
trust or fastpath matching traffic. For more information, see About Security Intelligence.

In a multidomain deployment, you can choose the Firepower System domains where you want to enforce
blocking, or exempting from Security Intelligence blocking, by adding items to Domain lists as well as the
Global lists; see Security Intelligence Lists and Multitenancy, on page 38.

Reusable Objects
37
 Reusable Objects
Security Intelligence Lists and Multitenancy

Security Intelligence Lists and Multitenancy

In a multidomain deployment, the Global domain owns the Global Block lists and Do Not Block lists. Only
Global administrators can add to or remove items from the Global lists. So that subdomain users can add
networks, domain names, and URLs to Block and Do Not Block lists, multitenancy adds:
• Domain lists—Block or Do Not Block lists whose contents apply to a particular subdomain only. The
Global lists are Domain lists for the Global domain.
• Descendant Domain lists—Block or Do Not Block lists that aggregate the Domain lists of the current
domain’s descendants.

Domain Lists
In addition to being able to access (but not edit) the Global lists, each subdomain has its own named lists, the
contents of which apply only to that subdomain. For example, a subdomain named Company A owns:
• Domain Block list - Company A and Domain Do Not Block list - Company A
• Domain Block list for DNS - Company A, Domain Do Not Block list for DNS - Company A
• Domain Block list for URL - Company A, Domain Do Not Block list for URL - Company A

Any administrator at or above the current domain can populate these lists. You can use the context menu to
add an item to the Block or Do Not Block list in the current and all descendant domains. However, only an
administrator in the associated domain can remove an item from a Domain list.
For example, a Global administrator could choose to add the same IP address to the Block list in the Global
domain and Company A’s domain, but not add it to the Block list in Company B’s domain. This action would
add the same IP address to:
• Global Block list (where it can be removed only by Global administrators)
• Domain Block list - Company A (where it can be removed only by Company A administrators)

The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.

Descendant Domain Lists

A Descendant Domain list is a Do Not Block list or Block list that aggregates the Domain lists of the current
domain’s descendants. Leaf domains do not have Descendant Domain lists.
Descendant Domain lists are useful because a higher-level domain administrator can enforce general Security
Intelligence settings, while still allowing subdomain users to add items to a Block or Do Not Block list in
their own deployment.
For example, the Global domain has the following Descendant Domain lists:
• Descendant Block lists - Global, Descendant Do Not Block lists - Global
• Descendant Block lists for DNS - Global, Descendant Do Not Block lists for DNS - Global
• Descendant Block lists for URL - Global, Descendant Do Not Block lists for URL - Global

Reusable Objects
38
 Reusable Objects
Add Entries to Global Security Intelligence Lists

Note Descendant Domain lists do not appear in the object manager because they are symbolic aggregations, not
hand-populated lists. They appear where you can use them: in access control and DNS policies.

Add Entries to Global Security Intelligence Lists

When reviewing events and dashboards, you can instantly block future traffic involving IP addresses, domains,
and URLs that appear in those events by adding them to a predefined Block list.
Similarly, if Security Intelligence is blocking traffic that you want evaluated by threat detection processes
subsequent to Security Intelligence blocking, you can add IP addresses, domains, and URLs from events to
a predefined Do Not Block list.
Traffic is evaluated against entries on these lists during the Security Intelligence phase of threat detection.
For more information about these lists, see Global and Domain Security Intelligence Lists, on page 37.

Before you begin

Because adding an entry to a Security Intelligence list affects access control, you must have one of the following
user roles:
• Administrator
• A combination of roles: Network Admin or Access Admin, plus Security Analyst and Security Approver
• A custom role with both Modify Access Control Policy and Deploy Configuration to Devices permissions

If appropriate, verify that these lists are used in the policies in which you expect them to be used.

Step 1 Navigate to an event that includes an IP address, domain, or URL that you want to always block using Security Intelligence,
or exempt from Security Intelligence blocking.
Step 2 Right-click the IP address, domain, or URL and choose the appropriate option:

Target Item Context Menu Option Affected Global Lists

An IP address Blacklist Now Global Block List

Whitelist Now Global Whitelist

A URL Blacklist HTTP/S Connections to URL Now Global Block List for URL
Whitelist HTTP/S Connections to URL Now Global Whitelist for URL

An entire domain Blacklist HTTP/S Connections to Domain Now Global Block List for URL
Whitelist HTTP/S Connections to Domain Now Global Whitelist for URL

DNS requests for an entire Blacklist DNS Requests to Domain Now Global Block List for DNS
domain
Whitelist DNS Requests to Domain Now Global Whitelist for DNS

Reusable Objects
39
 Reusable Objects
Delete Entries from Global Security Intelligence Lists

What to do next
You do NOT need to redeploy for these changes to take effect.
If you want to delete an item from a list, see Delete Entries from Global Security Intelligence Lists, on page
40.

Delete Entries from Global Security Intelligence Lists

Note • In multi-domain deployments, the names of these lists may not be "Global." For more information, see
Security Intelligence Lists and Multitenancy, on page 38.
• To add entries to these lists, see Add Entries to Global Security Intelligence Lists, on page 39.

Step 1 Choose Objects > Object Management.

Step 2 Click Security Intelligence.
Step 3 Click the appropriate option:
• Network Lists and Feeds (for IP addresses)
• DNS Lists and Feeds (for domain names)
• URL Lists and Feeds

Step 4 Click the pencil beside the Global Block or Global Do-Not-Block list.
Step 5 Click the trash button beside the entry to delete.

List and Feed Updates for Security Intelligence

List and feed updates replace the existing list or feed file with the contents of the new file. Contents of existing
and new files are not merged.
If the system downloads a corrupt feed or a feed with no recognizable entries, the system continues using the
old feed data (unless it is the first download). However, if the system can recognize even one entry in the
feed, it uses the entries it can recognize.
By default, each feed updates the Management Center every two hours; you can modify this frequency. Any
updates the Management Center receives are passed immediately to managed devices. In addition, managed
devices poll the FMC every 30 minutes for changes. You cannot modify this frequency.
In a multidomain deployment, the system-provided feeds belong to the Global domain and can be modified
only by an administrator in that domain. You can modify the update frequency for custom feeds belonging
to your domain.
To modify feed update intervals, see Changing the Update Frequency for Security Intelligence Feeds, on page
41.

Reusable Objects
40
 Reusable Objects
Changing the Update Frequency for Security Intelligence Feeds

Changing the Update Frequency for Security Intelligence Feeds

You can specify the intervals at which the Firepower Management Center updates Security Intelligence Feeds.
For details about feed updates, see List and Feed Updates for Security Intelligence, on page 40.

Step 1 Choose Objects > Object Management.

Step 2 Expand the Security Intelligence node, then choose the feed type whose frequency you want to change.
The system-provided URL feed is combined with the domain feed under DNS Lists and Feeds.

Step 3 Next to the feed you want to update, click Edit ( ).

If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.

Step 4 Edit the Update Frequency.

Step 5 Click Save.

Custom Security Intelligence Lists and Feeds

Custom Lists and Feeds: Requirements

List and Feed Formatting

Each list or feed must be a simple text file no larger than 500MB. List files must have the .txt extension.
Include one entry or comment per line: one IP address, one URL, one domain name.

Tip The number of entries you can include is limited by the maximum size of the file. For example, a URL list
with no comments and an average URL length of 100 characters (including Punycode or percent Unicode
representations and newlines) can contain more than 5.24 million entries.

In a DNS list entry, you can specify an asterisk (*) wildcard character for a domain label. All labels match
the wildcard. For example, an entry of [Link].* matches both [Link] and [Link].
If you add comment lines within the source file, they must start with the pound (#) character. If you upload
a source file with comments, the system removes your comments during upload. Source files you download
contain all your entries without your comments.

Feed Requirements
When you configure a feed, you specify its location using a URL; the URL cannot be Punycode-encoded.
If you use an MD5 checksum, the checksum must be stored in a simple text file with only the checksum.
Comments are not supported.

Reusable Objects
41
 Reusable Objects
URL Lists and Feeds: URL Syntax and Matching Criteria

URL Lists and Feeds: URL Syntax and Matching Criteria

Security Intelligence URL lists and feeds, including custom lists and feeds and entries in the global Block list
and Do Not Block list, can include the following, which have the matching behavior as described:
• Hostnames
For example, [Link].
• URLs
[Link] matches [Link] and all subdomains, including [Link],
[Link], [Link]/abc, and [Link]/def -- but NOT
[Link] or [Link] or [Link]
You can also include an entire URL path, such as
[Link]
• A slash at the end of a URL to specify an exact match
[Link]/ matches ONLY [Link]; it does NOT match [Link] or any
other URL.
• A wildcard (*) to represent any domain in a URL
An asterisk can represent a complete domain string separated by dots, but not a partial domain string,
and not any part of the URL following the first slash.
Valid examples:
• *.[Link]
• www.*.com
• example.*
(This will match [Link] and [Link] and [Link], for example, but NOT
[Link])
• *.example.*
• example.*/

Invalid examples:
• example*.com
• [Link]/*

• IP addresses (IPv4)
For IPv6 addresses, or to use ranges or CIDR notation, use the Security Intelligence Network object.
You can include one or more wildcards representing an octet, for example 10.10.10.* or 10.10.*.*.

See also Custom Security Intelligence Lists, on page 44.

Reusable Objects
42
 Reusable Objects
Custom Security Intelligence Feeds

Custom Security Intelligence Feeds

Custom or third-party Security Intelligence feeds allow you to augment the system-provided Intelligence
Feeds with other regularly-updated reputable Block lists and Do Not Block lists on the Internet. You can also
set up an internal feed, which is useful if you want to update multiple Firepower Management Center appliances
in your deployment using one source list.

Note You cannot add address blocks to Block or Do Not Block lists using a /0 netmask in a Security Intelligence
feed. If you want to monitor or block all traffic targeted by a policy, use an access control rule with the Monitor
or Block rule action, respectively, and a default value of any for the Source Networks and Destination
Networks.

You also can configure the system to use an MD5 checksum to determine whether to download an updated
feed. If the checksum has not changed since the last time the system downloaded the feed, the system does
not need to re-download it. You may want to use MD5 checksums for internal feeds, especially if they are
large.

Note The system does not perform peer SSL certificate verification when downloading custom feeds, nor does the
system support the use of certificate bundles or self-signed certificates to verify the remote peer.

If you want strict control over when the system updates a feed from the Internet, you can disable automatic
updates for that feed. However, automatic updates ensure the most up-to-date, relevant data.
Manually updating Security Intelligence feeds updates all feeds, including the Intelligence Feeds.
See complete requirements at Custom Lists and Feeds: Requirements, on page 41.

Creating Security Intelligence Feeds

You must have the Threat license (for FTD devices) or the Protection license (all other device types).

Step 1 Choose Objects > Object Management.

Step 2 Expand the Security Intelligence node, then choose a feed type you want to add.
Step 3 Click the option appropriate to the feed type you chose above:
• Add Network Lists and Feeds (for IP addresses)
• Add DNS Lists and Feeds
• Add URL Lists and Feeds

Step 4 Enter a Name for the feed.

In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Choose Feed from the Type drop-down list.

Step 6 Enter a Feed URL.
Step 7 (Optional) Enter an MD5 URL.

Reusable Objects
43
 Reusable Objects
Manually Updating Security Intelligence Feeds

This is used to determine whether the feed contents have changed since the last update, so the system does not download
unchanged feeds.

Step 8 Choose an Update Frequency.

Step 9 Click Save.
Unless you disabled feed updates, the system attempts to download and verify the feed.

Manually Updating Security Intelligence Feeds

You must have the Threat license (for FTD devices) or the Protection license (all other device types).

Before you begin

At least one device must already be added to the management center.

Step 1 Choose Objects > Object Management.

Step 2 Expand the Security Intelligence node, then choose a feed type.
Step 3 Click Update Feeds, then confirm.
Step 4 Click OK.

After the Firepower Management Center downloads and verifies the feed updates, it communicates any changes
to its managed devices. Your deployment begins filtering traffic using the updated feeds.

Custom Security Intelligence Lists

Security Intelligence lists are simple static lists of IP addresses and address blocks, URLs, or domain names
that you manually upload to the system. Custom lists are useful if you want to augment and fine-tune feeds
or one of the global lists, for a single Firepower Management Center’s managed devices.
For example, if a reputable feed improperly blocks your access to vital resources but is overall useful to your
organization, you can create a custom Do Not Block list that contains only the improperly classified IP
addresses, rather than removing the IP address feed object from the access control policy’s Block list.

Note You cannot add address blocks to a Block or Do Not Block list using a /0 netmask in a Security Intelligence
list. If you want to monitor or block all traffic targeted by a policy, use an access control rule with the Monitor
or Block rule action, respectively, and a default value of any for the Source Networks and Destination
Networks.

Regarding list entry formatting, note the following:

• Netmasks for address blocks can be integers from 0 to 32 or 0 to 128, for IPv4 and IPv6, respectively.
• Unicode in domain names must be encoded in Punycode format, and are case insensitive.
• Characters in domain names are case-insensitive.
• Unicode in URLs should be encoded in percent-encoding format.
• Characters in URL subdirectories are case-sensitive.

Reusable Objects
44
 Reusable Objects
Uploading New Security Intelligence Lists to the Firepower Management Center

• List entries that start with the pound sign (#) are treated as comments.
• See additional formatting requirements at Custom Lists and Feeds: Requirements, on page 41.

Regarding matching list entries, note the following:

• The system matches sub-level domains if a higher-level domain exists in a URL or DNS list. For example,
if you add [Link] to a DNS list, the system matches both [Link] and [Link].
• The system does not perform DNS lookups (forward or reverse) on DNS or URL list entries. For example,
if you add [Link] to a URL list, and it resolves to [Link] the system
only matches [Link] not [Link]

Uploading New Security Intelligence Lists to the Firepower Management Center

To modify a Security Intelligence list, you must make your changes to the source file and upload a new copy.
You cannot modify the file’s contents using the web interface. If you do not have access to the source file,
download a copy from the system.

Step 1 Choose Objects > Object Management.

Step 2 Expand the Security Intelligence node, then choose a list type.
Step 3 Click the option appropriate to the list you chose above:
• Add Network Lists and Feeds (for IP addresses)
• Add DNS Lists and Feeds
• Add URL Lists and Feeds

Step 4 Enter a Name.

In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 From the Type drop-down list, choose List.

Step 6 Click Browse to browse to the list .txt file, then click Upload.
Step 7 Click Save.

What to do next
If an active policy references your object, deploy configuration changes, see Deploy Configuration Changes

Updating Security Intelligence Lists

In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Expand the Security Intelligence node, then choose a list type.

Step 3 Next to the list you want to update, click Edit ( ).

Reusable Objects
45
 Reusable Objects
Sinkhole Objects

If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.

Step 4 If you need a copy of the list to edit, click Download, then follow your browser’s prompts to save the list as a text file.
Step 5 Make changes to the list as necessary.
Step 6 On the Security Intelligence pop-up window, click Browse to browse to the modified list, then click Upload.
Step 7 Click Save.

What to do next
If an active policy references your object, deploy configuration changes, see Deploy Configuration Changes.

Sinkhole Objects
A sinkhole object represents either a DNS server that gives non-routeable addresses for all domain names
within the sinkhole, or an IP address that does not resolve to a server. You can reference the sinkhole object
within a DNS policy rule to redirect matching traffic to the sinkhole. You must assign the object both an IPv4
address and an IPv6 address.

Creating Sinkhole Objects

You must have the Threat license (for FTD devices) or the Protection license (all other device types).

Step 1 Choose Objects > Object Management.

Step 2 Choose Sinkhole from the list of object types.
Step 3 Click Add Sinkhole.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Enter the IPv4 Address and IPv6 Address of your sinkhole.
Step 6 You have the following options:
• If you want to redirect traffic to a sinkhole server, choose Log Connections to Sinkhole.
• If you want to redirect traffic to a non-resolving IP address, choose Block and Log Connections to Sinkhole.

Step 7 If you want to assign an Indication of Compromise (IoC) type to your sinkhole, choose one from the Type drop-down.
Step 8 Click Save.

Reusable Objects
46
 Reusable Objects
File Lists

File Lists
If you use AMP for Networks, and the AMP cloud incorrectly identifies a file’s disposition, you can add the
file to a file list to better detect the file in the future. These files are specified using SHA-256 hash values.
Each file list can contain up to 10000 unique SHA-256 values.
There are two predefined categories of file lists:
Clean List
If you add a file to this list, the system treats it as if the AMP cloud assigned a clean disposition.
Custom Detection List
If you add a file to this list, the system treats it as if the AMP cloud assigned a malware disposition.
In a multidomain deployment, a clean list and custom detection list is present for each domain. In lower-level
domains, you can view but not modify ancestor's lists.
Because you manually specify the blocking behavior for the files included in these lists, the system does not
query the AMP cloud for these files’ dispositions. You must configure a rule in the file policy with either a
Malware Cloud Lookup or Block Malware action and a matching file type to calculate a file’s SHA value.

Caution Do not include malware on the clean list. The clean list overrides both the AMP cloud and the custom detection
list.

Source Files for File Lists

You can add multiple SHA-256 values to a file list by uploading a comma-separated value (CSV) source file
containing a list of SHA-256 values and descriptions. The Firepower Management Center validates the contents
and populates the file list with valid SHA-256 values.
The source file must be a simple text file with a .csv file name extension. Any header must start with a pound
sign (#); it is treated as a comment and not uploaded. Each entry should contain a single SHA-256 value
followed by a description and end with either the LF or CR+LF Newline character. The system ignores any
additional information in the entry.
Note the following:
• Deleting a source file from the file list also removes all associated SHA-256 hashes from the file list.
• You cannot upload multiple files to a file list if the successful source file upload results in the file list
containing more than 10000 distinct SHA-256 values.
• The system truncates descriptions exceeding 256 characters to the first 256 characters on upload. If the
description contains commas, you must use an escape character (\,). If no description is included, the
source file name is used instead.
• All non-duplicate SHA-256 values are added to the file list. If a file list contains a SHA-256 value, and
you upload a source file containing that value, the newly uploaded value does not modify the existing
SHA-256 value. When viewing captured files, file events, or malware events related to the SHA-256
value, any threat name or description is derived from the individual SHA-256 value.

Reusable Objects
47
 Reusable Objects
Adding Individual SHA-256 Values to File Lists

• The system does not upload invalid SHA-256 values in a source file.
• If multiple uploaded source files contain an entry for the same SHA-256 value, the system uses the most
recent value.
• If a source file contains multiple entries for the same SHA-256 value, the system uses the last one.
• You cannot directly edit a source file within the object manager. To make changes, you must first modify
your source file directly, delete the copy on the system, then upload the modified source file.
• The number of entries associated with a source file refers to the number of distinct SHA-256 values. If
you delete a source file from a file list, the total number of SHA-256 entries the file list contains decreases
by the number of valid entries in the source file.

Adding Individual SHA-256 Values to File Lists

You must have the Malware license for this procedure.
You can submit a file’s SHA-256 value to add it to a file list. You cannot add duplicate SHA-256 values.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Before you begin

• Right-click a file or malware event from the event view, choose Show Full Text in the context menu,
and copy the full SHA-256 value for pasting into the file list.

Step 1 Choose Objects > Object Management.

Step 2 Choose File List from the list of object types.

Step 3 Click Edit ( ) next to the clean list or custom detection list where you want to add a file.

If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.

Step 4 Choose Enter SHA Value from the Add by drop-down list.
Step 5 Enter a description of the source file in the Description field.
Step 6 Enter or paste the file’s entire value in the SHA-256 field. The system does not support matching partial values.
Step 7 Click Add.
Step 8 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Reusable Objects
48
 Reusable Objects
Uploading Individual Files to File Lists

Note After configuration changes are deployed, the system no longer queries the AMP cloud for files on the list.

Uploading Individual Files to File Lists

You must have the Malware license for this procedure.
If you have a copy of the file you want to add to a file list, you can upload the file to the Firepower Management
Center for analysis; the system calculates the file’s SHA-256 value and adds the file to the list. The system
does not enforce a limit on the size of files for SHA-256 calculation.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Choose File List from the list of object types.

Step 3 Click Edit ( ) next to the clean list or custom detection list where you want to add a file.

If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.

Step 4 From the Add by drop-down list, choose Calculate SHA.

Step 5 Optionally, enter a description of the file in the Description field. If you do not enter a description, the file name is used
for the description on upload.
Step 6 Click Browse, and choose a file to upload.
Step 7 Click Calculate and Add SHA.
Step 8 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Note After you deploy configuration changes, the system no longer queries the AMP cloud for files on the list.

Uploading Source Files to File Lists

You must have the Malware license for this procedure.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Reusable Objects
49
 Reusable Objects
Editing SHA-256 Values in File Lists

Step 1 Choose Objects > Object Management.

Step 2 Click File List.

Step 3 Click Edit ( ) next to the file list where you want to add values from a source file.

If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.

Step 4 In the Add by drop-down list, choose List of SHAs.

Step 5 Optionally, enter a description of the source file in the Description field. If you do not enter a description, the system
uses the file name.
Step 6 Click Browse to browse to the source file, then click Upload and Add List.
Step 7 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Note After you deploy the policies, the system no longer queries the AMP cloud for files on the list.

Editing SHA-256 Values in File Lists

You must have the Malware license for this procedure.
You can edit or delete individual SHA-256 values on a file list. Note that you cannot directly edit a source
file within the object manager. To make changes, you must first modify your source file directly, delete the
copy on the system, then upload the modified source file.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Click File List.

Step 3 Click Edit ( ) next to the clean list or custom detection list where you want to modify a file.

If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.

Step 4 You can:

• Click Edit ( ) next to the SHA-256 value you want to change, and modify the SHA-256 or Description values
as desired.

Reusable Objects
50
 Reusable Objects
Downloading Source Files from File Lists

• Click Delete ( ) next to the SHA-256 value you want to delete.

Step 5 Click Save to update the file entry in the list.

Step 6 Click Save to save the file list.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Note After configuration changes are deployed, the system no longer queries the AMP cloud for files on the list.

Downloading Source Files from File Lists

You must have the Malware license for this procedure.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Choose File List from the list of object types.

Step 3 Click Edit ( ) next to the clean list or custom detection list where you want to download a source file.

If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.

Step 4 Next to the source file you want to download, click View ( ).
Step 5 Click Download SHA List and follow the prompts to save the source file.
Step 6 Click Close.

Cipher Suite Lists

A cipher suite list is an object comprised of several cipher suites. Each predefined cipher suite value represents
a cipher suite used to negotiate an SSL- or TLS-encrypted session. You can use cipher suites and cipher suite
lists in SSL rules to control encrypted traffic based on whether the client and server negotiated the SSL session
using that cipher suite. If you add a cipher suite list to an SSL rule, SSL sessions negotiated with any of the
cipher suites in the list match the rule.

Reusable Objects
51
 Reusable Objects
Creating Cipher Suite Lists

Note Although you can use cipher suites in the web interface in the same places as cipher suite lists, you cannot
add, modify, or delete cipher suites.

Creating Cipher Suite Lists

You can use these objects with any device type except NGIPSv.

Step 1 Choose Objects > Object Management.

Step 2 Choose Cipher Suite List from the list of object types.
Step 3 Click Add Cipher Suites.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Choose one or more cipher suites from the Available Ciphers list.
Step 6 Click Add.

Step 7 Optionally, click Delete ( ) next to any cipher suites in the Selected Ciphers list that you want to remove.
Step 8 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Distinguished Name Objects

Each distinguished name object represents the distinguished name for a public key certificate’s subject or
issuer. You can use distinguished name objects and groups in TLS/SSL rules to control encrypted traffic based
on whether the client and server negotiated the TLS/SSL session using a server certificate with the distinguished
name as subject or issuer.
(A distinguished name group is a named collection of existing distinguished name objects.)
The distinguished name can consist of country code, common name, organization, and organizational unit,
but typically consists of a common name only. For example, the common name in the certificate for
[Link] is [Link]. (However, it's not always this simple; Distinguished Name (DN) Rule
Conditions shows how to find common names.) The certificate can contain multiple Subject Alternative Names
(SANs) you can use as DNs in a rule condition. For detailed information about SANs, see RFC 528, section
[Link].
The format of a distginguished name object that references a common name is CN=name. If you add a DN
rule condition without CN=, the system prepends CN= before saving the object.

Reusable Objects
52
Reusable Objects
Distinguished Name Objects

As discussed further in Distinguished Name (DN) Rule Conditions, the Firepower System uses Server Name
Indication (SNI) to match the DN in the TLS/SSL rule whenever possible.
You can also add a distinguished name with one of each of the attributes listed in the following table, separated
by commas.

Table 3: Distinguished name attributes

Attribute Description Allowed Values

C Country Code two alphabetic characters

CN Common Name up to 64 alphanumeric, backslash (/), hyphen (-), quotation

("), or asterisk (*) characters, or spaces

O Organization up to 64 alphanumeric, backslash (/), hyphen (-), quotation

("), or asterisk (*) characters, or spaces

OU Organizational Unit up to 64 alphanumeric, backslash (/), hyphen (-), quotation

("), or asterisk (*) characters, or spaces

Important notes about DN rule conditions

• The first time the system detects an encrypted session to a new server, DN data is not available for
ClientHello processing, which might result in an undecrypted first session.
• You cannot configure a distinguished name condition if you also choose the Decrypt - Known Key
action. Because that action requires you to choose a server certificate to decrypt traffic, the certificate
already matches the traffic.

Wildcard examples
You can define one or more asterisks (*) as wildcards in an attribute. In a common name attribute, you can
define one or more asterisks per domain name label. wildcards match only in that label, but you can define
multiple labels with wildcards. See the following table for examples.

Table 4: Common Name attribute wildcard examples

Attribute Matches Does Not Match

CN=*[Link] [Link] [Link]

[Link]
[Link]

CN=exam*.com [Link] [Link]

[Link]
[Link]

CN=*xamp*.com [Link] [Link]

[Link]
[Link]

Reusable Objects
53
 Reusable Objects
Creating Distinguished Name Objects

Attribute Matches Does Not Match

CN=*.[Link] [Link] [Link]

[Link]
[Link]
[Link]

Note The DN object CN=[Link] would not match a CN like CN=[Link], which is why we
recommend wildcards in these cases.

For more information and examples, see Distinguished Name (DN) Rule Conditions.

Creating Distinguished Name Objects

You can use these objects with any device type except NGIPSv.

Step 1 Choose Objects > Object Management.

Step 2 Expand the Distinguished Name node, and choose Individual Objects.
Step 3 Click Add Distinguished Name.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 In the DN field, enter a value for the distinguished name or common name. You have the following options:
• If you add a distinguished name, you can include one of each attribute listed in Distinguished Name Objects, on
page 52 separated by commas.
• If you add a common name, you can include multiple labels and wild cards.

Step 6 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

PKI Objects
PKI Objects for SSL Application
PKI objects represent the public key certificates and paired private keys required to support your deployment.
Internal and trusted CA objects consist of certificate authority (CA) certificates; internal CA objects also

Reusable Objects
54
 Reusable Objects
Internal Certificate Authority Objects

contain the private key paired with the certificate. Internal and external certificate objects consist of server
certificates; internal certificate objects also contain the private key paired with the certificate.
If you use trusted certificate authority objects and internal certificate objects to configure a connection to
ISE/ISE-PIC, you can use ISE/ISE-PIC as an identity source.
If you use internal certificate objects to configure captive portal, the system can authenticate the identity of
your captive portal device when connecting to users' web browsers.
If you use trusted certificate authority objects to configure realms, you can configure secure connections to
LDAP or AD servers.
If you use PKI objects in SSL rules, you can match traffic encrypted with:
• the certificate in an external certificate object
• a certificate either signed by the CA in a trusted CA object, or within the CA’s chain of trust

If you use PKI objects in SSL rules, you can decrypt:

• outgoing traffic by re-signing the server certificate with an internal CA object
• incoming traffic using the known private key in an internal certificate object

You can manually input certificate and key information, upload a file containing that information, or in some
cases, generate a new CA certificate and private key.
When you view a list of PKI objects in the object manager, the system displays the certificate’s Subject
distinguished name as the object value. Hover your pointer over the value to view the full certificate Subject
distinguished name. To view other certificate details, edit the PKI object.

Note The Firepower Management Center and managed devices encrypt all private keys stored in internal CA objects
and internal certificate objects with a randomly generated key before saving them. If you upload private keys
that are password protected, the appliance decrypts the key using the user-supplied password, then reencrypts
it with the randomly generated key before saving it.

PKI Objects for Certificate Enrollment

A certificate enrollment object contains the Certification Authority (CA) server information and enrollment
parameters that are required for creating Certificate Signing Requests (CSRs) and obtaining Identity Certificates
from the specified CA. These activities occur in your Private Key Infrastructure (PKI).
The certificate enrollment object may also includes certificate revocation information. For more information
on PKI, digital certificates, and certificate enrollment see PKI Infrastructure and Digital Certificates.

Internal Certificate Authority Objects

Each internal certificate authority (CA) object you configure represents the CA public key certificate of a CA
your organization controls. The object consists of the object name, CA certificate, and paired private key.
You can use internal CA objects and groups in SSL rules to decrypt outgoing encrypted traffic by re-signing
the server certificate with the internal CA.

Reusable Objects
55
 Reusable Objects
CA Certificate and Private Key Import

Note If you reference an internal CA object in a Decrypt - Resign SSL rule and the rule matches an encrypted
session, the user’s browser may warn that the certificate is not trusted while negotiating the SSL handshake.
To avoid this, add the internal CA object certificate to either the client or domain list of trusted root certificates.

You can create an internal CA object in the following ways:

• import an existing RSA-based or elliptic curve-based CA certificate and private key
• generate a new self-signed RSA-based CA certificate and private key
• generate an unsigned RSA-based CA certificate and private key. You must submit a certificate signing
request (CSR) to another CA to sign the certificate before using the internal CA object.

After you create an internal CA object containing a signed certificate, you can download the CA certificate
and private key. The system encrypts downloaded certificates and private keys with a user-provided password.
Whether system-generated or user-created, you can modify the internal CA object name, but cannot modify
other object properties.
You cannot delete an internal CA object that is in use. Additionally, after you edit an internal CA object used
in an SSL policy, the associated access control policy goes out-of-date. You must re-deploy the access control
policy for your changes to take effect.

CA Certificate and Private Key Import

You can configure an internal CA object by importing an X.509 v3 CA certificate and private key. You can
upload files encoded in one of the following supported formats:
• Distinguished Encoding Rules (DER)
• Privacy-enhanced Electronic Mail (PEM)

If the private key file is password-protected, you can supply the decryption password. If the certificate and
key are encoded in the PEM format, you can also copy and paste the information.
You can upload only files that contain proper certificate or key information, and that are paired with each
other. The system validates the pair before saving the object.

Note If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced
internal CA certificate’s encryption algorithm type, in addition to any configured rule conditions. You must
upload an elliptic curve-based CA certificate to decrypt outgoing traffic encrypted with an elliptic curve-based
algorithm, for example.

Importing a CA Certificate and Private Key

You can use these objects with any device type except NGIPSv.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Reusable Objects
56
 Reusable Objects
Generating a New CA Certificate and Private Key

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal CAs.
Step 3 Click Import CA.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate file.
Step 6 Above the Key field, click Browse to upload a DER or PEM-encoded paired private key file.
Step 7 If the uploaded file is password-protected, check the Encrypted, and the password is: check box, and enter the password.
Step 8 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Generating a New CA Certificate and Private Key

You can use these objects with any device type except NGIPSv.
You can configure an internal CA object by providing identification information to generate a self-signed
RSA-based CA certificate and private key.
The generated CA certificate is valid for ten years. The Valid From date is a week before generation.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal CAs.
Step 3 Click Generate CA.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Enter the identification attributes.

Step 6 Click Generate self-signed CA.

New Signed Certificates

You can configure an internal CA object by obtaining a signed certificate from a CA. This involves two steps:

Reusable Objects
57
 Reusable Objects
Creating an Unsigned CA Certificate and CSR

• Provide identification information to configure the internal CA object. This generates an unsigned
certificate and paired private key, and creates a certificate signing request (CSR) to a CA you specify.
• After the CA issues the signed certificate, upload it to the internal CA object, replacing the unsigned
certificate.

You can only reference an internal CA object in an SSL rule if it contains a signed certificate.

Creating an Unsigned CA Certificate and CSR

You can use these objects with any device type except NGIPSv.

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal CAs.
Step 3 Click Generate CA.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Enter the identification attributes.

Step 6 Click Generate CSR.
Step 7 Copy the CSR to submit to a CA.
Step 8 Click OK.

What to do next
• You must upload a signed certificate issued by a CA as described in Uploading a Signed Certificate
Issued in Response to a CSR, on page 58

Uploading a Signed Certificate Issued in Response to a CSR

You can use these objects with any device type except NGIPSv.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Once uploaded, the signed certificate can be referenced in SSL rules.

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal CAs.

Step 3 Click Edit ( ) next to the CA object containing the unsigned certificate awaiting the CSR.
Step 4 Click Install Certificate.
Step 5 Click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate file.
Step 6 If the uploaded file is password protected, check the Encrypted, and the password is: check box, and enter the password.

Reusable Objects
58
 Reusable Objects
CA Certificate and Private Key Downloads

Step 7 Click Save to upload a signed certificate to the CA object.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

CA Certificate and Private Key Downloads

You can back up or transfer a CA certificate and paired private key by downloading a file containing the
certificate and key information from an internal CA object.

Caution Always store downloaded key information in a secure location.

The system encrypts the private key stored in an internal CA object with a randomly generated key before
saving it to disk. If you download a certificate and private key from an internal CA object, the system first
decrypts the information before creating a file containing the certificate and private key information. You
must then provide a password the system uses to encrypt the downloaded file.

Caution Private keys downloaded as part of a system backup are decrypted, then stored in the unencrypted backup
file.

Downloading a CA Certificate and Private Key

You can use these objects with any device type except NGIPSv.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
You can download CA certificates for both the current domain and ancestor domains.

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal CAs.

Step 3 Next to the internal CA object whose certificate and private key you want to download, click Edit ( ).

In a multidomain deployment, click View ( ) to download the certificate and private key for an object in an ancestor
domain.

Step 4 Click Download.

Step 5 Enter an encryption password in the Password and Confirm Password fields.
Step 6 Click OK.

Reusable Objects
59
 Reusable Objects
Trusted Certificate Authority Objects

Trusted Certificate Authority Objects

Each trusted certificate authority (CA) object you configure represents a CA public key certificate belonging
to a trusted CA. The object consists of the object name and CA public key certificate. You can use external
CA objects and groups in:
• your SSL policy to control traffic encrypted with a certificate signed either by the trusted CA, or any CA
within the chain of trust.
• your realm configurations to establish secure connections to LDAP or AD servers.
• your ISE/ISE-PIC connection. Select trusted certificate authority objects for the pxGrid Server CA and
MNT Server CA fields.

After you create the trusted CA object, you can modify the name and add certificate revocation lists (CRL),
but cannot modify other object properties. There is no limit on the number of CRLs you can add to an object.
If you want to modify a CRL you have uploaded to an object, you must delete the object and recreate it.

Note Adding a CRL to an object has no effect when the object is used in your ISE/ISE-PIC integration configuration.

You cannot delete a trusted CA object that is in use. Additionally, after you edit a trusted CA object that is in
use, the associated access control policy goes out-of-date. You must re-deploy the access control policy for
your changes to take effect.

Trusted CA Object
You can configure an external CA object by uploading an X.509 v3 CA certificate. You can upload a file
encoded in one of the following supported formats:
• Distinguished Encoding Rules (DER)
• Privacy-enhanced Electronic Mail (PEM)

If the file is password-protected, you must supply the decryption password. If the certificate is encoded in the
PEM format, you can also copy and paste the information.
You can upload a CA certificate only if the file contains proper certificate information; the system validates
the certificate before saving the object.

Adding a Trusted CA Object

You can use these objects with any device type except NGIPSv.

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Trusted CAs.
Step 3 Click Add Trusted CAs.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Reusable Objects
60
 Reusable Objects
Certificate Revocation Lists in Trusted CA Objects

Step 5 Click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate file.

Step 6 If the file is password-protected, check the Encrypted, and the password is: check box, and enter the password.
Step 7 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Certificate Revocation Lists in Trusted CA Objects

You can upload CRLs to a trusted CA object. If you reference that trusted CA object in an SSL policy, you
can control encrypted traffic based on whether the CA that issued the session encryption certificate subsequently
revoked the certificate. You can upload files encoded in one of the following supported formats:
• Distinguished Encoding Rules (DER)
• Privacy-enhanced Electronic Mail (PEM)

After you add the CRL, you can view the list of revoked certificates. If you want to modify a CRL you have
uploaded to an object, you must delete the object and recreate it.
You can upload only files that contain a proper CRL. There is no limit to the number of CRLs you can add
to a trusted CA object. However, you must save the object each time you upload a CRL, before adding another
CRL.

Note Adding a CRL to an object has no effect when the object is used in your ISE/ISE-PIC integration configuration.

Adding a Certificate Revocation List to a Trusted CA Object

You can use these objects with any device type except NGIPSv.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.

Note Adding a CRL to an object has no effect when the object is used in your ISE/ISE-PIC integration configuration.

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Trusted CAs.

Step 3 Click Edit ( ) next to a trusted CA object.

If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.

Reusable Objects
61
 Reusable Objects
External Certificate Objects

Step 4 Click Add CRL to upload a DER or PEM-encoded CRL file.

Step 5 Click OK.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

External Certificate Objects

Each external certificate object you configure represents a server public key certificate that does not belong
to your organization. The object consists of the object name and certificate. You can use external certificate
objects and groups in SSL rules to control traffic encrypted with the server certificate. For example, you can
upload a self-signed server certificate that you trust, but cannot verify with a trusted CA certificate.
You can configure an external certificate object by uploading an X.509 v3 server certificate. You can upload
a file in one of the following supported formats:
• Distinguished Encoding Rules (DER)
• Privacy-enhanced Electronic Mail (PEM)

You can upload only files that contains proper server certificate information; the system validates the file
before saving the object. If the certificate is encoded in the PEM format, you can also copy and paste the
information.

Adding External Certificate Objects

You can use these objects with any device type except NGIPSv.

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose External Certs.
Step 3 Click Add External Cert.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 server certificate file.
Step 6 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

Reusable Objects
62
 Reusable Objects
Internal Certificate Objects

Internal Certificate Objects

Each internal certificate object you configure represents a server public key certificate belonging to your
organization. The object consists of the object name, public key certificate, and paired private key. You can
use internal certificate objects and groups in:
• your SSL rules to decrypt traffic incoming to one of your organization’s servers using the known private
key.
• your ISE/ISE-PIC connection. Select an internal certificate object for the MC Server Certificate field.
• your captive portal configuration to authenticate the identity of your captive portal device when connecting
to users' web browsers. Select an internal certificate object for the Server Certificate field.

You can configure an internal certificate object by uploading an X.509 v3 RSA-based or elliptic curve-based
server certificate and paired private key. You can upload a file in one of the following supported formats:
• Distinguished Encoding Rules (DER)
• Privacy-enhanced Electronic Mail (PEM)

If the file is password-protected, you must supply the decryption password. If the certificate and key are
encoded in the PEM format, you can also copy and paste the information.
You can upload only files that contain proper certificate or key information, and that are paired with each
other. The system validates the pair before saving the object.
After you create the internal certificate object, you can modify the name, but cannot modify other object
properties.
You cannot delete an internal certificate object that is in use. Additionally, after you edit an internal certificate
object that is in use, the associated access control policy goes out-of-date. You must re-deploy the access
control policy for your changes to take effect.

Adding Internal Certificate Objects

You can use these objects with any device type except NGIPSv.

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal Certs.
Step 3 Click Add Internal Cert.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 server certificate file.
Step 6 Above the Key field, or click Browse to upload a DER or PEM-encoded paired private key file.
Step 7 If the uploaded private key file is password-protected, check the Encrypted, and the password is: check box, and enter
the password.
Step 8 Click Save.

Reusable Objects
63
 Reusable Objects
Certificate Enrollment Objects

Certificate Enrollment Objects

Trustpoints let you manage and track CAs and certificates. A trustpoint is a representation of a CA or identity
pair. A trustpoint includes the identity of the CA, CA-specific configuration parameters, and an association
with one, enrolled identity certificate.
A certificate enrollment object contains the Certification Authority (CA) server information and enrollment
parameters that are required for creating Certificate Signing Requests (CSRs) and obtaining Identity Certificates
from the specified CA. These activities occur in your Private Key Infrastructure (PKI).
The certificate enrollment object may also includes certificate revocation information. For more information
on PKI, digital certificates, and certificate enrollment see PKI Infrastructure and Digital Certificates.

How to Use Certificate Enrollment Objects

Certificate Enrollment Objects are used to enroll your managed devices into your PKI infrastructure, and
create trustpoints (CA objects) on devices that support VPN connections by doing the following:
1. Define parameters for CA authentication and enrollment in a Certificate Enrollment Object. Specify shared
parameters and use the override facility to specify unique object setting for different devices.
2. Associate and install this object on each managed device that requires the identity certificate. On the
device, it becomes a trustpoint.
When a certificate enrollment object is associated with and then installed on a device, the process of
certificate enrollment starts immediately. The process is automatic for self-signed, SCEP, and PKCS12
file enrollment types, meaning it does not require any additional administrator action. Manual certificate
enrollment requires extra administrator action.
3. Specify the created trustpoint in your VPN configuration.

Managing Certificate Enrollment Objects

To manage certificate enrollment objects, go to Objects > Object Management, then from the navigation
pane choose PKI > Cert Enrollment. The following information is shown:
• Existing certificate enrollment objects are listed in the Name column.
Use the search field (the magnifying glass) to filter the list.
• The enrollment type of each object is shown in the Type column. The following enrollment methods
can be used:
• Self Signed—The managed device generates its own self signed root certificate.
• SCEP—(Default) Simple Certificate Enrollment Protocol is used by the device to obtain an identity
certificate from the CA.
• Manual—The process of enrolling is carried out manually by the administrator.
• PKCS12 File—Import a PKCS12 file on a Firepower Threat Defense managed device that supports
VPN connectivity. A PKCS#12, or PFX or P12 file holds the server certificate, any intermediate
certificates, and the private key in one encrypted file. Enter the Passphrase value for decryption.

• The Override column indicates whether the object allows overrides (a green check mark) or not (a red
X). If a number is displayed, it is the number of overrides in place.

Reusable Objects
64
 Reusable Objects
Adding Certificate Enrollment Objects

Use the Override option to customize the object settings for each device that is part of the VPN
configuration. Overriding makes each device's trustpoint details unique. Typically the Common Name
or Subject is overridden for each device in the VPN configuration.
See Object Overrides, on page 7 for details and procedures on overriding objects of any type.
• Edit a previously created certificate enrollment object by clicking on the edit icon (a pencil). Editing
can only be done if the enrollment object is not associated with any managed devices. Refer to the adding
instructions for editing a certificate enrollment object. Failed enrollment objects can be edited.
• Delete a previously created certificate enrollment object by clicking on the delete icon (a trash can). You
cannot delete a certificate enrollment object if it is associated with any managed device.

Press (+) Add Cert Enrollment to open the Add Cert Enrollment dialog and configure a Certificate
Enrollment Object, see Adding Certificate Enrollment Objects, on page 65. Then install the certificate on
each managed, headend device.
Related Topics
Installing a Certificate Using Self-Signed Enrollment
Installing a Certificate Using SCEP Enrollment
Installing a Certificate Using Manual Enrollment
Installing a Certificate Using a PKCS12 File

Adding Certificate Enrollment Objects

You can use these objects with Firepower Threat Defense devices. You must have Admin or Network Admin
privileges to do this task.

Step 1 Open the Add Cert Enrollment dialog:

• Directly from Object Management: In the Objects > Object Management screen, choose PKI > Cert Enrollment
from the navigation pane, and press Add Cert Enrollment.
• While configuring a managed device: In the Devices > Certificates screen, choose Add > Add New Certificate
and click (+) for the Certificate Enrollment field.

Step 2 Enter the Name, and optionally, a Description of this enrollment object.
When enrollment is complete, this name is the name of the trustpoint on the managed devices with which it is associated.

Step 3 Open the CA Information tab and choose the Enrollment Type.
• Self-Signed Certificate—The managed device, acting as a CA, generates its own self-signed root certificate. No
other information is needed in this pane.
Note When enrolling a self-signed certificate you must specify the Common Name (CN) in the certificate
parameters.

• SCEP—(Default) Simple Certificate Enrollment Protocol. Specify the SCEP information. See Certificate Enrollment
Object SCEP Options, on page 66.
• Manual—Paste an obtained CA certificate in the CA Certificate box. You can also obtain a CA certificate by
copying it from another device.
• PKCS12 File—Import a PKCS12 file on a Firepower Threat Defense managed device that supports VPN connectivity.
A PKCS#12, or PFX, file holds a server certificate, intermediate certificates, and a private key in one encrypted file.
Enter the Passphrase value for decryption.

Reusable Objects
65
 Reusable Objects
Certificate Enrollment Object SCEP Options

Step 4 (Optional) Open the Certificate Parameters tab and specify the certificate contents. See Certificate Enrollment Object
Certificate Parameters, on page 67.
This information is placed in the certificate and is readable by any party who receives the certificate from the router.

Step 5 (Optional) Open the Key tab and specify the Key information. See Certificate Enrollment Object Key Options, on page
68.
Step 6 (Optional) Click the Revocation tab, and specify the revocation options: See Certificate Enrollment Object Revocation
Options, on page 68.
Step 7 Allow Overrides of this object if desired. See Object Overrides, on page 7 for a full description of object overrides.

What to do next
Associate and install the enrollment object on a device to create a trustpoint on that device.
Related Topics
Installing a Certificate Using Self-Signed Enrollment
Installing a Certificate Using SCEP Enrollment
Installing a Certificate Using Manual Enrollment
Installing a Certificate Using a PKCS12 File

Certificate Enrollment Object SCEP Options

Firepower Management Center Navigation Path

Objects > Object Management, then from the navigation pane choose PKI > PKI Enrollment. Press (+)
Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the CA Information tab.

Fields
Enrollment Type—set to SCEP.
Enrollment URL—The URL of the CA server to which devices should attempt to enroll.
Use an HTTP URL in the form of [Link] where CA_name is the host DNS name or
IP address of the CA server. The port number is mandatory.

Note If the SCEP Server is referred with hostname/FQDN, configure DNS Server using FlexConfig object.

If the CA cgi-bin script location at the CA is not the default (/cgi-bin/[Link]), you must also include
the nonstandard script location in the URL, in the form of [Link] where
script_location is the full path to the CA scripts.
Challenge Password / Confirm Password—The password used by the CA server to validate the identity of
the device. You can obtain the password by contacting the CA server directly or by entering the following
address in a web browser: [Link] The password is
good for 60 minutes from the time you obtain it from the CA server. Therefore, it is important that you deploy
the password as soon as possible after you create it.

Reusable Objects
66
 Reusable Objects
Certificate Enrollment Object Certificate Parameters

Retry Period—The interval between certificate request attempts, in minutes. Value can be 1 to 60 minutes.
The default is 1 minute.
Retry Count—The number of retries that should be made if no certificate is issued upon the first request.
Value can be 1 to 100. The default is 10.
CA Certificate Source—Specify how the CA certificate will be obtained.
• Retrieve Using SCEP (Default, and only supported option)—Retrieve the certificate from the CA server
using the Simple Certificate Enrollment Process (SCEP). Using SCEP requires a connection between
your device and the CA server. Ensure there is a route from your device to the CA server before beginning
the enrollment process.

Fingerprint—When retrieving the CA certificate using SCEP, you may enter the fingerprint for the CA
server. Using the fingerprint to verify the authenticity of the CA server’s certificate helps prevent an
unauthorized party from substituting a fake certificate in place of the real one. Enter the Fingerprint for the
CA server in hexadecimal format. If the value you enter does not match the fingerprint on the certificate, the
certificate is rejected. Obtain the CA’s fingerprint by contacting the server directly, or by entering the following
address in a web browser: [Link]

Certificate Enrollment Object Certificate Parameters

Specify additional information in certificate requests sent to the CA server. This information is placed in the
certificate and can be viewed by any party who receives the certificate from the router.

Firepower Management Center Navigation Path

Objects > Object Management, then from the navigation pane choose PKI > PKI Enrollment. Press (+)
Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the Certificate Parameters tab.

Fields
Enter all information using the standard LDAP X.500 format.
• Include FQDN—Whether to include the device’s fully qualified domain name (FQDN) in the certificate
request. Choices are:
• Use Device Hostname as FQDN
• Don't use FQDN in certificate
• Custom FQDN—Select this and then specify it in the Custom FQDN field that displays.

• Include Device's IP Address—The interface whose IP address is included in the certificate request.
• Common Name (CN)—The X.500 common name to include in the certificate.

Note When enrolling a self-signed certificate you must specify the Common Name
(CN) in the certificate parameters.

• Organization Unit (OU)—The name of the organization unit (for example, a department name) to
include in the certificate.
• Organization (O)—The organization or company name to include in the certificate.

Reusable Objects
67
 Reusable Objects
Certificate Enrollment Object Key Options

• Locality (L)—The locality to include in the certificate.

• State (ST)—The state or province to include in the certificate.
• County Code (C)—The country to include in the certificate. These codes conform to ISO 3166 country
abbreviations, for example "US" for the United States of America.
• Email (E)—The email address to include in the certificate.
• Include Device's Serial Number—Whether to include the serial number of the device in the certificate.
The CA uses the serial number to either authenticate certificates or to later associate a certificate with a
particular device. If you are in doubt, include the serial number, as it is useful for debugging purposes.

Certificate Enrollment Object Key Options

Firepower Management Center Navigation Path

Objects > Object Management, then from the navigation pane choose PKI > Cert Enrollment. Press (+)
Add Cert Enrollment to open the Add Cert Enrollment dialog, and select the Key tab.

Fields
• Key Type—RSA, ECDSA.
• Key Name—If the key pair you want to associate with the certificate already exists, this field specifies
the name of that key pair. If the key pair does not exist, this field specifies the name to assign to the key
pair that will be generated during enrollment. If you do not specify a name, the fully qualified domain
name (FQDN) key pair is used instead.
• Key Size—If the key pair does not exist, defines the desired key size (modulus), in bits. The recommended
size is 2048 bits. The larger the modulus size, the more secure the key. However, keys with larger modulus
sizes take longer to generate (a minute or more when larger than 512 bits) and longer to process when
exchanged.
• Advanced Settings—Select Ignore IPsec Key Usage if you do not want to validate values in the key
usage and extended key usage extensions of IPsec remote client certificates. You can suppress key usage
checking on IPsec client certificates. By default this option is not enabled.

Note For site-to-site VPN connection, if you use a Windows Certificate Authority
(CA), the default Application Policies extension is IP security IKE intermediate.
If you are using this default setting, you must select the Ignore IPsec Key Usage
option for the object you select. Otherwise, the endpoints cannot complete the
site-to-site VPN connection.

Certificate Enrollment Object Revocation Options

Specify whether to check the revocation status of a certificate by choosing and configuring the method.
Revocation checking is off by default, neither method (CRL or OCSP) is checked.

Reusable Objects
68
 Reusable Objects
Key Chain Objects

Firepower Management Center Navigation Path

Objects > Object Management, then from the navigation pane choose PKI > PKI Enrollment. Press (+)
Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the Revocation tab.

Fields
• Enable Certificate Revocation Lists—Check to enable CRL checking.
• Use CRL distribution point from the certificate—Check to obtain the revocation lists ditribution
URL from the certificate.
• Use static URL configured—Check this to add a static, pre-defined distribution URL for revocation
lists. Then add the URLs.
CRL Server URLs—The URL of the LDAP server from which the CRL can be downloaded. This
URL must start with ldap://, and include a port number in the URL.

• Enable Online Certificate Status Protocol (OCSP)—Check to enable OCSP checking.

OCSP Server URL—The URL of the OCSP server checking for revocation if you require OCSP checks.
This URL must start with [Link]
• Consider the certificate valid if revocation information can not be reached—Checked by default.
Uncheck if you do not want to allow this.

Key Chain Objects

To enhance data security and protection of devices, rotating keys for authenticating IGP peers that have a
duration of 180 days or less is introduced. The rotating keys prevent any malicious user from guessing the
keys used for routing protocol authentication and thereby protecting the network from advertising incorrect
routes and redirecting traffic. Changing the keys frequently reduces the risk of them eventually being guessed.
When configuring authentication for routing protocols that provide key chains, configure the keys in a key
chain to have overlapping lifetimes. This helps to prevent loss of key-secured communication due to absence
of an active key. The rotating keys are applicable only for OSPFv2 protocol. If the key lifetime expires and
no active keys are found, OSPF uses the last valid key to maintain the adjacency with peers.

Note Only MD5 cryptographic algorithm is used for authentication.

Lifetime of a Key
To maintain stable communications, each device stores key chain authentication keys and uses more than one
key for a feature at the same time. Based on the send and accept lifetimes of a key, key chain management
provides a secured mechanism to handle key rollover. The device uses the lifetimes of keys to determine
which keys in a key chain are active.
Each key in a key chain has two lifetimes:
• Accept lifetime—The time interval within which the device accepts the key during key exchange with
another device.

Reusable Objects
69
 Reusable Objects
Creating Key Chain Objects

• Send lifetime—The time interval within which the device sends the key during key exchange with another
device.

During a key send lifetime, the device sends routing update packets with the key. The device does not accept
communication from other devices when the key sent is not within the accept lifetime of the key on the device.
If lifetimes are not configured then it is equivalent to configuring MD5 authentication key without timelines.

Key Selection
• When key chain has more than one valid key, OSPF selects the key that has the maximum life time.
• Key having an infinite lifetime is preferred.
• If keys have the same lifetime, then key with the higher key ID is preferred.

Creating Key Chain Objects

Step 1 Choose Objects > Object Management.

Step 2 Choose Key Chain from the list of object types.
Step 3 Click Add Key Chain.
Step 4 In the Add Key Chain Object dialog box, enter a name for the key chain in the Name field.
The name must start with an underscore or alphabet, followed by alphanumeric characters or special characters( -, _,
+, .).

Step 5 To add a key to the key chain, click Add.

Step 6 Specify the key identifier in the Key ID field.
The key id value can be between 0 and 255. Use the value 0 only when you want to signal an invalid key.

Step 7 The Algorithm field and the Crypto Encryption Type field displays the supported algorithm and the encryption type,
namely MD5 and Plain Text respectively.
Step 8 Enter the password in the Crypto Key String field, and re-enter the password in the Confirm Crypto Key String
field.
• The password can be of a maximum length of 80 characters.
• The passwords cannot be a single digit nor those starting with a digit followed by a white space. For example, "0
pass" or "1" are invalid.

Step 9 To set the time interval for a device to accept/send the key during key exchange with another device, provide the lifetime
values in the Accept Lifetime and Send Lifetime fields:
Note The Date Time values default to UTC timezones.

The end time can be the duration, the absolute time when the accept/send lifetime ends, or never expires. The default
end time is DateTime.
Following are the validation rules for the start and end values:
• Start lifetime cannot be null when the end lifetime is specified.

Reusable Objects
70
 Reusable Objects
DNS Server Group Objects

• The start lifetime for accept or send lifetime must be earlier than the respective end lifetime.

Step 10 Click Add.

Repeat steps 5 to 10 to create keys. Create a minimum of two keys for a key chain with overlapping lifetimes. This
helps to prevent loss of key-secured communication due to absence of an active key.

Step 11 Manage overrides for the object:

• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
• If you want to add override values to this object, expand the Override section and click Add; see Adding Object
Overrides, on page 9.

Step 12 Click Save.

What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes.

DNS Server Group Objects

Domain Name System (DNS) servers resolve fully-qualified domain names (FQDN), such as
[Link], to IP addresses.

Creating DNS Server Group Objects

You can use these objects with any device type except NGIPSv.

Step 1 Choose Objects > Object Management.

Step 2 Click DNS Server Group from the network objects list.
Step 3 Click Add DNS Server Group.
Step 4 Enter a Name.
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may identify a
conflict with the name of an object you cannot view in your current domain.

Step 5 Optionally, enter the Default Domain that will be used to append to the host names that are not fully-qualified.
Step 6 The default Timeout and Retries values are pre-populated. Change these values if necessary.
• Retries—The number of times, from 0 to 10, to retry the list of DNS servers when the system does not receive a
response. The default is 2.
• Timeout—The number of seconds, from 1 to 30, to wait before trying the next DNS server. The default is 2 seconds.
Each time the system retries the list of servers, this timeout doubles.

Step 7 Enter the DNS Servers that will be a part of this group, either in IPv4 or IPv6 format as comma separated entries.

Reusable Objects
71
 Reusable Objects
SLA Monitor Objects

A maximum of 6 DNS servers can belong to one group.

Step 8 Click Save.

What to do next
The DNS servers configured in the DNS server group should be assigned to interface objects in the DNS
platform settings. For more information, see Configure DNS.

SLA Monitor Objects

Each Internet Protocol Service Level Agreement (SLA) monitor defines a connectivity policy to a monitored
address and tracks the availability of a route to the address. The route is periodically checked for availability
by sending ICMP echo requests and waiting for the response. If the requests time out, the route is removed
from the routing table and replaced with a backup route. SLA monitoring jobs start immediately after
deployment and continue to run unless you remove the SLA monitor from the device configuration (that is,
they do not age out). The Internet Protocol Service Level Agreement (SLA) Monitor Object is used in the
Route Tracking field of an IPv4 Static Route Policy. IPv6 routes do not have the option to use SLA monitor
via route tracking.
You can use these objects with Firepower Threat Defense devices.

Step 1 Select Objects > Object Management and choose SLA Monitor from the table of contents.
Step 2 Click Add SLA Monitor.
Step 3 Enter a name for the object in the Name field.
Step 4 (Optional) Enter a description for the object in the Description field.
Step 5 Enter the frequency of ICMP echo request transmissions, in seconds, in the Frequency field. Valid values range from
1 to 604800 seconds (7 days). The default is 60 seconds.
Note The frequency cannot be less than the timeout value; you must convert frequency to milliseconds to compare
the values.

Step 6 Enter the ID number of the SLA operation in the SLA Monitor ID field. Values range from 1 to 2147483647. You
can create a maximum of 2000 SLA operations on a device. Each ID number must be unique to the policy and the
device configuration.
Step 7 Enter the amount of time that must pass after an ICMP echo request before a rising threshold is declared, in milliseconds,
in the Threshold field. Valid values range from 0 to 2147483647 milliseconds. The default is 5000 milliseconds. The
threshold value is used only to indicate events that exceed the defined value. You can use these events to evaluate the
proper timeout value. It is not a direct indicator of the reachability of the monitored address.
Note The threshold value should not exceed the timeout value.

Step 8 Enter the amount of time that the SLA operation waits for a response to the ICMP echo requests, in milliseconds, in
the Timeout field. Values range from 0 to 604800000 milliseconds (7 days). The default is 5000 milliseconds. If a
response is not received from the monitored address within the amount of time defined in this field, the static route is
removed from the routing table and replaced by the backup route.
Note The timeout value cannot exceed the frequency value (adjust the frequency value to milliseconds to compare
the numbers).

Reusable Objects
72
 Reusable Objects
Prefix Lists

Step 9 Enter the size of the ICMP request packet payload, in bytes, in the Data Size field. Values range from 0 to 16384 bytes.
The default is 28 bytes, which creates a total ICMP packet of 64 bytes. Do not set this value higher than the maximum
allowed by the protocol or the Path Maximum Transmission Unit (PMTU). For purposes of reachability, you might
need to increase the default data size to detect PMTU changes between the source and the target. A low PMTU can
affect session performance and, if detected, might indicate that the secondary path should be used.
Step 10 Enter a value for type of service (ToS) defined in the IP header of the ICMP request packet in the ToS field. Values
range from 0 to 255. The default is 0. This field contains information such as delay, precedence, reliability, and so on.
It can be used by other devices on the network for policy routing and features such as committed access rate.
Step 11 Enter the number of packets that are sent in the Number of Packets field. Values range from 1 to 100. The default is
1 packet.
Note Increase the default number of packets if you are concerned that packet loss might falsely cause the
Firepower Threat Defense device to believe that the monitored address cannot be reached.

Step 12 Enter the IP address that is being monitored for availability by the SLA operation, in the Monitored Address field.
Step 13 The Available Zones list displays both zones and interface groups. In the Zones/Interfaces list, add the zones or
interface groups that contain the interfaces through which the device communicates with the management station. To
specify a single interface, you need to create a zone or the interface groups for the interface; see Creating Security Zone
and Interface Group Objects, on page 19. The host will be configured on a device only if the device includes the selected
interfaces or zones.
Step 14 Click Save.

Prefix Lists
You can create prefix list objects for IPv4 and IPv6 to use when you are configuring route maps, policy maps,
OSPF Filtering, or BGP Neighbor Filtering.

Configure IPv6 Prefix List

Use the Configure IPv6 Prefix list page to create, copy and edit prefix list objects. You can create prefix list
objects to use when you are configuring route maps, policy maps, OSPF Filtering, or BGP Neighbor Filtering.
You can use this object with Firepower Threat Defense devices.

Step 1 Select Objects > Object Management and choose Prefix Lists > IPv6 Prefix List from the table of contents.
Step 2 Click Add Prefix List.
Step 3 Enter a name for the prefix list object in the Name field on the New Prefix List Object window.
Step 4 Click Add on theNew Prefix List Object window.
Step 5 Select the appropriate action, Allow or Block from the Action drop-down list, to indicate the redistribution access.
Step 6 Enter a unique number that indicates the position a new prefix list entry will have in the list of prefix list entries already
configured for this object, in the Sequence No. field. If left blank, the sequence number will default to five more than
the largest sequence number currently in use.
Step 7 Specify the IPv6 address in the IP address/mask length format in the IP address field. The mask length must be a valid
value between 1-128.

Reusable Objects
73
 Reusable Objects
Configure IPv4 Prefix List

Step 8 Enter the minimum prefix length in the Minimum Prefix Length field. The value must be greater than the mask length
and less than or equal to the Maximum Prefix Length, if specified.
Step 9 Enter the maximum prefix length in the Maximum Prefix Length field. The value must be greater than or equal to
the Minimum Prefix Length, if present, or greater than the mask length if the Minimum Prefix Length is not specified.
Step 10 Click Add.
Step 11 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
Step 12 Click Save.

Configure IPv4 Prefix List

Use the Configure IPv4 Prefix list page to create, copy and edit prefix list objects. You can create prefix list
objects to use when you are configuring route maps, policy maps, OSPF Filtering, or BGP Neighbor Filtering.
You can use this object with Firepower Threat Defense devices.

Step 1 Select Objects > Object Management and choose Prefix Lists > IPv4 Prefix List from the table of contents.
Step 2 Click Add Prefix List.
Step 3 Enter a name for the prefix list object in the Name field on the New Prefix List Object window.
Step 4 Click Add.
Step 5 Select the appropriate action, Allow or Block from the Action drop-down list, to indicate the redistribution access.
Step 6 Enter a unique number that indicates the position a new prefix list entry will have in the list of prefix list entries already
configured for this object, in the Sequence No. field. If left blank, the sequence number will default to five more than
the largest sequence number currently in use.
Step 7 Specify the IPv4 address in the IP address/mask length format in the IP address field. The mask length must be a valid
value between 1- 32.
Step 8 Enter the minimum prefix length in the Minimum Prefix Length field. The value must be greater than the mask length
and less than or equal to the Maximum Prefix Length, if specified.
Step 9 Enter the maximum prefix length in the Maximum Prefix Length field. The value must be greater than or equal to
the Minimum Prefix Length, if present, or greater than the mask length if the Minimum Prefix Length is not specified.
Step 10 Click Add.
Step 11 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
Step 12 Click Save.

Route Maps
Route maps are used when redistributing routes into any routing process. They are also used when generating
a default route into a routing process. A route map defines which of the routes from the specified routing
protocol are allowed to be redistributed into the target routing process. Configure a route map, to create a new
route map entry for a Route Map object or to edit an existing one.

Reusable Objects
74
 Reusable Objects
Route Maps

You can use this object with Firepower Threat Defense devices.

Before you begin

A Route Map may use one or mores of these objects; it is not mandatory to add all these objects. Create and
use any of these objects as required, to configure your route map.
• Add ACLs.
• Add Prefix Lists.
• Add AS Path.
• Add Community Lists.
• Add Policy Lists.

Step 1 Select Objects > Object Management and choose Route Map from the table of contents.
Step 2 Click Add Route Map.
Step 3 Click Add on theNew Route Map Object window.
Step 4 In the Sequence No. field, enter a number, between 0 and 65535, that indicates the position a new route map entry will
have in the list of route maps entries already configured for this route map object.
Note We recommend that you number clauses in intervals of at least 10 to reserve numbering space in case you
need to insert clauses in the future.

Step 5 Select the appropriate action, Allow or Block from the Redistribution drop-down list, to indicate the redistribution
access.
Step 6 Click the Match Clauses tab to match (routes/traffic) based on the following criteria, which you select in the table of
contents:
• Security Zones — Match traffic based on the (ingress/egress) interfaces. You can select zones and add them, or
type in interface names and add them.
• IPv4 — Match IPv4 (routes/traffic) based on the following criteria; select the tab to define the criteria.
a. Click the Address tab to match routes based on the route address. For IPv4 addresses, choose whether to use
an Access list or Prefix list for matching from the drop-down list and then enter or select the ACL objects or
Prefix list objects you want to use for matching.
b. Click the Next Hop tab to match routes based on the next hop address of a route. For IPv4 addresses, choose
whether to use an access list or Prefix list for matching from the drop-down list and then enter or select the
ACL objects or Prefix list objects you want to use for matching.
c. Click the Route Source tab to match routes based on the advertising source address of the route. For IPv4
addresses, choose whether to use an access list or Prefix list for matching from the drop-down list and then
enter or select the ACL objects or Prefix list objects you want to use for matching.

• IPv6 — Match IPv6 (routes/traffic) based on the route address, next-hop address or advertising source address of
route.
• BGP — Match BGP (routes/traffic) based on the following criteria; select the tab to define the criteria.
a. Click the AS Path tab to enable matching the BGP autonomous system path access list with the specified path
access list. If you specify more than one path access list, then the route can match either path access list.

Reusable Objects
75
 Reusable Objects
Route Maps

b. Click the Community List tab to enable matching the BGP community with the specified community. If you
specify more than one community, then the route can match either community. Any route that does not match
at least one Match community will not be advertised for outbound route maps.
c. Click the Policy List tab to configure a route map to evaluate and process a BGP policy. When multiple policy
lists perform matching within a route map entry, all policy lists match on the incoming attribute only.

• Others — Match routes or traffic based on the following criteria.

a. Enter the metric values to use for matching in the Metric Route Value field, to enable matching the metric
of a route. You can enter multiple values separated by commas. This setting allows you to match any routes
that have a specified metric. The metric values can range from 0 to 4294967295.
b. Enter the tag values to use for matching in the Tag Values field. You can enter multiple values separated by
commas. This setting allows you to match any routes that have a specified security group tag. The tag values
can range from 0 to 4294967295.
c. Check the appropriate Route Type option to enable matching of the route type. Valid route types are External1,
External2, Internal, Local, NSSA-External1, and NSSA-External2. You can choose more than one route type
from the list.

Step 7 Click the Set Clauses tab to set routes/traffic based on the following criteria, which you select in the table of contents:
• Metric Values — Set either Bandwidth, all of the values or none of the values.
a. Enter a metric value or bandwidth in Kbits per second in the Bandwidth field. Valid values are an integer
value in the range from 0 to 4294967295.
b. Select to specify the type of metric for the destination routing protocol, from the Metric Type drop-down list.
Valid values are : internal, type-1, or type-2.

• BGP Clauses — Set BGP routes based on the following criteria; select the tab to define the criteria.
a. Click the AS Path tab to modify an autonomous system path for BGP routes.
1. Enter an AS path number in the Prepend AS Path field to prepend an arbitrary autonomous system path
string to BGP routes. Usually the local AS number is prepended multiple times, increasing the autonomous
system path length. If you specify more than one AS path number then the route can prepend either AS
number.
2. Enter an AS path number in the Prepend Last AS to AS Path field to prepend the AS path with the last
AS number. Enter a value for the AS number from 1 to 10.
3. Check the Convert route tag into AS path check box to convert the tag of a route into an autonomous
system path.

b. Click the Community List tab to set the community attributes.

1. Click the None radio button, to remove the community attribute from the prefixes that pass the route map.
2. Click the Specific Community radio button, to enter a community number, if applicable. Valid values
are from 1 to 4294967295.
3. Check the Add to existing communities check box, to add the community to the already existing
communities.
4. Select the Internet, No-Advertise, or No-Export check-boxes to use one of the well-known communities.

Reusable Objects
76
 Reusable Objects
Access List

c. Click the Others tab to set additional attributes.

1. Check the Set Automatic Tag check-box to automatically compute the tag value.
2. Enter a preference value for the autonomous system path in the Set Local Preference field. Enter a value
between 0 and 4294967295.
3. Enter a BGP weight for the routing table in the Set Weight field. Enter a value between 0 and 65535.
4. Select to specify the BGP origin code. Valid values are Local IGP Local IGP and Incomplete.
5. In the IPv4 Settings section, specify a next hop IPv4 address of the next hop to which packets are output.
It need not be an adjacent router. If you specify more than one IPv4 address then the packets can output
at either IP address.
Select to specify an IPv4 prefix list in the Prefix List drop-down list.
6. In the IPv6 Settings section, specify a next hop IPv6 address of the next hop to which packets are output.
It need not be an adjacent router. If you specify more than one IPv6 address then the packets can output
at either IP address.
Select to specify an IPv6 prefix in the Prefix List drop-down list.

Step 8 Click Add.

Step 9 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
Step 10 Click Save.

Access List
An access list object, also known as an access control list (ACL), selects the traffic to which a service will
apply. You use these objects when configuring particular features, such as route maps, for Firepower Threat
Defense devices. Traffic identified as allowed by the ACL is provided the service, whereas “blocked” traffic
is excluded from the service. Excluding traffic from a service does not necessarily mean that it is dropped
altogether.
You can configure the following types of ACL:
• Extended—Identifies traffic based on source and destination address and ports. Supports IPv4 and IPv6
addresses, which you can mix in a given rule.
• Standard—Identifies traffic based on destination address only. Supports IPv4 only.

An ACL is composed of one or more access control entry (ACE), or rule. The order of ACEs is important.
When the ACL is evaluated to determine if a packet matches an “allowed” ACE, the packet is tested against
each ACE in the order in which the entries are listed. After a match is found, no more ACEs are checked. For
example, if you want to “allow” [Link], but “block” the rest of [Link]/24, the allow entry must
come before the block entry. In general, place more specific rules at the top of an ACL.
Packets that do not match an “allow” entry are considered to be blocked.
The following topics explain how to configure ACL objects.

Reusable Objects
77
 Reusable Objects
Configure Extended ACL Objects

Configure Extended ACL Objects

Use extended ACL objects when you want to match traffic based on source and destination addresses, protocol
and port, or if the traffic is IPv6.

Step 1 Select Objects > Object Management and choose Access List > Extended from the table of contents.
Step 2 Do one of the following:
• Click Add Extended Access List to create a new object.

• Click Edit ( ) to edit an existing object.

Step 3 In the Extended ACL Object dialog box, enter a name for the object (no spaces allowed), and configure the access control
entries:
a) Do one of the following:
• Click Add to create a new entry.

• Click Edit ( ) to edit an existing entry.

b) Select the Action, whether to Allow (match) or Block (not match) the traffic criteria.
Note The Logging, Log Level, and Log Interval options are used for access rules only (ACLs attached to
interfaces or applied globally). Because ACL objects are not used for access rules, leave these values at
their defaults.

c) Configure the source and destination addresses on the Network tab using any of the following techniques:
• Select the desired network objects or groups from the Available list and click Add to Source or Add to
Destination. You can create new objects by clicking the + button above the list. You can mix IPv4 and IPv6
addresses.
• Type an address in the edit box below the source or destination list and click Add. You can specify a single host
address (such as [Link] or 2001:DB8::0DB8:800:200C:417A), or a subnet (in [Link]/24 or [Link]
[Link] format, or for IPv6, 2001:DB8:0:CD30::/60).

d) Click the Port tab and configure the service using any of the following techniques.
• Select the desired port objects from the Available list and click Add to Source or Add to Destination. You can
create new objects by clicking the + button above the list. The object can specify TCP/UDP ports, ICMP/ICMPv6
message types, or other protocols (including “any”). However, the source port, which you typically would leave
empty, accepts TCP/UDP only. You cannot select port groups.
• Type or select a port or protocol in the edit box below the source or destination list and click Add.

Note To get an entry that applies to all IP traffic, select a destination port object that specifies “all” protocols.

e) Click Add to add the entry to the object.

f) If necessary, click and drag the entry to move it up or down in the rule order to the desired location.
Repeat the process to create or edit additional entries in the object.

Reusable Objects
78
 Reusable Objects
Configure Standard ACL Objects

Step 4 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides, on
page 9.
Step 5 Click Save.

Configure Standard ACL Objects

Use standard ACL objects when you want to match traffic based on destination IPv4 address only. Otherwise,
use extended ACLs.

Step 1 Select Objects > Object Management and choose Access List > Standard from the table of contents.
Step 2 Do one of the following:
• Click Add Standard Access List to create a new object.

• Click Edit ( ) to edit an existing object.

Step 3 In the Standard ACL Object dialog box, enter a name for the object (no spaces allowed), and configure the access control
entries:
a) Do one of the following:
• Click Add to create a new entry.

• Click Edit ( ) to edit an existing entry.

b) For each access control entry, configure the following properties:

• Action—Whether to Allow (match) or Block (not match) the traffic criteria.
• Network—Add the IPv4 network objects or groups that identify the destination of the traffic.

c) Click Add to add the entry to the object.

d) If necessary, click and drag the entry to move it up or down in the rule order to the desired location.
Repeat the process to create or edit additional entries in the object.

Step 4 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides, on
page 9.
Step 5 Click Save.

AS Path Objects
An AS Path is a mandatory attribute to set up BGP. It is a sequence of AS numbers through which a network
can be accessed. An AS-PATH is a sequence of intermediate AS numbers between source and destination
routers that form a directed route for packets to travel. Neighboring autonomous systems (ASes ) use BGP to
exchange and update messages about how to reach different AS prefixes. After each router makes a new local

Reusable Objects
79
 Reusable Objects
Community Lists

decision on the best route to a destination, it will send that route, or path information, along with the
accompanying distance metrics and path attributes, to each of its peers. As this information travels through
the network, each router along the path prepends its unique AS number to a list of ASes in the BGP message.
This list is the route's AS-PATH. An AS-PATH along with an AS prefix, provides a specific handle for a
one-way transit route through the network. Use the Configure AS Path page to create, copy and edit autonomous
system (AS) path policy objects. You can create AS path objects to use when you are configuring route maps,
policy maps, or BGP Neighbor Filtering. An AS path filter allows you to filter the routing update message
by using regular expressions.
You can use this object with Firepower Threat Defense devices.

Step 1 Select Objects > Object Management and choose AS Path from the table of contents.
Step 2 Click Add AS Path.
Step 3 Enter a name for the AS Path object in the Name field. Valid values are between 1 and 500.
Step 4 Click Add on the New AS Path Object window.
a) Select the Allow or Block options from the Action drop-down list to indicate redistribution access.
b) Specify the regular expression that defines the AS path filter in the Regular Expression field.
c) Click Add.
Step 5 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides, on
page 9.
Step 6 Click Save.

Community Lists
A Community is an optional transitive BGP attribute. A community is a group of destinations that share some
common attribute. It is used for route tagging. The BGP community attribute is a numerical value that can be
assigned to a specific prefix and advertised to other neighbors. Communities can be used to mark a set of
prefixes that share a common attribute. Upstream providers can use these markers to apply a common routing
policy such as filtering or assigning a specific local preference or modifying other attributes. Use the Configure
Community Lists page to create, copy and edit community list policy objects. You can create community list
objects to use when you are configuring route maps or policy maps. You can use community lists to create
groups of communities to use in a match clause of a route map. The community list is an ordered list of
matching statements. Destinations are matched against the rules until a match is found.
You can use this object with Firepower Threat Defense devices.

Step 1 Select Objects > Object Management and choose Community List from the table of contents.
Step 2 Click Add Community List.
Step 3 In the Name field, specify a name for the community list object.
Step 4 Click Add on the New Community List Object window.
Step 5 Select the Standard radio button to indicate the community rule type.
Standard community lists are used to specify well-known communities and community numbers.

Reusable Objects
80
 Reusable Objects
Policy Lists

Note You cannot have entries using Standard and entries using Expanded community rule types in the same
Community List object.
a) Select the Allow or Block options from the Action drop-down list to indicate redistribution access.
b) In the Communities field, specify a community number. Valid values can be from 1 to 4294967295 or from 0:1 to
65534:65535.
c) Select the appropriate Route Type.
• Internet — Select to specify the Internet well-known community. Routes with this community are advertised
to all peers (internal and external).
• No Advertise — Select to specify the no-advertise well-known community. Routes with this community are
not advertised to any peer (internal or external).
• No Export — Select to specify the no-export well-known community. Routes with this community are advertised
to only peers in the same autonomous system or to only other sub-autonomous systems within a confederation.
These routes are not advertised to external peers.

Step 6 Select the Expanded radio button to indicate the community rule type.
Expanded community lists are used to filter communities using a regular expression. Regular expressions are used to
specify patterns to match COMMUNITIES attributes.
a) Select the Allow or Block options from the Action drop-down list to indicate redistribution access.
b) Specify the regular expression in the Expressions field.
Step 7 Click Add.
Step 8 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides, on
page 9.
Step 9 Click Save.

Policy Lists
Use the Configure Policy List page to create, copy, and edit policy list policy objects. You can create policy
list objects to use when you are configuring route maps. When a policy list is referenced within a route map,
all of the match statements within the policy list are evaluated and processed. Two or more policy lists can
be configured with a route map. A policy list can also coexist with any other preexisting match and set
statements that are configured within the same route map but outside of the policy list. When multiple policy
lists perform matching within a route map entry, all policy lists match on the incoming attribute only.
You can use this object with Firepower Threat Defense devices.

Step 1 Select Objects > Object Management and choose Policy List from the table of contents.
Step 2 Click Add Policy List.
Step 3 Enter a name for the policy list object in the Name field. Object names are not case-sensitive.
Step 4 Select whether to allow or block access for matching conditions from the Action drop-down list.
Step 5 Click the Interface tab to distribute routes that have their next hop out of one of the interfaces specified.
In the Zones/Interfaces list, add the zones that contain the interfaces through which the device communicates with the
management station. For interfaces not in a zone, you can type the interface name into the field below the Selected

Reusable Objects
81
 Reusable Objects
VPN Objects

Zone/Interface list and click Add. The host will be configured on a device only if the device includes the selected
interfaces or zones.

Step 6 Click the Address tab to redistribute any routes that have a destination address that is permitted by a standard access
list or prefix list.
Choose whether to use an Access List or Prefix List for matching and then enter or select the Standard Access List
Objects or Prefix list objects you want to use for matching.

Step 7 Click the Next Hop tab to redistribute any routes that have a next hop router address passed by one of the access lists
or prefix lists specified.
Choose whether to use an Access List or Prefix List for matching and then enter or select the Standard Access List
Objects or Prefix list objects you want to use for matching.

Step 8 Click the Route Source tab to redistribute routes that have been advertised by routers and access servers at the address
specified by the access lists or prefix list.
Choose whether to use an Access List or Prefix List for matching and then enter or select the Standard Access List
Objects or Prefix list objects you want to use for matching.

Step 9 Click the AS Path tab to match a BGP autonomous system path. If you specify more than one AS path, then the route
can match either AS path.
Step 10 Click the Community Rule tab to enable matching the BGP community with the specified community. If you specify
more than one community, then the route can match either community. To enable matching the BGP community exactly
with the specified community, check the Match the specified community exactly check box.
Step 11 Click the Metric & tag tab to match the metric and security group tag of a route.
a) Enter the metric values to use for matching in the Metric field. You can enter multiple values separated by commas.
This setting allows you to match any routes that have a specified metric. The metric values can range from 0 to
4294967295.
b) Enter the tag values to use for matching in the Tag field. You can enter multiple values separated by commas. This
setting allows you to match any routes that have a specified security group tag. The tag values can range from 0 to
4294967295.
Step 12 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 9.
Step 13 Click Save.

VPN Objects
You can use the following VPN objects on Firepower Threat Defense devices. To use these objects, you must
have Admin privileges, and your Smart License account must satisfy export controls. You can configure these
objects in leaf domains only.

Firepower Threat Defense IKE Policies

Internet Key Exchange (IKE) is a key management protocol that is used to authenticate IPsec peers, negotiate
and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs). The IKE
negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which
enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes SAs for

Reusable Objects
82
 Reusable Objects
Configure IKEv1 Policy Objects

other applications, such as IPsec. Both phases use proposals when they negotiate a connection. An IKE
proposal is a set of algorithms that two peers use to secure the negotiation between them. IKE negotiation
begins by each peer agreeing on a common (shared) IKE policy. This policy states which security parameters
are used to protect subsequent IKE negotiations.
For IKEv1, IKE proposals contain a single set of algorithms and a modulus group. You can create multiple,
prioritized policies to ensure that at least one policy matches a remote peer’s policy. Unlike IKEv1, in an
IKEv2 proposal, you can select multiple algorithms and modulus groups in one policy. Since peers choose
during the Phase 1 negotiation, this makes it possible to create a single IKE proposal, but consider multiple,
different proposals to give higher priority to your most desired options. For IKEv2, the policy object does not
specify authentication, other policies must define the authentication requirements.
An IKE policy is required when you configure a site-to-site IPsec VPN. For more information, see Firepower
Threat Defense VPN.

Configure IKEv1 Policy Objects

Use the IKEv1 Policy page to create, delete, or edit an IKEv1 policy object. These policy objects contain the
parameters required for IKEv1 policies.

Step 1 Choose Objects > Object Management and then VPN > IKEv1 Policy from the table of contents.
Previously configured policies are listed including system defined defaults. Depending on your level of access, you

may Edit ( ), View View ( ), or Delete ( ) a proposal.

Step 2 (Optional) Choose Add ( )Add IKEv1 Policy to create a new policy object.
Step 3 Enter a Name for this policy. A maximum of 128 characters is allowed.
Step 4 (Optional) Enter a Description for this proposal. A maximum of 1,024 characters is allowed.
Step 5 Enter the Priority value of the IKE policy.
The priority value determines the order of the IKE policy compared by the two negotiating peers when attempting to
find a common security association (SA). If the remote IPsec peer does not support the parameters selected in your
first priority policy, it tries to use the parameters defined in the next lowest priority. Valid values range from 1 to 65,535.
The lower the number, the higher the priority. If you leave this field blank, Management Center assigns the lowest
unassigned value starting with 1, then 5, then continuing in increments of 5.

Step 6 Choose the Encryption method.

When deciding which encryption and Hash Algorithms to use for the IKEv1 policy, your choice is limited to algorithms
supported by the peer devices. For an extranet device in the VPN topology, you must choose the algorithm that matches
both peers. For IKEv1, select one of the options. For a full explanation of the options, see Deciding Which Encryption
Algorithm to Use.

Step 7 Choose the Hash Algorithm that creates a Message Digest, which is used to ensure message integrity.
When deciding which encryption and Hash Algorithms to use for the IKEv1 proposal, your choice is limited to algorithms
supported by the managed devices. For an extranet device in the VPN topology, you must choose the algorithm that
matches both peers. For a full explanation of the options, see Deciding Which Hash Algorithms to Use.

Step 8 Set the Diffie-Hellman Group.

Reusable Objects
83
 Reusable Objects
Configure IKEv2 Policy Objects

The Diffie-Hellman group to use for encryption. A larger modulus provides higher security but requires more processing
time. The two peers must have a matching modulus group. Select the group that you want to allow in the [Link] a
full explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use.

Step 9 Set the Lifetimeof the security association (SA), in seconds. You can specify a value from 120 to 2,147,483,647 seconds.
The default is 86400.
When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. Generally, the shorter
the lifetime (up to a point), the more secure your IKE negotiations. However, with longer lifetimes, future IPsec security
associations can be set up more quickly than with shorter lifetimes.

Step 10 Set the Authentication Method to use between the two peers.
• Preshared Key—Preshared keys allow for a secret key to be shared between two peers and to be used by IKE
during the authentication phase. If one of the participating peers is not configured with the same preshared key,
the IKE SA cannot be established.
• Certificate—When you use Certificates as the authentication method for VPN connections, peers obtain digital
certificates from a CA server in your PKI infrastructure, and trade them to authenticate each other.

Note In a VPN topology that supports IKEv1, the Authentication Method specified in the chosen IKEv1 Policy
object becomes the default in the IKEv1 Authentication Type setting. These values must match, otherwise,
your configuration will error.

Step 11 Click Save

The new IKEv1 policy is added to the list.

Configure IKEv2 Policy Objects

Use the IKEv2 policy dialog box to create, delete, and edit an IKEv2 policy object. These policy objects
contain the parameters required for IKEv2 policies.

Step 1 Choose Objects > Object Management and then VPN > IKEv2 Policy from the table of contents.
Previously configured policies are listed including system defined defaults. Depending on your level of access, you

may Edit ( ), View ( ), or Delete ( ) a policy.

Step 2 Choose Add ( )Add IKEv2 Policy to create a new policy.

Step 3 Enter a Name for this policy.
The name of the policy object. A maximum of 128 characters is allowed.

Step 4 Enter a Description for this policy.

A description of the policy object. A maximum of 1024 characters is allowed.

Step 5 Enter the Priority.

The priority value of the IKE proposal. The priority value determines the order of the IKE proposals compared by the
two negotiating peers when attempting to find a common security association (SA). If the remote IPsec peer does not
support the parameters selected in your first priority policy, it tries to use the parameters defined in the next lowest
priority policy. Valid values range from 1 to 65535. The lower the number, the higher the priority. If you leave this

Reusable Objects
84
 Reusable Objects
Firepower Threat Defense IPsec Proposals

field blank, Management Center assigns the lowest unassigned value starting with 1, then 5, then continuing in increments
of 5.

Step 6 Set the Lifetimeof the security association (SA), in seconds. You can specify a value from 120 to 2,147,483,647 seconds.
The default is 86400.
When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. Generally, the shorter
the lifetime (up to a point), the more secure your IKE negotiations. However, with longer lifetimes, future IPsec security
associations can be set up more quickly than with shorter lifetimes.

Step 7 Choose the Integrity Algorithms portion of the Hash Algorithm used in the IKE policy. The Hash Algorithm creates
a Message Digest, which is used to ensure message integrity.
When deciding which encryption and Hash Algorithms to use for the IKEv2 proposal, your choice is limited to algorithms
supported by the managed devices. For an extranet device in the VPN topology, you must choose the algorithm that
matches both peers. Select all the algorithms that you want to allow in the [Link] a full explanation of the options,
see Deciding Which Hash Algorithms to Use.

Step 8 Choose the Encryption Algorithm used to establish the Phase 1 SA for protecting Phase 2 negotiations.
When deciding which encryption and Hash Algorithms to use for the IKEv2 proposal, your choice is limited to algorithms
supported by the managed devices. For an extranet device in the VPN topology, you must choose the algorithm that
matches both peers. Select all the algorithms that you want to allow in the VPN. For a full explanation of the options,
see Deciding Which Encryption Algorithm to Use.

Step 9 Choose the PRF Algorithm.

The pseudorandom function (PRF) portion of the Hash Algorithm used in the IKE policy. In IKEv1, the Integrity and
PRF algorithms are not separated, but in IKEv2, you can specify different algorithms for these elements. Select all of
the algorithms that you want to allow in the VPN. For a full explanation of the options, see Deciding Which Hash
Algorithms to Use.

Step 10 Select and Add a DH Group.

The Diffie-Hellman group used for encryption. A larger modulus provides higher security but requires more processing
time. The two peers must have a matching modulus group. Select the groups that you want to allow in the VPN. For a
full explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use.

Step 11 Click Save

If a valid combination of choices has been selected the new IKEv2 policy is added to the list. If not, errors are displayed
and you must make changes accordingly to successfully save this policy.

Firepower Threat Defense IPsec Proposals

IPsec Proposals (or Transform Sets) are used when configuring VPN topologies. During the IPsec security
association negotiation with ISAKMP, the peers agree to use a particular proposal to protect a particular data
flow. The proposal must be the same for both peers.
There are separate IPsec proposal objects based on the IKE version, IKEv1, or IKEv2:
• When you create an IKEv1 IPsec Proposal (Transform Set) object, you select the mode in which IPsec
operates, and define the required encryption and authentication types. You can select single options for
the algorithms. If you want to support multiple combinations in a VPN, create multiple IKEv1 IPsec
Proposal objects.

Reusable Objects
85
 Reusable Objects
Configure IKEv1 IPsec Proposal Objects

• When you create an IKEv2 IPsec Proposal object, you can select all of the encryption and Hash Algorithms
allowed in a VPN. During IKEv2 negotiations, the peers select the most appropriate options that each
support.

The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec Proposals. It provides
authentication, encryption, and antireplay services. ESP is IP protocol type 50.

Note We recommend using both encryption and authentication on IPsec tunnels.

Configure IKEv1 IPsec Proposal Objects

Step 1 Choose Objects > Object Management and then VPN > IPsec IKev1 Proposal from the table of contents.
Previously configured Proposals are listed including system defined defaults. Depending on your level of access, you

may Edit ( ), View View ( ), or Delete ( ) a Proposal.

Step 2 Choose Add ( )Add IPsec IKEv1 Proposal to create a new Proposal.
Step 3 Enter a Name for this Proposal
The name of the policy object. A maximum of 128 characters is allowed.

Step 4 Enter a Description for this Proposal.

A description of the policy object. A maximum of 1024 characters is allowed.

Step 5 Choose the ESP Encryption method. The Encapsulating Security Protocol (ESP) encryption algorithm for this Proposal.
For IKEv1, select one of the options. When deciding which encryption and Hash Algorithms to use for the IPsec proposal,
your choice is limited to algorithms supported by the devices in the VPN. For a full explanation of the options, see
Deciding Which Encryption Algorithm to Use.

Step 6 Select an option for ESP Hash.

For a full explanation of the options, see Deciding Which Hash Algorithms to Use.

Step 7 Click Save

The new Proposal is added to the list.

Configure IKEv2 IPsec Proposal Objects

Step 1 Choose Objects > Object Management and then VPN > IKEv2 IPsec Proposal from the table of contents.
Previously configured Proposals are listed including system defined defaults. Depending on your level of access, you

may Edit Edit ( ), View View ( ), or Delete Delete ( ) a Proposal.

Step 2 Choose Add ( )Add IKEv2 IPsec Proposal to create a new Proposal.

Reusable Objects
86
 Reusable Objects
Firepower Threat Defense Group Policy Objects

Step 3 Enter a Name for this Proposal

The name of the policy object. A maximum of 128 characters is allowed.

Step 4 Enter a Description for this Proposal.

A description of the policy object. A maximum of 1024 characters is allowed.

Step 5 Choose the ESP Hash method, the hash or integrity algorithm to use in the Proposal for authentication.
Note Firepower Threat Defense does not support IPSec tunnels with NULL encryption. Make sure that you do
not choose NULL encryption for IPSec IKEv2 proposal.

For IKEv2, select all the options you want to support for ESP Hash. For a full explanation of the options, see Deciding
Which Hash Algorithms to Use.

Step 6 Choose the ESP Encryption method. The Encapsulating Security Protocol (ESP) encryption algorithm for this Proposal.
For IKEv2, click Select to open a dialog box where you can select all of the options you want to support. When deciding
which encryption and Hash Algorithms to use for the IPsec proposal, your choice is limited to algorithms supported by
the devices in the VPN. For a full explanation of the options, see Deciding Which Encryption Algorithm to Use.

Step 7 Click Save

The new Proposal is added to the list.

Firepower Threat Defense Group Policy Objects

A group policy is a set of attribute and value pairs, stored in a group policy object, that define the remote
access VPN experience. For example, in the group policy object, you configure general attributes such as
addresses, protocols, and connection settings.
The group policy applied to a user is determined when the VPN tunnel is being established. The RADIUS
authorization server assigns the group policy, or it is obtained from the current connection profile.

Note There is no group policy attribute inheritance on the Firepower Threat Defense. A group policy object is used,
in its entirety, for a user. The group policy object identified by the AAA server upon login is used, or, if that
is not specified, the default group policy configured for the VPN connection is used. The provided default
group policy can be set to your default values, but will only be used if it is assigned to a connection profile
and no other group policy has been identified for the user.

To use group objects, you must have one of these AnyConnect licenses associated with your Smart License
account with Export-Controlled Features enabled:
• AnyConnect VPN Only
• AnyConnect Plus
• AnyConnect Apex

Related Topics
Configure Group Policy Objects, on page 88

Reusable Objects
87
 Reusable Objects
Configure Group Policy Objects

Configure Group Policy Objects

See Firepower Threat Defense Group Policy Objects, on page 87.

Step 1 Choose Objects > Object Management > VPN > Group Policy.
Previously configured policies are listed including the system default. Depending on your level of access, you may edit,
view, or delete a group policy.

Step 2 Click Add Group Policy or choose a current policy to edit.

Step 3 Enter a Name and optionally a Description for this policy.
The name can be up to 64 characters, spaces are allowed. The description can be up to 1,024 characters.

Step 4 Specify the General parameters for this Group Policy as described in Group Policy General Options, on page 88.
Step 5 Specify the AnyConnect parameters for this Group Policy as described in Group Policy AnyConnect Options, on page
90.
Step 6 Specify the Advanced parameters for this Group Policy as described in Group Policy Advanced Options, on page 92.
Step 7 Click Save.
The new Group Policy is added to the list.

What to do next
Add the group policy object to a remote access VPN connection profile.

Group Policy General Options

Navigation Path
Objects > Object Management > VPN > Group Policy, click Click Add Group Policy or choose a current
policy to edit., then select the General tab.

VPN Protocols Fields

Specify the types of Remote Access VPN tunnels that can be used when applying this group policy. SSL or
IPsec IKEv2.

IP Address Pools
Specifies the IPv4 address assignment that is applied based on address pools that are specific to user-groups
in Remote Access VPN. For Remote Access VPN, you can assign IP address from specific address pools for
identified user groups using RADIUS/ISE for authorization. You can seamlessly perform policy enforcement
for user or user groups in systems which are not identity-aware, by configuring particular Group Policy as
RADIUS Authorization attribute (GroupPolicy/Class), for a particular user group. For example, you have to
select a specific address pool for contractors and policy enforcement using those addresses to allow restricted
access to internal network.
The order of preference that Firepower Threat Defense device assigns the IPv4 Address Pools to the clients:
1. RADIUS attribute for IPv4Address Pool

Reusable Objects
88
Reusable Objects
Group Policy General Options

2. RADIUS attribute for Group Policy

3. Address Pool in Group Policy mapped to a Connection Profile
4. IPv4Address Pool in Connection Profile

Some limitations around using IP address pools in Group Policy:

• IPv6 address pool is not supported.
• Maximum of six IPv4 address pools can be configured in a Group Policy.
• Deployment failures are seen when address pools in use are modified. You must logoff all the users
before making any changes to the address pools.
• When address pools are renamed or overlapping address pools are configured, deployment could fail.
You must deploy the changes by removing the old address pool and later deploying the changed address
pool.
Some troubleshooting commands :
• show ip local pool <address-pool-name>

• show vpn-sessiondb detail anyconnect

• vpn-sessiondb loggoff all noconfirm

Banner Fields
Specifies the banner text to present to users at login. The length can be up to 491 characters. There is no default
value. The IPsec VPN client supports full HTML for the banner, however, the AnyConnect client supports
only partial HTML. To ensure that the banner displays properly to remote users, use the /n tag for IPsec clients,
and the <BR> tag for SSL clients.

DNS/WINS Fields
Domain Naming System (DNS) and Windows Internet Naming System (WINS) servers. Used for AnyConnect
client name resolution.
• Primary DNS Server and Secondary DNS Server—Choose or create a Network Object which defines
the IPv4 or IPv6 addresses of the DNS servers you want this group to use.
• Primary WINS Server and Secondary WINS Server—Choose or create a Network Object containing
the IP addresses of the WINS servers you want this group to use.
• DHCP Network Scope—Choose or create a Network Object containing a routeable IPv4 address on
the same subnet as the desired pool, but not within the pool. The DHCP server determines which subnet
this IP address belongs to and assigns an IP address from that pool. If not set properly, deployment of
the VPN policy fails.
If you configure DHCP servers for the address pool in the connection profile, the DHCP scope identifies
the subnets to use for the pool for this group. The DHCP server must also have addresses in the same
subnet identified by the scope. The scope allows you to select a subset of the address pools defined in
the DHCP server to use for this specific group.
If you do not define a network scope, the DHCP server assigns IP addresses in the order of the address
pools configured. It goes through the pools until it identifies an unassigned address.

Reusable Objects
89
 Reusable Objects
Group Policy AnyConnect Options

We recommend using the IP address of an interface whenever possible for routing purposes. For example,
if the pool is [Link]-[Link], and the interface address is [Link]/24, use [Link] as
the DHCP scope. Do not use the network number. You can use DHCP for IPv4 addressing only. If the
address you choose is not an interface address, you might need to create a static route for the scope
address.
LINK-SELECTION (RFC 3527) and SUBNET-SELECTION (RFC 3011) are currently not supported.
• Default Domain—Name of the default domain. Specify a top-level domain, for example, [Link].

Split Tunneling Fields

Split tunneling directs some network traffic through the VPN tunnel (encrypted) and the remaining network
traffic outside the VPN tunnel (unencrypted or “in the clear”).
• IPv4 Split Tunneling / IPv6 Split Tunneling—By default, split tunneling is not enabled. For both IPv4
and IPv6 it is set to Allow all traffic over tunnel. Left as is, all traffic from the endpoint goes over the
VPN connection.
To configure split tunneling, choose the Tunnel networks specified below or Exclude networks
specified below policy. Then configure an access control list for that policy.
• Split Tunnel Network List Type—Choose the type of Access List you are using. Then choose or create
a Standard Access List or Extended Access List. See Access List, on page 77 for details.
• DNS Request Split Tunneling—Also known as Split DNS. Configure the DNS behaviour expected in
your environment.
By default, split DNS is not enabled and set to Send DNS request as per split tunnel policy. Choosing
Always send DNS request over tunnel forces all DNS requests to be sent over the tunnel to the private
network.
To configure split DNS, choose Send only specified domains over tunnel, and enter the list of domain
names in the Domain List field. These requests are resolved through the split tunnel to the private
network. All other names are resolved using the public DNS server. Enter up to ten entries in the list of
domains, separated by commas. The entire string can be no longer than 255 characters.

Related Topics
Configure Group Policy Objects, on page 88

Group Policy AnyConnect Options

These specifications apply to the operation of the AnyConnect VPN client.

Navigation
Objects > Object Management > VPN > Group Policy. Click Add Group Policy or choose a current policy
to edit. Then select the AnyConnect tab.

Profile Fields
Profile—Choose or create a file object containing an AnyConnect Client Profile. See Firepower Threat
Defense File Objects, on page 93 for object creation details.

Reusable Objects
90
Reusable Objects
Group Policy AnyConnect Options

An AnyConnect Client Profile is a group of configuration parameters stored in an XML file. The AnyConnect
software client uses it to configure the connection entries that appear in the client's user interface. These
parameters (XML tags) also configure settings to enable more AnyConnect features.
Use the GUI-based AnyConnect Profile Editor, an independent configuration tool, to create an AnyConnect
Client Profile. See the AnyConnect Profile Editor chapter in the appropriate release of the Cisco AnyConnect
Secure Mobility Client Administrator Guide for details.

SSL Settings Fields

• SSL Compression—Whether to enable data compression, and if so, the method of data compression to
use, Deflate, or LZS. SSL Compression is Disabled by default.
Data compression speeds up transmission rates, but also increases the memory requirement and CPU
usage for each user session. Therefore, decreasing the overall throughput of the security appliance.
• DTLS Compression—Whether to compress Datagram Transport Layer Security (DTLS) connections
for this group using LZS or not. DTLS Compression is Disabled by default.
• MTU Size—The maximum transmission unit (MTU) size for SSL VPN connections established by the
Cisco AnyConnect VPN Client. Default is 1406 Bytes, valid range is 576 to 1462 Bytes.
• Ignore DF Bit—Whether to ignore the Don't Fragment (DF) bit in packets that need fragmentation.
Allows the forced fragmentation of packets that have the DF bit set, allowing them to pass through
the tunnel.

Connection Settings Fields

• Enable Keepalive Messages between AnyConnect Client and VPN gateway. And its Interval
setting.—Whether to exchange keepalive messages between peers to demonstrate that they are available
to send and receive data in the tunnel. Default is enabled. Keepalive messages transmit at set intervals.
If enabled, enter the time interval (in seconds) that the remote client waits between sending IKE keepalive
packets. The default interval is 20 seconds, the valid range is 15 to 600 seconds.
• Enable Dead Peer Detection on .... And their Interval settings.—Dead Peer Detection (DPD) ensures
that the VPN secure gateway or the VPN client quickly detects when the peer is no longer responding,
and the connection has failed. Default is enabled for both the gateway and the client. DPD messages
transmit at set intervals. If enabled, enter the time interval (in seconds) that the remote client waits between
sending DPD messages. The default interval is 30 seconds, the valid range is 5 to 3600 seconds.
• Enable Client Bypass Protocol—Allows you to configure how the secure gateway manages IPv4 traffic
(when it is expecting only IPv6 traffic), or how it manages IPv6 traffic (when it is expecting only IPv4
traffic).
When the AnyConnect client makes a VPN connection to the headend, the headend assigns it an IPv4,
IPv6, or both an IPv4 and IPv6 address. If the headend assigns the AnyConnect connection only an IPv4
address or only an IPv6 address, you can configure the Client Bypass Protocol to drop network traffic
for which the headend did not assign an IP address (default, disabled, not checked), or allow that traffic
to bypass the headend and be sent from the client unencrypted or “in the clear” (enabled, checked).
For example, assume that the secure gateway assigns only an IPv4 address to an AnyConnect connection
and the endpoint is dual-stacked. When the endpoint attempts to reach an IPv6 address, if Client Bypass
Protocol is disabled, the IPv6 traffic is dropped; however, if Client Bypass Protocol is enabled, the IPv6
traffic is sent from the client in the clear.

Reusable Objects
91
 Reusable Objects
Group Policy Advanced Options

• SSL rekey—Enables the client to rekey the connection, renegotiating the crypto keys and initialization
vectors, increasing the security of the connection. This is disabled by default. When enabled, the
renegotiation can be done at a specified interval and rekey the existing tunnel or create a new tunnel by
setting the following fields:
• Method—Available when SSL rekey is enabled. Create a New Tunnel (default), or renegotiate,
the Existing Tunnel's specifications.
• Interval—Available when SSL rekey is enabled. Set to a default of 4 minutes with a range of
4-10080 minutes (1 week).

• Client Firewall Rules—Use the Client Firewall Rules to configure firewall settings for the VPN client's
platform. Rules are based on criteria such as source address, destination address, and protocol. Extended
Access Control List building block objects are used to define the traffic filter criteria. Choose or create
an Extended ACL for this group policy. Define a Private Network Rule to control data flowing to the
private network, a Public Network Rule to control data flowing "in the clear", outside of the established
VPN tunnel, or both.

Note Ensure that the ACL contains only TCP/UDP/ICMP/IP ports and source network
as any, any-ipv4 or any-ipv6.
Only VPN clients running Microsoft Windows can use these firewall settings.

Related Topics
Configure Group Policy Objects, on page 88

Group Policy Advanced Options

Navigation Path
Objects > Object Management > VPN > Group Policy, click Click Add Group Policy or choose a current
policy to edit., then select the Advanced tab.

Traffic Filter Fields

• Access List Filter—Filters consist of rules that determine whether to allow or block tunneled data packets
coming through the VPN connection. Rules are based on criteria such as source address, destination
address, and protocol. Note that the VPN filter applies to initial connections only. It does not apply to
secondary connections, such as a SIP media connection, that are opened due to the action of application
inspection. Extended Access Control List building block objects are used to define the traffic filter criteria.
Choose or create a new Extended ACL for this group policy.
• Restrict VPN to VLAN—Also called “VLAN mapping,” this parameter specifies the egress VLAN
interface for sessions to which this group policy applies. The ASA forwards all traffic from this group
to the selected VLAN.
Use this attribute to assign a VLAN to the group policy to simplify access control. Assigning a value to
this attribute is an alternative to using ACLs to filter traffic on a session. In addition to the default value
(Unrestricted), the drop-down list shows only the VLANs that are configured in this ASA. Allowed
values range from 1 to 4094.

Reusable Objects
92
 Reusable Objects
Firepower Threat Defense File Objects

Session Settings Fields

• Access Hours—Choose or create a time range object. This object specifies the range of time this group
policy is available to be applied to a remote access user. See Time Range Objects, on page 20 for details.
• Simultaneous Logins Per User—Specifies the maximum number of simultaneous logins allowed for
a user. The default value is 3. The minimum value is 0, which disables login and prevents user access.
Allowing several simultaneous connections may compromise security and affect performance.
• Maximum Connection Time / Alert Interval—Specifies the maximum user connection time in minutes.
At the end of this time, the system stops the connection. The minimum is 1 minute). The Alert interval
specifies the interval of time before maximum connection time is reached to display a message to the
user.
• Idle Timeout / Alert Interval—Specifies this user’s idle timeout period in minutes. If there is no
communication activity on the user connection in this period, the system stops the connection. The
minimum time is 1 minute. The default is 30 minutes. The Alert interval specifies the interval of time
before idle time is reached to display a message to the user.

Related Topics
Configure Group Policy Objects, on page 88

Firepower Threat Defense File Objects

Use the Add and Edit File Object dialog boxes to create, and edit file objects. File objects represent files used
in configurations, typically for remote access VPN policies. They can contain AnyConnect Client Profile and
AnyConnect Client Image files.
When you create a file object, the Firepower Management Center makes a copy of the file in its repository.
These files are backed up whenever you create a backup of the database, and they are restored if you restore
the database. When copying a file to the Firepower Management Center platform to be used in a file object,
do not copy the file directly to the file repository.
When you deploy configurations that specify a file object, the associated file is downloaded to the device in
the appropriate directory.
You can click one of the following options against each file:
• Download —Click to download an AnyConnect file.
• Edit —Modify the file object details.
• Delete —Delete an AnyConnect file object. When you delete a file object, the associated file is not
deleted from the file repository, only the object is deleted.

Navigation Path
Objects > Object Management > VPN > AnyConnect File > Add AnyConnect File.

Fields
• Name and Description—Enter the name, up to 128 characters, and an optional description to identify
this file object.

Reusable Objects
93
 Reusable Objects
Firepower Threat Defense Certificate Map Objects

• File Name and File Type—The name and full path of the file, and its type. Click Browse to select the
file, and choose the corresponding type.
Only the AnyConnect Client Image and AnyConnect Client Profile types are valid, and they must be
located on the Firepower Management Center platform to include them in a file object.

Related Topics
Cisco AnyConnect Secure Mobility Client Image
Group Policy AnyConnect Options, on page 90

Firepower Threat Defense Certificate Map Objects

Certificate Map objects are a named set of certificate matching rules. These objects are used to provide an
association between a received certificate and a Remote Access VPN connection profile. Connection Profiles
and Certificate Map objects are both part of a remote access VPN policy. If a received certificate matches the
rules contained in the certificate map, the connection is "mapped", or associated with the specified connection
profile. The rules are in priority order, they are matched in the order they are shown in the UI. The matching
ends when the first rule within the Certificate Map object results in a match.

Navigation
Objects > Object Management > VPN > Certificate Map

Fields
• Name—Identify this object so it can be referred to from other configurations, such as Remote Access
VPN.
• Mapping Criteria—Specify the contents of the certificate to evaluate. If the certificate satisifies these
rules, the user will be mapped to the connection profile containing this object.
• Component—Select the component of the client certificate to use for the matching rule.
• Field—Select the field for the matching rule according to the Subject or the Issuer of the client
certificate.
If the Field is set to Alternative Subject or Extended Key Usage the Component will be frozen as
Whole Field
• Operator—Select the operator for the matching rule as follows:
• Equals—The certificate component must match the entered value. If they do not match exactly,
the connection is denied.
• Contains—The certificate component must contain the entered value. If the component does
not contain the value, the connection is denied.
• Does Not Equal—The certificate component cannot equal the entered value. For example, for
a selected certificate component of Country, and an entered value of US, if the client county
value equals US, then the connection is denied.
• Does Not Contain—The certificate component cannot contain the entered value. For example,
for a selected certificate component of Country, and an entered value of US, if the client county
value contains US, the connection is denied.

Reusable Objects
94
 Reusable Objects
Address Pools

• Value—The value of the matching rule. The value entered is associated with the selected component
and operator.

Related Topics
Configure Certificate Maps

Address Pools
You can configure IP address pools for both IPv4 and IPv6 that can be used for the Diagnostic interface with
clustering, or for VPN remote access profiles.
You can use this object with Firepower Threat Defense devices.

Step 1 Select Objects > Object Management > Address Pools > IPv4 Pools.
Step 2 Click Add IPv4 Pools, and configure the following fields:
• Name—Enter the name of the address pool. It can be up to 64 characters
• Description—Add an optional description for this pool.
• IP Address—Enter a range of addresses available in the pool. Use dotted decimal notation and a dash between the
beginning and the end address, for example: [Link]-[Link].
• Mask—Identifies the subnet on which this IP address pool resides.
• Allow Overrides—Check this check box to enable object overrides. Click the expand arrow to show the Overrides
table. You can add a new override by clicking Add. See Object Overrides, on page 7 for more information.

Step 3 Click Save.

Step 4 Click Add IPv6 Pools, and configure the following fields:
• Name—Enter the name of the address pool. It can be up to 64 characters
• Description—Add an optional description for this pool.
• IPv6 Address—Enter the first IP address available in the configured pool and the prefix length in bits. For example:
2001:DB8::1/64.
• Number of Addresses—Identifies the number of IPv6 addresses, starting at the Starting IP Address, that are in the
pool.
• Allow Overrides—Check this check box to enable overrides. Click the expand arrow to show the Overrides table.
You can add a new override by clicking Add. See Object Overrides, on page 7 for more information.

Step 5 Click Save.

Reusable Objects
95
 Reusable Objects
FlexConfig Objects

FlexConfig Objects
Use FlexConfig policy objects in FlexConfig policies to provide customized configuration of features on
Firepower Threat Defense devices that you cannot otherwise configure using Firepower Management Center.
For more information on FlexConfig policies, see FlexConfig Policy Overview.
You can configure the following types of objects for FlexConfig.
Text Objects
Text objects define free-form text strings that you use as variables in a FlexConfig object. These objects
can have single values or be a list of multiple values.
There are several predefined text objects that are used in the predefined FlexConfig objects. If you use
the associated FlexConfig object, you simply need to edit the contents of the text object to customize
how the FlexConfig object configures a given device. When editing a predefined object, it is in general
a better option to create device overrides for each device you are configuring, rather than directly change
the default values of these objects. This helps avoid unintended consequences if another user wants to
use the same FlexConfig object for a different set of devices.
For information on configuring text objects, see Configure FlexConfig Text Objects.
FlexConfig Objects
FlexConfig Objects include device configuration commands, variables, and scripting language instructions.
During configuration deployment, these instructions are processed to create a sequence of configuration
commands with customized parameters to configure specific features on the target devices.
These instructions are either configured before (prepended) the system configures features defined in
regular Firepower Management Center policies and settings, or after (appended). Any FlexConfig that
depends on Firepower Management Center-configured objects (for example, a network object) must be
appended to the configuration deployment, or the needed objects would not be configured before the
FlexConfig needed to refer to the objects.
For more information on configuring FlexConfig objects, see Configure FlexConfig Objects.

RADIUS Server Groups

RADIUS Server Group objects contain one or more references to RADIUS servers. These servers are used
to authenticate users logging in through Remote Access VPN connections.
You can use this object with Firepower Threat Defense devices.

Before you begin

Note You cannot override RADIUS Server Group Objects.

Step 1 Select Objects > Object Management > RADIUS Server Group.
All currently configured RADIUS Server Group objects will be listed. Use the filter to narrow down the list.

Reusable Objects
96
 Reusable Objects
RADIUS Server Group Options

Step 2 Choose and edit a listed RADIUS Server Group object, or add a new one.
See RADIUS Server Options, on page 98 and RADIUS Server Group Options, on page 97 to configure this object.

Step 3 Click Save

RADIUS Server Group Options

Navigation Path
Objects > Object Management > RADIUS Server Group. Choose and edit a configured RADIUS Server
Group object or add a new one.

Fields
• Name and Description—Enter a name and optionally, a description to identify this RADIUS Server
Group object.
• Group Accounting Mode—The method for sending accounting messages to the RADIUS servers in
the group. Choose Single, accounting messages are sent to a single server in the group, this is the default.
Or, Simultaneous, accounting messages are sent to all servers in the group simultaneously.
• Retry Interval—The interval between attempts to contact the RADIUS servers. Values range from 1 to
10 seconds.
• Realms(Optional)—Specify or select the Active Directory (AD) realm this RADIUS server group is
associated with. This realm is then selected in identity policies to access the associated RADIUS server
group when determining the VPN authentication identity source for a traffic flow. This realm effectively
provides a bridge from the identity policy to this Radius server group. If no realm is associated with this
RADIUS server group, the RADIUS server group cannot be reached to determine the VPN authentication
identity source for a traffic flow in an identity policy.
• Enable authorize only—If this RADIUS server group is not being used for authentication, but is being
used for authorization or accounting, check this field to enable authorize-only mode for the RADIUS
server group.
Authorize only mode eliminates the need of including the RADIUS server password in the Access-Request.
Thus, the password, configured for the individual RADIUS servers, is ignored.
• Enable interim account update and Interval—Enables the generation of RADIUS
interim-accounting-update messages in order to inform the RADIUS server of newly assigned IP addresses.
Set the length, in hours, of the interval between periodic accounting updates in the Interval field. The
valid range is 1 to 120 and the default value is 24.
• Enable Dynamic Authorization and Port— Enables the RADIUS dynamic authorization or change of
authorization (CoA) services for this RADIUS server group. Specify the listening port for RADIUS CoA
requests in the Port field. The valid range is 1024 to 65535 and the default value is 1700. Once defined,
the corresponding RADIUS server group will be registered for CoA notification and it listens to the port
for the CoA policy updates from the Cisco Identity Services Engine (ISE).
• RADIUS Servers—See RADIUS Server Options, on page 98.

Reusable Objects
97
 Reusable Objects
RADIUS Server Options

Related Topics
RADIUS Server Groups, on page 96

RADIUS Server Options

Navigation Path
Objects > Object Management > RADIUS Server Group. Choose and edit a listed RADIUS Server Group
object or add a new one. Then, in the RADIUS Server Group dialog, choose and edit a listed RADIUS Server
or add a new one.

Fields
• IP Address/Hostname—The network object that identifies the hostname or IP address of the RADIUS
server to which authentication requests will be sent. You may only select one, to add additional servers,
add additional RADIUS Server to the RADIUS Server Group list.

Note Firepower Threat Defense now supports IPv6 IP addresses for RADIUS
authentication.

• Authentication Port—The port on which RADIUS authentication and authorization are performed. The
default is 1812.
• Key and Confirm Key— The shared secret that is used to encrypt data between the managed device
(client) and the RADIUS server.
The key is a case-sensitive, alphanumeric string of up to 127 characters. Special characters are permitted.
The key you define in this field must match the key on the RADIUS server. Enter the key again in the
Confirm field.
• Accounting Port—The port on which RADIUS accounting is performed. The default is 1813.
• Timeout— Session timeout for authentication.

Note The timeout value must be 60 seconds or more for RADIUS two factor
authentication. The default timeout value is 10 seconds.

• Connect Using —Establishes connectivity from Firepower Threat Defense to a RADIUS server using
a route lookup or using a specific interface. Select Routing to use the routing table. Or select Specific
Interface and choose a security zone/interface group or the interface (the default).
• Redirect ACL—Select the redirect ACL from the list or add a new one.

Reusable Objects
98
Reusable Objects
RADIUS Server Options

Note This is the name of the ACL defined in Firepower Threat Defense to decide the
traffic to be redirected. The Redirect ACL name here must be the same as the
redirect-acl name in ISE server. When you configure the ACL object, ensure that
you select Block action for ISE and DNS servers, and Allow action for the rest
of the servers.

Related Topics
RADIUS Server Groups, on page 96
RADIUS Server Group Options, on page 97

Reusable Objects
99
 Reusable Objects
RADIUS Server Options

Reusable Objects
100