Firepower Management Center Configuration Guide, V6.6
Firepower Management Center Configuration Guide, V6.6
Firepower Management Center Configuration Guide, V6.6
6
First Published: 2020-04-06
Last Modified: 2020-07-23
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of
the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.
Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:
https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (1721R)
© 2020 Cisco Systems, Inc. All rights reserved.
CONTENTS
User Roles 42
User Passwords 44
Guidelines and Limitations for User Accounts for FMC 45
Requirements and Prerequisites for User Accounts for FMC 46
Add an Internal User 46
Configure External Authentication 48
About External Authentication 48
About LDAP 48
About RADIUS 49
Add an LDAP External Authentication Object for FMC 49
Add a RADIUS External Authentication Object for FMC 55
Enable External Authentication for Users on the FMC 60
Configure Common Access Card Authentication with LDAP 61
Customize User Roles for the Web Interface 62
Create Custom User Roles 62
Deactivate User Roles 64
Enable User Role Escalation 64
Set the Escalation Target Role 65
Configure a Custom User Role for Escalation 65
Escalate Your User Role 66
Troubleshooting LDAP Authentication Connections 66
History for User Accounts for FMC 68
About RADIUS 74
Add an LDAP External Authentication Object for FTD 74
Add a RADIUS External Authentication Object for FTD 79
Enable External Authentication for Users on FTD Devices 83
Troubleshooting LDAP Authentication Connections 83
History for User Accounts for Devices 85
URL Lists and Feeds: URL Syntax and Matching Criteria 479
Custom Security Intelligence Feeds 480
Custom Security Intelligence Lists 481
Sinkhole Objects 483
Creating Sinkhole Objects 483
File Lists 484
Source Files for File Lists 484
Adding Individual SHA-256 Values to File Lists 485
Uploading Individual Files to File Lists 486
Uploading Source Files to File Lists 487
Editing SHA-256 Values in File Lists 487
Downloading Source Files from File Lists 488
Cipher Suite Lists 489
Creating Cipher Suite Lists 489
Distinguished Name Objects 489
Creating Distinguished Name Objects 491
PKI Objects 491
Internal Certificate Authority Objects 492
CA Certificate and Private Key Import 493
Importing a CA Certificate and Private Key 493
Generating a New CA Certificate and Private Key 494
New Signed Certificates 494
Creating an Unsigned CA Certificate and CSR 495
Uploading a Signed Certificate Issued in Response to a CSR 495
CA Certificate and Private Key Downloads 496
Downloading a CA Certificate and Private Key 496
Trusted Certificate Authority Objects 496
Trusted CA Object 497
Adding a Trusted CA Object 497
Certificate Revocation Lists in Trusted CA Objects 498
Adding a Certificate Revocation List to a Trusted CA Object 498
External Certificate Objects 499
Adding External Certificate Objects 499
Internal Certificate Objects 499
CHAPTER 26 Transparent or Routed Firewall Mode for Firepower Threat Defense 563
CHAPTER 27 Logical Devices for the Firepower Threat Defense on the Firepower 4100/9300 575
PART VII Firepower Threat Defense Interfaces and Device Settings 623
CHAPTER 30 Inline Sets and Passive Interfaces for Firepower Threat Defense 681
PART VIII Firepower Threat Defense High Availability and Scalability 711
About Virtual Routers and Virtual Routing and Forwarding (VRF) 801
Applications of Virtual Routers 802
Global and User-Defined Virtual Routers 802
CHAPTER 38 Static and Default Routes for Firepower Threat Defense 843
CHAPTER 56 Network Address Translation (NAT) for Firepower Threat Defense 1213
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet 1263
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet and DNS Translation 1265
NAT66: Translating IPv6 Addresses to Different IPv6 Addresses 1269
NAT66 Example, Static Translation between Networks 1269
NAT66 Example, Simple IPv6 Interface PAT 1272
Monitoring NAT 1275
Examples for NAT 1276
Providing Access to an Inside Web Server (Static Auto NAT) 1276
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server 1278
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT, One-to-Many) 1283
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation) 1286
Different Translation Depending on the Destination (Dynamic Manual PAT) 1291
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT) 1296
NAT and Site-to-Site VPN 1301
Rewriting DNS Queries and Responses Using NAT 1305
DNS64 Reply Modification 1306
DNS Reply Modification, DNS Server on Outside 1313
DNS Reply Modification, DNS Server on Host Network 1316
History for FTD NAT 1319
PART XVI Advanced Malware Protection (AMP) and File Control 1535
CHAPTER 75 File and Malware Inspection Performance and Storage Tuning 1577
http_encode Keyword example: Using Two http_endcode Keywords to Search for Two Encodings
1828
CHAPTER 86 Advanced Access Control Settings for Network Analysis and Intrusion Policies 1847
About Advanced Access Control Settings for Network Analysis and Intrusion Policies 1847
Requirements and Prerequisites for Advanced Access Control Settings for Network Analysis and
Intrusion Policies 1847
Inspection of Packets That Pass Before Traffic Is Identified 1848
Best Practices for Handling Packets That Pass Before Traffic Identification 1848
Specify a Policy to Handle Packets That Pass Before Traffic Identification 1848
Advanced Settings for Network Analysis Policies 1849
Setting the Default Network Analysis Policy 1850
Network Analysis Rules 1850
Configuring Network Analysis Rules 1851
Managing Network Analysis Rules 1851
Configure the Captive Portal Part 3: Create a User Access Control Rule 2114
Configure Captive Portal Part 4: Create an SSL Decrypt-Resign Policy 2115
Configure Captive Portal Part 5: Associate Identity and SSL Policies with the Access Control Policy
2116
log-ips-connection 2668
managers 2668
memory 2669
model 2669
netstat 2669
network 2670
network-static-routes 2670
ntp 2670
perfstats 2671
process-tree 2671
processes 2672
route 2672
serial-number 2672
ssl-policy-config 2673
summary 2673
syslog 2673
time 2674
traffic-statistics 2674
user 2675
users 2676
version 2677
vmware-tools 2677
Classic Device CLI Configuration Commands 2678
audit_cert Commands 2678
delete 2678
import 2678
log-ips-connections 2679
manager Commands 2679
add 2679
delete 2680
network Commands 2680
dns searchdomains 2680
dns servers 2681
hostname 2681
http-proxy 2681
http-proxy-disable 2682
ipv4 delete 2682
ipv4 dhcp 2682
ipv4 manual 2683
ipv6 delete 2683
ipv6 dhcp 2683
ipv6 manual 2684
ipv6 router 2684
management-interface tcpport 2684
management-port 2685
static-routes ipv4 add 2685
static-routes ipv4 delete 2685
static-routes ipv6 add 2686
static-routes ipv6 delete 2686
password 2686
user Commands 2687
access 2687
add 2687
aging 2688
delete 2688
disable 2688
enable 2688
forcereset 2689
maxfailedlogins 2689
minpasswdlen 2689
password 2690
strengthcheck 2690
unlock 2690
user-agent 2691
vmware-tools 2691
Classic Device CLI System Commands 2692
access-control Commands 2692
archive 2692
clear-rule-counts 2693
rollback 2693
compliance Commands 2693
enable cc 2693
enable ucapl 2694
show 2694
disable-http-user-cert 2694
file Commands 2695
copy 2695
delete 2695
list 2696
secure-copy 2696
generate-troubleshoot 2696
ldapsearch 2697
lockdown 2698
reboot 2698
restart 2699
support Commands 2699
ssl-client-hello-display 2699
ssl-client-hello-enabled 2699
ssl-client-hello-force-reset 2701
ssl-client-hello-reset 2702
ssl-client-hello-tuning 2702
shutdown 2704
History for Classic Device CLI 2705
version 2709
Firepower Management Center CLI Configuration Commands 2710
password 2710
user-agent 2710
Firepower Management Center CLI System Commands 2711
generate-troubleshoot 2711
lockdown 2712
reboot 2712
restart 2713
shutdown 2713
History for the Firepower Management Center CLI 2713
Managers provide a centralized management console with graphical user interface that you can use to perform
administrative, management, analysis, and reporting tasks.
This guide focuses on the Firepower Management Center managing appliance. For information about the
Firepower Device Manager or ASA with FirePOWER Services managed via ASDM, see the guides for those
management methods.
• Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager
• ASA with FirePOWER Services Local Management Configuration Guide
Install and perform initial setup on all physical appliances using the documentation for your appliance:
• Firepower Management Center
• Cisco Firepower Management Center Getting Started Guide for your hardware model, available from
http://www.cisco.com/go/firepower-mc-install
Step 1 Determine the supported virtual platforms you will use for the Management Center and devices (these may not be the
same). See the Cisco Firepower Compatibility Guide.
Step 2 Deploy virtual Firepower Management Centers using the documentation for your environment:
• Firepower Management Center Virtual running on VMware: Cisco Firepower Management Center Virtual for
VMware Deployment Quick Start Guide
• Firepower Management Center Virtual running on AWS: Cisco Firepower Management Center Virtual for AWS
Deployment Quick Start Guide
• Firepower Management Center Virtual running on KVM: Cisco Firepower Management Center Virtual for KVM
Deployment Quick Start Guide
Step 3 Deploy virtual devices using the documentation for your appliance:
• NGIPSv running on VMware: Cisco Firepower NGIPSv Quick Start Guide for VMware
• Firepower Threat Defense Virtual running on VMware: Cisco Firepower Threat Defense for the ASA 5508-X and
ASA 5516-X Using Firepower Management Center Quick Start Guide
• Firepower Threat Defense Virtual running on AWS: Cisco Firepower Threat Defense Virtual for AWS Deployment
Quick Start Guide
• Firepower Threat Defense Virtual running on KVM: Cisco Firepower Threat Defense Virtual for KVM Deployment
Quick Start Guide
• Firepower Threat Defense Virtual running on Azure: Cisco Firepower Threat Defense Virtual for Azure Deployment
Quick Start Guide
• IPv4 address
• Network mask
• Gateway
• DNS Servers
• NTP Servers
Values for these settings can be viewed and changed through the FMC web interface; see Modify FMC
Management Interfaces, on page 1102 and Time and Time Synchronization, on page 1124 for more
information.
• As a part of initial configuration the FMC configures a weekly automatic GeoDB update. You can observe
the status of this update using the web interface Message Center. If configuring the update fails and your
FMC has internet access, we recommend you configure regular GeoDB updates as described in Schedule
GeoDB Updates, on page 164.
• As a part of initial configuration the FMC schedules a weekly task to download the latest software for
the FMC and its managed devices. You can observe the status of this task using the web interface Message
Center. If the task scheduling fails and your FMC has internet access, we recommend you schedule a
recurring task for downloading software updates as described in Automating Software Downloads, on
page 218.
Important This task only downloads software updates to the FMC. It is your responsibility
to install any updates this task downloads. See the Cisco Firepower Management
Center Upgrade Guide for more information.
• As a part of initial configuration the FMC schedules a weekly task to perform a locally-stored
configuration-only backup. You can observe the status of this task using the web interface Message
Center. If the task scheduling fails we recommend you schedule a recurring task to perform a backup as
described in Schedule FMC Backups, on page 209.
• As a part of initial configuration the FMC downloads and installs the latest vulnerability database (VDB)
update from the Cisco support site. This is a one-time operation. You can observe the status of this update
using the web interface Message Center. To keep your system up to date, if your FMC has internet access,
we recommend you schedule tasks to perform automatic recurring VDB update downloads and installations
as described in Vulnerability Database Update Automation, on page 220.
• As a part of initial configuration the FMC configures a daily automatic intrusion rule update from the
Cisco support site. (The FMC deploys automatic intrusion rule updates to affected managed devices
when it next deploys affected policies.) You can observe the status of this update using the web interface
Message Center. If configuring the update fails and your FMC has internet access, we recommend you
configure regular intrusion rule updates as described in Configure Recurring Intrusion Rule Updates, on
page 167.
On completion of FMC initial configuration, the web interface displays the device management page, described
in Device Management Basics, on page 249. (This is the default login page only for the first time the admin
user logs in. On subsequent logins by the admin or any user, the default login page is determined as described
in Specifying Your Home Page, on page 34.)
Once you have completed the initial configuration, begin controlling and analyzing traffic by configuring
basic policies as described in Setting Up Basic Policies and Configurations, on page 5.
Note This is not a full discussion of policy or feature capabilities. For guidance on other features and more advanced
configurations, see the rest of this guide.
Step 1 Set a time zone for this account as described in Setting Your Default Time Zone, on page 39.
Step 2 If needed, add licenses as described in Licensing the Firepower System, on page 89.
Step 3 Add managed devices to your deployment as described in Add a Device to the FMC, on page 260.
Step 4 Configure your managed devices as described in:
• Introduction to IPS Device Deployment and Configuration, on page 551, to configure passive or inline interfaces
on Classic devices
• Interface Overview for Firepower Threat Defense, on page 625, to configure transparent or routed mode on Firepower
Threat Defense devices
• Interface Overview for Firepower Threat Defense, on page 625, to configure interfaces on Firepower Threat Defense
devices
Step 5 Configure an access control policy as described in Creating a Basic Access Control Policy, on page 1343.
• In most cases, Cisco suggests setting the Balanced Security and Connectivity intrusion policy as your default
action. For more information, see Access Control Policy Default Action, on page 1323 and System-Provided Network
Analysis and Intrusion Policies, on page 1635.
• In most cases, Cisco suggests enabling connection logging to meet the security and compliance needs of your
organization. Consider the traffic on your network when deciding which connections to log so that you do not
clutter your displays or overwhelm your system. For more information, see About Connection Logging, on page
2429.
Step 6 Apply the system-provided default health policy as described in Applying Health Policies, on page 317.
Step 7 Customize a few of your system configuration settings:
• If you want to allow inbound connections for a service (for example, SNMP or the syslog), modify the ports in
the access list as described in Configure an Access List, on page 1112.
• Understand and consider editing your database event limits as described in Configuring Database Event Limits,
on page 1095.
• If you want to change the display language, edit the language setting as described in Set the Language for the Web
Interface, on page 1122.
• If your organization restricts network access using a proxy server, edit your proxy settings as described in Modify
FMC Management Interfaces, on page 1102.
Step 8 Customize your network discovery policy as described in Configuring the Network Discovery Policy, on page 2145. By
default, the network discovery policy analyzes all traffic on your network. In most cases, Cisco suggests restricting
discovery to the addresses in RFC 1918.
Step 9 Consider customizing these other common settings:
• If you do not want to display message center pop-ups, disable notifications as described in Configuring Notification
Behavior, on page 357.
• If you want to customize the default values for system variables, understand their use as described in Variable
Sets, on page 459.
• If you want to create additional locally authenticated user accounts to access the appliance, see Add an Internal
User Account.
• If you want to use LDAP or RADIUS external authentication to allow access to the appliance, see Configure
External Authentication.
Step 10 Deploy configuration changes; see Deploy Configuration Changes, on page 385.
What to do next
• Review and consider configuring other features described in Firepower Features, on page 7 and the
rest of this guide.
Firepower Devices
In a typical deployment, multiple traffic-handling devices report to one Firepower Management Center, which
you use to perform administrative, management, analysis, and reporting tasks.
Classic Devices
Classic devices run next-generation IPS (NGIPS) software. They include:
• NGIPSv, hosted on VMware.
• ASA with FirePOWER Services, available on select ASA 5500-X series devices (also includes ISA
3000). The ASA provides the first-line system policy, and then passes traffic to an ASA FirePOWER
module for discovery and access control.
Note that you must use the ASA CLI or ASDM to configure the ASA-based features on an ASA
FirePOWER device. This includes device high availability, switching, routing, VPN, NAT, and so on.
You cannot use the FMC to configure ASA FirePOWER interfaces, and the FMC GUI does not display
ASA interfaces when the ASA FirePOWER is deployed in SPAN port mode. Also, you cannot use the
FMC to shut down, restart, or otherwise manage ASA FirePOWER processes.
Compatibility
For details on manager-device compatibility, including the software compatible with specific device models,
virtual hosting environments, operating systems, and so on, see the Cisco Firepower Release Notes and Cisco
Firepower Compatibility Guide.
Firepower Features
These tables list some commonly used Firepower features.
Monitor the health of system hardware Health monitoring policy About Health Monitoring, on
and software page 307
Back up data on your appliance Backup and restore Backup and Restore, on page 175
Baseline your physical appliance Restore to factory defaults The Cisco Firepower
(reimage) Management Center Upgrade
Guide, for a list of links to
instructions on performing fresh
installations.
Update the VDB, intrusion rule updates, Vulnerability Database (VDB) System Software Updates, on
or GeoDB on your appliance updates, intrusion rule updates, page 159
or Geolocation Database
(GeoDB) updates
Apply licenses in order to take advantage Classic or Smart licensing About Firepower Licenses, on
of license-controlled functionality page 89
Ensure continuity of appliance operations Managed device high About Firepower Threat Defense
availability and/or Firepower High Availability, on page 713
Management Center high
About Firepower Management
availability
Center High Availability, on
page 231
Configure packet switching between two Device switching Configure Bridge Group
or more networks Interfaces, on page 659
Translate private addresses into public Network Address Translation Network Address Translation
addresses for internet connections (NAT) (NAT) for Firepower Threat
Defense, on page 1213
Establish a secure tunnel between Site-to-Site virtual private VPN Overview for Firepower
managed Firepower Threat Defense network (VPN) Threat Defense, on page 917
Establish secure tunnels between remote Remote Access VPN VPN Overview for Firepower
users and managed Firepower Threat Threat Defense, on page 917
Defense devices
Segment user access to managed devices, Multitenancy using domains Introduction to Multitenancy
configurations, and events Using Domains, on page 369
View and manage appliance REST API and REST API REST API Preferences, on page
configuration using a REST API client Explorer 1138
Firepower REST API Quick
Start Guide
NGIPSv — —
ASA FirePOWER In these deployments, the ASA device provides the first-line system
policy, then passes traffic to an ASA FirePOWER module for discovery
and access control. See the ASA documentation for information on high
availability and scalability configurations.
Related Topics
About Firepower Threat Defense High Availability, on page 713
About Firepower Management Center High Availability, on page 231
Block or monitor connections to or from Security Intelligence within your About Security Intelligence, on
IP addresses, URLs, and/or domain access control policy page 1393
names
Control the websites that users on your URL filtering within your policy URL Filtering, on page 1369
network can access rules
Monitor malicious traffic and intrusions Intrusion policy Intrusion Policy Basics, on page
on your network 1659
Block encrypted traffic without SSL policy SSL Policies Overview, on page
inspection 1477
Inspect encrypted or decrypted traffic
Tailor deep inspection to encapsulated Prefilter policy About Prefiltering, on page 1417
traffic and improve performance with
fastpathing
Rate limit network traffic that is allowed Quality of Service (QoS) policy About QoS Policies, on page 705
or trusted by access control
Allow or block files (including malware) File/malware policy File Policies and Malware
on your network Protection, on page 1537
Operationalize data from threat Cisco Threat Intelligence Cisco Threat Intelligence
intelligence sources Director (TID) Director (TID) Overview, on
page 1583
Configure passive or active user User awareness, user identity, About User Identity Sources, on
authentication to perform user awareness identity policies page 2004
and user control
About Identity Policies, on page
2135
Collect host, application, and user data Network Discovery policies Overview: Network Discovery
from traffic on your network to perform Policies, on page 2143
user awareness
Use tools beyond your Firepower system Integration with external tools Event Analysis Using External
to collect and analyze data about network Tools, on page 2333
traffic and potential threats
Stream event data from a Firepower eStreamer integration eStreamer Server Streaming, on
Management Center to a page 2349
custom-developed client application
Firepower System eStreamer
Integration Guide
Query database tables on a Firepower External database access External Database Access
Management Center using a third-party Settings, on page 1094
client
Firepower System Database
Access Guide
Augment discovery data by importing Host input Host Input Data, on page 2022
data from third-party sources
Firepower System Host Input
API Guide
Investigate events using external event Integration with external event Event Analysis Using External
data storage tools and other data analysis tools Tools, on page 2333
resources
• Displays ancestor domains, but may disable access to them based on the privileges assigned to your user
account.
• Hides any other domain your user account cannot access, including sibling and descendant domains.
From the drop-down list under your user name, choose the domain you want to access.
On pages or locations that do not support the Firepower System context menu, the normal context menu for
your browser appears.
Policy Editors
Many policy editors contain hotspots over each rule. You can insert new rules and categories; cut, copy,
and paste rules; set the rule state; and edit the rule.
Intrusion Rules Editor
The intrusion rules editor contains hotspots over each intrusion rule. You can edit the rule, set the rule
state, configure thresholding and suppression options, and view rule documentation. Optionally, after
clicking Rule documentation in the context menu, you can click Rule Documentation in the
documentation pop-up window to view more-specific rule details.
Event Viewer
Event pages (the drill-down pages and table views available under the Analysis menu) contain hotspots
over each event, IP address, URL, DNS query, and certain files’ SHA-256 hash values. While viewing
most event types, you can:
• View related information in the Context Explorer.
• Drill down into event information in a new window.
• View the full text in places where an event field contains text too long to fully display in the event
view, such as a file’s SHA-256 hash value, a vulnerability description, or a URL.
• Open a web browser window with detailed information about the element from a source external
to Firepower, using the Contextual Cross-Launch feature. For more information, see Event
Investigation Using Web-Based Resources, on page 2334.
While viewing connection events, you can add items to the default Security Intelligence Allow lists and
Block lists:
• An IP address, from an IP address hotspot.
• A URL or domain name, from a URL hotspot.
• A DNS query, from a DNS query hotspot.
While viewing captured files, file events, and malware events, you can:
• Add a file to or remove a file from the clean list or custom detection list.
• Download a copy of the file.
• View nested files inside an archive file.
• Download the parent archive file for a nested file.
• View the file composition.
• Submit the file for local malware and dynamic analysis.
While viewing intrusion events, you can perform similar tasks to those in the intrusion rules editor or an
intrusion policy:
• Edit the triggering rule.
• Set the rule state, including disabling the rule.
• Configure thresholding and suppression options.
• View rule documentation. Optionally, after clicking Rule documentation in the context menu,
you can click Rule Documentation in the documentation pop-up window to view more-specific
rule details.
How To is a widget that provides walkthroughs to navigate through tasks on Firepower Management Center.
The walkthroughs guide you to perform the steps required to achieve a task by taking you through each step,
one after the other irrespective of the various UI screens that you may have to navigate, to complete the task.
The How To widget is enabled by default. To disable the widget, choose User Preferences from the drop-down
list under your user name, and uncheck the Enable How-Tos check box in How-To Settings.
Note The walkthroughs are generally available for all UI pages, and are not user role sensitive. However, depending
on the privileges of the user, some of the menu items will not appear on the Firepower Management Center
interface. Thereby, the walkthroughs will not execute on such pages.
• Configure Routing Settings: Various routing protocols are supported by Firepower Threat Defense. A
static route defines where to send traffic for specific destination networks. This walkthrough guides you
to configure static routing for the devices.
• Create a NAT Policy - A Feature Walkthrough: This walkthrough guides you to create a NAT policy
and walks you through the various features of a NAT rule.
You can find additional documentation related to the Firepower system using the documentation roadmap:
http://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/firepower-roadmap.html.
Note Some of the linked documents are not applicable to Firepower Management Center deployments. For example,
some links on Firepower Threat Defense pages are specific to deployments managed by Firepower Device
Manager, and some links on hardware pages are unrelated to Firepower. To avoid confusion, pay careful
attention to document titles. Also, some documents cover multiple products and therefore may appear on
multiple product pages.
Firepower Threat Defense, also called NGFW (Next Generation Firewall) devices
• Firepower Threat Defense software:
http://www.cisco.com/c/en/us/support/security/firepower-ngfw/tsd-products-support-series-home.html
• Firepower Threat Defense Virtual:
http://www.cisco.com/c/en/us/support/security/firepower-ngfw-virtual/
tsd-products-support-series-home.html
• Firepower 1000 series:
https://www.cisco.com/c/en/us/support/security/firepower-1000-series/
tsd-products-support-series-home.html
• Firepower 2100 series:
https://www.cisco.com/c/en/us/support/security/firepower-2100-series/
tsd-products-support-series-home.html
• Firepower 4100 series:
https://www.cisco.com/c/en/us/support/security/firepower-4100-series/
tsd-products-support-series-home.html
• Firepower 9300:
https://www.cisco.com/c/en/us/support/security/firepower-9000-series/
tsd-products-support-series-home.html
• ASA 5500-X series:
• https://www.cisco.com/c/en/us/support/security/asa-firepower-services/
tsd-products-support-series-home.html
• https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/
tsd-products-support-series-home.html
• ISA 3000:
https://www.cisco.com/c/en/us/support/security/industrial-security-appliance-isa/
tsd-products-support-series-home.html
Classic devices, also called NGIPS (Next Generation Intrusion Prevention System) devices
• ASA with FirePOWER Services:
• ASA 5500-X with FirePOWER Services:
• https://www.cisco.com/c/en/us/support/security/asa-firepower-services/
tsd-products-support-series-home.html
• https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/
tsd-products-support-series-home.html
An “or” statement in a License statement indicates that you must assign a particular license to the managed
device to enable the feature described in the section, but an additional license can add functionality. For
example, within a file policy, some file rule actions require that you assign a Protection license to the device
while others require that you assign a Malware license.
For more information about licenses, see About Firepower Licenses, on page 89.
Related Topics
About Firepower Licenses, on page 89
Additional Resources
The Firewalls Community is an exhaustive repository of reference material that complements our extensive
documentation. This includes links to 3D models of our hardware, hardware configuration selector, product
collateral, configuration examples, troubleshooting tech notes, training videos, lab and Cisco Live sessions,
social media channels, Cisco Blogs and all the documentation published by the Technical Publications team.
Some of the individuals posting to community sites or video sharing sites, including the moderators, work
for Cisco Systems. Opinions expressed on those sites and in any corresponding comments are the personal
opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is
not meant to be an endorsement or representation by Cisco or any other party.
Note Some of the videos, technical notes, and reference material in the Firewalls Community points to older versions
of the Firepower Management Center. Your version of the Firepower Management Center and the version
referenced in the videos or technical notes might have differences in the user interface that cause the procedures
not to be identical.
Initial Configuration 6.5 Initial login on a new or newly-restored-to-factory-defaults FMC now presents the admin user
Wizard with an Initial Configuration Wizard documented in the Cisco Firepower Management Center
Getting Started Guide for FMC models that support Version 6.5. The wizard configures the
following:
• The passwords for the two admin accounts (one for web interface access and the other for
CLI access) are set to the same value, complying with strong password requirements.
• The network settings the FMC uses for network communication through its management
interface (eth0) are established.
• Weekly automatic updates for the GeoDB and system software for the FMC and its managed
devices are scheduled.
• Weekly locally-stored configuration-only automatic backups for the FMC are scheduled.
New/Modified Screens:
Initial login for admin user
Supported Platforms: FMC
Note The system audits user activity based on user accounts; make sure that users log into the system with the
correct account.
Caution All FMC CLI users and, on managed devices, users with Config level CLI access can obtain root privileges
in the Linux shell, which can present a security risk. For system security reasons, we strongly recommend:
• If you establish external authentication, make sure that you restrict the list of users with CLI access
appropriately.
• When granting CLI access privileges on managed devices, restrict the list of internal users with Config
level CLI access.
• Do not establish Linux shell users; use only the pre-defined admin user and users created by the admin
user within the CLI.
Caution We strongly recommend that you do not use the Linux shell unless directed by Cisco TAC or explicit
instructions in the Firepower user documentation.
Different appliances support different types of user accounts, each with different capabilities.
Caution For system security reasons, Cisco strongly recommends that you not establish additional Linux shell users
on any appliance.
NGIPSv Devices
NGIPSv devices support the following user account types:
• A pre-defined admin account which can be used for all forms of access to the device.
• Custom user accounts, which admin users and users with Config access can create and manage.
The Firepower Threat Defense supports external authentication for SSH users.
The ASA FirePOWER module does not support external authentication for users. Accessing ASA devices
via the ASA CLI and ASDM is described in the Cisco ASA Series General Operations CLI Configuration
Guide and the Cisco ASA Series General Operations ASDM Configuration Guide.
Note On all appliances, after a user makes three consecutive failed attempts to log into the CLI via SSH, the system
terminates the SSH connection.
Firepower Management Center • Supported for predefined • Supported for predefined • Supported for predefined
admin user and custom admin user and custom admin user.
user accounts. external user accounts.
• Must be accessed via
• Can be used for • Accessible using an SSH, expert command from the
administrative, serial, or keyboard and Firepower Management
management, and analysis monitor connection. Center CLI.
tasks.
• Should be used only for • Accessible using an SSH,
administration and serial, or keyboard and
troubleshooting directed by monitor connection.
Cisco TAC.
• Should be used only for
administration and
troubleshooting directed by
Cisco TAC or by explicit
instructions in the FMC
documentation.
Related Topics
Add an Internal User, on page 46
Related Topics
Specifying Your Home Page, on page 34
Session Timeout
By default, the Firepower System automatically logs you out of a session after 1 hour of inactivity, unless
you are otherwise configured to be exempt from session timeout.
Users with the Administrator role can change the session timeout interval for an appliance via the following
settings:
System > Configuration > Shell Timeout
Related Topics
Configure Session Timeouts, on page 1131
Step 1 Direct your browser to https://ipaddress_or_hostname/, where ipaddress or hostname corresponds to your FMC.
Step 2 In the Username and Password fields, enter your user name and password. Pay attention to the following guidelines:
• User names are not case-sensitive.
• In a multidomain deployment, prepend the user name with the domain where your user account was created. You
are not required to prepend any ancestor domains. For example, if your user account was created in SubdomainB,
which has an ancestor DomainA, enter your user name in the following format:
SubdomainB\username
• If your organization uses SecurID® tokens when logging in, append the token to your SecurID PIN and use that as
your password to log in. For example, if your PIN is 1111 and the SecurID token is 222222, enter 1111222222. You
must have already generated your SecurID PIN before you can log into the Firepower System.
Related Topics
Session Timeout, on page 25
• To access different FMCs, use a different browser for each login (for example Firefox and Chrome), or
set the browser to incognito or private mode.
Caution Do not remove a CAC during an active browsing session. If you remove or replace a CAC during a session,
your web browser terminates the session and the system logs you out of the web interface.
Related Topics
Configure Common Access Card Authentication with LDAP, on page 61
Session Timeout, on page 25
Caution We strongly recommend that you do not use the Linux shell unless directed by Cisco TAC or explicit
instructions in the FMC documentation.
Note For all appliances, after a user makes three consecutive failed attempts to log into the CLI via SSH, the system
terminates the SSH connection.
Step 1 Use the admin user name and password to connect to the FMC via SSH or the console port.
If your organization uses SecurID® tokens when logging in, append the token to your SecurID PIN and use that as your
password to log in. For example, if your PIN is 1111 and the SecurID token is 222222, enter 1111222222. You must have
already generated your SecurID PIN before you can log in.
Note For all appliances, after a user makes three consecutive failed attempts to log into the CLI via SSH, the system
terminates the SSH connection.
Step 1 SSH to the device's management interface (hostname or IP address) or use the console.
ASA FirePOWER devices accessed via the console default to the operating system CLI. This requires an extra step to
access the Firepower CLI: session sfr.
If your organization uses SecurID® tokens when logging in, append the token to your SecurID PIN and use that as your
password to log in. For example, if your PIN is 1111 and the SecurID token is 222222, enter 1111222222. You must have
already generated your SecurID PIN before you can log in.
Step 2 At the CLI prompt, use any of the commands allowed by your level of command line access.
Note On all appliances, after a user makes three consecutive failed attempts to log into the CLI via SSH, the system
terminates the SSH connection.
Step 1 Connect to the FTD CLI, either from the console port or using SSH.
You can SSH to the management interface of the FTD device. You can also connect to the address on a data interface if
you open the interface for SSH connections. SSH access to data interfaces is disabled by default. See Configure Secure
Shell, on page 1169 to allow SSH connections to specific data interfaces.
You can directly connect to the Console port on the device. Use the console cable included with the device to connect
your PC to the console using a terminal emulator set for 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control. See
the hardware guide for your device for more information about the console cable.
The initial CLI you access on the Console port differs by device type.
• ASA Series devices—The CLI on the Console port is the regular FTD CLI.
• Firepower Series devices—The CLI on the Console port is FXOS. You can get to the FTD CLI using the connect
ftd command. Use the FXOS CLI for chassis-level configuration and troubleshooting only. Use the FTD CLI for
basic configuration, monitoring, and normal system troubleshooting. See the FXOS documentation for information
on FXOS commands.
Note If you are logging out of an SSO session at the FMC, when you log out the system redirects your browser to
the SSO IdP for your organization. To ensure FMC security and prevent others from accessing the FMC using
your SSO account, we recommend you log out of the SSO federation at the IdP.
Step 1 From the drop-down list under your user name, choose Logout.
Step 2 If you are logging out of an SSO session at the FMC, the system redirects you to the SSO IdP for your organization. Log
out at the IdP to ensure FMC security.
Related Topics
Session Timeout, on page 25
View information about 6.5 View the date, time, and IP address from which you last logged in.
the last time you signed
New/Modified menus:
in to the Firepower
Management Center The menu at the top right of the window that shows the username that you used to log in.
Supported platforms: FMC
Automatic CLI access for 6.5 When you use SSH to log into the FMC, you automatically access the CLI. Although strongly
the FMC discouraged, you can then use the CLI expert command to access the Linux shell.
Note This feature deprecates the Version 6.3 ability to enable and disable CLI access for
the FMC. As a consequence of deprecating this option, the virtual FMC no longer
displays the System > Configuration > Console Configuration page, which still
appears on physical FMCs.
Limit number of SSH 6.3 When a user accesses any device via SSH and fails three successive login attempts, the device
login failures terminates the SSH session.
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Change Password.
Step 3 Optionally, check the Show password check box to see the password while using this dialog.
Step 4 Enter your Current Password.
Step 1 From the drop-down list under your user name, choose User Preferences. The General tab displays by default.
Step 2 Select a theme:
• Light
• Classic (the look and feel of releases earlier than 6.6)
In a multidomain deployment, the home page you choose applies to all domains where your user account has
access. When choosing a home page for an account that frequently accesses multiple domains, keep in mind
that certain pages are constrained to the Global domain.
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Home Page.
Step 3 Choose the page you want to use as your home page from the drop-down list.
The options in the drop-down list are based on the access privileges for your user account. For more information, see
User Roles, on page 42.
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Event View Settings.
Step 3 In the Event Preferences section, configure the basic characteristics of event views; see Event View Preferences, on
page 35.
Step 4 In the File Preferences section, configure file download preferences; see File Download Preferences, on page 36.
Step 5 In the Default Time Windows section, configure the default time window or windows; see Default Time Windows, on
page 37.
Step 6 In the Default Workflow sections, configure default workflows; see Default Workflows, on page 39.
Step 7 Click Save.
• The Resolve IP Addresses field allows the appliance, whenever possible, to display host names instead
of IP addresses in event views.
Note that an event view may be slow to display if it contains a large number of IP addresses and you
have enabled this option. Note also that for this setting to take effect, you must use management interfaces
configuration to establish a DNS server in the system settings.
• The Expand Packet View field allows you to configure how the packet view for intrusion events appears.
By default, the appliance displays a collapsed version of the packet view:
• None - collapse all subsections of the Packet Information section of the packet view
• Packet Text - expand only the Packet Text subsection
• Packet Bytes - expand only the Packet Bytes subsection
• All - expand all sections
Regardless of the default setting, you can always manually expand the sections in the packet view to view
detailed information about a captured packet.
• The Rows Per Page field controls how many rows of events per page you want to appear in drill-down
pages and table views.
• The Refresh Interval field sets the refresh interval for event views in minutes. Entering 0 disables the
refresh option. Note that this interval does not apply to dashboards.
• The Statistics Refresh Interval controls the refresh interval for event summary pages such as the Intrusion
Event Statistics and Discovery Statistics pages. Entering 0 disables the refresh option. Note that this
interval does not apply to dashboards.
• The Deactivate Rules field controls which links appear on the packet view of intrusion events generated
by standard text rules:
• All Policies - a single link that deactivates the standard text rule in all the locally defined custom
intrusion policies
• Current Policy - a single link that deactivates the standard text rule in only the currently deployed
intrusion policy. Note that you cannot deactivate rules in the default policies.
• Ask - links for each of these options
To see these links on the packet view, your user account must have either Administrator or Intrusion Admin
access.
Related Topics
Management Interfaces, on page 1097
Caution Cisco strongly recommends you do not download malware, as it can cause adverse
consequences. Exercise caution when downloading any file, as it may contain
malware. Ensure you have taken any necessary precautions to secure the download
destination before downloading files.
Note that you can disable this option any time you download a file.
• When you download a captured file, the system creates a password-protected .zip archive containing the
file. The Zip File Password field defines the password you want to use to restrict access to the .zip file.
If you leave this field blank, the system creates archive files without passwords.
• The Show Zip File Password check box toggles displaying plain text or obfuscated characters in the
Zip File Password field. When this field is cleared, the Zip File Password displays obfuscated characters.
Note that, regardless of the default time window setting, you can always manually change the time window
for individual event views during your event analysis. Also, keep in mind that time window settings are valid
for only the current session. When you log out and then log back in, time windows are reset to the defaults
you configured on this page.
There are three types of events for which you can set the default time window:
• The Events Time Window sets a single default time window for most events that can be constrained by
time.
• The Audit Log Time Window sets the default time window for the audit log.
• The Health Monitoring Time Window sets the default time window for health events.
You can only set time windows for event types your user account can access. All user types can set event
time windows. Administrators, Maintenance Users, and Security Analysts can set health monitoring time
windows. Administrators and Maintenance Users can set audit log time windows.
Note that because not all event views can be constrained by time, time window settings have no effect on
event views that display hosts, host attributes, applications, clients, vulnerabilities, user identity, or white list
violations.
You can either use Multiple time windows, one for each of these types of events, or you can use a Single
time window that applies to all events. If you use a single time window, the settings for the three types of
time window disappear and a new Global Time Window setting appears.
There are three types of time window:
• static, which displays all the events generated from a specific start time to a specific end time
• expanding, which displays all the events generated from a specific start time to the present; as time moves
forward, the time window expands and new events are added to the event view
• sliding, which displays all the events generated from a specific start time (for example, one day ago) to
the present; as time moves forward, the time window “slides” so that you see only the events for the
range you configured (in this example, for the last day)
The maximum time range for all time windows is from midnight on January 1, 1970 (UTC) to 3:14:07 AM
on January 19, 2038 (UTC).
The following options appear in the Time Window Settings drop-down list:
• The Show the Last - Sliding option allows you configure a sliding default time window of the length
you specify.
The appliance displays all the events generated from a specific start time (for example, 1 hour ago) to
the present. As you change event views, the time window “slides” so that you always see events from
the last hour.
• The Show the Last - Static/Expanding option allows you to configure either a static or expanding
default time window of the length you specify.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from a specific start time (for example, 1 hour ago) to the time when you first viewed the
events. As you change event views, the time window stays fixed so that you see only the events that
occurred during the static time window.
For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from a specific start time (for example, 1 hour ago) to the present. As you change event
views, the time window expands to the present time.
• The Current Day - Static/Expanding option allows you to configure either a static or expanding default
time window for the current day. The current day begins at midnight, based on the time zone setting for
your current session.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from midnight to the time when you first viewed the events. As you change event views, the
time window stays fixed so that you see only the events that occurred during the static time window.
For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from midnight to the present. As you change event views, the time window expands to
the present time. Note that if your analysis continues for over 24 hours before you log out, this time
window can be more than 24 hours.
• The Current Week - Static/Expanding option allows you to configure either a static or expanding
default time window for the current week. The current week begins at midnight on the previous Sunday,
based on the time zone setting for your current session.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from midnight to the time when you first viewed the events. As you change event views, the
time window stays fixed so that you see only the events that occurred during the static time window.
For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from midnight Sunday to the present. As you change event views, the time window
expands to the present time. Note that if your analysis continues for over 1 week before you log out, this
time window can be more than 1 week.
Default Workflows
A workflow is a series of pages displaying data that analysts use to evaluate events. For each event type, the
appliance ships with at least one predefined workflow. For example, as a Security Analyst, depending on the
type of analysis you are performing, you can choose among ten different intrusion event workflows, each of
which presents intrusion event data in a different way.
The appliance is configured with a default workflow for each event type. For example, the Events by Priority
and Classification workflow is the default for intrusion events. This means whenever you view intrusion
events (including reviewed intrusion events), the appliance displays the Events by Priority and Classification
workflow.
You can, however, change the default workflow for each event type. The default workflows you are able to
configure depend on your user role. For example, intrusion event analysts cannot set default discovery event
workflows.
Warning The Time Zone function (in User Preferences) assumes that the system clock is set to UTC time. DO NOT
ATTEMPT TO CHANGE THE SYSTEM TIME. Changing the system time from UTC is NOT supported,
and doing so will require you to reimage the device to recover from an unsupported state.
Note This feature does not affect the time zone used for time-based policy application. Set the time zone for a device
in Devices > Platform Settings.
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Time Zone.
Step 3 Choose the continent or area that contains the time zone you want to use.
Step 4 Choose the country and state name that corresponds with the time zone you want to use.
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Dashboard Settings.
Step 3 Choose the dashboard you want to use as your default from the drop-down list. If you choose None, when you select
Overview > Dashboards, you can then choose a dashboard to view.
Step 4 Click Save.
Related Topics
Viewing Dashboards, on page 305
UI Themes 6.6 You can choose the look and feel of the FMC web interface. Select from the new Light theme,
or use the Classic theme that appeared in previous FMC releases.
New/Modified Screens:
User Name > User Preferences > General > UI Theme
Supported Platforms: FMC
Enhanced password 6.5 New requirements for strong passwords now appear in a single place in the document and are
security cross-referenced from this chapter.
New fields in the change password interface added: Show Password and Generate Password.
New/Modified Screens:
User Name > User Preferences > General > Change Password
Supported Platforms: FMC
Caution CLI users can access the Linux shell using the expert command. We strongly recommend that you do not
use the Linux shell unless directed by Cisco TAC or explicit instructions in the FMC documentation. CLI
users can obtain sudoers privileges in the Linux shell, which can present a security risk. For system security
reasons, we strongly recommend that you:
• Restrict the list of external users with CLI access appropriately.
• Do not add users directly in the Linux shell; only use the procedures in this chapter.
User Roles
CLI User Role
CLI external users on the FMC do not have a user role; they can use all available commands.
Note Predefined user roles that the system considers read-only for the purposes of concurrent session limits, are
labeled with (Read Only) in the role name under System > Users > Users and System > Users > User Roles.
If a user role does not contain (Read Only) in the role name, the system considers the role to be read/write.
For more information on concurrent session limits, see Global User Configuration Settings, on page 1128.
Access Admin
Provides access to access control policy and associated features in the Policies menu. Access Admins
cannot deploy policies.
Administrator
Administrators have access to everything in the product; their sessions present a higher security risk if
compromised, so you cannot make them exempt from login session timeouts.
You should limit use of the Administrator role for security reasons.
Discovery Admin
Provides access to network discovery, application detection, and correlation features in the Policies
menu. Discovery Admins cannot deploy policies.
External Database User (Read Only)
Provides read-only access to the Firepower System database using an application that supports JDBC
SSL connections. For the third-party application to authenticate to the Firepower System appliance, you
must enable database access in the system settings. On the web interface, External Database Users have
access only to online help-related options in the Help menu. Because this role’s function does not involve
the web interface, access is provided only for ease of support and password changes.
Intrusion Admin
Provides access to all intrusion policy, intrusion rule, and network analysis policy features in the Policies
and Objects menus. Intrusion Admins cannot deploy policies.
Maintenance User
Provides access to monitoring and maintenance features. Maintenance Users have access to
maintenance-related options in the Health and System menus.
Network Admin
Provides access to access control, SSL inspection, DNS policy, and identity policy features in the Policies
menu, as well as device configuration features in the Devices menus. Network Admins can deploy
configuration changes to devices.
Security Analyst
Provides access to security event analysis features, and read-only access to health events, in the Overview,
Analysis, Health, and System menus.
Security Analyst (Read Only)
Provides read-only access to security event analysis features and health event features in the Overview,
Analysis, Health, and System menus.
Security Approver
Provides limited access to access control and associated policies and network discovery policies in the
Policies menu. Security Approvers can view and deploy these policies, but cannot make policy changes.
Threat Intelligence Director (TID) User
Provides access to Threat Intelligence Director configurations in the Intelligence menu. Threat Intelligence
Director (TID) Users can view and configure TID.
User Passwords
The following rules apply to passwords for internal user accounts on the FMC, with Lights-Out Management
(LOM) enabled or disabled. Different password requirements apply for externally authenticated accounts or
in systems with security certifications compliance enabled. See Configure External Authentication and Security
Certifications Compliance, on page 1197 for more information.
During FMC initial configuration, the system requires the admin user to set the account password to comply
with strong password requirements for LOM-enabled users as described in the table below. At this time the
system synchronizes the passwords for the web interface admin and the CLI access admin. After initial
configuation, the web interface admin can remove the strong password requirement, but the CLI access admin
must always comply with strong password requirements.
The system checks passwords against a The rules for special characters vary
special dictionary containing not only between different series of physical FMCs.
many English dictionary words, but also We recommend restricting your choice of
other character strings that could be easily special characters to those listed in the final
cracked with common password hacking bullet above.
techniques.
Do not include the user name in the
password.
The system checks passwords against a
special dictionary containing not only
many English dictionary words, but also
other character strings that could be easily
cracked with common password hacking
techniques.
Password Strength Passwords must include the minimum Passwords must include:
Checking Off number of characters configured for the
• Between eight and twenty characters
user by the administrator. (See Add an
(On MC 1000, MC 2500, and MC
Internal User at the Web Interface for more
4500 the upper limit is fourteen
information.)
characters rather than twenty.)
• Characters from at least three of the
following four categories:
• Uppercase letters
• Lowercase letters
• Digits
• Special characters such as ! @ #
*-_+
You can change these settings for all users as a system configuration. (System > Configuration > User
Configuration) See Global User Configuration Settings, on page 1128.
Supported Domains
Any
User Roles
• All other features—Any user with the Admin role.
• Configure Common Access Card Authentication with LDAP, on page 61 also supports the Network
Admin role.
Step 4 Real Name: Enter descriptive information to identify the user or department to whom the account belongs.
Step 5 The Use External Authentication Method checkbox is checked for users that were added automatically when they
logged in with LDAP or RADIUS. You do not need to pre-configure external users, so you can ignore this field. For
an external user, you can revert this user to an internal user by unchecking the check box.
Step 6 Enter values in the Password and Confirm Password fields.
The values must conform to the password options you set for this user.
Step 12 In the User Role Configuration area, assign user role(s). For more information about user roles, see Customize User
Roles for the Web Interface, on page 62.
For external users, if the user role is assigned through group or list membership, you cannot remove the minimum
access rights. You can, however, assign additional rights. If the user role is the default user role that you set on the
device, then you can modify the role in the user account without limitations. When you modify the user role, the
Authentication Method column on the Users tab provides a status of External - Locally Modified.
The options you see depend on whether the device is in a single domain or multidomain deployment.
• Single domain—Check the user role(s) you want to assign the user.
• Multidomain—In a multidomain deployment, you can create user accounts in any domain in which you have been
assigned Administrator access. Users can have different privileges in each domain. You can assign user roles in
both ancestor and descendant domains. For example, you can assign read-only privileges to a user in the Global
domain, but Administrator privileges in a descendant domain. See the following steps:
a. Click Add Domain.
Note Users with Linux shell access can obtain root privileges, which can present a security risk. Make sure that
you:
• restrict the list of users with Linux shell access
• do not create Linux shell users
About LDAP
The Lightweight Directory Access Protocol (LDAP) allows you to set up a directory on your network that
organizes objects, such as user credentials, in a centralized location. Multiple applications can then access
those credentials and the information used to describe them. If you ever need to change a user's credentials,
you can change them in one place.
Microsoft has announced that Active Directory servers will start enforcing LDAP binding and LDAP signing
in 2020. Microsoft is making these a requirement because when using default settings, an elevation of privilege
vulnerability exists in Microsoft Windows that could allow a man-in-the-middle attacker to successfully
forward an authentication request to a Windows LDAP server. For more information, see 2020 LDAP channel
binding and LDAP signing requirement for Windows on the Microwoft support site.
If you have not done so already, we recommend you start using TLS/SSL encryption to authenticate with an
Active Directory server.
About RADIUS
Remote Authentication Dial In User Service (RADIUS) is an authentication protocol used to authenticate,
authorize, and account for user access to network resources. You can create an authentication object for any
RADIUS server that conforms to RFC 2865.
Firepower devices support the use of SecurID tokens. When you configure authentication by a server using
SecurID, users authenticated against that server append the SecurID token to the end of their SecurID PIN
and use that as their password when they log in. You do not need to configure anything extra on the Firepower
device to support SecurID.
• User Name Template—Provide a template that corresponds with your UI Access Attribute. For example,
to authenticate all users who work in the Security organization of the Example company by connecting to an
OpenLDAP server where the UI access attribute is uid, you might enter
uid=%s,ou=security,dc=example,dc=com in the User Name Template field. For a Microsoft Active Directory
server, you could enter %[email protected].
This field is required for CAC authentication.
• Timeout—Enter the number of seconds before rolling over to the backup connection. The default is 30.
• Enter a UI Access Attribute, or click Fetch Attrs to retrieve a list of available attributes. For example, on a
Microsoft Active Directory Server, you may want to use the UI Access Attribute to retrieve users, because there
may not be a uid attribute on Active Directory Server user objects. Instead, you can search the userPrincipalName
attribute by typing userPrincipalName in the UI Access Attribute field.
This field is required for CAC authentication.
• Set the Shell Access Attribute if you want to use a shell access attribute other than the user distinguished type.
For example, on a Microsoft Active Directory Server, use the sAMAccountName shell access attribute to retrieve
CLI access users by typing sAMAccountName.
cn=itgroup,ou=groups, dc=example,dc=com
b) Choose a Default User Role for users that do not belong to any of the specified groups.
c) If you use static groups, enter a Group Member Attribute.
Example:
If the member attribute is used to indicate membership in the static group for default Security Analyst access, enter
member.
If you change a user's role, you must save/deploy the changed external authentication object and also remove the user
from the Users screen. The user will be re-added automatically the next time they log in.
Step 14 (Optional) Set the Shell Access Filter to allow CLI users.
To prevent LDAP authentication of CLI access, leave this field blank. To specify CLI users, choose one of the following
methods:
• To use the same filter you specified when configuring authentication settings, choose Same as Base Filter.
• To retrieve administrative user entries based on attribute value, enter the attribute name, a comparison operator,
and the attribute value you want to use as a filter, enclosed in parentheses. For example, if all network administrators
have a manager attribute which has an attribute value of shell, you can set a base filter of (manager=shell).
Note Do not create any internal users that have the same user name as users included in the Shell Access Filter.
The only internal FMC user should be admin; do not include an admin user in the Shell Access Filter.
Step 16 (Optional) You can also enter Additional Test Parameters to test user credentials for a user who should be able to
authenticate: enter a User Name uid and Password, and then click Test.
If you are connecting to a Microsoft Active Directory Server and supplied a UI access attribute in place of uid, use the
value for that attribute as the user name. You can also specify a fully qualified distinguished name for the user.
Tip If you mistype the name or password of the test user, the test fails even if the server configuration is correct.
To verify that the server configuration is correct, click Test without entering user information in the Additional
Test Parameters field first. If that succeeds, supply a user name and password to test with the specific user.
Example:
To test if you can retrieve the JSmith user credentials at the Example company, enter JSmith and the correct password.
Examples
Basic Example
The following figures illustrate a basic configuration of an LDAP login authentication object for a
Microsoft Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4.
The connection uses port 389 for access.
However, because this server is a Microsoft Active Directory server, it uses the sAMAccountName
attribute to store user names rather than the uid attribute. Choosing the MS Active Directory server
type and clicking Set Defaults sets the UI Access Attribute to sAMAccountName. As a result, the
Firepower System checks the sAMAccountName attribute for each object for matching user names
when a user attempts to log into the Firepower System.
The connection to the server is encrypted using SSL and a certificate named certificate.pem is
used for the connection. In addition, connections to the server time out after 60 seconds because of
the Timeout setting.
Because this server is a Microsoft Active Directory server, it uses the sAMAccountName attribute to
store user names rather than the uid attribute. Note that the configuration includes a UI Access
Attribute of sAMAccountName. As a result, the Firepower System checks the sAMAccountName attribute
for each object for matching user names when a user attempts to log into the Firepower System.
In addition, a Shell Access Attribute of sAMAccountName causes each sAMAccountName attribute to
be checked for all objects in the directory for matches when a user logs into a CLI account on the
appliance.
This example also has group settings in place. The Maintenance User role is automatically assigned
to all members of the group with a member group attribute and the base domain name of
CN=SFmaintenance,DC=it,DC=example,DC=com.
The shell access filter is set to be the same as the base filter, so the same users can access the appliance
through the CLI as through the web interface.
d) Select the Default User Role for users that do not belong to any of the specified groups.
If you change a user's role, you must save/deploy the changed external authentication object and also remove the user
from the Users screen. The user will be re-added automatically the next time they log in.
When you create a RADIUS authentication object, a new dictionary file for that object is created on the device in the
/var/sf/userauth directory. Any custom attributes you add are added to the dictionary file.
Example:
If a RADIUS server is used on a network with a Cisco router, you might want to use the Ascend-Assign-IP-Pool
attribute to grant a specific role to all users logging in from a specific IP address pool. Ascend-Assign-IP-Pool is an
integer attribute that defines the address pool where the user is allowed to log in, with the integer indicating the number
of the assigned IP address pool.
To declare that custom attribute, you create a custom attribute with an attribute name of Ascend-IP-Pool-Definition,
an attribute ID of 218, and an attribute type of integer.
You could then enter Ascend-Assign-IP-Pool=2 in the Security Analyst (Read Only) field to grant read-only security
analyst rights to all users with an Ascend-IP-Pool-Definition attribute value of 2.
Step 12 (Optional) In the Shell Access Filter area Administrator Shell Access User List field, enter the user names that should
have CLI access, separated by commas.
Make sure that these usernames match usernames on the RADIUS server. The names must be Linux-valid usernames:
• Maximum 32 alphanumeric characters, plus hyphen (-) and underscore (_)
• All lowercase
• Cannot start with hyphen (-); cannot be all numbers; cannot include a period (.), at sign (@), or slash (/)
Step 13 (Optional) Click Test to test FMC connectivity to the RADIUS server.
Step 14 (Optional) You can also enter Additional Test Parameters to test user credentials for a user who should be able to
authenticate: enter a User Name and Password, and then click Test.
Tip If you mistype the name or password of the test user, the test fails even if the server configuration is correct.
To verify that the server configuration is correct, click Test without entering user information in the Additional
Test Parameters field first. If that succeeds, supply a user name and password to test with the specific user.
Example:
To test if you can retrieve the JSmith user credentials at the Example company, enter JSmith and the correct password.
Examples
Simple User Role Assignments
The following figure illustrates a sample RADIUS login authentication object for a server running
Cisco Identity Services Engine (ISE) with an IP address of 10.10.10.98 on port 1812. No backup
server is defined.
The following example shows RADIUS-specific parameters, including the timeout (30 seconds) and
number of failed retries before the Firepower System attempts to contact the backup server, if any.
This example illustrates important aspects of RADIUS user role configuration:
Users ewharton and gsand are granted web interface Administrative access.
The user cbronte is granted web interface Maintenance User access.
The user jausten is granted web interface Security Analyst access.
The user ewharton can log into the device using a CLI account.
The following graphic depicts the role configuration for the example:
Roles for Users Matching an Attribute-Value Pair
You can use an attribute-value pair to identify users who should receive a particular user role. If the
attribute you use is a custom attribute, you must define the custom attribute.
The following figure illustrates the role configuration and custom attribute definition in a sample
RADIUS login authentication object for the same ISE server as in the previous example.
In this example, however, the MS-RAS-Version custom attribute is returned for one or more of the
users because a Microsoft remote access server is in use. Note the MS-RAS-Version custom attribute
is a string. In this example, all users logging in to RADIUS through a Microsoft v. 5.00 remote access
server should receive the Security Analyst (Read Only) role, so you enter the attribute-value pair of
MS-RAS-Version=MSRASV5.00 in the Security Analyst (Read Only) field.
Step 4 Click the Slider enabled ( ) next to the each external authentication object that you want to use. If you enable more
than 1 object, then users are compared against servers in the order specified. See the next step to reorder servers.
If you enable shell authentication, you must enable an external authentication object that includes a Shell Access Filter.
Also, CLI access users can only authenticate against the server whose authentication object is highest in the list.
Step 5 (Optional) Drag and drop servers to change the order in which authentication they are accessed when an authentication
request occurs.
Step 6 Choose Shell Authentication > Enabled if you want to allow CLI access for external users.
The first external authentication object name is shown next to the Enabled option to remind you that only the first object
is used for CLI.
Step 9 Enable external authentication and CAC authentication as described in Enable External Authentication for Users on
the FMC, on page 60.
Step 10 Choose System > Configuration, and click HTTPS Certificate.
Step 11 Import a HTTPS server certificate, if necessary, following the procedure outlined in Importing HTTPS Server Certificates,
on page 1092.
The same certificate authority (CA) must issue the HTTPS server certificate and the user certificates on the CACs you
plan to use.
Step 12 Under HTTPS User Certificate Settings, choose Enable User Certificates. For more information, see Requiring
Valid HTTPS Client Certificates, on page 1093.
Step 13 Log into the device according to Logging Into the Firepower Management Center with CAC Credentials, on page 26.
Note Custom user roles that the system considers read-only for the purposes of concurrent session limits, are
automatically labeled by the system with (Read Only) in the role name on the System > Users > Users tab
and the System > Users > User Roles tab. If a user role does not contain (Read Only) in the role name, the
system considers the role to be read/write.
When you create a custom role or modify an existing custom role, the system automatically applies (Read
Only) to the role name if all of the selected permissions for that role meet the required criteria for being
read-only. You cannot make a role read-only by adding that text string manually to the role name. For more
information on concurrent session limits, see Global User Configuration Settings, on page 1128.
Caution Users with menu-based User Management permissions have the ability to elevate their own privileges or
create new user accounts with extensive privileges, including the Administrator user role. For system security
reasons we strongly recommend you restrict the list of users with User Management permissions appropriately.
• Click the Copy ( ) next to the user role you want to copy.
• Import a custom user role from another device:
a. On the old device, click the Export ( ) to save the role to your PC.
b. On the new device, choose System > Tools > Import/Export.
c. Click Upload Package, then follow the instructions to import the saved user role to the new device.
Step 4 Enter a Name for the new user role. User role names are case sensitive.
Step 5 (Optional) Add a Description.
Step 6 Choose Menu-Based Permissions for the new role.
When you choose a permission, all of its children are chosen, and the multi-value permissions use the first value. If you
clear a high-level permission, all of its children are cleared also. If you choose a permission but not its children, it appears
in italic text.
Copying a predefined user role to use as the base for your custom role preselects the permissions associated with that
predefined role.
You can apply restrictive searches to a custom user role. These searches constrain the data a user can see in the tables on
the pages available under the Analysis menu. You can configure a restrictive search by first creating a private saved
search and selecting it from the Restrictive Search drop-down menu under the appropriate menu-based permission.
Step 7 (Optional) Check the External Database Access check box to set database access permissions for the new role.
This option provides read-only access to the database using an application that supports JDBC SSL connections. For the
third-party application to authenticate to the device, you must enable database access in the system settings.
Step 8 (Optional) To set escalation permissions for the new user role, see Enable User Role Escalation, on page 64.
Step 9 Click Save.
Example
You can create custom user roles for access control-related features to designate whether users can
view and modify access control and associated policies.
The following table lists custom roles that you could create and user permissions granted for each
example. The table lists the privileges required for each custom role. In this example, Policy Approvers
can view (but not modify) access control and intrusion policies. They can also deploy configuration
changes to devices.
Custom Role Permission Example: Access Control Editor Example: Intrusion & Network Example: Policy Approver
Analysis Editor
Custom Role Permission Example: Access Control Editor Example: Intrusion & Network Example: Policy Approver
Analysis Editor
Step 1 Set the Escalation Target Role, on page 65. Only one user role at a time can be the escalation target role.
Step 2 Configure a Custom User Role for Escalation, on page 65.
Step 3 (For the logged in user) Escalate Your User Role, on page 66.
Step 1 Begin configuring your custom user role as described in Create Custom User Roles, on page 62.
Step 2 In System Permissions, choose the Set this role to escalate to: Maintenance User check box.
The current escalation target role is listed beside the check box.
Step 3 Choose the password that this role uses to escalate. You have two options:
• Choose Authenticate with the assigned user’s password if you want users with this role to use their own passwords
when they escalate, .
• Choose Authenticate with the specified user’s password and enter that username if you want users with this role
to use the password of another user.
Note When authenticating with another user’s password, you can enter any username, even that of a deactivated
or nonexistent user. Deactivating the user whose password is used for escalation makes escalation impossible
for users with the role that requires it. You can use this feature to quickly remove escalation powers if
necessary.
Step 1 From the drop-down list under your user name, choose Escalate Permissions.
If you do not see this option, your administrator did not enable escalation for your user role.
• Check that access to the server is not blocked by a firewall and that the port you have configured
in the object is open.
• If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match
the host name used for the server.
• Check that you have not used an IPv6 address for the server connection if you are authenticating
CLI access.
• If you used server type defaults, check that you have the correct server type and click Set Defaults
again to reset the default values.
• If you typed in your base distinguished name, click Fetch DNs to retrieve all the available base
distinguished names on the server, and select the name from the list.
• If you are using any filters, access attributes, or advanced settings, check that each is valid and typed
correctly.
• If you are using any filters, access attributes, or advanced settings, try removing each setting and testing
the object without it.
• If you are using a base filter or a shell access filter, make sure that the filter is enclosed in parentheses
and that you are using a valid comparison operator (maximum 450 characters, including the enclosing
parentheses).
• To test a more restricted base filter, try setting it to the base distinguished name for the user to retrieve
just that user.
• If you are using an encrypted connection:
• Check that the name of the LDAP server in the certificate matches the host name that you use to
connect.
• Check that you have not used an IPv6 address with an encrypted server connection.
• If you are using a test user, make sure that the user name and password are typed correctly.
• If you are using a test user, remove the user credentials and test the object.
• Test the query you are using by connecting to the LDAP server and using this syntax:
ldapsearch -x -b 'base_distinguished_name'
-h LDAPserver_ip_address -p port -v -D
'user_distinguished_name' -W 'base_filter'
For example, if you are trying to connect to the security domain on myrtle.example.com using the
[email protected] user and a base filter of (cn=*), you could test the connection using
this statement:
ldapsearch -x -b 'CN=security,DC=myrtle,DC=example,DC=com'
-h myrtle.example.com -p 389 -v -D
'[email protected]' -W '(cn=*)'
If you can test your connection successfully but authentication does not work after you deploy a platform
settings policy, check that authentication and the object you want to use are both enabled in the platform
settings policy that is applied to the device.
If you connect successfully but want to adjust the list of users retrieved by your connection, you can add or
change a base filter or shell access filter or use a more restrictive or less restrictive base DN.
Added a new field for name in user 6.6 Added a field that can identify the user or
accounts department responsible for an internal user
account.
New/Modified screens:
System > Users > Users> Real Name field
Cisco Security Manager Single Sign-on no 6.5 Single Sign-on between the FMC and Cisco
longer supported Security Manager is no longer supported
as of Firepower 6.5.
New/Modified screens:
System > Users> CSM Single Sign-on
Enhanced password security 6.5 New requirements for strong passwords
now appear in a single place in this chapter
and are cross-referenced from other
chapters.
No modified screens
Supported Platforms: FMC
CLI Access
Firepower devices include a Firepower CLI that runs on top of Linux. You can create internal users on devices
using the CLI. You can establish external users on FTD devices using the FMC. For detailed information
about the management UIs, see Firepower System User Interfaces, on page 23.
Caution Users with CLI Config level access can access the Linux shell using the expert command, and obtain sudoers
privileges in the Linux shell, which can present a security risk. For system security reasons, we strongly
recommend:
• Only use the Linux shell under TAC supervision or when explicitly instructed by Firepower user
documentation.
• Make sure that you restrict the list of users with CLI access appropriately.
• When granting CLI access privileges, restrict the list of users with Config level access.
• Do not add users directly in the Linux shell; only use the procedures in this chapter.
• Do not access Firepower devices using CLI expert mode unless directed by Cisco TAC or by explicit
instructions in the Firepower user documentation.
Supported Domains
Any
User Roles
Configure external users—Admin FMC user
Configure internal users—Config CLI user
Step 1 Log into the device CLI using an account with Config privileges.
The admin user account has the required privileges, but any account with Config privileges will work. You can use an
SSH session or the Console port.
For certain FTD models, the Console port puts you into the FXOS CLI. Use the connect ftd command to get to the FTD
CLI.
• basic—Gives the user basic access. This role does not allow the user to enter configuration commands.
• config—Gives the user configuration access. This role gives the user full administrator rights to all commands.
Example:
The following example adds a user account named johncrichton with Config access rights. The password is not shown
as you type it.
Note Tell users they can change their own passwords using the configure password command.
Step 3 (Optional) Adjust the characteristics of the account to meet your security requirements.
You can use the following commands to change the default account behavior.
• configure user aging username max_days warn_days
Sets an expiration date for the user's password. Specify the maximum number of days for the password to be valid
followed by the number of days before expiration the user will be warned about the upcoming expiration. Both
values are 1 to 9999, but the warning days must be less than the maximum days. When you create the account, there
is no expiration date for the password.
• configure user forcereset username
Forces the user to change the password on the next login.
• configure user maxfailedlogins username number
Sets the maximum number of consecutive failed logins you will allow before locking the account, from 1 to 9999.
Use the configure user unlock command to unlock accounts. The default for new accounts is 5 consecutive failed
logins.
• configure user minpasswdlen username number
Sets a minimum password length, which can be from 1 to 127.
• configure user strengthcheck username {enable | disable}
Enables or disables password strength checking, which requires a user to meet specific password criteria when
changing their password. When a user’s password expires or if the configure user forcereset command is used,
this requirement is automatically enabled the next time the user logs in.
Changes the password for the specified user. Users should normally change their own password using the configure
password command.
• configure user unlock username
Unlocks a user account that was locked due to exceeding the maximum number of consecutive failed login attempts.
Only a subset of fields in the external authentication object are used for FTD SSH access. If you fill in additional
fields, they are ignored. If you also use this object for other device types, those fields will be used.
LDAP users always have Config privileges. RADIUS users can be defined as either Config or Basic users.
You can either define users on the RADIUS server (with the Service-Type attribute), or you can pre-define
the user list in the external authentication object. For LDAP, you can specify a filter to match CLI users on
the LDAP server.
Note Users with Linux shell access can obtain root privileges, which can present a security risk. Make sure that
you:
• restrict the list of users with Linux shell access
• do not create Linux shell users
About LDAP
The Lightweight Directory Access Protocol (LDAP) allows you to set up a directory on your network that
organizes objects, such as user credentials, in a centralized location. Multiple applications can then access
those credentials and the information used to describe them. If you ever need to change a user's credentials,
you can change them in one place.
Microsoft has announced that Active Directory servers will start enforcing LDAP binding and LDAP signing
in 2020. Microsoft is making these a requirement because when using default settings, an elevation of privilege
vulnerability exists in Microsoft Windows that could allow a man-in-the-middle attacker to successfully
forward an authentication request to a Windows LDAP server. For more information, see 2020 LDAP channel
binding and LDAP signing requirement for Windows on the Microwoft support site.
If you have not done so already, we recommend you start using TLS/SSL encryption to authenticate with an
Active Directory server.
About RADIUS
Remote Authentication Dial In User Service (RADIUS) is an authentication protocol used to authenticate,
authorize, and account for user access to network resources. You can create an authentication object for any
RADIUS server that conforms to RFC 2865.
Firepower devices support the use of SecurID tokens. When you configure authentication by a server using
SecurID, users authenticated against that server append the SecurID token to the end of their SecurID PIN
and use that as their password when they log in. You do not need to configure anything extra on the Firepower
device to support SecurID.
• Timeout—Enter the number of seconds before rolling over to the backup connection. The default is 30.
Step 11 (Optional) Set the Shell Access Attribute if you want to use a shell access attribute other than the user distinguished
type. For example, on a Microsoft Active Directory Server, use the sAMAccountName shell access attribute to retrieve
shell access users by typing sAMAccountName in the Shell Access Attribute field.
Step 12 Set the Shell Access Filter.
Choose one of the following methods:
• To use the same filter you specified when configuring authentication settings, choose Same as Base Filter.
• To retrieve administrative user entries based on attribute value, enter the attribute name, a comparison operator,
and the attribute value you want to use as a filter, enclosed in parentheses. For example, if all network administrators
have a manager attribute which has an attribute value of shell, you can set a base filter of (manager=shell).
Note If you previously configured the same username for an internal user, the FTD first checks the password
against the internal user, and if that fails, it checks the LDAP server. Note that you cannot later add an internal
user with the same name as an external user; only pre-existing internal users are supported.
Examples
Basic Example
The following figures illustrate a basic configuration of an LDAP login authentication object for a
Microsoft Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4.
The connection uses port 389 for access.
This example illustrates an advanced configuration of an LDAP login authentication object for a
Microsoft Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4.
The connection uses port 636 for access.
The connection to the server is encrypted using SSL and a certificate named certificate.pem is
used for the connection. In addition, connections to the server time out after 60 seconds because of
the Timeout setting.
Because this server is a Microsoft Active Directory server, it uses the sAMAccountName attribute to
store user names rather than the uid attribute.
The Shell Access Attribute of sAMAccountName causes each sAMAccountName attribute to be checked
for all objects in the directory for matches when a user logs into the FTD.
In the following example, the shell access filter is set to be the same as the base filter.
Step 1 Define users on the RADIUS server using the Service-Type attribute.
The following are supported values for the Service-Type attribute:
• Administrator (6)—Provides Config access authorization to the CLI. These users can use all commands in the
CLI.
• NAS Prompt (7) or any level other than 6—Provides Basic access authorization to the CLI. These users can use
read-only commands, such as show commands, for monitoring and troubleshooting purposes.
Alternatively, you can predefine users in the external authentication object (see Step Step 12, on page 80). To use the
same RADIUS server for the FTD and FMC while using the Service-Type attribute method for the FTD, create two
external authentication objects that identify the same RADIUS server: one object includes the predefined Shell Access
Filter users (for use with the FMC), and the other object leaves the Shell Access Filter empty (for use with FTDs).
Make sure that these usernames match usernames on the RADIUS server. The names must be Linux-valid usernames:
• Maximum 32 alphanumeric characters, plus hyphen (-) and underscore (_)
• All lowercase
• Cannot start with hyphen (-); cannot be all numbers; cannot include a period (.), at sign (@), or slash (/)
Step 13 (Optional) Click Test to test FMC connectivity to the RADIUS server.
This function can only test FMC connectivity to the RADIUS server; there is no test function for managed device
connectivity to the RADIUS server.
Step 14 (Optional) You can also enter Additional Test Parameters to test user credentials for a user who should be able to
authenticate: enter a User Name and Password, and then click Test.
Tip If you mistype the name or password of the test user, the test fails even if the server configuration is correct.
To verify that the server configuration is correct, click Test without entering user information in the Additional
Test Parameters field first. If that succeeds, supply a user name and password to test with the specific user.
Example:
To test if you can retrieve the JSmith user credentials at the Example company, enter JSmith and the correct password.
Examples
Simple User Role Assignments
The following figure illustrates a sample RADIUS login authentication object for a server running
Cisco Identity Services Engine (ISE) with an IP address of 10.10.10.98 on port 1812. No backup
server is defined.
The following example shows RADIUS-specific parameters, including the timeout (30 seconds) and
number of failed retries before the Firepower System attempts to contact the backup server, if any.
This example illustrates important aspects of RADIUS user role configuration:
Users ewharton and gsand are granted web interface Administrative access.
The user cbronte is granted web interface Maintenance User access.
The user jausten is granted web interface Security Analyst access.
The user ewharton can log into the device using a CLI account.
The following graphic depicts the role configuration for the example:
Roles for Users Matching an Attribute-Value Pair
You can use an attribute-value pair to identify users who should receive a particular user role. If the
attribute you use is a custom attribute, you must define the custom attribute.
The following figure illustrates the role configuration and custom attribute definition in a sample
RADIUS login authentication object for the same ISE server as in the previous example.
In this example, however, the MS-RAS-Version custom attribute is returned for one or more of the
users because a Microsoft remote access server is in use. Note the MS-RAS-Version custom attribute
is a string. In this example, all users logging in to RADIUS through a Microsoft v. 5.00 remote access
server should receive the Security Analyst (Read Only) role, so you enter the attribute-value pair of
MS-RAS-Version=MSRASV5.00 in the Security Analyst (Read Only) field.
• If you typed in your base distinguished name, click Fetch DNs to retrieve all the available base
distinguished names on the server, and select the name from the list.
• If you are using any filters, access attributes, or advanced settings, check that each is valid and typed
correctly.
• If you are using any filters, access attributes, or advanced settings, try removing each setting and testing
the object without it.
• If you are using a base filter or a shell access filter, make sure that the filter is enclosed in parentheses
and that you are using a valid comparison operator (maximum 450 characters, including the enclosing
parentheses).
• To test a more restricted base filter, try setting it to the base distinguished name for the user to retrieve
just that user.
• If you are using an encrypted connection:
• Check that the name of the LDAP server in the certificate matches the host name that you use to
connect.
• Check that you have not used an IPv6 address with an encrypted server connection.
• If you are using a test user, make sure that the user name and password are typed correctly.
• If you are using a test user, remove the user credentials and test the object.
• Test the query you are using by connecting to the LDAP server and using this syntax:
ldapsearch -x -b 'base_distinguished_name'
-h LDAPserver_ip_address -p port -v -D
'user_distinguished_name' -W 'base_filter'
For example, if you are trying to connect to the security domain on myrtle.example.com using the
[email protected] user and a base filter of (cn=*), you could test the connection using
this statement:
ldapsearch -x -b 'CN=security,DC=myrtle,DC=example,DC=com'
-h myrtle.example.com -p 389 -v -D
'[email protected]' -W '(cn=*)'
If you can test your connection successfully but authentication does not work after you deploy a platform
settings policy, check that authentication and the object you want to use are both enabled in the platform
settings policy that is applied to the device.
If you connect successfully but want to adjust the list of users retrieved by your connection, you can add or
change a base filter or shell access filter or use a more restrictive or less restrictive base DN.
Support for the Service-Type attribute for 6.4 For RADIUS authentication of FTD CLI
FTD users defined on the RADIUS server users, you used to have to pre-define the
usernames in the RADIUS external
authentication object and manually make
sure that the list matched usernames defined
on the RADIUS server. You can now define
CLI users on the RADIUS server using the
Service-Type attribute and also define both
Basic and Config user roles. To use this
method, be sure to leave the shell access
filter blank in the external authentication
object.
New/Modified screens:
System > Users > External
Authentication > Add External
Authentication Object > Shell Access
Filter
Supported platforms: FTD
External Authentication for FTD SSH 6.2.3 You can now configure external
Access authentication for SSH access to the FTD
using LDAP or RADIUS.
New/Modified screens:
Devices > Platform Settings > External
Authentication
Supported platforms: FTD
Note "NGFW" means different things to different people, so this documentation does not use this term.
Supported Domains
Global, except where indicated.
User Roles
• Admin
Hardware FMC
A hardware Firepower Management Center does not require purchase of additional licenses or service
subscriptions in order to manage devices.
Virtual FMC
Firepower Management Center Virtual has additional licensing requirements. See Firepower Management
Center Virtual Licenses, on page 90.
Firepower Management Device See Firepower Management Center Virtual Licenses, on page
Center Virtual entitlements 90.
Firepower Threat Defense Smart See the topics under License Firepower Threat Defense
Devices (FTD), on page 91.
Firepower Threat Defense
Virtual
NGIPS software: Classic See License Classic Devices (ASA FirePOWER and NGIPSv),
on page 128.
• ASA FirePOWER
• NGIPSv
All other software products, See licensing information for your software product.
including those that run on
Firepower hardware
Manager, and purchase the license later. This allows you to deploy and use a feature, and avoid delays due
to purchase order approval.
Note At the end of FMC initial configuration the system displays a pop-up that offers you the opportunity to quickly
and easily set up Smart Licensing. Using this dialog is optional; if your FMC will be managing FTD devices
and you are familiar with Smart Licensing, use this dialog. Otherwise dismiss the dialog and use the information
in this chapter to set up Smart Licensing.
Step 3 Understand the feature licenses (sometimes called service subscriptions) that your organization needs.
See FTD License Types and Restrictions, on page 96 and subtopics.
Step 4 Determine the number of feature licenses/service subscriptions that your organization needs.
• Generally, each managed device needs to be licensed for each feature you will use.
• For Firepower Management Centers in a high availability pair:
See FMC HA License Requirements, on page 233.
• For Firepower Threat Defense devices in a high availability pair:
Each device (whether active or standby) must be licensed for each feature to be used. No additional licensing is
required.
See License Requirements for FTD Devices in a High Availability Pair, on page 714.
• For inter- or intra-chassis clustered Firepower Threat Defense devices:
See Licenses for Clustering, on page 744.
• For a multi-instance deployment:
See Licensing for Multi-Instance Deployments, on page 102.
Step 7 If you have multiple Firepower Management Center appliances and you want to connect to Cisco's licensing authority
through a single proxy:
Deploy a Smart Software Satellite Server. For information, see Smart Software Satellite Server Overview, on page 109.
Step 8 If you want to enable features that use strong encryption and that are restricted by geographic region:
See Licensing for Export-Controlled Functionality, on page 101.
Step 10 Verify that your reseller or Cisco sales representative has added your licenses to your Smart Account.
Look in CSSM: https://software.cisco.com/#SmartLicensing-Inventory. Click Inventory, then the Licenses tab. Filter
the list as needed. You may need your purchase confirmation in order to understand the license naming.
If you don't see the licenses you expect to see, make sure you are looking at the correct virtual account. For assistance
with this, see the resource links in CSSM.
If you still don't see your licenses, or the licenses are not correct, contact the person from whom you purchased the
licenses.
Step 11 After your virtual account (Smart Account) holds the licenses you expect, register your Firepower Management Center
to CSSM:
You must configure licensing in the Firepower Management Center using the web interface.
• If your Firepower Management Center connects directly to CSSM:
See the following topics:
• Obtain a Product License Registration Token for Smart Licensing, on page 104 and
• Register Smart Licenses, on page 105
Step 13 If you have not yet done so, add your devices to the Firepower Management Center as managed devices.
See Add a Device to the FMC, on page 260
Step 15 Verify that licenses have successfully been added to your devices.
See View FTD Licenses and License Status, on page 124.
Assign the licenses for the features that you want to use to both the active and standby device before you configure
high availability. If the devices are licensed for different features, the licenses on the standby device will be replaced
with the same set of licenses as the active device.
• For clustered Firepower Threat Defense devices:
See Licenses for Clustering, on page 744. Licensing steps are included in FMC: Add a Cluster, on page 763.
What to do next
• (Optional) If your Firepower Management Center also manages Classic devices (ASA FirePOWER,
NGIPSv), configure licensing for those devices:
See License Classic Devices (ASA FirePOWER and NGIPSv), on page 128.
• Understand validity periods and expiration. See License Expiration, on page 138.
with no communication), the Firepower Management Center reverts to a deregistered state and licensed
features usage become suspended.
The Firepower Management Center communicates with the License Authority on a periodic basis. If you
make changes in the Smart Software Manager, you can refresh the authorization on the Firepower Management
Center so the changes immediately take effect. You also can wait for the appliance to communicate as scheduled.
Your Firepower Management Center must have either direct Internet access to the License Authority through
the Cisco Smart Software Manager or access through the Smart Software Satellite Server at scheduled time
periods. Normal license communication occurs every 30 days, but with the grace period, your appliance will
operate for up to 90 days without calling home. You must contact the License Authority before 90 days have
passed.
Optionally, you can configure a Smart Software Satellite Server to serve as a proxy for communicating with
the License Authority. For information, see Smart Software Satellite Server Overview, on page 109.
T Threat
TM Threat + Malware
Your purchase of a managed device that uses Smart Licenses automatically includes a Base license. This
license is perpetual and enables system updates. All service subscriptions are optional for Firepower Threat
Defense devices.
Firepower Management Center Based on license type. Term-based or The platform license determines
Virtual perpetual based the number of devices the virtual
on license type. appliance can manage.
For details, see Firepower
Management Center Virtual
Licenses, on page 90.
Export-Controlled Features Based on license type. Term-based or Features that are subject to
perpetual based national security, foreign policy,
on license type. and anti-terrorism laws and
regulations; see Licensing for
Export-Controlled Functionality,
on page 101.
Remote Access VPN: Based on license type. Term-based or Remote access VPN
perpetual based configuration. Your base license
• AnyConnect Apex
on license type. must allow export-controlled
• AnyConnect Plus functionality to configure
Remote Access VPN. You select
• AnyConnect VPN Only whether you meet export
requirements when you register
the device. Firepower Threat
Defense can use any valid
AnyConnect license. The
available features do not differ
based on license type.
For more information, see
AnyConnect Licenses, on page
100 and VPN Licensing, on page
920.
Base Licenses
A base license is automatically included with every purchase of a Firepower Threat Defense or Firepower
Threat Defense Virtual device.
The Base license allows you to:
• configure your FTD devices to perform switching and routing (including DHCP relay and NAT)
• configure FTD devices as a high availability pair
• configure security modules as a cluster within a Firepower 9300 chassis (intra-chassis clustering)
• configure Firepower 9300 or Firepower 4100 series devices running Firepower Threat Defense as a
cluster (inter-chassis clustering)
• implement user and application control by adding user and application conditions to access control rules
Threat and malware detection and URL filtering features require additional, optional licenses.
Except in deployments using Specific License Reservation, Base licenses are automatically added to the
Firepower Management Center for every Firepower Threat Defense device you register.
For multi-instance deployments, see Licensing for Multi-Instance Deployments, on page 102.
Note Firepower Threat Defense managed devices with Malware licenses enabled periodically attempt to connect
to the AMP cloud even if you have not configured dynamic analysis. Because of this, the device’s Interface
Traffic dashboard widget shows transmitted traffic; this is expected behavior.
You configure AMP for Networks as part of a file policy, which you then associate with one or more access
control rules. File policies can detect your users uploading or downloading files of specific types over specific
application protocols. AMP for Networks allows you to use local malware analysis and file preclassification
to inspect a restricted set of those file types for malware. You can also download and submit specific file types
to the Cisco Threat Grid cloud for dynamic and Spero analysis to determine whether they contain malware.
For these files, you can view the network file trajectory, which details the path the file has taken through your
network. The Malware license also allows you to add specific files to a file list and enable the file list within
a file policy, allowing those files to be automatically allowed or blocked on detection.
If you disable all your Malware licenses, the system stops querying the AMP cloud, and also stops
acknowledging retrospective events sent from the AMP cloud. You cannot re-deploy existing access control
policies if they include AMP for Networks configurations. Note that for a very brief time after a Malware
license is disabled, the system can use existing cached file dispositions. After the time window expires, the
system assigns a disposition of Unavailable to those files.
Note that a Malware license is required only if you deploy AMP for Networks and Cisco Threat Grid. Without
a Malware license, the Firepower Management Center can receive AMP for Endpoints malware events and
indications of compromise (IOC) from the AMP cloud.
See also important information at License Requirements for File and Malware Policies, on page 1538.
Threat Licenses
A Threat license allows you to perform intrusion detection and prevention, file control, and Security Intelligence
filtering:
• Intrusion detection and prevention allows you to analyze network traffic for intrusions and exploits and,
optionally, drop offending packets.
• File control allows you to detect and, optionally, block users from uploading (sending) or downloading
(receiving) files of specific types over specific application protocols. AMP for Networks, which requires
a Malware license, allows you to inspect and block a restricted set of those file types based on their
dispositions.
• Security Intelligence filtering allows you to block —deny traffic to and from—specific IP addresses,
URLs, and DNS domain names, before the traffic is subjected to analysis by access control rules. Dynamic
feeds allow you to immediately block connections based on the latest intelligence. Optionally, you can
use a “monitor-only” setting for Security Intelligence filtering.
You can purchase a Threat license as a stand-alone subscription (T) or in combination with URL Filtering
(TC), Malware (TM), or both (TMC).
If you disable Threat on managed devices, the Firepower Management Center stops acknowledging intrusion
and file events from the affected devices. As a consequence, correlation rules that use those events as a trigger
criteria stop firing. Additionally, the Firepower Management Center will not contact the internet for either
Cisco-provided or third-party Security Intelligence information. You cannot re-deploy existing intrusion
policies until you re-enable Threat.
Tip Without a URL Filtering license, you can specify individual URLs or groups of URLs to allow or block. This
gives you granular, custom control over web traffic, but does not allow you to use URL category and reputation
data to filter network traffic.
Although you can add category and reputation-based URL conditions to access control rules without a URL
Filtering license, the Firepower Management Center will not download URL information. You cannot deploy
the access control policy until you first add a URL Filtering license to the Firepower Management Center,
then enable it on the devices targeted by the policy.
If you disable the URL Filtering license on managed devices, you may lose access to URL filtering. If your
license expires or if you disable it, access control rules with URL conditions immediately stop filtering URLs,
and your Firepower Management Center can no longer download updates to URL data. You cannot re-deploy
existing access control policies if they include rules with category and reputation-based URL conditions.
AnyConnect Licenses
You can use Firepower Threat Defense device to configure remote access VPN using the Cisco AnyConnect
Secure Mobility Client (AnyConnect) and standards-based IPSec/IKEv2.
To enable the Firepower Threat Defense Remote Access VPN feature, you must purchase and enable one of
the following licenses: AnyConnect Plus, AnyConnect Apex, or AnyConnect VPN Only. You can use any
of the AnyConnect licenses: Plus, Apex, or VPN Only. You can select AnyConnect Plus and AnyConnect
Apex if you have both licenses and you want to use them both. The Any Connect VPN only license cannot
be used with Apex or Plus. The AnyConnect license must be shared with the Smart Account. For more
instructions, see http://www.cisco.com/c/dam/en/us/products/collateral/security/anyconnect-og.pdf.
You cannot deploy the Remote Access VPN configuration to the FTD device if the specified device does not
have the entitlement for a minimum of one of the specified AnyConnect license types. If the registered license
moves out of compliance or entitlements expire, the system displays licensing alerts and health events.
While using Remote Access VPN, your Smart License Account must have the export controlled features
(strong encryption) enabled. The FTD requires stronger encryption (which is higher than DES) for successfully
establishing Remote Access VPN connections with AnyConnect clients. When you register the device, you
must do so with a Smart Software Manager account that is enabled for export-controlled features. For more
information about export-controlled features, see FTD License Types and Restrictions, on page 96.
You cannot deploy Remote Access VPN if the following are true:
How to determine whether export-controlled functionality is currently enabled for your system
To determine whether export-controlled functionality is currently enabled for your system: Go to System >
Licenses > Smart Licenses and see if Export-Controlled Features displays Enabled.
• When you create the new Product Instance Registration Token, you must select the option “Allow
export-controlled functionality on the products registered with this token.” This option is enabled
by default if this functionality is permitted for your Smart Account.
• After you install a token with export-controlled functionality on your Firepower Management Center
and assign the relevant licenses to managed Firepower Threat Defense devices:
• Reboot each device to make the newly-enabled features available.
• In a high availability deployment, the active and standby devices must be rebooted together to
avoid an Active-Active condition.
More Information
For general information about export controls, see https://www.cisco.com/c/en/us/about/legal/
global-export-trade.html.
See also the topics for specific license types under the FTD License Types and Restrictions, on page 96 topic.
Base Licenses
Each security engine or module consumes a single Base license, which is automatically assigned for all
deployments except those using Specific License Reservation.
Feature Licenses
Each feature you license (Malware, Threat, URL Filtering, AnyConnect Apex, AnyConnect Plus, and
AnyConnect VPN Only) requires one license per security engine/module. All instances on the engine/module
can share the same feature licenses.
You must assign the license to each instance.
High-Availability Deployments
Instances in a high-availability pair cannot share feature licenses with each other, but each instance may share
feature licenses with other instances on its respective engine/module.
Licensing Example
To see how the above licensing requirements work together, see Licenses for Container Instances, on page
596.
Step 2 Wait for an email telling you that your Smart Account is ready to set up. When it arrives, click the link it contains, as
directed.
Step 3 Set up your Smart Account:
Go here: https://software.cisco.com/software/company/smartaccounts/home?route=module/accountcreation.
For instructions, see https://community.cisco.com/t5/licensing-enterprise-agreements/
complete-smart-account-setup-for-customers/ta-p/3636631?attachment-id=132604.
Step 4 Verify that you can access the account in the Cisco Smart Software Manager (CSSM).
Go to https://software.cisco.com/#module/SmartLicensing and sign in.
What to do next
If you are following a longer workflow, return to the workflow:
How to License Firepower Threat Defense Devices, on page 92
Step 1 Obtain a token from the Cisco Smart Software Manager licensing portal.
See Obtain a Product License Registration Token for Smart Licensing, on page 104.
Step 2 Register your Firepower Management Center with the Smart licensing portal.
See Register Smart Licenses, on page 105. Be sure to address the prerequisites in this topic.
Step 3 Verify that your FMC registered successfully with the Smart licensing portal.
In the Firepower Management Center web interface, go to System > Licenses > Smart Licenses.
Product Registration should show a green checkmark.
Step 4 If you have not yet done so, add devices to your FMC.
See Add a Device to the FMC, on page 260.
Step 5 Assign licenses to the devices that are managed by your FMC.
See Assign Licenses to Multiple Managed Devices, on page 123.
What to do next
If applicable, set up licensing for high-availability and clustered deployments.
See the final steps in How to License Firepower Threat Defense Devices, on page 92.
• Verify that the licenses you need appear in your Smart Account.
If your licenses do not appear in your Smart Account, ask the person who ordered them (for example,
your Cisco sales representative or authorized reseller) to transfer those licenses to your Smart Account.
• Ideally, check the prerequisites for Register Smart Licenses, on page 105 to ensure that your registration
process goes smoothly.
• Make sure you have your credentials to sign in to the Cisco Smart Software Manager.
Step 1 Go to https://software.cisco.com.
Step 2 Click Smart Software Licensing (in the License section.)
Step 3 Sign in to the Cisco Smart Software Manager.
Step 4 Click Inventory.
Step 5 Click General.
Step 6 Click New Token.
Step 7 For Description, enter a name that uniquely and clearly identifies the Firepower Management Center for which you
will use this token.
Step 8 Enter an expiration time within 365 days.
This determines how much time you have to register the token to a Firepower Management Center. (Your license
entitlement term is independent of this setting but may start to count down even if you have not yet registered your
token.)
Step 9 If you see an option to enable export-controlled functionality, and you plan to use features that require strong encryption,
select this option.
Important If you see this option, you must select it now if you plan to use this functionality. You cannot enable
export-controlled functionality later.
If you do not see this option, and your organization has obtained a license for export-controlled functionality,
you will enable this functionality later, as described in Enabling the Export Control Feature (for Accounts
Without Global Permission), on page 107.
What to do next
Continue with the steps in Register Smart Licenses, on page 105.
What to do next
• Add your Firepower Threat Defense devices to the Firepower Management Center; see Add a Device to
the FMC, on page 260.
• Assign licenses to your Firepower Threat Defense devices; see Assign Licenses to Multiple Managed
Devices, on page 123.
Enabling the Export Control Feature (for Accounts Without Global Permission)
Important Use this procedure only if your Smart Account is not authorized for strong encryption. If your account is
authorized, or you aren't sure, see Licensing for Export-Controlled Functionality, on page 101.
Note If your deployment supports export-controlled features, you will see an option
that allows you to enable export-controlled functionality in the Create
Registration Token page in the Cisco Smart Software Manager. For more
information, see https://www.cisco.com/c/en/us/buy/smart-accounts/
software-manager.html.
Cisco Virtual FMC Series Strong Encryption All virtual Firepower Management Centers
(3DES/AES)
What to do next
You can now deploy configurations or policies that use the export-controlled features.
Remember The new export-controlled licenses and all features enabled by it do not take effect on the Firepower Threat
Defense devices until the devices are rebooted. Until then, only the features supported by the older license
will be active.
In high-availability deployments both the Firepower Threat Defense devices need to be rebooted simultaneously,
to avoid an Active-Active condition.
Disabling the Export Control Feature (for Accounts without Global Permission)
If you enabled the export-controlled functionality using the feature described in Enabling the Export Control
Feature (for Accounts Without Global Permission), on page 107, you can disable this functionality using this
procedure.
Step 2 Disable the export control license by clicking Return Export Key.
Scalable for a large number of products Best for a small number of devices
Automated licensing management, usage and asset Limited usage and asset management visibility
management visibility
No incremental operational costs to add devices Linear operational costs over time to add devices
Flexible, easier to use, less overhead Significant administrative and manual overhead for
moves, adds, and changes
Out-of-compliance status is allowed initially and at Out-of-compliance status impacts system functioning
various expiration states
For more information, see Smart Software Satellite For more information, see Specific License
Server Overview, on page 109 Reservation (SLR), on page 111
The Smart Software Satellite Server allows you to schedule synchronization or manually synchronize Smart
License authorization with the Smart Software Manager.
For more information about the Smart Software Satellite Server, see https://www.cisco.com/c/en/us/buy/
smart-accounts/software-manager-satellite.html.
An alternate solution for air-gapped networks is Specific License Reservation. For information, see Specific
License Reservation (SLR), on page 111.
Step 2 Connect the Firepower Management Center to the satellite, obtain a registration token, and register the management
center to the satellite.
See Configure the Connection to a Smart Software Satellite Server, on page 110.
Step 5 Synchronize the satellite to the Cisco Smart Software Management Server (CSSM).
See the Smart Software Manager Satellite User Guide you used above.
Step 5 Add a new SSL Certificate and paste the certificate text that you copied in the prerequisites for this procedure.
Step 6 Click Apply.
Step 7 Select System > Licenses > Smart Licenses and click Register.
Step 8 Create a new token on the Smart Satellite Server.
Step 9 Copy the token.
Step 10 Paste the token into the form on the management center page.
Step 11 Click Apply Changes.
The management center is now registered to the Smart Software Satellite Server.
What to do next
Complete remaining steps in How to Deploy a Smart Software Satellite Server, on page 109.
Note Various names are used at Cisco for Specific License Reservation, including SLR, SPLR, PLR, and Permanent
License Reservation. These terms may also be used at Cisco to refer to similar but not necessarily identical
licensing models.
When Specific License Reservation is enabled, the Firepower Management Center reserves licenses from
your virtual account for a specified duration without accessing the Cisco Smart Software Manager or Smart
Software Satellite Server.
Your Firepower Management Center can also simultaneously manage devices that use standard Classic
licenses. However, those devices do not use Specific License Reservation.
Features that require access to the internet, such as URL Lookups or contextual cross-launch to public web
sites, will not work.
Cisco does not collect web analytics or telemetry data for deployments that use Specific License Reservation.
Related Topics:
• Best Practices for Specific License Reservation, on page 111
• Requirements for Specific License Reservation, on page 111
• How to Implement Specific License Reservation, on page 112
• Specific License Reservation Status, on page 119
• Update a Specific License Reservation, on page 116
• Deactivate and Return the Specific License Reservation, on page 120
• Troubleshoot Specific License Reservation, on page 122
Step 1 Complete the prerequisites for this feature. Prerequisites for Specific License Reservation, on
page 112
Step 2 Verify that your Smart Account is ready to Verify that your Smart Account is Ready to Deploy
deploy Specific License Reservation. Specific License Reservation, on page 113
Step 3 Enable Specific License Reservation using the Enable the Specific Licensing Menu Option, on
Firepower Management Center page 114
Step 4 Generate a Reservation Request Code from the Generate a Reservation Request Code from the
Firepower Management Center Firepower Management Center, on page 114
Step 5 Use the Reservation Request Code to Generate Generate a Reservation Authorization Code from
a Reservation Authorization Code from Cisco Cisco Smart Software Manager, on page 115
Smart Software Manager
Step 6 Enter the Reservation Authorization Code into Enter the Specific License Reservation
the Firepower Management Center Authorization Code into the Firepower Management
Center, on page 116
Step 7 Assign Specific Licenses to managed Firepower Assign Specific Licenses to Managed Devices, on
Threat Defence devices page 116
Step 9 (Outside of your Firepower Management Maintain Your Air-Gapped Deployment, on page
Center) Schedule reminders for ongoing 174
maintenance tasks
• Arrange for export-controlled strong cryptographic functionality, if required and if your organization is
eligible. Confirm that your account is enabled to use it, or the required per-Firepower Management Center
licenses appear in your virtual account. Your account representative can assist you with this.
For more information, see Licensing for Export-Controlled Functionality, on page 101.
• Work with your account representative to obtain approval for Specific License Reservation (SLR) for
your Firepower products.
• Obtain confirmation from your account representative that the Specific License Reservation is ready for
use and reflected in your Smart Account.
• Add managed devices to your Firepower Management Center. For instructions, see Add a Device to the
FMC, on page 260. (You can add managed devices at any time, but adding them now simplifes this
process.) You will need to enable the evaluation license in order to do this (under System > Licenses >
Smart Licenses). Evaluation licensing does not require a connection to the License Authority.
• Make sure NTP is configured on the Firepower Management Center and managed devices. Time must
be synchronized for registration to succeed.
If you are deploying FTD on a Firepower 4100/9300 chassis, you must configure NTP on the Firepower
chassis using the same NTP server for the chassis as for the Firepower Management Center.
• (Recommended) If you will deploy a Firepower Management Center pair in a high availability
configuration, configure that before you assign licenses. (FMCs in a high availability configuration
require the same number of licenses as a single FMC.) If you have already deployed licenses to the
secondary appliance, de-register licensing from that appliance.
Verify that your Smart Account is Ready to Deploy Specific License Reservation
In order to prevent problems when deploying your Specific License Reservation, complete this procedure
before you make any changes in your Firepower Management Center.
Step 2 If applicable, select the correct account from the top right corner of the page.
Step 3 If necessary, click Inventory.
Step 4 Click Licenses.
Step 5 Verify the following:
• There is a License Reservation button.
• There are enough platform and feature licenses for the devices and features you will deploy, including Firepower
Management Center Virtual entitlements for your devices, if applicable.
Step 6 If any of these items is missing or incorrect, contact your account representative to resolve the problem.
Important Do not continue with this process until any problems are corrected.
Step 1 Access the Firepower Management Center console using a USB keyboard and VGA monitor, or use SSH to access the
management interface.
Step 2 Log into the Firepower Management Center admin account.
Step 3 Enter the expert command to access the Linux shell.
Step 4 Execute the following command to access the Specific License Reservation options:
sudo manage_slr.pl
Example:
admin@fmc63betaslr: ~$ sudo manage_slr.pl
Password:
**************************************************************
Enter choice:
Step 1 If you are not already viewing the Specific License Reservation page, choose System > Licenses > Specific Licenses.
Step 2 Click Generate.
Step 2 If necessary, select the correct account from the top right of the page.
Step 3 If necessary, click Inventory.
(This page may display automatically.)
Step 13 Download the Authorization Code in preparation for entering it into the Firepower Management Center.
Enter the Specific License Reservation Authorization Code into the Firepower Management Center
Step 1 If you are not already viewing the Specific License Reservation page, in the Firepower management center web interface,
choose System > Licenses > Specific Licenses.
Step 2 Click Browse to upload the text file with the authorization code that you generated from CSSM.
Step 3 Click Install.
Step 4 Verify that the Specific License Reservation page shows the Usage Authorization status as authorized.
Step 5 Click the Reserved License tab to verify the licenses selected while generating the Authorization Code.
If you do not see the licenses you require, then add the necessary licenses. For more info, see Update a Specific License
Reservation.
What to do next
• If export-controlled functionality is enabled, reboot each device. If devices are configured in a
high-availability pair, reboot both devices at the same time to avoid an Active-Active condition.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In Firepower Management Center, obtain the unique product instance identifier of this appliance:
a) Select System > Licenses > Specific Licenses.
b) Make a note of the Product Instance value.
You will need this value several times during this process.
Step 2 In Cisco Smart Software Manager, identify the Firepower Management Center appliance to update:
Step 3 When you have located the correct Firepower Management Center appliance in Cisco Smart Software Manager, update
the reserved licenses and generate a new authorization code:
a) On the page that shows the correct UUID, choose Actions > Update Reserved Licenses.
b) Update the reserved licenses as needed.
Important • You must explicitly include a Firepower Threat Defense Base Features license for each managed
device, or, for multi-instance deployments, a Firepower Threat Defense Base Features license for
each module.
• If you are using a virtual management center, you must include a Firepower MCv Device License
entitlement for each module (in multi-instance deployments) or each managed device (all other
deployments).
• If you use strong cryptographic functionality:
• If your entire Smart Account is enabled for export-controlled functionality, you do not need to
do anything here.
• If your organization's entitlement is per-Firepower Management Center, you must select the
appropriate license for your appliance.
For the correct license name to choose for your device, see the prerequisites in Enabling the
Export Control Feature (for Accounts Without Global Permission), on page 107.
c) Enter the confirmation code that you generated from the Firepower Management Center.
Step 6 In Firepower Management Center, verify that your licenses are reserved as you expect them, and that each feature for
each managed device shows a green circle with a Check Mark ( ).
If necessary, see Specific License Reservation Status, on page 119 for more information.
What to do next
If your deployment includes export-controlled functionality, reboot each device. If devices are configured in
a high-availability pair, reboot both devices at the same time to avoid an Active-Active condition.
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Usage Authorization
Possible status values are:
• Authorized — The Firepower Management Center is in compliance and registered successfully with
the License Authority, which has authorized the license entitlements for the appliance.
• Out-of-compliance — If licenses are expired or if the Firepower Management Center has overused
licenses even though they are not reserved, status shows as Out-of-Compliance. License entitlements are
enforced in Specific License Reservation, so you must take action.
Product Registration
Specifies registration status and the date that an authorization code was last installed or renewed on the
Firepower Management Center.
Export-Controlled Features
Specifies whether you have enabled export-controlled functionality for the Firepower Management Center.
For more information about Export-Controlled Features, see Licensing for Export-Controlled Functionality,
on page 101.
Product Instance
The Universally Unique Identifier (UUID) of this Firepower Management Center. This value identifies this
device in Cisco Smart Software Manager.
Confirmation Code
The Confirmation Code is needed if you update or deactivate and return Specific Licenses.
To renew your Specific License Reservation entitlements, purchase the necessary licenses, then follow the
procedure in Update a Specific License Reservation, on page 116.
Important If you do not follow all of the steps in this procedure, the license remains in an in-use state and cannot be
re-used.
This procedure releases all license entitlements associated with the Firepower Management Center back to
your virtual account. After you de-register, no updates or changes on licensed features are allowed.
Step 1 In the Firepower Management Center Web interface, select System > Licenses > Specific Licenses.
Step 2 Make a note of the Product Instance identifier for this Firepower Management Center.
Step 3 Generate a return code from Firepower Management Center:
a) Click Return SLR.
The following figure shows Return SLR.
Firepower Threat Defense devices become unlicensed and Firepower Management Center moves to the de-registered
state.
b) Make a note of the Return Code.
Step 4 In Cisco Smart Software Manager, identify the Firepower Management Center appliance to deregister:
a) Go to the Cisco Smart Software Manager:
https://software.cisco.com/#SmartLicensing-Inventory
b) If necessary, click Inventory.
Step 5 When you have identified the correct Firepower Management Center, return the licenses to your Smart Account:
a) On the page that shows the correct UUID, choose Actions > Remove.
b) Enter the reservation return code that you generated from the Firepower Management Center into the Remove Product
Instance dialog box.
c) Click Remove Product Instance.
The specific reserved licenses are returned to the available pool in your Smart Account and this Firepower Management
Center is removed from the Cisco Smart Software Manager Product Instances list.
Step 6 Disable the Specific License in the Firepower Management Center Linux shell:
a) Access the Firepower Management Center console using a USB keyboard and VGA monitor, or use SSH to access
the management interface.
b) Log in to the Firepower Management Center admin account. This gives you access to the command line interface.
c) Enter the expert command to access the Linux shell.
d) Execute the following command:
sudo manage_slr.pl
Example:
admin@fmc63betaslr: ~$ sudo manage_slr.pl
Password:
**************************************************************
Enter choice:
How do I identify a particular Firepower Management Center in the Product Instance list in Cisco Smart
Software Manager?
On the Product Instances page in Cisco Smart Software Manager, if you cannot identify the product instance
based on a value in one of the columns in the table, you must click the name of each generic product instance
of type FP to view the product instance details page. The UUID value on this page uniquely identifies one
Firepower Management Center.
In the Firepower Management Center web interface, the UUID for a Firepower Management Center is the
Product Instance value displayed on the System > Licenses > Specific Licenses page.
I was interrupted in the middle of the licensing process. How can I pick up where I left off?
If you have generated but not yet downloaded an Authorization code from Cisco Smart Software Manager,
you can go to the Product Instance page in Cisco Smart Software Manager, click the product instance, then
click Download Reservation Authorization Code.
I am unable to register Firepower Threat Defense devices to Firepower Management Center Virtual
Make sure you have enough MCv entitlements in your Smart Account to cover the devices you want to register,
then update your deployment to add the necessary entitlements.
See Update a Specific License Reservation, on page 116.
I have enabled Specific Licensing, but now I do not see a Smart License page.
This is the expected behavior. When you enable Specific Licensing, Smart Licensing is disabled. You can
use the Specific License page to perform licensing operations.
If you want to use Smart Licensing, you must return the Specific License. For more information see, Deactivate
and Return the Specific License Reservation, on page 120.
I have disabled Specific Licensing, but forgot to copy the Return Code. What should I do?
The Return Code is saved in Firepower Management Center. You must re-enable the Specific License from
the Linux shell (see Enable the Specific Licensing Menu Option, on page 114), then refresh the Firepower
Management Center web interface. Your Return Code will be displayed.
Note For container instances on the same security module/engine, you apply the license to each instance; note that
the security module/engine consumes only one license per feature for all instances on the security
module/engine.
Note For an FTD cluster, you apply the licenses to the cluster as a whole; note that each unit in the cluster consumes
a separate license per feature.
Step 1 Choose System > Licenses > Smart Licenses or Specific Licenses.
Step 2 Click Edit Licenses.
Step 3 For each type of license you want to add to a device:
a) Click the tab for that type of license.
b) Click a device in the list on the left.
c) Click Add to move that device to the list on the right.
d) Repeat for each device to receive that type of license.
For now, don't worry about whether you have licenses for all of the devices you want to add.
e) Repeat this subprocedure for each type of license you want to add.
f) Click Apply.
What to do next
• Verify that your licenses are correctly installed. Follow the procedure in View FTD Licenses and License
Status, on page 124.
• If export-controlled functionality is newly enabled, reboot each device. If devices are configured in a
high-availability pair, reboot both devices at the same time to avoid an Active-Active condition.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 3 In each folder, verify that each device has a green circle with a Check Mark ( ) in the License Status column.
Note If you see duplicate Firepower Management Center Virtual licenses, each represents one managed device.
If all devices show a green circle with a Check Mark ( ), your devices are properly licensed and ready to use.
If you see any License Status other than a green circle with a Check Mark ( ), hover over the status icon to view the
message.
What to do next
• If you had any devices that did NOT have a green circle with a Check Mark ( ), you may need to
purchase more licenses.
Smart Licensing
The Smart License Status section of the System > Licenses > Smart Licenses page provides an overview of
license usage on the Firepower Management Center, as described below.
Usage Authorization
Possible status values are:
• In-compliance ( ) — All licenses assigned to managed devices are in compliance and the Firepower
Management Center is communicating successfully with the Cisco licensing authority.
• License is in compliance but communication with licensing authority has failed— Device licenses
are in compliance, but the Firepower Management Center is not able to communicate with the Cisco
licensing authority.
• Out-of-compliance icon or unable to communicate with License Authority— One or more managed
devices is using a license that is out of compliance, or the Firepower Management Center has not
communicated with the Cisco licensing authority in more than 90 days.
Product Registration
Specifies the last date when the Firepower Management Center contacted the License Authority and registered.
Export-Controlled Features
If this option is enabled, you can deploy restricted features. For details, see Licensing for Export-Controlled
Functionality, on page 101.
Important If you need to move a license to a device managed by a different Firepower Management Center, see Transfer
FTD Licenses to a Different Firepower Management Center, on page 126.
What to do next
Deploy the changes to the managed devices.
Step 1 Look at the Smart Licenses section at the bottom of the page to determine which licenses are needed.
Step 2 Purchase the required licenses through your usual channels.
Step 3 In Cisco Smart Software Manager (https://software.cisco.com/#SmartLicensing-Inventory), verify that the licenses appear
in your virtual account.
If the expected licenses are not present, see Troubleshoot FTD Licensing, on page 127.
Step 4 In Firepower Management Center, select System > Licenses > Smart Licenses.
Step 5 Click Re-Authorize.
• Make sure they are not in a different Virtual Account. Your organization's license administrator may
need to assist you with this.
• Check with the person who sold you the licenses to be sure that transfer to your account is complete.
Important If you are running Firepower hardware but not Firepower software, see licensing information for the software
product you are using. This documentation is not applicable.
Classic licenses require a product authorization key (PAK) to activate and are device-specific. Classic licensing
is sometimes also referred to as "traditional licensing."
Your purchase of a managed device that uses Classic licenses automatically includes Control and Protection
licenses. These licenses are perpetual, but you must also purchase a TA service subscription to enable system
updates. Service subscriptions for additional features are optional.
Though there are some exceptions, you cannot use the features associated with an expired or deleted license.
The following table summarizes Classic licenses in the Firepower System.
License You Assign Service Subscription Platforms Granted Capabilities Also Expire
in Firepower System You Purchase Requires Capable?
Any TA, TAC, TAM, or ASA FirePOWER host, application, and user none depends on
TAMC discovery license
NGIPSv
decrypting and inspecting
SSL- and TLS-encrypted
traffic
Control none (included with ASA FirePOWER user and application control Protection no
device)
NGIPSv
Malware TAM, TAMC, or ASA FirePOWER AMP for Networks Protection yes
AMP (network-based Advanced
NGIPSv
Malware Protection)
File storage
URL Filtering TAC, TAMC, or ASA FirePOWER category and Protection yes
URL reputation-based URL
NGIPSv
filtering
Protection Licenses
A Protection license allows you to perform intrusion detection and prevention, file control, and Security
Intelligence filtering:
• Intrusion detection and prevention allows you to analyze network traffic for intrusions and exploits and,
optionally, drop offending packets.
• File control allows you to detect and, optionally, block users from uploading (sending) or downloading
(receiving) files of specific types over specific application protocols. AMP for Networks, which requires
a Malware license, allows you to inspect and block a restricted set of those file types based on their
dispositions.
• Security Intelligence filtering allows you to block —deny traffic to and from—specific IP addresses,
URLs, and DNS domain names, before the traffic is subjected to analysis by access control rules. Dynamic
feeds allow you to immediately block connections based on the latest intelligence. Optionally, you can
use a “monitor-only” setting for Security Intelligence filtering.
A Protection license (along with a Control license) is automatically included in the purchase of any Classic
managed device. This license is perpetual, but you must also purchase a TA subscription to enable system
updates.
Although you can configure an access control policy to perform Protection-related inspection without a license,
you cannot deploy the policy until you first add a Protection license to the Firepower Management Center,
then enable it on the devices targeted by the policy.
If you delete your Protection license from the Firepower Management Center or disable Protection on managed
devices, the Firepower Management Center stops acknowledging intrusion and file events from the affected
devices. As a consequence, correlation rules that use those events as a trigger criteria stop firing. Additionally,
the Firepower Management Center will not contact the internet for either Cisco-provided or third-party Security
Intelligence information. You cannot re-deploy existing policies until you re-enable Protection.
Because a Protection license is required for URL Filtering, Malware, and Control licenses, deleting or disabling
a Protection license has the same effect as deleting or disabling your URL Filtering, Malware, or Control
license.
Control Licenses
A Control license allows you to implement user and application control by adding user and application
conditions to access control rules. To enable a Control license on a managed device, you must also enable a
Protection license. A Control license is automatically included (along with a Protection license) in the purchase
of any Classic managed device. This license is perpetual, but you must also purchase a TA subscription to
enable system updates.
If you do not enable a Control license for a Classic managed device, you can add user and application conditions
to rules in an access control policy, but you cannot deploy the policy to the device.
If you delete a Control license from the Firepower Management Center or disable Control on individual
devices:
• You can continue to edit and delete existing configurations, but you cannot deploy those changes to the
affected devices.
• You cannot re-deploy existing access control policies if they include rules with user or application
conditions.
Tip Without a URL Filtering license, you can specify individual URLs or groups of URLs to allow or block. This
gives you granular, custom control over web traffic, but does not allow you to use URL category and reputation
data to filter network traffic.
Although you can add category and reputation-based URL conditions to access control rules without a URL
Filtering license, the Firepower Management Center will not download URL information. You cannot deploy
the access control policy until you first add a URL Filtering license to the Firepower Management Center,
then enable it on the devices targeted by the policy.
You may lose access to URL filtering if you delete the license from the Firepower Management Center or
disable URL Filtering on managed devices. Also, URL Filtering licenses may expire. If your license expires
or if you delete or disable it, access control rules with URL conditions immediately stop filtering URLs, and
your Firepower Management Center can no longer download updates to URL data. You cannot re-deploy
existing access control policies if they include rules with category and reputation-based URL conditions.
To View Do This
The Classic licenses that you have added to the Firepower Choose System > Licenses > Classic Licenses.
Management Center and details including their type, status,
The summary shows the number of licenses you have
usage, expiration dates, and the managed devices to which
purchased, followed by the number of licenses that are in
they are applied.
used in parentheses.
The licenses applied to each of your managed devices Choose Devices > Device Management.
To View Do This
License status in the Health Monitor Use the Classic License Monitor health module in a health
policy. For information, see Health Monitoring, on page
307, including Health Modules, on page 309 and Creating
Health Policies, on page 316.
An overview of your licenses in the Dashboard Add the Product Licensing widget to the dashboard of your
choice. For instructions, see The Product Licensing Widget,
on page 298 and Adding Widgets to a Dashboard, on page
301 and Dashboard Widget Availability by User Role, on
page 289.
What to do next
• Add a license to the Firepower Management Center; see Generate a Classic License and Add It to the
Firepower Management Center, on page 133.
This procedure includes the process of generating the actual license text using the license key.
Note If you add licenses after a backup has completed, these licenses will not be removed or overwritten if this
backup is restored. To prevent a conflict on restore, remove those licenses before restoring the backup, noting
where the licenses were used, and add and reconfigure them after restoring the backup. If a conflict occurs,
contact Support.
Tip You can also request licenses on the Licenses tab after you log into the Support Site.
Step 4 Click Get License to open the Cisco License Registration Portal.
Note If you cannot access the Internet using your current computer, switch to a computer that can, and browse to
http://cisco.com/go/license.
Step 5 Generate a license from the PAK in the License Registration Portal.
This step requires the PAK you received during the purchase process, as well as the license key for the Firepower
Management Center.
For information, see Product License Registration Portal, on page 128.
Step 6 Copy the license text from either the License Registration Portal display, or the email the License Registration Portal
sends you.
Important The licensing text block in the portal or email message may include more than one license. Each license is
bounded by a BEGIN LICENSE line and an END LICENSE line. Make sure that you copy and paste only
one license at a time.
Step 7 Return to the Add Feature License page in the Firepower Management Center’s web interface.
Step 8 Paste the license text into the License field.
Step 9 Click Verify License.
If the license is invalid, make sure that you correctly copied the license text.
What to do next
• Assign the license to a managed device; see Assign Licenses to Managed Devices from the Device
Management Page, on page 136. You must assign licenses to your managed devices before you can use
licensed features on those devices.
Important You cannot undo this process. You cannot convert a Smart License to a Classic license, even if the license
was originally a Classic license.
Step 1 The conversion process you will follow depends on whether or not the license has been consumed:
• If the PAK that you want to convert has never been used, follow instructions for converting a PAK.
• If the PAK you want to convert has already been assigned to a device, follow instructions for converting a Classic
license.
Make sure your existing classic license is still registered to your device.
Step 2 See instructions for your type of conversion (PAK or installed Classic license) in the following documentation:
• To convert PAKs or licenses using the LRP:
• To view a video that steps you through the License Registration Portal part of the conversion process, click
https://salesconnect.cisco.com/#/content-detail/7da52358-0fc1-4d85-8920-14a1b7721780.
• Search for "Convert" in the following document: https://cisco.app.box.com/s/
mds3ab3fctk6pzonq5meukvcpjizt7wu.
There are three conversion procedures. Choose the conversion procedure applicable to your situation.
• Sign in to the License Registration Portal (LRP) at https://tools.cisco.com/SWIFT/LicensingUI/Home and
follow the instructions in the documentation above.
Step 4 If you will use Firepower Device Manager to manage this device as a standalone device:
See information about licensing the device in the Cisco Firepower Threat Defense Configuration Guide for Firepower
Device Manager at https://www.cisco.com/c/en/us/support/security/firepower-ngfw/
products-installation-and-configuration-guides-list.html.
Skip the rest of this procedure.
Step 5 If you have already deployed Smart Licensing on your Firepower Management Center:
a) Set up Smart Licensing on your new Firepower Threat Defense device.
See Assign Licenses to Multiple Managed Devices, on page 123.
b) Verify that the new Smart License has been successfully applied to the device.
See View FTD Licenses and License Status, on page 124.
Step 6 If you have not yet deployed Smart Licensing on your Firepower Management Center:
See How to License Firepower Threat Defense Devices, on page 92. (Skip any steps that do not apply or that you have
already completed.)
Note For container instances on the same security module/engine, you apply the license to each instance; note that
the security module/engine consumes only one license per feature for all instances on the security
module/engine.
Note For an FTD cluster, you apply the licenses to the cluster as a whole; note that each unit in the cluster consumes
a separate license per feature.
What to do next
• If you assigned Smart Licenses, verify license status:
Go to System > Licenses > Smart Licenses, enter the hostname or IP address of the device into the
filter at the top of the Smart Licenses table, and verify that only a green circle with a Check Mark ( )
appears for each device, for each license type. If you see any other icon, hover over the icon for more
information.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• If you are licensing Firepower Threat Defense devices and you applied a Base license with
export-controlled functionality enabled, reboot each device. For devices configured in a high-availability
pair, reboot both devices at the same time to avoid an Active-Active condition.
License Expiration
• License Expiration vs. Service Subscription Expiration
• Smart Licensing
• Specific License Reservation
• Classic Licensing
• Subscription Renewals
Smart Licensing
Q. Can a Product Instance Registration Token expire?
A. A token can expire if it is not used to register a product within the specified validity period. You set the
number of days that the token is valid when you create the token in the Cisco Smart Software Manager.
If the token expires before you use it to register a Firepower Management Center, you must create a new
token.
After you use the token to register a Firepower Management Center, the token expiration date is no longer
relevant. When the token expiration date elapses, there is no impact on the Firepower Management Center
that you used the token to register.
Token expiration dates do not affect subscription expiration dates.
For more information, see the Cisco Smart Software Manager User Guide.
Q. How can I tell if my Smart Licenses/service subscriptions are expired or about to expire?
A. To determine when a service subscription will expire (or when it expired), review your entitlements in
the Cisco Smart Software Manager.
On the Firepower Management Center, you can determine whether a service subscription for a feature
license is currently in compliance by choosing System > Licenses > Smart Licenses. On this page, a
table summarizes the Smart License entitlements associated with this Firepower Management Center
via its product registration token. You can determine whether the service subscription for the license is
currently in compliance based on the License Status field.
On Firepower Device Manager, use the Smart License page to view the current license status for the
system: Click Device, then click View Configuration in the Smart License summary.
In addition, the Cisco Smart Software Manager will send you a notification 3 months before a license
expires.
Q. What happens if my Smart License/subscription expires?
A. If a purchased service subscription expires, you can see in Firepower Management Center and in your
Smart Account that your account is out of compliance. Cisco notifies you that you must renew the
subscription; see Subscription Renewals. There is no other impact.
Classic Licensing
Q. How can I tell if my Classic licenses/service subscriptions are expired or about to expire?
A. On the Firepower Management Center, choose System > Licenses > Classic Licenses.
On this page, a table summarizes the Classic licenses you have added to this Firepower Management
Center.
You can determine whether the service subscription for the license is currently in compliance based on
the Status field.
You can determine when the service subscription will expire (or when it expired) by the date in the
Expires field.
You can also obtain this information by reviewing your license information in the Cisco Product License
Registration Portal.
Q. What does this mean: 'IPS Term Subscription is still required for IPS'?
A. This message merely informs you that Protect and Control functionality requires not only a right-to-use
license (which never expires), but also one or more associated service subscriptions, which must be
renewed periodically. If the service subscriptions you want to use are current and will not expire soon,
no action is required.
Q. What happens if my Classic license/subscription expires?
A. If a service subscription supporting a Classic license expires, Cisco notifies you that you must renew the
subscription; see Subscription Renewals.
You might not be able to use the related features, depending on the feature type:
Control TA, TAC, TAM, TAMC You can continue to use existing Firepower
functionality, but you cannot download VDB updates,
including application signature updates.
Protection TA, TAC, TAM, TAMC You can continue to perform intrusion inspection, but
you cannot download intrusion rule updates.
URL Filtering URL, TAC, TAMC • Access control rules with URL conditions
immediately stop filtering URLs.
• Other policies (such as SSL policies) that filter
traffic based on URL category and reputation
immediately stop doing so.
• The Firepower Management Center can no longer
download updates to URL data.
• You cannot re-deploy existing policies that perform
URL category and reputation filtering.
Malware AMP, TAM, TAMC • For a very brief time, the system can use existing
cached file dispositions. After the time window
expires, the system assigns a disposition of
Unavailable to those files.
Subscription Renewals
Q. How do I renew an expiring Classic license?
A. To renew an expiring Classic license, simply purchase a new PAK key and follow the same process as
for implementing a new subscription.
Q. Can I renew a Firepower service subscription from the Firepower Management Center?
A. No. To renew a Firepower service subscription (Classic or Smart), purchase a new subscription using
either the Cisco Commerce Workspace or the Cisco Service Contract Center.
Information about the interface for FMC About Device Management Interfaces, on page 251
communications with the Smart Licensing authority and subtopics
For See
An explanation of the licensing information in tables License Statements in the Documentation, on page
at the beginning of each procedure in this document. 16
Important licensing considerations when restoring Backup and Restore, on page 175
from a backup
Effects of licensing on the way rules and policies are Policy and rule information, including but not limited
applied and how they trigger. to:
• Access Control Rule Management, on page 1357
• Access Control Rule Components, on page 1358,
information about Conditions
• TLS/SSL Rule Guidelines and Limitations, on
page 1485
• TLS/SSL Rule Components, on page 1462
• Rate Limiting with QoS Policies, on page 706
Deployment and policy or rule management errors Policy and rule information throughout this guide,
related to Licensing including but not limited to:
• Rule and Other Policy Warnings, on page 436
• Rate Limiting with QoS Policies, on page 706
Licensing requirements for SSL Prerequisites in Configure SSL Settings , on page 1166
for Firepower Threat Defense
Licensing requirements for SSL preprocessor The SSL Preprocessor, on page 1920
functionality
Licensing for AMP for Endpoints integrations Comparison of Malware Protection: Firepower vs.
AMP for Endpoints, on page 1571
Licensing and stream reassembly on client and server TCP Stream Preprocessing Options, on page 1958
services
Licensing and Cisco Threat Intelligence Director Platform, Element, and License Requirements, on
(TID) page 1586
Licensing impacts on connection events Requirements for Populating Connection Event Fields,
on page 2462
Information about the Licensing and other dashboard Dashboard Widget Availability by User Role, on page
widgets 289
The Custom Analysis Widget, on page 292
Information about the Health Monitor for licensing. Information about the Smart License Monitor and the
Classic License Monitor in Health Modules, on page
309
The Firepower Management Center establishes and maintains the secure connection between the Firepower
Management Center and the Cisco cloud at all times, after you have enabled either Cisco Support Diagnostics
or Cisco Success Network. You can turn off this connection at any time by disabling both Cisco Success
Network and Cisco Support Diagnostics, which disconnects Firepower Management Center from the Cisco
cloud. However, when Cisco Support Diagnostics is enabled, a secure connection is established and maintained
between the Firepower Threat Defense and the Cisco cloud along with the Firepower Management Center
and Cisco cloud. Therefore, when the Cisco Support Diagnostics is disabled, both these secure connections
are turned off.
Note The Cisco Success Network feature is disabled if the Firepower Management Center has a valid Smart Software
Satellite Server configuration, or uses Specific License Reservation.
Deployment Information
After you configure your deployment, and any time you change that configuration, you must deploy the
changes to the affected devices. The following table describes the collected and monitored data about
configuration deployment, such as the number of devices affected and the status of deployments, including
success and failure information.
Status SUCCEEDED
Handshake Process
When the system detects a TLS/SSL handshake over a TCP connection, it determines whether it can decrypt
the detected traffic. As the system handles encrypted sessions, it logs details about the traffic.
Cache Data
After a TLS/SSL handshake completes, the managed device caches encrypted session data, which allows
session resumption without requiring the full handshake. The managed device also caches server certificate
data, which allows faster handshake processing in subsequent sessions.
Certificate Status
The system evaluates encrypted traffic and reports the certificate status of the encrypting server.
Failure Reason
The system evaluates encrypted traffic and reports the failure reason when the system fails to decrypt traffic.
Version
The system evaluates encrypted traffic and reports the negotiated TLS/SSL version per connection.
Count of snort restarts when you create or modify a An integer value of 0 or greater
custom application detector
{
"recordType" : "CST_FMC",
"recordVersion" : "6.4.0",
"recordedAt" : 1550467152050,
"fmc" : {
"deviceInfo" : {
"deviceModel" : "Cisco Firepower Management Center for VMWare",
"deviceName" : "firepower",
"deviceUuid" : "18842483-30cf-11e9-a090-503c97636361",
"serialNumber" : "None",
"smartLicenseProductInstanceIdentifier" : "cbs246a5-6d51-4eb7-9gc2-118b177dc4de",
"smartLicenseVirtualAccountName" : "FTD-ENG-BLR",
"systemUptime" : 262007000,
"udiProductIdentifier" : "FS-VMW-SW-K9"
},
"versions" : {
"items" : [ {
"lastUpdated" : 0,
"type" : "SOFTWARE",
"version" : "6.4.0-1335"
}, {
"lastUpdated" : 0,
"type" : "SNORT_RULES_DB",
"version" : "2018-10-10-001-vrt"
}, {
"lastUpdated" : 1550200610000,
"type" : "VULNERABILITY_DB",
"version" : "309"
}, {
"lastUpdated" : 0,
"type" : "GEOLOCATION_DB",
"version" : "None"
} ]
}
},
"managedDevices" : {
"items" : [ {
"deviceInfo" : {
"deviceManager" : "FMC",
"deviceModel" : "Cisco Firepower Threat Defense for VMWare",
"deviceName" : "10.10.17.220",
"deviceVersion" : "6.4.0-1335",
"serialNumber" : "9AUVT5GTRPA"
},
"malware" : {
"malwareLicenseUsed" : false,
"numberOfACRulesNeedMalwareLicense" : 10,
"numberOfACRulesWithMalware" : 20
},
"sslUsage" : {
"isSSLEnabled" : false
},
"threat" : {
"acPolicyHasIntrusion" : true,
"acRulesWithIntrusion" : 20,
"isTIDEnabled" : true,
"threatLicenseUsed" : true
},
"urlFiltering" : {
"acRulesWithURLFiltering" : 10,
"numberOfACRulesNeedThreatLicense" : 3,
"numberOfACRulesNeedURLLicense" : 3,
"urlFilteringLicenseUsed" : true
}
}, {
"deviceInfo" : {
"deviceManager" : "FMC",
"deviceModel" : "Cisco Firepower Threat Defense for VMWare",
"deviceName" : "10.10.17.221",
"deviceVersion" : "6.4.0-1335",
"serialNumber" : "9A0NMB3VAL7"
},
"malware" : {
"malwareLicenseUsed" : false,
"numberOfACRulesNeedMalwareLicense" : 0,
"numberOfACRulesWithMalware" : 0
},
"sslUsage" : {
"isSSLEnabled" : false
},
"threat" : {
"acPolicyHasIntrusion" : false,
"acRulesWithIntrusion" : 0,
"isTIDEnabled" : false,
"threatLicenseUsed" : false
},
"urlFiltering" : {
"acRulesWithURLFiltering" : 0,
"urlFilteringLicenseUsed" : false
}
}, {
"deviceInfo" : {
"deviceManager" : "FMC",
"deviceModel" : "Cisco Firepower Threat Defense for VMWare",
"deviceName" : "10.10.17.222",
"deviceVersion" : "6.4.0-1335",
"serialNumber" : "9ATSKTCFNXA"
},
"malware" : {
"malwareLicenseUsed" : true,
"numberOfACRulesNeedMalwareLicense" : 0,
"numberOfACRulesWithMalware" : 0
},
"sslUsage" : {
"isSSLEnabled" : false
},
"threat" : {
"acPolicyHasIntrusion" : false,
"acRulesWithIntrusion" : 0,
"isTIDEnabled" : false,
"threatLicenseUsed" : true
},
"urlFiltering" : {
"acRulesWithURLFiltering" : 0,
"urlFilteringLicenseUsed" : true
}
}, {
"deviceInfo" : {
"deviceManager" : "FMC",
"deviceModel" : "Cisco Firepower Threat Defense for VMWare",
"deviceName" : "10.10.17.223",
"deviceVersion" : "6.4.0-1335",
"serialNumber" : "9AP4B2J9BC1"
},
"malware" : {
"malwareLicenseUsed" : true,
"numberOfACRulesNeedMalwareLicense" : 0,
"numberOfACRulesWithMalware" : 0
},
"sslUsage" : {
"isSSLEnabled" : false
},
"threat" : {
"acPolicyHasIntrusion" : false,
"acRulesWithIntrusion" : 0,
"isTIDEnabled" : false,
"threatLicenseUsed" : true
},
"urlFiltering" : {
"acRulesWithURLFiltering" : 0,
"urlFilteringLicenseUsed" : true
}
} ]
},
"deploymentData" : {
"deployJobInfoList" : [ {
"jobDeviceList" : [ {
"containerType" : "STANDALONE",
"deployEndTime" : "1550466953538",
"deployStartTime" : "1550466890057",
"deployStatus" : "SUCCEEDED",
"deviceModel" : "Cisco Firepower Threat Defense for VMWare",
"deviceOSVersion" : "6.4.0",
"deviceUuid" : "8918db92-30de-11e9-a576-92cc6a3b249d",
"pgTypes" : "[PG.FIREWALL.NGFWAccessControlPolicy]",
"policyBundleSize" : 3588153
}, {
"containerType" : "STANDALONE",
"deployEndTime" : "1550466953634",
"deployStartTime" : "1550466890057",
"deployStatus" : "SUCCEEDED",
"deviceModel" : "Cisco Firepower Threat Defense for VMWare",
"deviceOSVersion" : "6.4.0",
"deviceUuid" : "87cf54e6-30de-11e9-8fdb-ce9d0fc91a42",
"pgTypes" : "[PG.FIREWALL.NGFWAccessControlPolicy]",
"policyBundleSize" : 3588172
}, {
"containerID" : "5f009744-30fe-11e9-8a70-cd88086eeac0",
"containerType" : "HAPAIR",
"deployEndTime" : "1550467052791",
"deployStartTime" : "1550466890057",
"deployStatus" : "SUCCEEDED",
"deviceModel" : "Cisco Firepower Threat Defense for VMWare",
"deviceOSVersion" : "6.4.0",
"deviceUuid" : "c8df3b96-30ce-11e9-b5e5-d6beeb6498f5",
"pgTypes" : "[PG.FIREWALL.NGFWAccessControlPolicy]",
"policyBundleSize" : 3588212
} ],
"jobId" : "12884903350",
"numberOfDevices" : 3,
"numberOfFailedDevices" : 0,
"numberOfSuccessDevices" : 3
} ],
"lastJobId" : "12884903350"
},
"cspa" : {
"cspaCount" : 0,
"queryCount" : 0,
"queryGroupCount" : 0
},
"analysis" : {
"crossLaunchInfo" : {
"count" : 28,
"enabledCount" : 28,
"iocInfo" : [ {
"domain" : 10,
"ip" : 9,
"sha256" : 9
} ]
}
},
"SSLStats" : {
"action" : {
"block" : 10,
"block_with_reset" : 4,
"decrypt_resign_self_signed" : 0,
"decrypt_resign_self_signed_replace_key_only" : 0,
"decrypt_resign_signed_cert" : 227,
"decrypt_with_known_key" : 0,
"do_not_decrypt" : 9094
},
"cache_status" : {
"cached_session" : 18693,
"cert_validation_cache_hit" : 0,
"cert_validation_cache_miss" : 10883,
"orig_cert_cache_hit" : 15720,
"orig_cert_cache_miss" : 0,
"resigned_cert_cache_hit" : 14,
"resigned_cert_cache_miss" : 4,
"session_cache_hit" : 4398,
"session_cache_miss" : 1922
},
"cert_status" : {
"cert_expired" : 155,
"cert_invalid_issuer" : 866,
"cert_invalid_signature" : 0,
"cert_not_checked" : 1594,
"cert_not_yet_valid" : 0,
"cert_revoked" : 0,
"cert_self_signed" : 362,
"cert_unknown" : 0,
"cert_valid" : 9659
},
"failure_reason" : {
"decryption_error" : 0,
"handshake_error_before_verdict" : 254,
"handshake_error_during_verdict" : 17,
"ssl_compression" : 0,
"uncached_session" : 984,
"undecryptable_in_passive_mode" : 0,
"unknown_cipher_suite" : 56,
"unsupported_cipher_suite" : 125
},
"version" : {
"ssl_v20" : 0,
"ssl_v30" : 0,
"ssl_version_unknown" : 10,
"tls_v10" : 32,
"tls_v11" : 8,
"tls_v12" : 11355,
"tls_v13" : 922
}
},
"snortRestart" : {
"appDetectorSnortRestartCnt" : 3,
"appSnortRestartCnt" : 1
}
}
What to do next
(Optional) See (Optional) Opt Out of Web Analytics Tracking, on page 1139.
What to do next
If you have enabled Cisco Support Diagnostics, verify the regional cloud setting at System > Integration >
Cloud Services > Cisco Cloud Region to establish where the system data is sent.
Licensing for multi-instance capability for 6.3 You can now deploy multiple FTD
the FTD on the Firepower 4100/9300 container instances on a Firepower
4100/9300. You only need a single license
per feature per security module/engine. The
base license is automatically assigned to
each instance.
New/Modified screens: System >
Licenses > Smart Licenses
Supported platforms: FTD on the Firepower
4100/9300
Specific License Reservation for air-gapped 6.3 Customers whose deployments cannot
deployments connect to the internet to communicate with
the Cisco License Authority can use a
Specific License Reservation. For details,
see: Specific License Reservation (SLR),
on page 111.
New/Modified screens: System >
Licenses > Specific Licenses (This option
is not available by default.)
Supported platforms: FMC, FTD
Enhanced instructions for deploying Smart 6.3 A new topic provides end-to-end guidance:
Licensing for Firepower Threat Defense How to License Firepower Threat Defense
devices Devices, on page 92. There is also new and
improved information in topics linked from
this topic.
Cisco Support Diagnostics for enabling 6.5 Cisco Support Diagnostics is a user-enabled
streaming of system health information to feature that allows the Firepower
Cisco cloud Management Center and the Firepower
Threat Defense to stream system health
related information to the Cisco cloud using
a secure connection. For details, see Cisco
Support Diagnostics, on page 155.
New/Modified screens: System >
Licenses > Smart Licenses
Supported platforms: FMC and FTD
Intrusion rules Provides new and updated intrusion rules and preprocessor rules, Cisco-provided:
(SRUs) modified states for existing rules, and modified default intrusion policy Global only
settings.
Local imports:
May also delete rules, provide new rule categories and default variables, Any
and modify default variable values.
Geolocation Updates information on physical locations, connection types, and so on, Global only
database that can be associated with detected routable IP addresses. You must
(GeoDB) install the GeoDB to view geolocation details or perform
geolocation-based access control.
Supported Domains
Global unless indicated otherwise.
User Roles
Admin
Important We strongly recommend you review scheduled updates to be sure they occur when you intend.
Bandwidth Guidelines
Updates can require large data transfers from the Firepower Management Center to managed devices. Before
you begin, make sure your management network has sufficient bandwidth to successfully perform the transfer.
See the Troubleshooting Tech Note at https://www.cisco.com/c/en/us/support/docs/security/
firepower-management-center/212043-Guidelines-for-Downloading-Data-from-the.html.
For details on how to prepare for and complete a successful upgrade of a Firepower Management Center
deployment, see Cisco Firepower Management Center Upgrade Guide.
If the Firepower Management Center cannot access the internet, or you want to manually upload the VDB
update to the Firepower Management Center, use this procedure. To automate VDB updates, use task scheduling
(System > Tools > Scheduling). For details, see Vulnerability Database Update Automation, on page 220.
Important If you do not schedule automatic VDB updates, you should regularly check for these updates. Updates occur
no more than once daily and are posted to the appropriate child pages of https://www.cisco.com/go/
firepower-software.
Caution If a warning appears when you select the Firepower Management Center to begin installing a vulnerability
database (VDB) update, you must deploy configurations after installing the VDB, and the deploy restarts the
Snort process. Additional warnings appear on the deploy dialog for pending deploys to Firepower Threat
Defense devices. Whether traffic drops or passes without further inspection during the deploy interruption
depends on how the targeted device handles traffic. See Snort® Restart Traffic Behavior, on page 390 for more
information. VDB updates that apply only to the Firepower Management Center do not cause restarts, and
you cannot deploy them.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Deploy configurations
Note Download the update directly from the Support Site, either manually or by clicking Download and install
geolocation update from the Support Site on the Geolocation Updates page. If you transfer an update file
by email, it may become corrupted.
Time needed to update the GeoDB depends on your appliance; the installation usually takes 30 to 40 minutes.
Although a GeoDB update does not interrupt any other system functions (including the ongoing collection of
geolocation information), the update does consume system resources while it completes. Consider this when
planning your updates.
The GeoDB update overrides any previous versions of the GeoDB and is effective immediately. When you
update the GeoDB, the Firepower Management Center automatically updates the related data on its managed
devices. It may take a few minutes for a GeoDB update to take effect throughout your deployment. You do
not need to re-deploy after you update.
Step 1 Manually download the update from the Cisco Support Site (http://www.cisco.com/cisco/web/support/index.html).
Step 2 Choose System > Updates.
Step 3 Click Geolocation Updates.
Step 4 Choose Upload and install geolocation update.
Step 5 Browse to the update you downloaded, and click Upload.
Step 6 Click Import.
Step 7 Optionally, monitor the task status; see Viewing Task Messages, on page 356.
Step 8 After the update finishes, return to the Geolocation Updates page or choose Help > About to confirm that the GeoDB
build number matches the update you installed.
In a multidomain deployment, you can import local intrusion rules in any domain, but you can import intrusion
rule updates from Talos in the Global domain only.
Note that importing a rule update discards all cached changes to network analysis and intrusion policies. For
your convenience, the Rule Updates page lists policies with cached changes and the users who made those
changes.
Step 1 Manually download the update from the Cisco Support Site (http://www.cisco.com/cisco/web/support/index.html).
Step 2 Choose System > Updates, then click Rule Updates.
Step 3 If you want to move all user-defined rules that you have created or imported to the deleted folder, you must click Delete
All Local Rules in the toolbar, then click OK.
Step 4 Choose Rule Update or text rule file to upload and install and click Browse to navigate to and choose the rule update
file.
Step 5 If you want to automatically re-deploy policies to your managed devices after the update completes, choose Reapply all
policies after the rule update import completes.
Step 6 Click Import. The system installs the rule update and displays the Rule Update Log detailed view.
Note Contact Support if you receive an error message while installing the rule update.
Step 6 If you want to automatically re-deploy the changed configuration to your managed devices after the update completes,
check the Deploy updated policies to targeted devices after rule update completes check box.
Step 7 Click Save.
Caution Contact Support if you receive an error message while installing the intrusion rule update.
The status message under the Recurring Rule Update Imports section heading changes to indicate that the rule update
has not yet run.
• When importing an updated version of a local rule you have previously imported, or when reinstating a
local rule you have deleted, you must include the SID assigned by the system and a revision number
greater than the current revision number. You can determine the revision number for a current or deleted
rule by editing the rule.
Note The system automatically increments the revision number when you delete a local
rule; this is a device that allows you to reinstate local rules. All deleted local rules
are moved from the local rule category to the deleted rule category.
• Import local rules on the primary Firepower Management Center in a high availability pair to avoid SID
numbering issues.
• The import fails if a rule contains any of the following: .
• A SID greater than 2147483647.
• A list of source or destination ports that is longer than 64 characters.
• When importing into the Global domain in a multidomain deployment, a GID:SID combination
uses GID 1 and a SID that already exists in another domain; this indicates that the combination
existed before Version 6.2.1. You can reimport the rule using GID 1 and a unique SID.
• Policy validation fails if you enable an imported local rule that uses the deprecated threshold keyword
in combination with the intrusion event thresholding feature in an intrusion policy.
• All imported local rules are automatically saved in the local rule category.
• The system always sets local rules that you import to the disabled rule state. You must manually set the
state of local rules before you can use them in your intrusion policy.
Use this procedure to import local intrusion rules. Imported intrusion rules appear in the local rule category
in a disabled state.
Step 3 Under One-Time Rule Update/Rules Import, choose Rule update or text rule file to upload and install, then click
Choose File and browse to your local rule file.
Step 4 Click Import.
Step 5 Monitor import progress in the Message Center.
To display the Message Center, click System Status on the menu bar. Even if the Message Center shows no progress for
several minutes or indicates that the import has failed, do not restart the import. Instead, contact Cisco TAC.
What to do next
• Edit intrusion policies and enable the rules you imported.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Field Description
Summary The name of the import file. If the import fails, a brief
statement of the reason for the failure appears under
the file name.
User ID The user name of the user that triggered the import.
Field Description
• Succeeded ( )
• failed or is currently in progress Red Status
( )
Tip You can view import details as they appear while an intrusion rule update import is in progress.
• View — To view details for each object imported in a rule update or local rule file, click View ( ) next to the file
you want to view; see Viewing Details of the Intrusion Rule Update Import Log, on page 173.
• Delete — To delete an import file record from the import log, including detailed records for all objects included
with the file, click Delete ( ) next to the import file name.
Note Deleting the file from the log does not delete any object imported in the import file, but only deletes the
import log records.
Tip You search the entire Rule Update Import Log database even when you initiate a search by clicking Search
on the toolbar from the Rule Update Import Log detailed view with only the records for a single import file
displayed. Make sure you set your time constraints to include all objects you want to include in the search.
Field Description
Action An indication that one of the following has occurred for the object type:
• new (for a rule, this is the first time the rule has been stored on this appliance)
• changed (for a rule update component or rule, the rule update component has been modified, or the rule
has a higher revision number and the same GID and SID)
• collision (for a rule update component or rule, import was skipped because its revision conflicts with
an existing component or rule on the appliance)
• deleted (for rules, the rule has been deleted from the rule update)
• enabled (for a rule update edit, a preprocessor, rule, or other feature has been enabled in a default policy
provided with the system)
• disabled (for rules, the rule has been disabled in a default policy provided with the system)
• drop (for rules, the rule has been set to Drop and Generate Events in a default policy provided with the
system)
• error (for a rule update or local rule file, the import failed)
• apply (the Reapply all policies after the rule update import completes option was enabled for the
import)
Default Action The default action defined by the rule update. When the imported object type is rule, the default action is
Pass, Alert, or Drop. For all other imported object types, there is no default action.
Details A string unique to the component or rule. For rules, the GID, SID, and previous revision number for a changed
rule, displayed as previously (GID:SID:Rev). This field is blank for a rule that has not changed.
Domain The domain whose intrusion policies can use the updated rule. Intrusion policies in descendant domains can
also use the rule. This field is only present in a multidomain deployment.
GID The generator ID for a rule. For example, 1 (standard text rule, Global domain or legacy GID) or 3 (shared
object rule).
Name The name of the imported object, which for rules corresponds to the rule Message field, and for rule update
components is the component name.
Policy For imported rules, this field displays All. This means that the rule was imported successfully, and can be
enabled in all appropriate default intrusion policies. For other types of imported objects, this field is blank.
Field Description
Type The type of imported object, which can be one of the following:
• rule update component (an imported component such as a rule pack or policy pack)
• rule (for rules, a new or updated rule; note that in Version 5.0.1 this value replaced the update value,
which is deprecated)
• policy apply (the Reapply all policies after the rule update import completes option was enabled
for the import)
Count The count (1) for each record. The Count field appears in a table view when the table is constrained, and the
Rule Update Log detailed view is constrained by default to rule update records. This field is not searchable.
Step 4 Click View ( ) next to the file whose detailed records you want to view.
Step 5 You can take any of the following actions:
• Bookmark—To bookmark the current page, click Bookmark This Page.
• Edit Search—To open a search page prepopulated with the current single constraint, choose Edit Search or Save
Search next to Search Constraints.
• Manage bookmarks—To navigate to the bookmark management page, click Report Designer.
• Report—To generate a report based on the data in the current view, click Report Designer.
• Search—To search the entire Rule Update Import Log database for rule update import records, click Search.
• Sort—To sort and constain records on the current workflow page, see Using Drill-Down Pages, on page 2377 for more
information.
• Switch workflows—To temporarily use a different workflow, click (switch workflows).
Automatically 6.6 For a new or newly-restored-to-factory-defaults FMC the Initial Configuration Wizard
scheduled updates automatically downloads and installs the latest vulnerability database (VDB) update from the
Cisco support site.
No modified screens
Supported platforms: FMC
Automatically 6.5 For a new or newly-restored-to-factory-defaults FMC the Initial Configuration Wizard
scheduled updates automatically schedules the following:
• a weekly task to download software updates for the FMC and its managed devices.
• weekly updates for the GeoDB.
No modified screens
Supported platforms: Any device
On-Demand Backups
You can perform on-demand backups for the FMC and many FTD devices from the FMC.
For more information, see Backing Up Firepower Appliances, on page 183.
Scheduled Backups
You can use the scheduler on an FMC to automate backups. You can also schedule remote device backups
from the FMC.
The FMC setup process schedules weekly configuration-only backups, to be stored locally. This is not a
substitute for full off-site backups—after initial setup finishes, you should review your scheduled tasks and
adjust them to fit your organization's needs.
For more information, see Scheduled Backups, on page 209.
For more information, see Remote Storage Management, on page 1106 and Manage Backups and Remote
Storage, on page 197.
What Is Restored?
Restoring configurations overwrites all backed-up configurations, with very few exceptions. On the FMC,
restoring events and TID data overwrites all existing events and TID data, with the exception of intrusion
events.
Make sure you understand and plan for the following:
• You cannot restore what is not backed up.
FMC configuration backups do not include remote storage and audit log server certificate settings, so
you must reconfigure these after restore. Also, because FMC event backups do not include intrusion
event review status, restored intrusion events do not appear on Reviewed Events pages.
• Restoring fails VPN certificates.
The FTD restore process removes VPN certificates from FTD devices, including certificates added after
the backup was taken. After you restore an FTD device, you must re-add/re-enroll all VPN certificates.
• Restoring to a configured FMC — instead of factory-fresh or reimaged — merges intrusion events and
file lists.
The FMC event restore process does not overwrite intrusion events. Instead, the intrusion events in the
backup are added to the database. To avoid duplicates, delete existing intrusion events before you restore.
The FMC configuration restore process does not overwrite clean and custom detection file lists used by
AMP for Networks. Instead, it merges existing file lists with the file lists in the backup. To replace file
lists, delete existing file lists before you restore.
If you need to replace a device where backup and restore is not supported, you must manually recreate
device-specific configurations. However, backing up the FMC does back up policies and other configurations
that you deploy to managed devices, as well as events already transmitted from the devices to the FMC.
Version Requirements
As the first step in any backup, note the patch level. To restore a backup, the old and the new appliance must
be running the same Firepower version, including patches.
Additionally, to restore Firepower software on a Firepower 4100/9300 chassis, the chassis must be running
a compatible FXOS version.
For FMC backups, you are not required to have the same VDB or SRU. Note, however, that restoring a backup
will replace existing VDB with the VDB in the backup file.
License Requirements
Address licensing or orphan entitlements concerns as described in the best practices and procedures. If you
notice licensing conflicts, contact Cisco TAC.
Domain Requirements
To:
• Back up or restore the FMC: Global only.
• Back up a device from the FMC: Global only.
• Restore a device: None. Restore devices locally.
In a multidomain deployment you cannot back up only events/TID data. You must also back up configurations.
can later import that configuration file to quickly apply the configuration settings to your Firepower 4100/9300
chassis to return to a known good configuration or to recover from a system failure.
When to Back Up
We recommend backing up during a maintenance window or other time of low use.
While the system collects backup data, there may be a temporary pause in data correlation (FMC only), and
you may be prevented from changing configurations related to the backup.
You should back up in the following situations:
• Regular scheduled backups.
As part of your disaster recovery plan, we recommend that you perform periodic backups.
The Version 6.5.0+ FMC setup process schedules weekly configuration-only backups, to be stored locally.
This is not a substitute for full off-site backups—after initial setup finishes, you should review your
scheduled tasks and adjust them to fit your organization's needs. For more information, see Scheduled
Backups, on page 209.
Caution We recommend you back up Firepower appliances to a secure remote location and verify transfer success.
Backups left on an appliance may be deleted, either manually or by the upgrade process, which purges locally
stored backups.
Especially because backup files are unencrypted, do not allow unauthorized access. If backup files are modified,
the restore process will fail. Keep in mind that anyone with the Admin/Maint role can access the Backup
Management page, where they can move and delete files from remote storage.
In the FMC's system configuration, you can mount an NFS, SMB, or SSHFS network volume as remote
storage. After you do this, all subsequent backups are copied to that volume, but you can still use the FMC
to manage them. For more information, see Remote Storage Management, on page 1106 and Manage Backups
and Remote Storage, on page 197.
Note that only the FMC mounts the network volume. Managed device backup files are routed through the
FMC. Make sure you have the bandwidth to perform a large data transfer between the FMC and its devices.
For more information, see Guidelines for Downloading Data from the Firepower Management Center to
Managed Devices (Troubleshooting TechNote).
Note that you can replace an FTD HA device without a successful backup; see Replace a Unit in an FTD High
Availability Pair, on page 734.
Before Backup
Before you back up, you should:
• Update the VDB and SRU on the FMC.
We always recommend you use the latest vulnerability database (VDB) and intrusion rules (SRU). Before
you back up an FMC, check the Cisco Support & Download site for newer versions.
• Check Disk Space.
Before you begin a backup, make sure you have enough disk space on the appliance or on your remote
storage server. The space available is displayed on the Backup Management page.
Backups can fail if there is not enough space. Especially if you schedule backups, make sure you regularly
prune backup files or allocate more disk space to the remote storage location.
Before Restore
Before restore, you should:
• Revert licensing changes.
Revert any licensing changes made since you took the backup.
Otherwise, you may have license conflicts or orphan entitlements after the restore. However, do not
unregister from Cisco Smart Software Manager (CSSM). If you unregister from CSSM, you must
unregister again after you restore, then re-register.
After the restore completes, reconfigure licensing. If you notice licensing conflicts or orphan entitlements,
contact Cisco TAC.
• Disconnect faulty appliances.
Disconnect the management interface, and for devices, the data interfaces.
Restoring an FTD device sets the management IP address of the replacement device to the management
IP address of the old device. To avoid IP conflicts, disconnect the old device from the management
network before you restore the backup on its replacement.
Note that restoring an FMC does not change the management IP address. You must set that manually on
the replacement — just make sure you disconnect the old appliance from the network before you do.
• Do not unregister managed devices.
Whether you are restoring an FMC or managed device, do not unregister devices from the FMC, even
if you physically disconnect an appliance from the network.
If you unregister, you will need to redo some device configurations, such as security zone to interface
mappings. After you restore, the FMC and devices should begin communicating normally.
• Reimage.
In an RMA scenario, the replacement appliance will arrive configured with factory defaults. However,
if the replacement appliance is already configured, we recommend you reimage. Reimaging returns most
settings to factory defaults, including the system password. You can only reimage to major versions, so
you may need to patch after you reimage.
If you do not reimage, keep in mind that FMC intrusion events and file lists are merged rather than
overwritten.
After Restore
After restore, you should:
• Reconfigure anything that was not restored.
This can include reconfiguring licensing, remote storage, and audit log server certificate settings. You
also must re-add/re-enroll failed FTD VPN certificates.
• Update the VDB and SRU on the FMC.
We always recommend you use the latest vulnerability database (VDB) and intrusion rules (SRU). This
is especially important for the VDB, because the VDB in the backup will overwrite the VDB on the
replacement FMC.
• Deploy.
After you restore an FMC, deploy to all managed devices. After you restore a device, deploy to that
device. You must deploy. If the a device or devices are not marked out of date, force deploy from the
Device Management page: Redeploy Existing Configurations to a Device, on page 387.
In a multidomain deployment, you must back up configurations. You cannot back up events or TID data only. For details
on what is and what is not backed up for each of these choices, see About Backup and Restore, on page 175.
Step 5 (Optional) Enable Copy when complete to copy completed FMC backups to a remote server.
Provide a hostname or IP address, the path to the remote directory, and a username and password. To use an SSH public
key instead of a password, copy the contents of the SSH Public Key field to the specified user's authorized_keys file
on the remote server.
Note This option is useful if you want to store backups locally and also SCP them to a remote location. If you
configured SSH remote storage, do not copy backup files to the same directory using Copy when complete.
Step 6 (Optional) Enable Email and enter an email address to be notified when the backup completes.
To receive email notifications, you must configure the FMC to connect to a mail server: Configuring a Mail Relay Host
and Notification Address, on page 1121.
What to do next
If you configured remote storage or enabled Copy when complete, verify transfer success of the backup file.
Backup and restore is not supported for any other platforms or configurations, including clustered devices
and container instances.
If you are backing up a Firepower 4100/9300 chassis, it is especially important that you also back up FXOS
configurations: Exporting an FXOS Configuration File, on page 185.
Step 1 Select System > Tools > Backup/Restore, then click Managed Device Backup.
Step 2 Select one or more Managed Devices.
Step 3 Note the Storage Location for device backup files.
This will either be local storage in /var/sf/remote-backup/, or a remote network volume. For more information,
see Manage Backups and Remote Storage, on page 197.
Step 4 If you did not configure remote storage, choose whether you want to Retrieve to Management Center.
• Enabled (default): Saves the backup to the FMC in /var/sf/remote-backup/.
• Disabled: Saves the backup to the device in /var/sf/backup.
If you configured remote backup storage, backup files are saved remotely and this option has no effect.
What to do next
If you configured remote storage, verify transfer success of the backup file.
Note This procedure explains how to use Firepower Chassis Manager to export FXOS configurations when you
back up Firepower Threat Defense. For the CLI procedure, see the appropriate version of the Cisco Firepower
4100/9300 FXOS CLI Configuration Guide.
Step 1 Choose System > Configuration > Export on the Firepower Chassis Manager.
Step 2 To export a configuration file to your local computer:
a) Click Local.
b) Click Export.
The configuration file is created and, depending on your browser, the file might be automatically downloaded to your
default download location or you might be prompted to save the file.
Step 3 To export the configuration file to a remote server:
a) Click Remote.
b) Choose the protocol to use when communicating with the remote server. This can be one of the following: FTP,
TFTP, SCP, or SFTP.
c) Enter the hostname or IP address of the location where the backup file should be stored. This can be a server, storage
array, local drive, or any read/write media that the Firepower 4100/9300 chassis can access through the network.
If you use a hostname rather than an IP address, you must configure a DNS server.
d) If you are using a non-default port, enter the port number in the Port field.
e) Enter the username the system should use to log in to the remote server. This field does not apply if the protocol is
TFTP.
f) Enter the password for the remote server username. This field does not apply if the protocol is TFTP.
g) In the Location field, enter the full path to where you want the configuration file exported including the filename.
h) Click Export.
The configuration file is created and exported to the specified location.
Step 1 Select System > Tools > Backup/Restore, then click Backup Profiles.
Step 2 Click Create Profile and enter a Name.
Step 3 Choose what to back up.
• Back Up Configuration
• Back Up Events
• Back Up Threat Intelligence Director
In a multidomain deployment, you must back up configurations. You cannot back up events or TID data only. For details
on what is and what is not backed up for each of these choices, see About Backup and Restore, on page 175.
Step 5 (Optional) Enable Copy when complete to copy completed FMC backups to a remote server.
Provide a hostname or IP address, the path to the remote directory, and a username and password. To use an SSH public
key instead of a password, copy the contents of the SSH Public Key field to the specified user's authorized_keys file
on the remote server.
Note This option is useful if you want to store backups locally and also SCP them to a remote location. If you
configured SSHFS remote storage, do not copy backup files to the same directory using Copy when complete.
Step 6 (Optional) Enable Email and enter an email address to be notified when the backup completes.
To receive email notifications, you must configure the FMC to connect to a mail server: Configuring a Mail Relay Host
and Notification Address, on page 1121.
Note Restoring configurations overwrites all configurations, with very few exceptions. It also reboots the FMC.
Restoring events and TID data overwrites all existing events and TID data, with the exception of intrusion
events. Make sure you are ready.
Use this procedure to restore an FMC from backup. For more information on backup and restore in an FMC
HA deployment, see Replacing FMCs in a High Availability Pair, on page 244.
Step 3 Select the backup file you want to restore and click Restore.
Step 4 Select from the available components to restore, then click Restore again to begin.
Step 5 Monitor progress in the Message Center.
If you are restoring configurations, you can log back in after the FMC reboots.
What to do next
• If necessary, reconfigure any licensing settings that you reverted before the restore. If you notice licensing
conflicts or orphan entitlements, contact Cisco TAC.
• If necessary, reconfigure remote storage and audit log server certificate settings. These settings are not
included in backups.
• (Optional) Update the SRU and VDB. If the SRU or the VDB available on the Cisco Support & Download
site is newer than the version currently running, we recommend you install the newer version.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note Do not unregister from the FMC, even when disconnecting a device from the network. In an FTD HA
deployment, do not suspend or break HA. Maintaining these links ensures replacement devices can automatically
reconnect after restore.
In an FTD HA deployment, you back up the pair as a unit but the backup process produces unique backup files. The
device's role is noted in the backup file name.
If the only copy of the backup is on the faulty device, copy it somewhere else now. If you reimage the device, the
backup will be erased. If something else goes wrong, you may not be able to recover the backup. For more information,
see Manage Backups and Remote Storage, on page 197.
The replacement device will need the backup, but can retrieve it with SCP during the restore process. We recommend
you put the backup somewhere SCP-accessible to the replacement device. Or, you can copy the backup to the replacement
device itself.
Step 4 Install the replacement device and connect it to the management network.
Connect the device to power and the management interface to the management network. In an FTD HA deployment,
connect the failover link. However, do not connect the data interfaces.
See the hardware installation guide for your model: Cisco Firepower NGFW: Install and Upgrade Guides.
Step 7 Make sure the replacement device is running the same Firepower software version, including patches, as the faulty
device.
Ensure that the existing device should not be deleted from the FMC. The replacement device should be unmanaged
from the physical network and the new hardware as well as the replacing FTD patch should have the same version.
The FTD CLI does not have an upgrade command. To patch:
a) From the FMC web interface, complete the device registration process: Add a Device to the FMC, on page 260.
Create a new AC policy and use the default action "Network Discovery". Leave this policy as is; do not add any
features or modifications. This is being used to register the device and deploy a policy with no features so that you
do not require licenses, and you will then be able to patch the device. Once backup is restored, it should restore the
licensing and policy into the expected state.
b) Patch the device: Cisco Firepower Management Center Upgrade Guide.
c) Unregister the freshly patched device from the FMC: Delete a Device from the FMC, on page 264.
If you do not unregister, you will have a ghost device registered to the FMC after the restore process brings your
"old" device back up.
Step 8 Make sure the replacement device has access to the backup file.
The restore process can retrieve the backup with SCP, so we recommend you put the backup somewhere accessible.
Or, you can manually copy the backup to the replacement device itself, to /var/sf/backup.
• With SCP: restore remote-manager-backup location scp-hostname username filepath backup tar-file
• From the local device: restore remote-manager-backup backup tar-file
In an FTD HA deployment, make sure you choose the appropriate backup file: primary vs secondary. The role is noted
in the backup file name. If you are restoring both devices in the HA pair, do this sequentially. Do not run the restore
command on the second device until the restore process completes for the first device, including the reboot.
Step 10 Log into the FMC and wait for the replacement device to connect.
When the restore is done, the device logs you out of the CLI, reboots, and automatically connects to the FMC. At this
time, the device should appear out of date.
Step 11 Before you deploy, perform any post-restore tasks and resolve any post-restore issues:
• Resolve licensing conflicts or orphan entitlements. Contact Cisco TAC.
• Resume HA synchronization. From the FTD CLI, enter configure high-availability resume. See Suspend
and Resume High Availability, on page 733.
• Re-add/re-enroll all VPN certificates. The restore process removes VPN certificates from FTD devices, including
certificates added after the backup was taken. See Managing FTD Certificates, on page 538.
What to do next
Verify that the restore succeeded and the replacement device is passing traffic as expected.
Note Do not unregister from the FMC, even when disconnecting a device from the network. Maintaining registration
ensures replacement devices can automatically reconnect after restore.
If the only copy of the backup is on the faulty device, copy it somewhere else now. If you reimage the device, the
backup will be erased. If something else goes wrong, you may not be able to recover the backup. For more information,
see Manage Backups and Remote Storage, on page 197.
The replacement device will need the backup, but can retrieve it with SCP during the restore process. We recommend
you put the backup somewhere SCP-accessible to the replacement device. Or, you can copy the backup to the replacement
device itself.
Step 5 Install the replacement device and connect it to the management network.
Connect the device to power and the management interface to the management network. However, do not connect the
data interfaces.
See the hardware installation guide for your model: Cisco Firepower NGFW: Install and Upgrade Guides.
See the instructions on restoring the factory default configuration in the appropriate Cisco Firepower 4100/9300 FXOS
Firepower Chassis Manager Configuration Guide.
Step 8 Use Firepower Chassis Manager to add logical devices and perform initial configurations.
Do not set the same management IP addresses as the logical device or devices on the faulty chassis. This can cause
problems if you need to register a logical device in order to patch it. The restore process will correctly reset the
management IP address.
See the FMC deployment chapter in the getting started guide for your model: Cisco Firepower NGFW: Install and
Upgrade Guides.
Note If you need to patch a logical device, register to the FMC as described in the getting started guide. If you do
not need to patch, do not register.
Step 9 Make sure the replacement device is running the same Firepower software version, including patches, as the faulty
device.
Ensure that the existing device should not be deleted from the FMC. The replacement device should be unmanaged
from the physical network and the new hardware as well as the replacing FTD patch should have the same version.
The FTD CLI does not have an upgrade command. To patch:
a) From the FMC web interface, complete the device registration process: Add a Device to the FMC, on page 260.
Create a new AC policy and use the default action "Network Discovery". Leave this policy as is; do not add any
features or modifications. This is being used to register the device and deploy a policy with no features so that you
do not require licenses, and you will then be able to patch the device. Once backup is restored, it should restore the
licensing and policy into the expected state.
b) Patch the device: Cisco Firepower Management Center Upgrade Guide.
c) Unregister the freshly patched device from the FMC: Delete a Device from the FMC, on page 264.
If you do not unregister, you will have a ghost device registered to the FMC after the restore process brings your
"old" device back up.
Step 10 Make sure the replacement device has access to the backup file.
The restore process can retrieve the backup with SCP, so we recommend you put the backup somewhere accessible.
Or, you can manually copy the backup to the replacement device itself, to /var/sf/backup.
Step 12 Log into the FMC and wait for the replacement device to connect.
When the restore is done, the device logs you out of the CLI, reboots, and automatically connects to the FMC. At this
time, the device should appear out of date.
Step 13 Before you deploy, perform any post-restore tasks and resolve any post-restore issues:
• Resolve licensing conflicts or orphan entitlements. Contact Cisco TAC.
• Re-add/re-enroll all VPN certificates. The restore process removes VPN certificates from FTD devices, including
certificates added after the backup was taken. See Managing FTD Certificates, on page 538.
What to do next
Verify that the restore succeeded and the replacement device is passing traffic as expected.
Note This procedure explains how to use Firepower Chassis Manager to import FXOS configurations before you
restore the Firepower software. For the CLI procedure, see the appropriate version of the Cisco Firepower
4100/9300 FXOS CLI Configuration Guide.
Step 1 Choose System > Tools > Import/Export on the Firepower Chassis Manager.
Step 2 To import from a local configuration file:
a) Click Local.
b) Click Choose File to navigate to and select the configuration file that you want to import.
c) Click Import.
A confirmation dialog box opens asking you to confirm that you want to proceed and warning you that the chassis
might need to restart.
d) Click Yes to confirm that you want to import the specified configuration file.
The existing configuration is deleted and the configuration specified in the import file is applied to the Firepower
4100/9300 chassis. If there is a breakout port configuration change during the import, the Firepower 4100/9300
chassis will need to restart.
Note Do not unregister from the FMC, even when disconnecting a device from the network. Maintaining registration
ensures replacement devices can automatically reconnect after restore.
If the only copy of the backup is on the faulty device, copy it somewhere else now. If you reimage the device, the
backup will be erased. If something else goes wrong, you may not be able to recover the backup. For more information,
see Manage Backups and Remote Storage, on page 197.
The replacement device will need the backup, but can retrieve it with SCP during the restore process. We recommend
you put the backup somewhere SCP-accessible to the replacement device. Or, you can copy the backup to the replacement
device itself.
Step 5 Make sure the replacement device is running the same Firepower software version, including patches, as the faulty
device.
Ensure that the existing device should not be deleted from the FMC. The replacement device should be unmanaged
from the physical network and the new hardware as well as the replacing FTD patch should have the same version.
The FTD CLI does not have an upgrade command. To patch:
a) From the FMC web interface, complete the device registration process: Add a Device to the FMC, on page 260.
Create a new AC policy and use the default action "Network Discovery". Leave this policy as is; do not add any
features or modifications. This is being used to register the device and deploy a policy with no features so that you
do not require licenses, and you will then be able to patch the device. Once backup is restored, it should restore the
licensing and policy into the expected state.
b) Patch the device: Cisco Firepower Management Center Upgrade Guide.
c) Unregister the freshly patched device from the FMC: Delete a Device from the FMC, on page 264.
If you do not unregister, you will have a ghost device registered to the FMC after the restore process brings your
"old" device back up.
Step 6 Make sure the replacement device has access to the backup file.
The restore process can retrieve the backup with SCP, so we recommend you put the backup somewhere accessible.
Or, you can manually copy the backup to the replacement device itself, to /var/sf/backup.
Access the FTD CLI as the admin user. You can use the console or you can SSH to the newly configured management
interface (IP address or hostname). Keep in mind that the restore process will change this IP address.
To restore:
• With SCP: restore remote-manager-backup location scp-hostname username filepath backup tar-file
• From the local device: restore remote-manager-backup backup tar-file
Step 8 Log into the FMC and wait for the replacement device to connect.
When the restore is done, the device logs you out of the CLI, reboots, and automatically connects to the FMC. At this
time, the device should appear out of date.
Step 9 Before you deploy, perform any post-restore tasks and resolve any post-restore issues:
• Resolve licensing conflicts or orphan entitlements. Contact Cisco TAC.
• Re-add/re-enroll all VPN certificates. The restore process removes VPN certificates from FTD devices, including
certificates added after the backup was taken. See Managing FTD Certificates, on page 538.
What to do next
Verify that the restore succeeded and the replacement device is passing traffic as expected.
We recommend you back up Firepower appliances to a secure remote location and verify transfer success.
Backups left on an appliance may be deleted, either manually or by the upgrade process; upgrades purge
locally stored backups. For more information on your options, see Backup Storage Locations, on page 199.
Caution Especially because backup files are unencrypted, do not allow unauthorized access. If backup files are modified,
the restore process will fail. Keep in mind that anyone with the Admin/Maint role can access the Backup
Management page, where they can move and delete files from remote storage.
To Do This
Enable or disable remote storage for Click Enable Remote Storage for Backups.
backups without having to edit the
This option appears only after you configure remote storage. Toggling it here
FMC system configuration.
also toggles it in the system configuration (System > Configuration > Remote
Storage Device).
Tip To quickly access your remote storage configuration, click Remote
Storage at the upper right of the Backup Management page.
Upload a backup file from your Click Upload Backup, choose a backup file, and click Upload Backup again.
computer.
Download a backup to your computer. Choose a backup file and click Download.
Unlike moving a backup file, this does not delete the backup from the FMC.
Location Details
Remote, by mounting a In the FMC's system configuration, you can mount an NFS, SMB, or SSHFS
network volume (NFS, SMB, network volume as remote storage for FMC and device backups; see Remote
SSHFS). Storage Management, on page 1106.)
After you do this, all subsequent FMC backups and FMC-initiated device
backups are copied to that volume, but you can still use the FMC to manage
them (restore, download, upload, delete, move).
Note that only the FMC mounts the network volume. Managed device backup
files are routed through the FMC. Make sure you have the bandwidth to
perform a large data transfer between the FMC and its devices. For more
information, see Guidelines for Downloading Data from the Firepower
Management Center to Managed Devices (Troubleshooting TechNote).
Remote, by copying (SCP). For the FMC, you can use a Copy when complete option to securely copy
(SCP) completed backups to a remote server.
Compared with remote storage by mounting a network volume, Copy when
complete cannot copy to NFS or SMB volumes. You cannot provide CLI
options or set a disk space threshold, and it does not affect remote storage of
reports. You also cannot manage backup files after they are copied out.
This option is useful if you want to store backups locally and SCP them to a
remote location.
Note If you configure SSHFS remote storage in the FMC system
configuration, do not copy backup files to the same directory using
Copy when complete.
Local, on the FMC. If you do not configure remote storage by mounting a network volume, you
can save backup files on the FMC:
• FMC backups are saved to /var/sf/backup.
• Device backups are saved to /var/sf/remote-backup on the FMC
if you enable the Retrieve to Management Center option when you
perform the backup.
Local, on the device. Device backup files are saved to /var/sf/backup on the device if you:
• Do not configure remote storage by mounting a network volume.
• Do not enable Retrieve to Management Center.
Automatically 6.5 For new or reimaged FMCs, the setup process creates a weekly scheduled
scheduled backups task to back up FMC configurations and store them locally.
Supported platforms: FMC
On-demand remote 6.3 You can now use the FMC to perform on-demand remote backups of
backups of managed certain managed devices.
devices
New/modified screens: System > Tools > Backup/Restore > Managed
Device Backup
New/modified FTD CLI commands: restore
Supported platforms: FTD physical platforms, FTDv for VMware
Exceptions: No support for FTD clustered devices or container instances
Note The importing and exporting appliances must be running the same version of the Firepower System. For
access control and its subpolicies (including intrusion policies), the intrusion rule update version must also
match. If the versions do not match, the import fails. You cannot use the Import/Export feature to update
intrusion rules. Instead, download and apply the latest rule update version.
• FlexConfig policies. However, the contents of any secret key variables are cleared when you export the
policy. You must manually edit the values of all secret keys after importing a FlexConfig policy that
uses secret keys.
• Platform settings
• Health policies
• Alert responses
• Application detectors (both user-defined and those provided by Cisco Professional Services)
• Dashboards
• Custom tables
• Custom workflows
• Saved searches
• Custom user roles
• Report templates
• Third-party product and vulnerability mappings
• Custom user objects—If you have created custom user groups or objects in your Firepower Management
Center and if such a custom user object is a part of any rule in your access control policy, note that the
export file (.sfo) does not carry the user object information and therefore while importing such a policy,
any reference to such custom user objects will be removed and will not be imported to the destination
Firepower Management Center. To avoid detection issues due to the missing user group, add the
customized user objects manually to the new Firepower Management Center and re-configure the access
control policy after import.
RequirementsandPrerequisitesforConfigurationImport/Export
Model Support
Any
Supported Domains
Any
User Roles
• Admin
Exporting Configurations
Depending on the number of configurations being exported and the number of objects those configurations
reference, the export process may take several minutes.
Tip
Many list pages in the Firepower System include an YouTube EDU ( ) next to list items. Where this icon
is present, you can use it as a quick alternative to the export procedure that follows.
Step 2 Click Collapse ( ) and Expand ( ) to collapse and expand the list of available configurations.
Step 3 Check the configurations you want to export and click Export.
Step 4 Follow your web browser’s prompts to save the exported package to your computer.
Importing Configurations
Depending on the number of configurations being imported and the number of objects those configurations
reference, the import process may take several minutes.
Note If you log out of the system, if you change to a different domain, or if your user session times out after you
click Import, the import process continues in the background until it is complete.
Step 1 On the importing appliance, choose System > Tools > Import/Export.
Step 2 Click Upload Package.
Step 3 Enter the path to the exported package or browse to its location, then click Upload.
Step 4 If there are no version mismatches or other issues, choose the configurations you want to import, then click Import.
If you do not need to perform any conflict resolution or interface object mapping, the import completes and a success
message appears. Skip the rest of this procedure.
Step 5 If prompted, on the Import Conflict Resolution page, map interface objects used in the imported configurations to zones
and groups with matching interface types managed by the importing Firepower Management Center.
Interface object type (security zone or interface group) and interface type (passive, inline, routed, and so on) of source
and destination objects must match. For information, see Interface Objects: Interface Groups and Security Zones, on
page 456.
If the configurations you are importing reference security zones or interface groups that do not already exist, you can
map them to existing interface objects, or create new ones.
Step 7 If prompted, on the Import Resolution page, expand each configuration and choose the appropriate option as described
in Import Conflict Resolution, on page 205.
Step 8 Click Import.
Step 9 Update all feeds.
For example, go to Objects > Object Management > Security Intelligence and click the Update Feed button on the
URL, Network, and DNS Lists and Feeds pages.
Imported policies do not include feed contents.
Step 10 Wait for all feed updates to complete before deploying the policies to devices.
What to do next
• Optionally, view a report summarizing the imported configurations; see Viewing Task Messages, on
page 356.
The resolution options the system offers depends on whether your deployment uses domains, and whether
the imported configuration is a duplicate of a configuration defined in the current domain, or a configuration
defined in an ancestor or descendant of the current domain. The following table lists when the system does
or does not present a resolution option.
When you import an access control policy with a file policy that uses clean or custom detection file lists and
a file list presents a duplicate name conflict, the system offers conflict resolution options as described in the
table above, but the action the system performs on the policies and file lists varies as described in the table
below:
Access control policy and its Existing access control policy and its
associated file policy are associated file policy and file lists remain
imported as new and the file unchanged
lists are merged
If you modify an imported configuration on an appliance, and later re-import that configuration to the same
appliance, you must choose which version of the configuration to keep.
Important Keep the following best practices in mind when considering the tasks to schedule for your system:
• As a part of initial configuration the FMC schedules a weekly task to download the latest software for
the FMC and its managed devices. You can observe the status of this task using the web interface Message
Center. If the task scheduling fails and your FMC has internet access, we recommend you schedule a
recurring task for downloading software updates as described in Automating Software Downloads, on
page 218. This task only downloads software updates to the FMC. It is your responsibility to install any
updates this task downloads. See the Cisco Firepower Management Center Upgrade Guide for more
information.
• As a part of initial configuration the FMC schedules a weekly task to perform a locally-stored
configuration-only backup. You can observe the status of this task using the web interface Message
Center. If the task scheduling fails we recommend you schedule a recurring task to perform a backup as
described in Schedule FMC Backups, on page 209.
• As a part of initial configuration the FMC downloads and installs the latest vulnerability database (VDB)
update from the Cisco support site. This is a one-time operation. You can observe the status of this update
using the web interface Message Center. To keep your system up to date, if your FMC has internet access,
we recommend you schedule tasks to perform automatic recurring VDB update downloads and installations
as described in Vulnerability Database Update Automation, on page 220.
Tasks configured using this feature are scheduled in UTC, which means when they occur locally depends on
the date and your specific location. Also, because tasks are scheduled in UTC, they do not adjust for Daylight
Saving Time, summer time, or any such seasonal adjustments that you may observe in your location. If you
are affected, scheduled tasks occur one hour "later" in the summer than in the winter, according to local time.
Important We strongly recommend you review scheduled tasks to be sure they occur when you intend.
Note Some tasks (such as those involving automated software updates or that require pushing updates to managed
devices) may place a significant load on networks with low bandwidths. You should schedule tasks like these
to run during periods of low network use.
Supported Domains
Any
User Roles
• Admin
• Maintenace User
Step 5 In the Start On field, specify the date when you want to start your recurring task.
Step 6 In the Repeat Every field, specify how often you want the task to recur.
You can either type a number or click Up ( ) and Down ( ) to specify the interval. For example, type 2 and click
Days to run the task every two days.
Step 7 In the Run At field, specify the time when you want to start your recurring task.
Step 8 For a task to be run on a weekly or monthly basis, select the days when you want to run the task in the Repeat On
field.
Step 9 Select the remaining options for the type of task you are creating:
• Backup - Schedule backup jobs as described in Schedule FMC Backups, on page 209.
• Download CRL - Schedule certificate revocation list downloads as described in Configuring Certificate Revocation
List Downloads, on page 211.
• Deploy Policies - Schedule policy deployment as described in Automating Policy Deployment, on page 212.
• Nmap Scan - Schedule Nmap scans as described in Scheduling an Nmap Scan, on page 213.
• Report - Schedule report generation as described in Automating Report Generation, on page 214
• Firepower Recommended Rules - Schedule automatic update of Firepower recommended rules as described in
Automating Firepower Recommendations, on page 216
• Download Latest Update - Schedule software or VDB update downloads as described in Automating Software
Downloads, on page 218 or Automating VDB Update Downloads, on page 220.
• Install Latest Update - Schedule installation of software or VDB updates on a Firepower Management Center or
managed device as described in Automating Software Installs, on page 219 or Automating VDB Update Installs,
on page 221
• Push Latest Update - Schedule push of software updates to managed devices as described in Automating Software
Pushes, on page 218.
• Update URL Filtering Database - Scheduling automatic update of URL filtering data as described in Automating
URL Filtering Updates Using a Scheduled Task, on page 222
Scheduled Backups
You can use the scheduler on a Firepower Management Center to automate its own backups. You can also
schedule remote device backups from the FMC. For more information on backups, see Backup and Restore,
on page 175.
Note that not all devices support remote backups.
Note As a part of initial configuration the FMC schedules a weekly task to perform a locally-stored configuration-only
backup. You can observe the status of this task using the web interface Message Center. If the task scheduling
fails we recommend you schedule a recurring task to perform a backup as described in this topic.
Step 8 (Optional) Enter an email address, or a comma-separated list of email addresses, in the Email Status To: field.
For information on setting up an email relay server to send task status messages, see Configuring a Mail Relay Host and
Notification Address, on page 1121.
Step 7 If you did not configure remote storage for backups, choose whether you want to Retrieve to Management Center.
• Enabled (default): Saves the backup to the FMC in /var/sf/remote-backup/.
• Disabled: Saves the backup to the device in /var/sf/backup/.
If you configured remote backup storage, backup files are saved remotely and this option has no effect. For more
information, see Manage Backups and Remote Storage, on page 197.
Step 9 (Optional) Enter an email address, or a comma-separated list of email addresses, in the Email Status To: field.
For information on setting up an email relay server to send task status messages, see Configuring a Mail Relay Host
and Notification Address, on page 1121.
Step 7 If you want to email task status messages, type an email address (or multiple email addresses separated by commas) in
the Email Status To: field. You must have a valid email relay server configured on the Firepower Management Center
to send status messages.
Step 8 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on how the target
device handles traffic. See Snort® Restart Traffic Behavior, on page 390 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 391.
Step 8 If you want to comment on the task, type a comment in the Comment field.
The comment field displays in the Tasks Details section of the schedule calendar page; keep comments brief.
Step 9 If you want to email task status messages, type an email address (or multiple email addresses separated by commas)
in the Email Status To: field. You must have a valid email relay server configured to send status messages.
Step 10 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
Out-of-Date Policies, on page 395
• For recurring tasks, see Configuring a Recurring Task, on page 208 for details.
Step 10 If you want to email task status messages, type an email address (or multiple email addresses separated by commas)
in the Email Status To: field. You must have a valid email relay server configured to send status messages.
Step 11 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by commas)
in the Email Status To: field. You must have a valid email relay server configured to send status messages.
Note Configuring this option does not distribute the reports.
Step 9 If you do not want to receive report email attachments when reports have no data (for example, when no events of a
certain type occurred during the report period), select the If report is empty, still attach to email check box.
Step 10 Click Save.
Note If the system automatically generates scheduled recommendations for an intrusion policy with unsaved changes,
you must discard your changes in that policy and commit the policy if you want the policy to reflect the
automatically generated recommendations.
When the task runs, the system automatically generates recommended rule states, and modifies the states of
intrusion rules based on the configuration of your policy. Modified rule states take effect the next time you
deploy your intrusion policy.
In a multidomain deployment, you can automate recommendations for intrusion policies at the current domain
level. The system builds a separate network map for each leaf domain. In a multidomain deployment, if you
enable this feature in an intrusion policy in an ancestor domain, the system generates recommendations using
data from all descendant leaf domains. This can enable intrusion rules tailored to assets that may not exist in
all leaf domains, which can affect performance.
Step 8 (Optional) To email task status messages, type an email address (or multiple email addresses separated by commas) in
the Email Status To: field.
Step 9 Click Save.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1643
About Firepower Recommended Rules, on page 1695
Configuring a Mail Relay Host and Notification Address, on page 1121
Important As a part of initial configuration the FMC schedules a weekly task to download the latest software for the
FMC and its managed devices. You can observe the status of this task using the web interface Message Center.
If the task scheduling fails and your FMC has internet access, we recommend you schedule a recurring task
for downloading software updates as described in Automating Software Downloads, on page 218. This task
only downloads software updates to the FMC. It is your responsibility to install any updates this task downloads.
See the Cisco Firepower Management Center Upgrade Guide for more information.
The tasks you must schedule to install software updates vary depending on whether you are updating the FMC
or are using a FMC to update managed devices.
Note Cisco strongly recommends that you use your FMCs to update the devices they manage.
• To update the FMC, schedule the software installation using the Install Latest Update task.
• To use a FMC to automate software updates for its managed devices, you must schedule two tasks:
• Push (copy) the update to managed devices using the Push Latest Update task.
• Install the update on managed devices using the Install Latest Update task.
When scheduling updates to managed devices, schedule the push and install tasks to happen in succession;
you must first push the update to the device before you can install it. To automate software updates on
a device group, you must select all the devices within the group. Allow enough time between tasks for
the process to complete; schedule tasks at least 30 minutes apart. If you schedule a task to install an
update and the update has not finished copying from the FMC to the device, the installation task will not
succeed. However, if the scheduled installation task repeats daily, it will install the pushed update when
it runs the next day.
Note You must manually upload and install updates in two situations. First, you cannot schedule major updates to
the Firepower System. Second, you cannot schedule updates for or pushes from FMC that cannot access the
Support Site. If your FMC is not directly connected to the Internet, you should use management interfaces
configuration to set up a proxy to allow it to download updates from the Support Site.
Note that a task scheduled to install an update on a device group will install the pushed update to each device
within the device group simultaneously. Allow enough time for the scheduled task to complete for each device
within the device group.
If you want to have more control over this process, you can use the Once option to download and install
updates during off-peak hours after you learn that an update has been released.
Related Topics
Management Interfaces, on page 1097
About Firepower Updates, on page 159
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by commas) in
the Email Status To: field. You must have a valid email relay server configured to send status messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
• For one-time tasks, use the drop-down lists to specify the start date and time.
• For recurring tasks, see Configuring a Recurring Task, on page 208 for details.
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by commas) in
the Email Status To: field. You must have a valid email relay server configured to send status messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
Caution Depending on the update being installed, the appliance may reboot after the software is installed.
Step 9 If you want to email task status messages, type an email address (or multiple email addresses separated by commas)
in the Email Status To: field. You must have a valid email relay server configured to send status messages.
Step 10 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
As a part of initial configuration the FMC downloads and installs the latest vulnerability database (VDB)
update from the Cisco support site. This is a one-time operation. You can observe the status of this update
using the web interface Message Center. To keep your system up to date, if your FMC has internet access,
we recommend you schedule tasks to perform automatic recurring VDB update downloads and installations
as described in this section.
Caution When a VDB update includes changes applicable to managed devices, the first manual or scheduled deploy
after installing the VDB restarts the Snort process, interrupting traffic inspection. Deploy dialog messages
warn you of restarts in pending deploys to Firepower Threat Defense devices. Whether traffic drops or passes
without further inspection during this interruption depends on how the targeted device handles traffic. You
cannot deploy VDB updates that apply only to the Firepower Management Center, and they do not cause
restarts. See Snort® Restart Traffic Behavior, on page 390 for more information.
Allow enough time between tasks for the process to complete. For example, if you schedule a task to install
an update and the update has not fully downloaded, the installation task will not succeed. However, if the
scheduled installation task repeats daily, it will install the downloaded VDB update when the task runs the
next day.
Note:
• You cannot schedule updates for appliances that cannot access the Support Site. If your FMC is not
directly connected to the Internet, you should use management interfaces configuration to set up a proxy
to allow it to download updates from the Support Site.
• If you want to have more control over this process, you can use the Once option to download and install
VDB updates during off-peak hours after you learn that an update has been released.
• In multidomain deployments, you can only schedule VDB updates for the Global domain. The changes
take effect when you redeploy policies.
Related Topics
Management Interfaces, on page 1097
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by commas) in
the Email Status To: field. You must have a valid email relay server configured to send status messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
Caution When a VDB update includes changes applicable to managed devices, the first manual or scheduled deploy
after installing the VDB restarts the Snort process, interrupting traffic inspection. Deploy dialog messages
warn you of restarts in pending deploys to Firepower Threat Defense devices. Whether traffic drops or passes
without further inspection during this interruption depends on how the targeted device handles traffic. You
cannot deploy VDB updates that apply only to the Firepower Management Center, and they do not cause
restarts. See Snort® Restart Traffic Behavior, on page 390 for more information.
Step 7 Next to Update Items, check the Vulnerability Database check box.
Step 8 If you want to comment on the task, type a comment in the Comment field.
Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.
Step 9 If you want to email task status messages, type an email address (or multiple email addresses separated by commas)
in the Email Status To: field. You must have a valid email relay server configured to send status messages.
Step 10 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
Step 7 If you want to email task status messages, type an email address (or multiple email addresses separated by commas) in
the Email Status To: field. You must have a valid email relay server configured to send status messages.
Step 8 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1121
Column Description
Last Run Time Displays the actual start date and time.
For a recurring task, this applies to the most recent
execution.
Column Description
Last Run Status Describes the current status for a scheduled task:
Next Run Time Displays the next execution time for a recurring task.
Displays N/A for a one-time task.
Step 3 In the Task Details table, click Delete ( ), then confirm your choice.
No modified screens
Supported platforms: FMC
General information about data storage on the FMC The Disk Usage Widget, on page 296
Purging old data Purging Data from the FMC Database, on page 228
Allowing external access to the data on the FMC (this External Database Access Settings, on page 1094
is an advanced feature)
Caution Purging a database removes the data you specify from the Firepower Management Center. After the data is
deleted, it cannot be recovered.
Note Checking the Connection Events check box does not remove Security Intelligence events. Connections with
Security Intelligence data will still appear in the Security Intelligence event page (available under the Analysis
> Connections menu). Correspondingly, checking the Security Intelligence Events check box does not remove
connection events with associated Security Intelligence data.
For See
Remote data storage in the Stealthwatch 6.4 Use syslog to send select Firepower data
Cloud using Cisco Security Analytics and Logging
(SaaS). Supported events: Connection,
Security Intelligence, intrusion, file, and
malware.
For details, see the Firepower Management
Center and Cisco Security Analytics and
Logging (SaaS) Integration Guide at
https://cisco.com/go/
firepower-sal-saas-integration-docs.
Caution Because the system restricts some functionality to the active Firepower Management Center, if that appliance
fails, you must promote the standby Firepower Management Center to active.
Hardware Requirements
• The two Firepower Management Centers in a high availability configuration must be the same model.
• The primary Firepower Management Center backup must not be restored to the secondary Firepower
Management Center.
• Bandwidth Requirements: There must be atleast a 5Mbps network bandwidth between two Firepower
Management Centers to setup a high availability configuration between them.
• The two Firepower Management Centers in a high availability configuration may be physically and
geographically separated from each other in different data centers.
Software Requirements
Access the Appliance Information widget to verify the software version, the intrusion rule update version
and the vulnerability database update. By default, the widget appears on the Status tab of the Detailed
Dashboard and theSummary Dashboard. For more information, see The Appliance Information Widget,
on page 290
• The two Firepower Management Centers in a high availability configuration must have the same major
(first number), minor (second number), and maintenance (third number) software version.
• The two Firepower Management Centers in a high availability configuration must have the same version
of the intrusion rule update installed.
• The two Firepower Management Centers in a high availability configuration must have the same version
of the vulnerability database update installed.
• The two Firepower Management Centers in a high availability configuration must have the same version
of the LSP (Lightweight Security Package) installed.
Warning If the software versions, intrusion rule update versions and vulnerability database update versions are not
identical on both Firepower Management Centers, you cannot establish high availability.
License Requirements
Smart Licensing
Example: If you want to enable advanced malware protection for two Firepower Threat Defense devices
managed by a Firepower Management Center pair, buy two Malware licenses and two TM subscriptions,
register the active Firepower Management Center with the Cisco Smart Software Manager, then assign the
licenses to the two Firepower Threat Defense devices on the active Firepower Management Center.
Only the active Firepower Management Center is registered with Cisco Smart Software Manager. When
failover occurs, the system communicates with Cisco Smart Software Manager to release the Smart License
entitlements from the originally-active Firepower Management Center and assign them to the newly-active
Firepower Management Center.
Classic Licensing
Example: If you want to enable advanced malware protection for two devices managed by a Firepower
Management Center pair, buy two Malware licenses and two TAM subscriptions, add those licenses to the
Firepower Management Center, then assign the licenses to the two devices on the active Firepower Management
Center.
Active/Standby Status
The main differences between the two Firepower Management Centers in a high availability pair are related
to which peer is active and which peer is standby. The active Firepower Management Center remains fully
functional, where you can manage devices and policies. On the standby Firepower Management Center,
functionality is hidden; you cannot make any configuration changes.
Supported Domains
Global
User Roles
Admin
You can now proceed to establish high availability. For more information, see Establishing Firepower
Management Center High Availability, on page 238.
ConfigurationManagementonFirepowerManagementCenterHighAvailability
Pairs
In a high availability deployment, only the active Firepower Management Center can manage devices and
apply policies. Both Firepower Management Centers remain in a state of continuous synchronization.
If the active Firepower Management Center fails, the high availability pair enters a degraded state until you
manually promote the standby appliance to the active state. Once the promotion is complete, the appliances
leave maintenance mode.
Note Whichever appliance you use as the secondary loses all of its device registrations and policy configurations
when you resolve split-brain. For example, you would lose modifications to any policies that existed on the
secondary but not on the primary. If the Firepower Management Center is in a high availability split-brain
scenario where both appliances are active, and you register managed devices and deploy policies before you
resolve split-brain, you must export any policies and unregister any managed devices from the intended standby
Firepower Management Center before re-establishing high availability. You may then register the managed
devices and import the policies to the intended active Firepower Management Center.
Warning Make sure that there is at least one operational Firepower Management Center during an upgrade.
Step 1 Access the web interface of the active Firepower Management Center and pause data synchronization; see Pausing
Communication Between Paired Firepower Management Centers, on page 242.
Step 2 Upgrade the standby Firepower Management Center; see Update Software on a Firepower Management Center.
When the upgrade completes, the standby unit becomes active. When both peers are active, the high availability pair is
in a degraded state (split-brain).
Step 3 Upgrade the other Firepower Management Center.
Step 4 Decide which Firepower Management Center you want to use as the standby. Any additional devices or policies added
to the standby after pausing synchronization are not synced to the active Firepower Management Center. Unregister only
those additional devices and export any configurations you want to preserve.
When you choose a new active Firepower Management Center, the Firepower Management Center you designate as
secondary will lose device registrations and deployed policy configurations, which are not synced.
Step 5 Resolve split-brain by choosing the new active Firepower Management Center which has all the latest required
configurations for policies and devices.
You must reset your You attempted to log into the standby FMC As the database is read-only for a standby
password on the when a force password reset is enabled for FMC, reset the password on the login page
active Firepower your account. of the active FMC.
Management Center
before you can log
into the standby
500 Internal May appear when attempting to access the Wait until the operation completes before
web interface while performing critical using the web interface.
Firepower Management Center high
availability operations, including switching
peer roles or pausing and resuming
synchronization.
System processes May appear when the Firepower 1. Access the Firepower Management
are starting, please Management Center reboots (manually or Center shell and use the
wait while recovering from a power down) manage_hadc.pl command to access
during a high availability or data the Firepower Management Center
Also, the web
synchronization operation. high availability configuration utility.
interface does not
respond. Note Run the utility as a root
user, using sudo.
Step 1 Log into the Firepower Management Center that you want to designate as the secondary.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Under Role for this Firepower Management Center, choose Secondary.
Step 5 Enter the hostname or IP address of the primary Firepower Management Center in the Primary Firepower Management
Center Host text box.
You can leave this empty if the primary Firepower Management Center does not have an IP address reachable from
the peer FMC (which can be public or private IP address). In this case, use both the Registration Key and the Unique
NAT ID fields. You need to specify the IP address of at least one FMC to enable HA connection.
Step 6 Enter a one-time-use registration key in the Registration Key text box.
The registration key is any user-defined alphanumeric value up to 37 characters in length. This registration key will be
used to register both -the secondary and the primary Firepower Management Centers.
Step 7 If you did not specify the primary IP address, or if you do not plan to specify the secondary IP address on the primary
Firepower Management Center, then in the Unique NAT ID field, enter a unique alphanumeric ID. See NAT
Environments, on page 1099 for more information.
Step 8 Click Register.
Step 9 Using an account with Admin access, log into the Firepower Management Center that you want to designate as the
primary.
Step 10 Choose System > Integration.
Step 11 Choose High Availability.
Step 12 Under Role for this Firepower Management Center, choose Primary.
Step 13 Enter the hostname or IP address of the secondary Firepower Management Center in the Secondary Firepower
Management Center Host text box.
You can leave this empty if the secondary Firepower Management Center does not have an IP address reachable from
the peer FMC (which can be public or private IP address). In this case, use both the Registration Key and the Unique
NAT ID fields. You need to specify the IP address of at least one FMC to enable HA connection.
Step 14 Enter the same one-time-use registration key in the Registration Key text box you used in step 6.
Step 15 If required, enter the same NAT ID that you used in step 7 in the Unique NAT ID text box.
Step 16 Click Register.
What to do next
After establishing a Firepower Management Center high availability pair, devices registered to the active
Firepower Management Center are automatically registered to the standby Firepower Management Center.
Note When a registered device has a NAT IP address, automatic device registration fails and the secondary Firepower
Management Center High Availablity page lists the device as local, pending. You can then assign a different
NAT IP address to the device on the standby Firepower Management Center High Availability page. If
automatic registration otherwise fails on the standby Firepower Management Center, but the device appears
to be registered to the active Firepower Management Center, see Using CLI to Resolve Device Registration
in Firepower Management Center High Availability, on page 241.
ViewingFirepowerManagementCenterHighAvailabilityStatus
After you identify your active and standby Firepower Management Centers, you can view information about
the local Firepower Management Center and its peer.
Note In this context, Local Peer refers to the appliance where you are viewing the system status. Remote Peer refers
to the other appliance, regardless of active or standby status.
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
You can view:
Summary Information
• The health status of the high availability pair
• The current synchronization status of the high availability pair
• The IP address of the active peer and the last time it was synchronized
• The IP address of the standby peer and the last time it was synchronized
System Status
• The IP addresses for both peers
• The operating system for both peers
• The software version for both peers
• The appliance model of both peers
• Prefilter policies
• Network discovery rules
• Application detectors
• Correlation policy rules
• Alerts
• Scanners
• Response groups
• Contextual cross-launch of external resources for investigating events
• Remediation settings, although you must install custom modules on both Firepower Management Centers.
For more information on remediation settings, see Managing Remediation Modules, on page 2241.
Warning If you do an RMA of Secondary Firepower Management Center or add a Secondary Firepower Management
Center, the managed FTDs are unregistered and as a result, their configuration may be deleted.
Step 1 Unregister the device from the active Firepower Management Center.
Step 2 Log into the CLI for the affected device.
Step 3 Run the CLI command: configure manager delete.
This command disables and removes the current Firepower Management Center.
Step 5 Log into the active Firepower Management Center and register the device.
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Switch Peer Roles to change the local role from Active to Standby, or Standby to Active. With the Primary or
Secondary designation unchanged, the roles are switched between the two peers.
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Pause Synchronization.
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Peer Manager.
Step 5 Choose Edit ( ).
Step 6 Enter the display name of the appliance, which is used only within the context of the Firepower System.
Entering a different display name does not change the host name for the appliance.
Step 7 Enter the fully qualified domain name or the name that resolves through the local DNS to a valid IP address (that is, the
host name), or the host IP address.
Step 8 Click Save.
Note If you choose to manage the registered devices from the secondary Firepower Management Center, the devices
will be unregistered from the primary Firepower Management Center. The devices are now registered to be
managed by the secondary Firepower Management Center. However the licenses that were applied to these
devices are deregistered on account of the high availability break operation. You must now proceed to re-register
(enable) the licenses on the devices from the secondary Firepower Management Center. For more information
see Move or Remove Licenses from FTD Devices, on page 126.
Primary FMC Data backup successful Replace a Failed Primary FMC (Successful Backup), on
failed page 244
Data backup not successful Replace a Failed Primary FMC (Unsuccessful Backup),
on page 245
Secondary FMC Data backup successful Replace a Failed Secondary FMC (Successful Backup),
failed on page 246
Data backup not successful Replace a Failed Secondary FMC (Unsuccessful Backup),
on page 247
Step 1 Contact Support to request a replacement for a failed Firepower Management Center - FMC1.
Step 2 When the primary Firepower Management Center - FMC1 fails, access the web interface of the secondary Firepower
Management Center - FMC2 and switch peers. For more information, see Switching Peers in a Firepower Management
Center High Availability Pair, on page 242.
This promotes the secondary Firepower Management Center - FMC2 to active.
You can use FMC2 as the active Firepower Management Center until the primary Firepower Management Center - FMC1
is replaced.
Caution Do not break Firepower Management Center High Availability from FMC2, since licenses that were synced
to FMC2 from FMC1 (before failure ), will be removed from FMC2 and you will be unable to perform any
deploy actions from FMC2.
Step 3 Reimage the replacement Firepower Management Center with the same software version as FMC1.
Step 4 Restore the data backup retrieved from FMC1 to the new Firepower Management Center.
Step 5 Install required Firepower Management Center patches, geolocation database (GeoDB) updates, vulnerability database
(VDB) updates and system software updates to match FMC2.
The new Firepower Management Center and FMC2 will now both be active peers, resulting in a high availability split-brain.
Step 6 When the Firepower Management Center web interface prompts you to choose an active appliance, select FMC2 as active.
This syncs the latest configuration from FMC2 to the newFirepower Management Center - FMC1.
Step 7 When the configuration syncs successfully, access the web interface of the secondary Firepower Management Center -
FMC2 and switch roles to make the primaryFirepower Management Center - FMC1 active. For more information, see
Switching Peers in a Firepower Management Center High Availability Pair, on page 242.
Step 8 Apply Classic licenses received with the new Firepower Management Center - FMC1 and delete the old licenses. For
more information, see Generate a Classic License and Add It to the Firepower Management Center, on page 133.
Smart licenses work seamlessly.
What to do next
High availability has now been re-established and the primary and the secondary Firepower Management
Centers will now work as expected.
Step 1 Contact Support to request a replacement for a failed Firepower Management Center - FMC1.
Step 2 When the primary Firepower Management Center - FMC1 fails, access the web interface of the secondary Firepower
Management Center - FMC2 and switch peers. For more information, see Switching Peers in a Firepower Management
Center High Availability Pair, on page 242.
This promotes the secondary Firepower Management Center - FMC2 to active.
You can use FMC2 as the active Firepower Management Center until the primary Firepower Management Center - FMC1
is replaced.
Caution Do not break Firepower Management Center High Availability from FMC2, since classic and smart licenses
that were synced to FMC2 from FMC1 (before failure ), will be removed from FMC2 and you will be unable
to perform any deploy actions from FMC2.
Step 3 Reimage the replacement Firepower Management Center with the same software version as FMC1.
Step 4 Install required Firepower Management Center patches, geolocation database (GeoDB) updates, vulnerability database
(VDB) updates and system software updates to match FMC2.
Step 5 Deregister the Firepower Management Center - FMC2 from the Cisco Smart Software Manager. For more information,
see Deregister a Firepower Management Center from the Cisco Smart Software Manager, on page 127.
Deregistering a Firepower Management Center from the Cisco Smart Software Manager removes the Management Center
from your virtual account. All license entitlements associated with the Firepower Management Center release back to
your virtual account. After deregistration, the Firepower Management Center enters Enforcement mode where no update
or changes on licensed features are allowed.
Step 6 Access the web interface of the secondary Firepower Management Center - FMC2 and break Firepower Management
Center high availability. For more information, see Disabling Firepower Management Center High Availability, on page
243. When prompted to select an option for handling managed devices, choose Manage registered devices from this
console.
As a result, classic and smart licenses that were synced to the secondary Firepower Management Center- FMC2, will be
removed and you cannot perform deployment activities from FMC2.
Step 7 Re-establish Firepower Management Center high availability, by setting up the Firepower Management Center - FMC2
as the primary and Firepower Management Center - FMC1 as the secondary. For more information , see Establishing
Firepower Management Center High Availability, on page 238.
Step 8 Apply Classic licenses received with the new Firepower Management Center - FMC1 and delete the old licenses. For
more information, see Generate a Classic License and Add It to the Firepower Management Center, on page 133.
Step 9 Register a Smart License to the primary Firepower Management Center - FMC2. For more information see Register
Smart Licenses, on page 105.
What to do next
High availability has now been re-established and the primary and the secondary Firepower Management
Centers will now work as expected.
Step 1 Contact Support to request a replacement for a failed Firepower Management Center - FMC2.
Step 2 Continue to use the primary Firepower Management Center - FMC1 as the active Firepower Management Center.
Step 3 Reimage the replacement Firepower Management Center with the same software version as FMC2.
Step 4 Restore the data backup from FMC2 to the new Firepower Management Center.
Step 5 Install required Firepower Management Center patches, geolocation database (GeoDB) updates, vulnerability database
(VDB) updates and system software updates to match FMC1.
Step 6 Resume data synchronization (if paused) from the web interface of the new Firepower Management Center - FMC2, to
synchronize the latest configuration from the primary Firepower Management Center - FMC1. For more information,
see Restarting Communication Between Paired Firepower Management Centers, on page 242.
Classic and Smart Licenses work seamlessly.
What to do next
High availability has now been re-established and the primary and the secondary Firepower Management
Centers will now work as expected.
Step 1 Contact Support to request a replacement for a failed Firepower Management Center - FMC2.
Step 2 Continue to use the primary Firepower Management Center - FMC1 as the active Firepower Management Center.
Step 3 Reimage the replacement Firepower Management Center with the same software version as FMC2.
Step 4 Install required Firepower Management Center patches, geolocation database (GeoDB) updates, vulnerability database
(VDB) updates and system software updates to match FMC1.
Step 5 Access the web interface of the primary Firepower Management Center - FMC1 and break Firepower Management Center
high availability. For more information, see Disabling Firepower Management Center High Availability, on page 243.
When prompted to select an option for handling managed devices, choose Manage registered devices from this console.
Step 6 Re-establish Firepower Management Center high availability, by setting up the Firepower Management Center - FMC1
as the primary and Firepower Management Center - FMC2 as the secondary. For more information , see Establishing
Firepower Management Center High Availability, on page 238.
• When high availability is successfully established, the latest configuration from the primary Firepower Management
Center - FMC1 is synchronized to the secondary Firepower Management Center - FMC2.
• Classic and Smart Licenses work seamlessly.
What to do next
High availability has now been re-established and the primary and the secondary Firepower Management
Centers will now work as expected.
The Firepower Management Center aggregates and correlates intrusion events, network discovery information,
and device performance data, allowing you to monitor the information that your devices are reporting in
relation to one another, and to assess the overall activity occurring on your network.
You can use a Firepower Management Center to manage nearly every aspect of a device’s behavior.
Note Although a Firepower Management Center can manage devices running certain previous releases as specified
in the compatibility matrix available at http://www.cisco.com/c/en/us/support/security/defense-center/
products-device-support-tables-list.html, new features are not available to these previous-release devices.
When you manage a device, information is transmitted between the Firepower Management Center and the
device over a secure, SSL-encrypted TCP tunnel.
The following illustration lists what is transmitted between a Firepower Management Center and its managed
devices. Note that the types of events and policies that are sent between the appliances are based on the device
type.
Backing Up a Device
You cannot create or restore backup files for NGIPSv devices or ASA FirePOWER modules.
When you perform a backup of a physical managed device from the device itself, you back up the device
configuration only. To back up configuration data and, optionally, unified files, perform a backup of the
device using the managing Firepower Management Center.
To back up event data, perform a backup of the managing Firepower Management Center.
Updating Devices
From time to time, Cisco releases updates to the Firepower System, including:
• intrusion rule updates, which may contain new and updated intrusion rules
• vulnerability database (VDB) updates
• geolocation updates
• software patches and updates
You can use the Firepower Management Center to install an update on the devices it manages.
Note For the Firepower 4100/9300 chassis, the MGMT interface is for chassis management, not for FTD logical
device management. You must configure a separate NIC interface to be of type mgmt (and/or
firepower-eventing), and then assign it to the FTD logical device.
Note For FTD on any chassis, the physical management interface is shared between the Diagnostic logical interface,
which is useful for SNMP or syslog, and is configured along with data interfaces in the FMC, and the
Management logical interface for FMC communication. See Management/Diagnostic Interface, on page 625
for more information.
See the following table for supported management interfaces on each managed device model.
Note The routing for management interfaces is completely separate from routing that you configure for data
interfaces.
You can configure multiple management interfaces on some platforms (a management interface and an
event-only interface). The default route does not include an egress interface, so the interface chosen depends
on the gateway address you specify, and which interface's network the gateway belongs to. In the case of
multiple interfaces on the default network, the device uses the lower-numbered interface as the egress interface.
At least 1 static route is recommended per management interface to access remote networks, including when
multiple interfaces are on the same network.
For example, both management0 and management1 are on the same network, but the FMC management and
event interfaces are on different networks. The gateway is 192.168.45.1. If you want management1 to connect
to the FMC's event-only interface at 10.6.6.1/24, you can create a static route for 10.6.6.0/24 through
management1 with the same gateway of 192.168.45.1. Traffic to 10.6.6.0/24 will hit this route before it hits
the default route, so management1 will be used as expected.
Another example includes separate management and event-only interfaces on both the FMC and the managed
device. The event-only interfaces are on a separate network from the management interfaces. In this case, add
a static route through the event-only interface for traffic destined for the remote event-only network, and vice
versa.
NAT Environments
Network address translation (NAT) is a method of transmitting and receiving network traffic through a router
that involves reassigning the source or destination IP address. The most common use for NAT is to allow
private networks to communicate with the internet. Static NAT performs a 1:1 translation, which does not
pose a problem for FMC communication with devices, but port address translation (PAT) is more common.
PAT lets you use a single public IP address and unique ports to access the public network; these ports are
dynamically assigned as needed, so you cannot initiate a connection to a device behind a PAT router.
Normally, you need both IP addresses (along with a registration key) for both routing purposes and for
authentication: the FMC specifies the device IP address when you add a device, and the device specifies the
FMC IP address. However, if you only know one of the IP addresses, which is the minimum requirement for
routing purposes, then you must also specify a unique NAT ID on both sides of the connection to establish
trust for the initial communication and to look up the correct registration key. The FMC and device use the
registration key and NAT ID (instead of IP addresses) to authenticate and authorize for initial registration.
For example, you add a device to the FMC, and you do not know the device IP address (for example, the
device is behind a PAT router), so you specify only the NAT ID and the registration key on the FMC; leave
the IP address blank. On the device, you specify the FMC IP address, the same NAT ID, and the same
registration key. The device registers to the FMC's IP address. At this point, the FMC uses the NAT ID instead
of IP address to authenticate the device.
Although the use of a NAT ID is most common for NAT environments, you might choose to use the NAT
ID to simplify adding many devices to the FMC. On the FMC, specify a unique NAT ID for each device you
want to add while leaving the IP address blank, and then on each device, specify both the FMC IP address
and the NAT ID. Note: The NAT ID must be unique per device.
The following example shows three devices behind a PAT IP address. In this case, specify a unique NAT ID
per device on both the FMC and the devices, and specify the FMC IP address on the devices.
The following example shows the FMC behind a PAT IP address. In this case, specify a unique NAT ID per
device on both the FMC and the devices, and specify the device IP addresses on the FMC.
Figure 2: NAT ID for FMC Behind PAT
The following example shows the Firepower Management Center using separate management interfaces for
devices; and each managed device using 1 management interface.
Figure 4: Mutliple Management Interfaces on the Firepower Management Center
The following example shows the Firepower Management Center and managed devices using a separate event
interface.
Figure 5: Separate Event Interface on the Firepower Management Center and Managed Devices
The following example shows a mix of multiple management interfaces and a separate event interface on the
Firepower Management Center and a mix of managed devices using a separate event interface, or using a
single management interface.
Supported Domains
The domain in which the device resides.
User Roles
• Admin
• Network Admin
Step 1 Connect to the FTD CLI, either from the console port or using SSH to the Management interface. If you intend to change
the network settings, we recommend using the console port so you do not get disconnected.
(Firepower 1000/2100) The console port connects to the FXOS CLI. The SSH session connects directly to the FTD CLI.
Step 2 Log in with the username admin and the password Admin123.
(Firepower 1000/2100) At the console port, you connect to the FXOS CLI. The first time you log in to FXOS, you are
prompted to change the password. This password is also used for the FTD login for SSH.
Example:
[...]
[...]
firepower#
Step 3 (Firepower 1000/2100) If you connected to FXOS on the console port, connect to the FTD CLI.
connect ftd
Example:
Step 4 The first time you log in to FTD, you are prompted to accept the End User License Agreement (EULA) and, if using an
SSH connection, to change the admin password. You are then presented with the CLI setup script.
Note You cannot repeat the CLI setup wizard unless you clear the configuration; for example, by reimaging. However,
all of these settings can be changed later at the CLI using configure network commands. See the FTD command
reference.
Defaults or previously entered values appear in brackets. To accept previously entered values, press Enter.
See the following guidelines:
• Enter the IPv4 default gateway for the management interface—The data-interfaces setting applies only to
Firepower Device Manager management; you should set a gateway IP address for Management 1/1 when using
FMC. In the edge deployment example shown in the network deployment section, the inside interface acts as the
management gateway. In this case, you should set the gateway IP address to be the intended inside interface IP
address; you must later use FMC to set the inside IP address.
• If your networking information has changed, you will need to reconnect—If you are connected with SSH but
you change the IP address at initial setup, you will be disconnected. Reconnect with the new IP address and password.
Console connections are not affected.
• Manage the device locally?—Enter no to use FMC. A yes answer means you will use Firepower Device Manager
instead.
• Configure firewall mode?—We recommend that you set the firewall mode at initial configuration. Changing the
firewall mode after initial setup erases your running configuration.
Example:
You can register the sensor to a Firepower Management Center and use the
Firepower Management Center to manage it. Note that registering the sensor
to a Firepower Management Center disables on-sensor Firepower Services
management capabilities.
However, if the sensor and the Firepower Management Center are separated by a
NAT device, you must enter a unique NAT ID, along with the unique registration
key.
'configure manager add DONTRESOLVE [registration key ] [ NAT ID ]'
Later, using the web interface on the Firepower Management Center, you must
use the same registration key and, if necessary, the same NAT ID when you add
this sensor to the Firepower Management Center.
>
• reg_key—Specifies a one-time registration key of your choice that you will also specify on the FMC when you
register the FTD. The registration key must not exceed 37 characters. Valid characters include alphanumerical
characters (A–Z, a–z, 0–9) and the hyphen (-).
• nat_id—Specifies a unique, one-time string of your choice that you will also specify on the FMC when you register
the FTD when one side does not specify a reachable IP address or hostname. It is required if you set the FMC to
DONTRESOLVE. The NAT ID must not exceed 37 characters. Valid characters include alphanumerical characters
(A–Z, a–z, 0–9) and the hyphen (-). This ID cannot be used for any other devices registering to the FMC.
Example:
If the FMC is behind a NAT device, enter a unique NAT ID along with the registration key, and specify DONTRESOLVE
instead of the hostname, for example:
Example:
If the FTD is behind a NAT device, enter a unique NAT ID along with the FMC IP address or hostname, for example:
Example:
What to do next
Register your device to a FMC.
Note If you have established or will establish FMC high availability, add devices only to the active (or intended
active) FMC. When you establish high availability, devices registered to the active FMC are automatically
registered to the standby.
Step 3 In the Host field, enter the IP address or the hostname of the device you want to add.
The hostname of the device is the fully qualified domain name or the name that resolves through the local DNS to a
valid IP address. Use a hostname rather than an IP address if your network uses DHCP to assign IP addresses.
In a NAT environment, you may not need to specify the IP address or hostname of the device, if you already specified
the IP address or hostname of the FMC when you configured the device to be managed by the FMC. For more
information, see NAT Environments, on page 254.
Step 4 In the Display Name field, enter a name for the device as you want it to display in the FMC.
Step 5 In the Registration Key field, enter the same registration key that you used when you configured the device to be
managed by the FMC. The registration key is a one-time-use shared secret.
Step 6 In a multidomain deployment, regardless of your current domain, assign the device to a leaf Domain.
If your current domain is a leaf domain, the device is automatically added to the current domain. If your current domain
is not a leaf domain, post-registration, you must switch to the leaf domain to configure the device.
Note You can apply an AnyConnect remote access VPN license after you add the device, from the System >
Licenses > Smart Licenses page.
Classic Licensing
• Control, Malware, and URL Filtering licenses require a Protection license.
Step 10 If you used a NAT ID during device setup, expand in the Advanced section and enter the same NAT ID in the Unique
NAT ID field.
Step 11 Check the Transfer Packets check box to allow the device to transfer packets to the Firepower Management Center.
This option is enabled by default. When events like IPS or Snort are triggered with this option enabled, the device sends
event metadata information and packet data to the FMC for inspection. If you disable it, only event information will
be sent to the FMC but packet data is not sent.
Note When a device is deleted and then re-added, the FMC web interface prompts you to re-apply your access
control policies. However, there is no option to re-apply the NAT and VPN policies during registration. Any
previously applied NAT or VPN configuration will be removed during registration and must be re-applied
after registration is complete.
To edit an existing group, click Edit ( ) for the group you want to edit.
Step 4 Under Available Devices, choose one or more devices to add to the device group. Use Ctrl or Shift while clicking to
choose multiple devices.
Step 5 Click Add to include the devices you chose in the device group.
Step 6 Optionally, to remove a device from the device group, click Delete ( ) next to the device you want to remove.
Step 7 Click OK to add the device group.
Note You cannot shut down or restart the ASA FirePOWER with the Firepower System user interface. See the
ASA documentation for more information on how to shut down the respective devices.
Step 4 To shut down the device, click Shut Down Device ( ) in the System section.
Step 5 When prompted, confirm that you want to shut down the device.
Disabling management blocks the connection between the Firepower Management Center and the device, but does not
delete the device from the Firepower Management Center.
In the Management dialog box, modify the name or IP address in the Host field, and click Save.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 7 Click Force Deploy to force deployment of current policies and device configuration to the device.
Note Force-deploy consumes more time than the regular deployment since it involves the complete generation of
the policy rules to be deployed on the FTD.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• The source and destination Firepower Threat Defense devices are in the same domain.
• Configuration deployment is not in progress on either the source or the destination Firepower Threat
Defense devices.
Model Support—FTD
• Click Get Device Configuration ( ) to copy device configuration from another device to the new device. On the
Get Device Configuration page, select the source device in the Select Device drop-down list.
• Click Push Device Configuration ( ) to copy device configuration from the current device to the new device.
On the Push Device Configuration page, select the the destination to which configuration is to be copied in the
Target Device drop-down list.
Step 5 (Optional) Check Include shared policies configuration check box to copy policies.
Shared policies like AC policy, NAT, Platform Settings and FlexConfig policies can be shared across multiple devices.
When the copy device configuration task is initiated, it erases the configuration on the target device and copies
the configuration of the source device to the destination device.
Warning When you have completed the copy device configuration task, you cannot revert the target device to its original
configuration.
Step 5 Check or clear the check box next to the license you want to enable or disable for the managed device.
Step 6 Click Save.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note For information about the Transfer Packets setting, see Edit General Settings, on page 267.
Caution AAB activation partially restarts the Snort process, which temporarily interrupts the inspection of a few
packets. Whether traffic drops during this interruption or passes without further inspection depends on how
the target device handles traffic. See Snort® Restart Traffic Behavior, on page 390 for more information.
Step 3 Click Device, then click Edit ( ) in the Advanced Settings section.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note If you enable object group search and then configure and operate the device for a while, be aware that
subsequently disabling the feature might lead to undesirable results. When you disable object group search,
your existing access control rules will be expanded in the device’s running configuration. If the expansion
requires more memory than is available on the device, your device can be left in an inconsistent state and you
might see a performance impact. If your device is operating normally, you should not disable object group
search once you have enabled it.
Step 3 Click the Device tab, then click the Edit ( ) in the Advanced Settings section.
Step 4 Check Object Group Search.
Step 5 Click Save.
Note When using SSH, be careful when making changes to the management interface; if you cannot re-connect
because of a configuration error, you will need to access the device console port.
Note If you change the device management IP address, then see the following tasks for FMC connectivity depending
on how you identified the FMC during initial device setup using the configure manager add command (see
Identify a New FMC, on page 277):
• IP address—No action. If you identified the FMC using a reachable IP address, then the management
connection will be reestablished automatically after several minutes. We recommend that you also change
the device IP address shown in FMC to keep the information in sync; see Update the Hostname or IP
Address in FMC, on page 266. This action can help the connection reestablish faster. Note: If you specified
an unreachable FMC IP address, then see the procedure for NAT ID below.
• NAT ID only—Manually reestablish the connection. If you identified the FMC using only the NAT
ID, then the connection cannot be automatically reestablished. In this case, change the device management
IP address in FMC according to Update the Hostname or IP Address in FMC, on page 266.
Note In a High Availability configuration, when you modify the management IP address of a registered Firepower
device from the device CLI or from the FMC, the secondary FMC does not reflect the changes even after an
HA synchronization. To ensure that the secondary FMC is also updated, switch roles between the two FMCs,
making the secondary FMC the active unit. Modify the management IP address of the registered Firepower
device on the device management page of the now active FMC.
Step 1 Connect to the device CLI, either from the console port or using SSH.
See Logging Into the Command Line Interface on FTD Devices, on page 28 or Logging Into the CLI on ASA
FirePOWER and NGIPSv Devices, on page 28.
Step 2 Log in with the Admin username and password.
Step 3 (Firepower 4100/9300 only) Enable an event-only interface.
configure network management-interface enable management1
configure network management-interface disable-management-channel management1
Example:
>
The Firepower Management Center event-only interface cannot accept management channel traffic, so you should
simply disable the management channel on the device event interface.
You can optionally disable events for the management interface using the configure network management-interface
disable-events-channel command. In either case, the device will try to send events on the event-only interface, and if
that interface is down, it will send events on the management interface even if you disable the event channel.
You cannot disable both event and management channels on an interface.
Step 4 Configure the network settings of the management interface and/or event interface:
If you do not specify the management_interface argument, then you change the network settings for the default
management interface. When configuring an event interface, be sure to specify the management_interface argument.
The event interface can be on a separate network from the management interface, or on the same network. If you are
connected to the interface you are configuring, you will be disconnected. You can re-connect to the new IP address.
a) Configure the IPv4 address:
• Manual configuration:
configure network ipv4 manual ip_address netmask gateway_ip [management_interface]
Note that the gateway_ip in this command is used to create the default route for the device. If you configure
an event-only interface, then you must enter the gateway_ip as part of the command; however, this entry just
configures the default route to the value you specify and does not create a separate static route for the eventing
interface. If you are using an event-only interface on a different network from the management interface, we
recommend that you set the gateway_ip for use with the management interface, and then create a static route
separately for the event-only interface using the configure network static-routes command.
Example:
>
>
• Manual configuration:
configure network ipv6 manual ip6_address ip6_prefix_length [ip6_gateway_ip] [management_interface]
Note that the ipv6_gateway_ip in this command is used to create the default route for the device. If you
configure an event-only interface, then you must enter the ipv6_gateway_ip as part of the command; however,
this entry just configures the default route to the value you specify and does not create a separate static route
for the eventing interface. If you are using an event-only interface on a different network from the management
interface, we recommend that you set the ipv6_gateway_ip for use with the management interface, and then
create a static route separately for the event-only interface using the configure network static-routes command.
Example:
>
Step 5 For IPv6, enable or disable ICMPv6 Echo Replies and Destination Unreachable messages. These messages are enabled
by default.
configure network ipv6 destination-unreachable {enable | disable}
configure network ipv6 echo-reply {enable | disable}
You might want to disable these packets to guard against potential denial of service attacks. Disabling Echo Reply
packets means you cannot use IPv6 ping to the device management interfaces for testing purposes.
Example:
Step 6 (FTD only) Enable a DHCP server on the default management interface to provide IP addresses to connected hosts:
configure network ipv4 dhcp-server-enable start_ip_address end_ip_address
Example:
>
You can only configure a DHCP server when you set the management interface IP address manually. This command
is not supported on the Firepower Threat Defense Virtual. To display the status of the DHCP server, enter show
network-dhcp-server:
Step 7 Add a static route for the event-only interface if the Firepower Management Center is on a remote network; otherwise,
all traffic will match the default route through the management interface.
configure network static-routes {ipv4 | ipv6}add management_interface destination_ip netmask_or_prefix gateway_ip
For the default route, do not use this command; you can only change the default route gateway IP address when you
use the configure network ipv4 or ipv6 commands (see step 4).
For information about routing, see Network Routes on Device Management Interfaces, on page 253.
Example:
> configure network static-routes ipv4 add management1 192.168.6.0 255.255.255.0 10.10.10.1
Configuration updated successfully
>
To display static routes, enter show network-static-routes (the default route is not shown):
Set the search domain(s) for the device, separated by commas. These domains are added to hostnames when you do
not specify a fully-qualified domain name in a command, for example, ping system. The domains are used only on the
management interface, or for commands that go through the management interface.
Step 11 Set the remote management port for communication with the FMC:
configure network management-interface tcpport number
Example:
The FMC and managed devices communicate using a two-way, SSL-encrypted communication channel, which by
default is on port 8305.
Note Cisco strongly recommends that you keep the default settings for the remote management port, but if the
management port conflicts with other communications on your network, you can choose a different port. If
you change the management port, you must change it for all devices in your deployment that need to
communicate with each other.
Step 12 (FTD only) Set the management or eventing interface MTU. The MTU is 1500 bytes by default.
configure network mtu [bytes] [interface_id]
• bytes—Sets the MTU in bytes. For the management interface, the value can be between 64 and 1500 if you enable
IPv4, and 1280 to 1500 if you enable IPv6. For the eventing interface, the value can be between 64 and 9000 if
you enable IPv4, and 1280 to 9000 if you enable IPv6. If you enable both IPv4 and IPv6, then the minimum is
1280. If you do not enter the bytes, you are prompted for a value.
• interface_id—Specifies the interface ID on which to set the MTU. Use the show network command to see available
interface IDs, for example management0, management1, br1, and eth0, depending on the platform. If you do not
specify an interface, then the management interface is used.
Example:
> configure network mtu 8192 management1
MTU set successfully to 1500 from 8192 for management1
Refreshing Network Config...
NetworkSettings::refreshNetworkConfig MTU value at start 8192
Step 13 Configure an HTTP proxy. The device is configured to directly-connect to the internet on ports TCP/443 (HTTPS) and
TCP/80 (HTTP). You can use a proxy server, to which you can authenticate via HTTP Digest. After issuing the command,
you are prompted for the HTTP proxy address and port, whether proxy authentication is required, and if it is required,
the proxy username, proxy password, and confirmation of the proxy password.
Note For proxy password on Cisco Firepower Threat Defense, you can use A-Z, a-z, and 0-9 characters only.
configure network http-proxy
Example:
Step 14 If you change the device management IP address, then see the following tasks for FMC connectivity depending on how
you identified the FMC during initial device setup using the configure manager add command (see Identify a New
FMC, on page 277):
• IP address—No action. If you identified the FMC using a reachable IP address, then the management connection
will be reestablished automatically after several minutes. We recommend that you also change the device IP address
shown in FMC to keep the information in sync; see Update the Hostname or IP Address in FMC, on page 266.
This action can help the connection reestablish faster. Note: If you specified an unreachable FMC IP address, then
you must manually reestablish the connection using Update the Hostname or IP Address in FMC, on page 266.
• NAT ID only—Manually reestablish the connection. If you identified the FMC using only the NAT ID, then
the connection cannot be automatically reestablished. In this case, change the device management IP address in
FMC according to Update the Hostname or IP Address in FMC, on page 266.
• Reestablish the Management Connection if You Change the FMC IP Address, on page 277—If you change
the FMC IP address or hostname, reestablishing the management connection depends on how you added
the device to the FMC.
• Identify a New FMC, on page 277—After you delete the device from the old FMC, if present, you can
configure the device for the new FMC, and then add it to the FMC.
• Switch from Firepower Device Manager to FMC, on page 278—You cannot use both FDM and FMC at
the same time for the same device. If you change from FDM to FMC, the FTD configuration will be
erased, and you will need to start over.
• Switch from FMC to Firepower Device Manager, on page 279—You cannot use both FDM and FMC at
the same time for the same device. If you change from FMC to FDM, the FTD configuration will be
erased, and you will need to start over.
Depending on how you added the device to the FMC, see the following tasks:
• IP address—No action. If you added the device to the FMC using a reachable device IP address, then the management
connection will be reestablished automatically after several minutes even though the IP address identified on the
FTD is the old IP address. Note: If you specified a device IP address that is unreachable, then you must contact
Cisco TAC, who can advise you how to restore connectivity for your devices.
• NAT ID only—Contact Cisco TAC. If you added the device using only the NAT ID, then the connection cannot
be reestablished. In this case, you must contact Cisco TAC, who can advise you how to restore connectivity for your
devices.
Step 1 On the old FMC, if present, delete the managed device. See Delete a Device from the FMC, on page 264.
You cannot change the FMC IP address if you have an active connection with an FMC.
• {hostname | IPv4_address | IPv6_address}—Sets the FMC hostname, IPv4 address, or IPv6 address.
• DONTRESOLVE—If the FMC is not directly addressable, use DONTRESOLVE instead of a hostname or IP
address. If you use DONTRESOLVE , then a nat_id is required. When you add this device to the FMC, make sure
that you specify both the device IP address and the nat_id; one side of the connection needs to specify an IP address,
and both sides need to specify the same, unique NAT ID.
• regkey—Make up a registration key to be shared between the FMC and the device during registration. You can
choose any text string for this key between 1 and 37 characters; you will enter the same key on the FMC when you
add the FTD.
• nat_id—Make up an alphanumeric string from 1 to 37 characters used only during the registration process between
the FMC and the device when one side does not specify an IP address. This NAT ID is a one-time password used
only during registration. Make sure the NAT ID is unique, and not used by any other devices awaiting registration.
Specify the same NAT ID on the FMC when you add the FTD.
Example:
>
Step 4 Add the device to the FMC. See Add a Device to the FMC, on page 260.
Caution Changing the manager resets the FTD configuration to the factory default. However, the management bootstrap
configuration is maintained.
Step 1 In FDM, for High Availability, break the high availability configuration. Ideally, break HA from the active unit.
Step 2 In FDM, unregister the device from the Smart Licensing server.
Step 3 Connect to the device CLI, for example using SSH.
Step 4 Remove the current management setting.
configure manager delete
Caution Deleting the local manager resets the FTD configuration to the factory default. However, the management
bootstrap configuration is maintained.
Example:
Example:
>
Step 6 Add the device to the FMC. See Add a Device to the FMC, on page 260.
Caution Changing the manager resets the FTD configuration to the factory default. However, the management bootstrap
configuration is maintained.
Step 1 In FMC, for High Availability, break the high availability configuration. Ideally, break HA from the active unit. See
Separate Units in a High Availability Pair, on page 735.
Step 2 In FMC, delete the managed device. See Delete a Device from the FMC, on page 264.
You cannot change the manager if you have an active connection with an FMC.
Example:
Example:
>
Step 6 Add the device to the FMC. See Add a Device to the FMC, on page 260.
In a multidomain deployment, if you are in an ancestor domain, you can click View ( ) to view a device from a descendant
domain in read-only mode.
• For Firepower 4100/9300 series devices, a link to the Firepower Chassis Manager web interface.
General Information
The General section of the Device tab displays the settings described in the table below.
Field Description
Transfer Packets This displays whether or not the managed device sends
packet data with the events to the Firepower
Management Center.
License Information
The License section of the Device page displays the licenses enabled for the device.
System Information
The System section of the Device page displays a read-only table of system information, as described in the
following table.
Field Description
Model The model name and number for the managed device.
Field Description
Time Zone setting for time-based rules The current system time of the device, in the time
zone specified in device platform settings.
Health Information
The Health section of the Device page displays the information described in the table below.
Field Description
Management Information
The Management section of the Device page displays the fields described in the table below.
Field Description
Host The IP address or hostname of the device. To change the hostname or IP Address
of the device, see Edit Management Settings, on page 265.
Field Description
Status An icon indicating the status of the communication channel between the Firepower
Management Center and the managed device. You can hover over the status icon
to view the last time the Firepower Management Center contacted the device.
Advanced Settings
The Advanced Settings section of the Device page displays a table of advanced configuration settings, as
described below. You can edit any of these settings.
Application Bypass The state of Automatic Application Bypass on the device. NGIPSv
Object Group Search The state of object group search on the device. While Firepower Threat
operating, the FTD device expands access control rules Defense
into multiple access control list entries based on the
contents of any network objects used in the access rule.
You can reduce the memory required to search access
control rules by enabling object group search. With object
group search enabled, the system does not expand network
objects, but instead searches access rules for matches
based on those group definitions. Object group search
does not impact how your access rules are defined or how
they appear in Firepower Management Center. It impacts
only how the device interprets and processes them while
matching connections to access control rules.
One-click access to 6.4.0 For Firepower 4100/9300 series devices, the Device Management page
Firepower Chassis provides a link to the Firepower Chassis Manager web interface.
Manager.
New/modified screens: Devices > Device Management
Filter devices by health 6.2.3 The Device Management page now provides version information for
and deployment status; managed devices, as well as the ability to filter devices by health and
view version information. deployment status.
New/modified screens: Devices > Device Management
About Dashboards
Firepower System dashboards provide you with at-a-glance views of current system status, including data
about the events collected and generated by the system. You can also use dashboards to see information about
the status and overall health of the appliances in your deployment. Keep in mind that the information the
dashboard provides depends on how you license, configure, and deploy the system.
Tip The dashboard is a complex, highly customizable monitoring feature that provides exhaustive data. For a
broad, brief, and colorful picture of your monitored network, use the Context Explorer.
A dashboard uses tabs to display widgets: small, self-contained components that provide insight into different
aspects of the system. For example, the predefined Appliance Information widget tells you the appliance
name, model, and currently running version of the Firepower System software. The system constrains widgets
by the dashboard time range, which you can change to reflect a period as short as the last hour or as long as
the last year.
The system is delivered with several predefined dashboards, which you can use and modify. If your user role
has access to dashboards (Administrator, Maintenance User, Security Analyst, Security Analyst [Read Only],
and custom roles with the Dashboards permission), by default your home page is the predefined Summary
Dashboard. However, you can configure a different default home page, including non-dashboards. You can
also change the default dashboard. Note that if your user role cannot access dashboards, your default home
page is relevant to the role; for example, a Discovery Admin sees the Network Discovery page.
You can also use predefined dashboards as the base for custom dashboards, which you can either share or
restrict as private. Unless you have Administrator access, you cannot view or modify private dashboards
created by other users.
Note Some drill-down pages and table views of events include a Dashboard toolbar link that you can click to view
a relevant predefined dashboard. If you delete a predefined dashboard or tab, the associated toolbar links do
not function.
In a multidomain deployment, you cannot view dashboards from ancestor domains; however, you can create
new dashboards that are copies of the higher-level dashboards.
In addition, each dashboard has a set of preferences that determines its behavior.
You can minimize and maximize widgets, add and remove widgets from tabs, as well as rearrange the widgets
on a tab.
Note For widgets that display event counts over a time range, the total number of events may not reflect the number
of events for which detailed data is available in the tables on pages under the Analysis menu. This occurs
because the system sometimes prunes older event details to manage disk space usage. To minimize the
occurrence of event detail pruning, you can fine-tune event logging to log only those events most important
to your deployment.
Widget Availability
The dashboard widgets that you can view depend on the type of appliance you are using, your user role, and
your current domain (in a multidomain deployment).
In a multidomain deployment, if you do not see a widget that you expect to see, switch to the Global domain.
See Switching Domains on the Firepower Management Center, on page 11.
Note that:
• An invalid widget is one that you cannot view because you are using the wrong type of appliance.
• An unauthorized widget is one that you cannot view because your user account does not have the necessary
privileges.
For example, the Appliance Status widget is available only on the FMC for users with Administrator,
Maintenance User, Security Analyst, or Security Analyst (Read Only) account privileges.
Although you cannot add an unauthorized or invalid widget to a dashboard, an imported dashboard may
contain unauthorized or invalid widgets. For example, such widgets can be present if the imported dashboard:
• Was created by a user with different access privileges, or
• Belongs to an ancestor domain.
Unavailable widgets are disabled and display error messages that indicate why you cannot view them.
Individual widgets also display error messages when those widgets have timed out or are otherwise experiencing
problems.
Note You can delete or minimize unauthorized and invalid widgets, as well as widgets that display no data, keeping
in mind that modifying a widget on a shared dashboard modifies it for all users of the appliance.
Note The dashboard widgets you can view depend on the type of appliance you are using, your user role, and your
current domain in a multidomain deployment.
You can configure the widget to display more or less information by modifying the widget preferences to
display a simple or an advanced view; the preferences also control how often the widget updates.
The color of the ball representing link state indicates the current status, as follows:
• green: link is up and at full speed
• yellow: link is up but not at full speed
• red: link is not up
• gray: link is administratively disabled
Note A red-shaded Custom Analysis widget indicates that its use is harming system performance. If the widget
continues to stay red over time, remove the widget. You can also disable all Custom Analysis widgets from
the Dashboard settings in your system configuration (System > Configuration > Dashboard)
Next to each event, the widget can display one of three icons to indicate any changes from the most recent
results:
• The new event icon Add ( ) signifies that the event is new to the results.
• The Up Arrow icon indicates that the event has moved up in the standings since the last time the widget
updated. A number indicating how many places the event has moved up appears next to the icon.
• The Down Arrow icon indicates that the event has moved down in the standings since the last time the
widget updated. A number indicating how many places the event has moved down appears next to the
icon.
Note In a multidomain deployment, the system builds a separate network map for each leaf domain. As a result, a
leaf domain can contain an IP address that is unique within its network, but identical to an IP address in another
leaf domain. When you view Custom Analysis widgets in an ancestor domain, multiple instances of that
repeated IP address can be displayed. At first glance, they might appear to be duplicate entries. However, if
you drill down to the host profile information for each IP address, the system shows that they belong to
different leaf domains.
first example (intrusion events using the Classification field, aggregated by Count) using the Dropped
Events search tells you how many intrusion events of each type were dropped.
Related Topics
Modifying Dashboard Time Settings, on page 304
Preference Details
Title If you do not specify a title for the widget, the system uses the
configured event type as the title.
Table (required) The table of events or assets that contains the data the widget
displays.
Field (required) The specific field of the event type you want to display. To show
data over time (line graphs), choose Time. To show relative
occurrences of events (bar graphs), choose another option.
Aggregate (required) The aggregation method configures how the widget groups the
data it displays. For most event types, the default option is Count.
Filter You can use application filters to constrain data from the
Application Statistics and Intrusion Event Statistics by Application
tables.
Preference Details
Search You can use a saved search to constrain the data that the widget
displays. You do not have to specify a search, although some
presets use predefined searches.
Only you can access searches that you have saved as private. If
you configure the widget on a shared dashboard and constrain its
events using a private search, the widget resets to not using the
search when another user logs in. This affects your view of the
widget as well. If you want to make sure that this does not happen,
save the dashboard as private.
Only fields that constrain connection summaries can constrain
Custom Analysis dashboard widgets based on connection events.
Invalid saved searches are dimmed.
If you constrain a Custom Analysis widget using a saved search,
then edit the search, the widget does not reflect your changes until
the next time it updates.
Show Choose whether you want to display the most (Top) or the least
(Bottom) frequently occurring events.
Show Movers Choose whether you want to display the icons that indicate
changes from the most recent results.
Time Zone Choose the time zone you want to use to display results.
Color You can change the color of the bars in the widget's bar graph.
Related Topics
Configuring Widget Preferences, on page 302
• On any Custom Analysis widget, click View ( ) in the lower right corner of the widget to view all associated
events, constrained by the widget preferences.
• On a Custom Analysis widget showing relative occurrences of events (bar graph), click any event to view associated
events constrained by the widget preferences, as well as by that event.
You can hover your pointer over a disk usage category in the By Category stacked bar to view the percentage
of available disk space used by that category, the actual storage space on the disk, and the total disk space
available for that category. Note that if you have a malware storage pack installed, the total disk space available
for the Files category is the available disk space on the malware storage pack.
You can configure the widget to display only the By Category stacked bar, or you can show the stacked bar
plus the admin (/), /Volume, and /boot partition usage, as well as the /var/storage partition if the malware
storage pack is installed, by modifying the widget preferences.
The widget preferences also control how often the widget updates, as well as whether it displays the current
disk usage or collected disk usage statistics over the dashboard time range.
Devices with Malware licenses enabled periodically attempt to connect to the AMP cloud even if you have
not configured dynamic analysis. Because of this, these devices show transmitted traffic; this is expected
behavior.
The widget preferences control how often the widget updates.
Table 34: Inline Result Field Contents in Workflow and Table Views
A black down arrow The system dropped the packet that triggered the rule
A gray down arrow IPS would have dropped the packet if you enabled the Drop when Inline
intrusion policy option (in an inline deployment), or if a Drop and Generate
rule generated the event while the system was pruning
No icon (blank) The triggered rule was not set to Drop and Generate Events
In a passive deployment, the system does not drop packets, including when an inline interface is in tap
mode, regardless of the rule state or the inline drop behavior of the intrusion policy.
• Show to specify Average Events Per Second (EPS) or Total Events.
• Vertical Scale to specify Linear (incremental) or Logarithmic (factor of ten) scale.
• How often the widget updates.
The resulting event view is constrained by the dashboard time range; accessing intrusion events via the
dashboard changes the events (or global) time window for the appliance. Note that packets in a passive
deployment are not dropped, regardless of intrusion rule state or the inline drop behavior of the intrusion
policy.
You can configure the widget to hide the latest versions by modifying the widget preferences. The preferences
also control how often the widget updates.
The widget also provides you with links to pages where you can update the software. You can:
• Manually update an appliance by clicking the current version.
• Create a scheduled task to download an update by clicking the latest version.
Managing Dashboards
Step 1 Choose Overview > Dashboards, and then choose the dashboard you want to modify from the menu.
Step 2 Manage your dashboards:
• Create Dashboards — Create a custom dashboard; see Creating Custom Dashboards, on page 302.
• Delete Dashboards — To delete a dashboard, click Delete ( ) next to the dashboard you want to delete. If you
delete your default dashboard, you must define a new default or the appliance prompts you to choose a dashboard
every time you attempt to view a dashboard.
• Edit Options — Edit custom dashboard options; see Editing Dashboards Options, on page 304.
• Modify Time Constraints — Modify the time display or pause/unpause the dashboard as described in Modifying
Dashboard Time Settings, on page 304.
Step 3 Add (see Adding a Dashboard, on page 301), Delete (click Close ( )), and Rename (see Renaming a Dashboard, on
page 305) dashboards.
Note You cannot change the order of dashboards.
Tip Every configuration of the Custom Analysis widget in the Cisco predefined dashboards corresponds to a system
preset for that widget. If you change or delete one of these widgets, you can restore it by creating a new Custom
Analysis widget based on the appropriate preset.
Adding a Dashboard
Step 1 View the dashboard you want to modify; see Viewing Dashboards, on page 305.
Tip After you add widgets, you can move them to any location on the tab. You cannot, however, move widgets
from tab to tab.
The dashboard widgets you can view depend on the type of appliance you are using, your user role, and your
current domain (in a multidomain deployment). Keep in mind that because not all user roles have access to
all dashboard widgets, users with fewer permissions viewing a dashboard created by a user with more
permissions may not be able to use all of the widgets on the dashboard. Although the unauthorized widgets
still appear on the dashboard, they are disabled.
Step 1 View the dashboard where you want to add a widget; see Viewing Dashboards, on page 305.
Step 2 Click the tab where you want to add the widget.
Step 3 Click Add Widgets. You can view the widgets in each category by clicking on the category name, or you can view all
widgets by clicking All Categories.
Step 4 Click Add next to the widgets you want to add. The Add Widgets page indicates how many widgets of each type are on
the tab, including the widget you want to add.
Tip To add multiple widgets of the same type (for example, you may want to add multiple RSS Feed widgets, or
multiple Custom Analysis widgets), click Add again.
Step 5 When you are finished adding widgets, click Done to return to the dashboard.
What to do next
• If you added a Custom Analysis widget, configure the widget preferences; see Configuring Widget
Preferences, on page 302.
Related Topics
Widget Availability, on page 288
Step 1 On the title bar of the widget whose preferences you want to change, click Show Preferences ( ).
Step 2 Make changes as needed.
Step 3 On the widget title bar, click Hide Preferences ( ) to hide the preferences section.
Tip Instead of creating a new dashboard, you can export a dashboard from another appliance, then import it onto
your appliance. You can then edit the imported dashboard to suit your needs.
Option Description
Copy Dashboard When you create a custom dashboard, you can choose to base it
on any existing dashboard, whether user-created or
system-defined. This option makes a copy of the preexisting
dashboard, which you can modify to suit your needs. Optionally,
you can create a blank new dashboard by choosing None. This
option is available only when you create a new dashboard.
In a multidomain deployment, you can copy any non-private
dashboards from ancestor domains.
Change Tabs Every Specifies (in minutes) how often the dashboard should cycle
through its tabs. Unless you pause the dashboard or your
dashboard has only one tab, this setting advances your view to
the next tab at the interval you specify. To disable tab cycling,
enter 0 in the Change Tabs Every field.
Refresh Page Every Determines how often the entire dashboard page automatically
refreshes.
Refreshing the entire dashboard allows you to see any preference
or layout changes that were made to a shared dashboard by another
user, or that you made to a private dashboard on another computer,
since the last time the dashboard refreshed. A frequent refresh
can be useful, for example, in a networks operations center (NOC)
where a dashboard is displayed at all times. If you make changes
to the dashboard at a local computer, the dashboard in the NOC
automatically refreshes at the interval you specify, and no manual
refresh is required.
This refresh does not update the data, and you do not need to
refresh the entire dashboard to see data updates; individual widgets
update according to their preferences.
This value must be greater than the Change Tabs Every setting.
Unless you pause the dashboard, this setting will refresh the entire
dashboard at the interval you specify. To disable the periodic page
refresh, enter 0 in the Refresh Page Every field.
Note This setting is separate from the update interval
available on many individual widgets; although
refreshing the dashboard page resets the update interval
on individual widgets, widgets will update according
to their individual preferences even if you disable the
Refresh Page Every setting.
Option Description
Save As Private Determines whether the custom dashboard can be viewed and
modified by all users of the appliance or is associated with your
user account and reserved solely for your own use. Keep in mind
that any user with dashboard access, regardless of role, can modify
shared dashboards. If you want to make sure that only you can
modify a particular dashboard, save it as private.
• To minimize or maximize a widget on the dashboard, click Minimize ( ) or Maximize ( ) in a widget’s title
bar.
• To delete a widget if you no longer want to view it on a tab, click Close ( ) in the title bar of the widget.
Step 1 View the dashboard you want to edit; see Viewing Dashboards, on page 305.
Step 2 Click Edit ( ).
Step 3 Change the options as described in Custom Dashboard Options, on page 302.
Step 4 Click Save.
Keep in mind that for enterprise deployments of the Firepower System, changing the time range to a long
period may not be useful for widgets like the Custom Analysis widget, depending on how often newer events
replace older events.
You can also pause a dashboard, which allows you to examine the data provided by the widgets without the
display changing and interrupting your analysis. Pausing a dashboard has the following effects:
• Individual widgets stop updating, regardless of any Update Every widget preference.
• Dashboard tabs stop cycling, regardless of the Cycle Tabs Every setting in the dashboard properties.
• Dashboard pages stop refreshing, regardless of the Refresh Page Every setting in the dashboard properties.
• Changing the time range has no effect.
When you are finished with your analysis, you can unpause the dashboard. Unpausing the dashboard causes
all appropriate widgets on the page to update to reflect the current time range. In addition, dashboard tabs
resume cycling and the dashboard page resumes refreshing according to the settings you specified in the
dashboard properties.
If you experience connectivity problems or other issues that interrupt the flow of system information to the
dashboard, the dashboard automatically pauses and an error notice appears until the problem is resolved.
Note Your session normally logs you out after 1 hour of inactivity (or another configured interval), regardless of
whether the dashboard is paused. If you plan to passively monitor the dashboard for long periods of time,
consider exempting some users from session timeout, or changing the system timeout settings.
Step 1 View the dashboard where you want to add a widget; see Viewing Dashboards, on page 305.
Step 2 Optionally, to change the dashboard time range, choose a time range from the Show the Last drop-down list.
Step 3 Optionally, pause or unpause the dashboard on the time range control, using Pause ( ) or Play ( ).
Renaming a Dashboard
Step 1 View the dashboard you want to modify; see Viewing Dashboards, on page 305.
Step 2 Click the dasboard title you want to rename.
Step 3 Type a name.
Step 4 Click OK.
Viewing Dashboards
By default, the home page for your appliance displays the default dashboard. If you do not have a default
dashboard defined, the home page shows the Dashboard Management page, where you can choose a dashboard
to view.
Supported Domains
Any
User Roles
Admin
Maintenace User
You can use the health monitor to create a collection of tests, referred to as a health policy, and apply the
health policy to one or more appliances. The tests, referred to as health modules, are scripts that test for criteria
you specify. You can modify a health policy by enabling or disabling tests or by changing test settings, and
you can delete health policies that you no longer need. You can also suppress messages from selected appliances
by blacklisting them.
The tests in a health policy run automatically at the interval you configure. You can also run all tests, or a
specific test, on demand. The health monitor collects health events based on the test conditions configured.
Note All appliances automatically report their hardware status via the Hardware Alarms health module. The
Firepower Management Center also automatically reports status using the modules configured in the default
health policy. Some health modules, such as the Appliance Heartbeat module, run on the Firepower Management
Center and report the status of the Firepower Management Center's managed devices. Some health modules
do not provide managed device status unless you apply a health policy configured with those modules to a
device.
You can use the health monitor to access health status information for the entire system, for a particular
appliance, or, in a multidomain deployment, a particular domain. Pie charts and status tables on the Health
Monitor page provide a visual summary of the status of all appliances on your network, including the Firepower
Management Center. Individual appliance health monitors let you drill down into health details for a specific
appliance.
Fully customizable event views allow you to quickly and easily analyze the health status events gathered by
the health monitor. These event views allow you to search and view event data and to access other information
that may be related to the events you are investigating. For example, if you want to see all the occurrences of
CPU usage with a certain percentage, you can search for the CPU usage module and enter the percentage
value.
You can also configure email, SNMP, or syslog alerting in response to health events. A health alert is an
association between a standard alert and a health status level. For example, if you need to make sure an
appliance never fails due to hardware overload, you can set up an email alert. You can then create a health
alert that triggers that email alert whenever CPU, disk, or memory usage reaches the Warning level you
configure in the health policy applied to that appliance. You can set alerting thresholds to minimize the number
of repeating alerts you receive.
You can also generate troubleshooting files for an appliance if you are asked to do so by Support.
Because health monitoring is an administrative activity, only users with administrator user role privileges can
access system health data.
Health Modules
Health modules, or health tests, test for the criteria you specify in a health policy.
AMP for Endpoints FMC The module alerts if the FMC cannot connect to the AMP cloud or Cisco AMP
Status Private Cloud after an initial successful connection, or if the private cloud
cannot contact the public AMP cloud. It also alerts if you deregister an AMP
cloud connection using the AMP for Endpoints management console.
If your FMC loses connectivity to the Internet, the system may take up to 30
minutes to generate a health alert.
Appliance Heartbeat Any This module determines if an appliance heartbeat is being heard from the
appliance and alerts based on the appliance heartbeat status.
Backlog Status FMC This module displays an alert if the backlog of event data awaiting transmission
from the device to the FMC has grown continuously for more than 30 minutes.
To reduce the backlog, evaluate your bandwidth and consider logging fewer
events.
Classic License Monitor FMC This module determines if sufficient Classic licenses remain. It alerts based on
a warning level automatically configured for the module. You cannot change
the configuration of this module.
CPU Usage Any This module checks that the CPU on the appliance is not overloaded and alerts
when CPU usage exceeds the percentages configured for the module.
Card Reset Any This module checks for network cards which have restarted due to hardware
failure and alerts when a reset occurs.
Cluster Status Threat Defense This module monitors the status of device clusters. The module alerts if:
• A new primary unit is elected to a cluster.
• A new secondary unit joins a cluster.
• A primary or secondary unit leaves a cluster.
Configuration Database FMC This module checks the size of the configuration database and alerts when the
size exceeds the values (in gigabytes) configured for the module.
Disk Status Any This module examines performance of the hard disk, and malware storage pack
(if installed) on the appliance.
This module generates a Warning (yellow) health alert when the hard disk and
RAID controller (if installed) are in danger of failing, or if an additional hard
drive is installed that is not a malware storage pack. This module generates an
Alert (red) health alert when an installed malware storage pack cannot be
detected.
Disk Usage Any This module compares disk usage on the appliance’s hard drive and malware
storage pack to the limits configured for the module and alerts when usage
exceeds the percentages configured for the module. This module also alerts
when the system excessively deletes files in monitored disk usage categories,
or when disk usage excluding those categories reaches excessive levels, based
on module thresholds.
Use the Disk Usage health status module to monitor disk usage for the / and
/volume partitions on the appliance and track draining frequency. Although
the disk usage module lists the /boot partition as a monitored partition, the
size of the partition is static so the module does not alert on the boot partition.
Attention If you receive alerts for high unmanaged disk usage for the partition
/volume even though the usage is below the critical or warning
threshold specified in the health policy, this could indicate that there
are files which need to be deleted manually from the system. Contact
TAC if you receive these alerts.
Host Limit FMC This module determines if the number of hosts the FMC can monitor is
approaching the limit and alerts based on the warning level configured for the
module. For more information, see Firepower System Host Limit, on page
2010.
Hardware Alarms Threat Defense (physical) This module determines if hardware needs to be replaced on a physical managed
device and alerts based on the hardware status. The module also reports on the
status of hardware-related daemons.
HA Status FMC This module monitors and alerts on the high availability status of the FMC. If
you have not established FMC high availability, the HA Status is Not in
HA.
This module does not monitor or alert on the high availability status of managed
devices, regardless of whether they are paired. The HA Status for a managed
device is always Not in HA. Use the device management page Devices >
Device Management to monitor devices in high availability pairs.
Health Monitor Process Any This module monitors the status of the health monitor itself and alerts if the
number of minutes since the last health event received by the FMC exceeds
the Warning or Critical limits.
ISE Connection Status FMC This module monitors the status of the server connections between the Cisco
Monitor Identity Services Engine (ISE) and the FMC. ISE provides additional user data,
device type data, device location data, SGTs (Security Group Tags), and SXP
(Security Exchange Protocol) services.
Inline Link Mismatch Any managed device This module monitors the ports associated with inline sets and alerts if the two
Alarms except ASA FirePOWER interfaces of an inline pair negotiate different speeds.
Intrusion and File Event Any managed device This module compares the number of intrusion events per second to the limits
Rate configured for this module and alerts if the limits are exceeded. If the Intrusion
and File Event Rate is zero, the intrusion process may be down or the managed
device may not be sending events. Select Analysis > Intrusions > Events to
check if events are being received from the device.
Typically, the event rate for a network segment averages 20 events per second.
For a network segment with this average rate, Events per second (Critical)
should be set to 50 and Events per second (Warning) should be set to 30. To
determine limits for your system, find the Events/Sec value on the Statistics
page for your device (System > Monitoring > Statistics), then calculate the
limits using these formulas:
• Events per second (Critical) = Events/Sec * 2.5
• Events per second (Warning) = Events/Sec * 1.5
The maximum number of events you can set for either limit is 999, and the
Critical limit must be higher than the Warning limit.
Interface Status Any This module determines if the device currently collects traffic and alerts based
on the traffic status of physical interfaces and aggregate interfaces. For physical
interfaces, the information includes interface name, link state, and bandwidth.
For aggregate interfaces, the information includes interface name, number of
active links, and total aggregate bandwidth.
For ASA FirePOWER, interfaces labeled DataPlaneInterfacex, where x is a
numerical value, are internal interfaces (not user-defined) and involve packet
flow within the system.
Link State Propagation Any except NGIPSv, This module determines when a link in a paired inline set fails and triggers the
ASA FirePOWER, link state propagation mode.
Firepower 9300,
If a link state propagates to the pair, the status classification for that module
Firepower 4100 series,
changes to Critical and the state reads:
Firepower 2100 series,
Firepower 1000 series
Module Link State Propagation: ethx_ethy is Triggered
Local Malware Analysis Any This module alerts if a device running a version earlier than 6.3 is configured
for local malware analysis and fails to download local malware analysis engine
signature updates from the AMP cloud.
For devices running version 6.3 or higher, see the Threat Data Updates on
Devices module.
Memory Usage Any This module compares memory usage on the appliance to the limits configured
for the module and alerts when usage exceeds the levels configured for the
module.
For appliances with more than 4 GB of memory, the preset alert thresholds are
based on a formula that accounts for proportions of available memory likely
to cause system problems. On >4 GB appliances, because the interval between
Warning and Critical thresholds may be very narrow, Cisco recommends that
you manually set the Warning Threshold % value to 50. This will further
ensure that you receive memory alerts for your appliance in time to address
the issue. See Memory Usage Thresholds for Health Monitor Alerts, on page
357 for additional information about how thresholds are calculated.
Beginning with Version 6.6, the minimum required RAM for FMCv upgrades
to Version 6.6.0+ is 28 GB, and the recommended RAM for FMCv deployments
is 32 GB. We recommend you do not decrease the default settings: 32 GB
RAM for most FMCv instances, 64 GB for the FMCv 300 (VMware only).
Attention A critical alert is generated by the health monitor when insufficient
RAM is allocated to an FMCv deployment.
Complex access control policies and rules can command significant resources
and negatively affect performance. Some lower-end ASA devices with
FirePOWER Services Software may generate intermittent memory usage
warnings, as the device’s memory allocation is being used to the fullest extent
possible.
Platform Faults Firepower 1000/2100 On Firepower 2100 and Firepower 1000 devices, a fault is a mutable object
that is managed by the FMC. Each fault represents a failure in the Firepower
1000/2100 instance or an alarm threshold that has been raised. During the
lifecycle of a fault, it can change from one state or severity to another.
Each fault includes information about the operational state of the affected object
at the time the fault was raised. If the fault is transitional and the failure is
resolved, then the object transitions to a functional state.
For more information, see the Cisco Firepower 1000/2100 FXOS Faults and
Error Messages Guide.
Power Supply Physical FMCs This module determines if power supplies on the device require replacement
and alerts based on the power supply status.
Process Status Any This module determines if processes on the appliance exit or terminate outside
of the process manager.
If a process is deliberately exited outside of the process manager, the module
status changes to Warning and the health event message indicates which process
exited, until the module runs again and the process has restarted. If a process
terminates abnormally or crashes outside of the process manager, the module
status changes to Critical and the health event message indicates the terminated
process, until the module runs again and the process has restarted.
Realm Any managed device Enables you to set a warning threshold for realm or user mismatches, which
are:
• User mismatch: A user is reported to the Firepower Management Center
without being downloaded.
A typical reason for a user mismatch is that the user belongs to a group
you have excluded from being downloaded to the Firepower Management
Center. Review the information discussed in Realm Fields, on page 2074.
• Realm mismatch: A user logs into a domain that corresponds to a realm
not known to the Firepower Management Center.
For more information, see Detect Realm or User Mismatches, on page 2087.
Reconfiguring Detection Any managed device This module alerts if a device reconfiguration has failed.
RRD Server Process FMC This module determines if the round robin data server that stores time series
data is running properly. The module will alert If the RRD server has restarted
since the last time it updated; it will enter Critical or Warning status if the
number of consecutive updates with an RRD server restart reaches the numbers
specified in the module configuration.
Security Intelligence FMC and some managed This module alerts if Security Intelligence is in use and:
devices
• The FMC cannot update a feed, or feed data is corrupt or contains no
recognizable IP addresses.
• A managed device that is running a release earlier than 6.3 had a problem
receiving updated Security Intelligence data from the FMC.
• A managed device that is running a release earlier than 6.3 cannot load
all of the Security Intelligence data provided to it by the FMC due to
memory issues; see Troubleshooting Memory Use, on page 1403.
• For managed devices running version 6.3 or higher, see the Threat Data
Updates on Devices module.
Snort Identity Memory Any managed device Enables you to set a warning threshold for Snort identity processing and alerts
Usage when memory usage exceeds the level configured for the module. The Critical
Threshold % default value is 80.
Threat Data Updates on FMC and devices Certain intelligence data and configurations that devices use to detect threats
Devices running release 6.3 and are updated on the FMC from the cloud every 30 minutes.
later.
This module alerts you if this information has not been updated on the devices
(For devices running a within the time period you have specified.
version earlier than 6.3,
Monitored updates include:
see information in this
table about the Security • Local URL category and reputation data
Intelligence, URL
Filtering, and Local • Security Intelligence URL lists and feeds, including global Allow lists
Malware Analysis health and Block lists and URLs from Threat Intelligence Director
modules.) • Security Intelligence network lists and feeds (IP addresses), including
global Allow lists and Block lists and IP addresses from Threat Intelligence
Director
• Security Intelligence DNS lists and feeds, including global Allow lists
and Block lists and domains from Threat Intelligence Director
• Local malware analysis signatures (from ClamAV)
• SHA lists from Threat Intelligence Director, as listed on the Objects >
Object Management > Security Intelligence > Network Lists and
Feeds page
• Dynamic analysis settings configured on the AMP > Dynamic Analysis
Connections page
• Threat Configuration settings related to expiration of cached URLs,
including the Cached URLs Expire setting on the System > Integration
> Cloud Services page. (Updates to the URL cache are not monitored
by this module.)
• Communication issues with the Cisco cloud for sending events. See the
Cisco Cloud box on the System > Integration > Cloud Services page.
Time Series Data FMC This module tracks the presence of corrupt files in the directory where time
Monitor series data (such as correlation event counts) are stored and alerts when files
are flagged as corrupt and removed.
Time Synchronization Any This module tracks the synchronization of a device clock that obtains time
Status using NTP with the clock on the NTP server and alerts if the difference in the
clocks is more than ten seconds.
URL Filtering Monitor FMCs This module alerts if the FMC fails to:
For devices running • Register with the Cisco cloud
version 6.3 or higher, see
also the Threat Data • Download URL threat data updates from the Cisco cloud
Updates on Devices • (For devices running versions earlier than 6.3) Push URL threat data to
module. its managed devices.
(For devices running version 6.3 or later, configure alerts for this problem
in the Threat Data Updates on Devices module.)
• Complete URL lookups
User Agent Status FMC This module alerts when heartbeats are not detected for any User Agents
Monitor connected to the FMC.
VPN Status FMC This module alerts when one or more VPN tunnels between Firepower devices
are down.
This module tracks:
• Site-to-site VPN for Firepower Threat Defense
• Remote access VPN for Firepower Threat Defense
Step 1 Determine which health modules you want to monitor as discussed in Health Modules, on page 309.
You can set up specific policies for each kind of appliance you have in your Firepower System, enabling only the
appropriate tests for that appliance.
Tip To quickly enable health monitoring without customizing the monitoring behavior, you can apply the default
policy provided for that purpose.
Step 2 Apply a health policy to each appliance where you want to track health status as discussed in Creating Health Policies,
on page 316.
Step 3 (Optional.) Configure health monitor alerts as discussed in Creating Health Monitor Alerts, on page 321.
You can set up email, syslog, or SNMP alerts that trigger when the health status level reaches a particular severity level
for specific health modules.
Health Policies
A health policy contains configured health test criteria for several modules. You can control which health
modules run against each of your appliances and configure the specific limits used in the tests run by each
module.
When you configure a health policy, you decide whether to enable each health module for that policy. You
also select the criteria that control which health status each enabled module reports each time it assesses the
health of a process.
You can create one health policy that can be applied to every appliance in your system, customize each health
policy to the specific appliance where you plan to apply it, or use the default health policy provided for you.
In a multidomain deployment, administrators in ancestor domains can apply health policies to devices in
descendant domains, which descendant domains can use or replace with customized local policies.
What to do next
• Apply the health policy to each appliance as described in Applying Health Policies, on page 317. This
applies your changes and updates the policy status for all affected policies.
Step 2 Click the Apply ( ) next to the policy you want to apply.
Tip
The Status ( ) next to the Health Policy column indicates the current health status for the appliance.
Step 3 Choose the appliances where you want to apply the health policy.
Step 4 Click Apply to apply the policy to the appliances you chose.
What to do next
• Optionally, monitor the task status; see Viewing Task Messages, on page 356.
Monitoring of the appliance starts as soon as the policy is successfully applied.
What to do next
• Reapply the health policy as described in Applying Health Policies, on page 317. This applies your changes
and updates the policy status for all affected policies.
Tip To stop health monitoring for an appliance, create a health policy with all modules disabled and apply it to
the appliance.
A Blocklist ( ) and a notation are visible after you expand the view for a blacklisted or partially blacklisted
appliance.
Note On a Firepower Management Center, Health Monitor blacklist settings are local configuration settings.
Therefore, if you blacklist a device, then delete it and later re-register it with the Firepower Management
Center, the blacklist settings remain persistent. The newly re-registered device remains blacklisted.
In a multidomain deployment, administrators in ancestor domains can blacklist an appliance or health module
in descendant domains. However, administrators in the descendant domains can override the ancestor
configuration and clear the blacklist for devices in their domain.
Blacklisting Appliances
You can blacklist appliances individually or by group, model, or associated health policy.
After the blacklist settings take effect, the appliance shows as disabled in the Health Monitor Appliance
Module Summary and Device Management page. Health events for the appliance have a status of disabled.
If you need to set the events and health status for an individual appliance to disabled, you can blacklist the
appliance. After the blacklist settings take effect, the appliance shows as disabled in the Health Monitor
Appliance Module Summary, and health events for the appliance have a status of disabled.
In a multidomain deployment, blacklisting an appliance in an ancestor domain blacklists it for all descendant
domains. Descendant domains can override this inherited configuration and clear the blacklisting. You can
only blacklist the Firepower Management Center at the Global level.
Tip Make sure that you keep track of individually blacklisted modules so you can reactivate them when you need
them. You may miss necessary warning or critical messages if you accidentally leave a module disabled.
In a multidomain deployment, administrators in ancestor domains can blacklist health modules in descendant
domains. However, administrators in descendant domains can override this ancestor configuration and clear
the blacklisting for policies applied in their domains. You can only blacklist Firepower Management Center
health modules at the Global level.
Severity Description
Critical The health test results met the criteria to trigger a Critical alert
status.
Warning The health test results met the criteria to trigger a Warning alert
status.
Normal The health test results met the criteria to trigger a Normal alert
status.
Recovered The health test results met the criteria to return to a normal alert
status, following a Critical or Warning alert status.
If you create or update a threshold in a way that duplicates an existing threshold, you are notified of the
conflict. When duplicate thresholds exist, the health monitor uses the threshold that generates the fewest alerts
and ignores the others. The timeout value for the threshold must be between 5 and 4,294,967,295 minutes.
In a multidomain deployment, you can view and modify health monitor alerts created in the current domain
only.
What to do next
• Disable or delete the underlying alert response to ensure that alerting does not continue; see Firepower
Management Center Alert Responses, on page 2271.
In a multidomain deployment, the health monitor in an ancestor domain displays data from all descendant
domains. In the descendant domains, it displays data from the current domain only.
Error Error ( ) Black Indicates that at least one health monitoring module
has failed on the appliance and has not been
successfully re-run since the failure occurred.
Contact your technical support representative to
obtain an update to the health monitoring module.
Critical Red Indicates that the critical limits have been exceeded
Critical ( )
for at least one health module on the appliance and
the problem has not been corrected.
Tip Your session normally logs you out after 1 hour of inactivity (or another configured interval). If you plan to
passively monitor health status for long periods of time, consider exempting some users from session timeout,
or changing the system timeout settings. See Add an Internal User at the Web Interface and Configure Session
Timeouts, on page 1131 for more information.
Step 3 In the Appliance column of the appliance list, click the name of the appliance for which you want to view details.
Tip In the Module Status Summary graph, click the color for an event status category to toggle display of Alert
Details for that status category.
What to do next
• If you want to run all health modules for the appliance, see Running All Modules for an Appliance, on
page 325
• If you want to run a specific health module for an appliance, see Running a Specific Health Module, on
page 326
• If you want to generate health module alert graphs for the appliance, see Generating Health Module Alert
Graphs, on page 326
• If you want to produce troubleshooting files for the appliance, see Downloading Advanced Troubleshooting
Files, on page 360
• If you want to download advanced troubleshooting files for the appliance, see Downloading Advanced
Troubleshooting Files, on page 360
• If you want to execute Firepower Threat Defense CLI commands from the Firepower Management Center
web interface, see Using the FTD CLI from the Web Interface, on page 362
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 324.
Step 2 Click Run All Modules. The status bar indicates the progress of the tests, then the Health Monitor Appliance page
refreshes.
Note When you manually run health modules, the first refresh that automatically occurs may not reflect the data
from the manually run tests. If the value has not changed for a module that you just ran manually, wait a few
seconds, then refresh the page by clicking the device name. You can also wait for the page to refresh again
automatically.
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 324.
Step 2 In the Module Status Summary graph, click the color for the health alert status category you want to view.
Step 3 In the Alert Detail row for the alert for which you want to view a list of events, click Run.
The status bar indicates the progress of the test, then the Health Monitor Appliance page refreshes.
Note When you manually run health modules, the first refresh that automatically occurs may not reflect the data
from the manually run tests. If the value has not changed for a module that you just manually ran, wait a few
seconds, then refresh the page by clicking the device name. You can also wait for the page to refresh automatically
again.
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 324.
Step 2 In the Module Status Summary graph of the Health Monitor Appliance page, click the color for the health alert status
category you want to view.
Step 3 In the Alert Detail row for the alert for which you want to view a list of events, click Graph.
Tip If no events appear, you may need to adjust the time range.
Tip You can bookmark this view to allow you to return to the page in the health events workflow containing the
Health Events table of events. The bookmarked view retrieves events within the time range you are currently
viewing, but you can then modify the time range to update the table with more recent information if needed.
Note If no events appear, you may need to adjust the time range.
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 324.
Step 2 In the Module Status Summary graph, click the color for the event status category you want to view.
The Alert Detail list toggles the display to show or hide events.
Step 3 In the Alert Detail row for the alert for which you want to view a list of events, click Events.
The Health Events page appears, containing results for a query with the name of the appliance and the name of the
specified health alert module as constraints. If no events appear, you may need to adjust the time range.
Step 4 If you want to view all health events for the specified appliance, expand Search Constraints, and click the Module
Name constraint to remove it.
Field Description
Module Name Specify the name of the module which generated the
health events you want to view. For example, to view
events that measure CPU performance, type CPU. The
search should retrieve applicable CPU Usage and CPU
temperature events.
Test Name The name of the health module that generated the
event.
(Search only)
Units The units descriptor for the result. You can use the
asterisk (*) to create wildcard searches.
For example, if the Firepower Management Center
generates a health event when a device it is monitoring
is using 80 percent or more of its CPU resources, the
units descriptor is a percentage sign (%).
URL Filtering Monitor 6.5 The URL Filtering Monitor module now alerts if the FMC fails to register to the Cisco cloud.
improvements
URL Filtering Monitor 6.4 You can now configure time thresholds for URL Filtering Monitor alerts.
improvements
Modified screens: New options on the System > Health > Policy > URL Filtering Monitor
page.
Supported platforms: Firepower Management Center
New health module: 6.3 A new module, Threat Data Updates on Devices, was added.
Threat Data Updates on
This module alerts you if certain intelligence data and configurations that devices use to detect
Devices
threats has not been updated on the devices within the time period you specify.
New screens: New health policy on System > Health > Policy
Modified screens: New monitor results on System > Health > Monitor
Supported platforms: Firepower Management Center and managed devices running version 6.3
and higher.
Category Description
Disk Usage The percentage of the disk that is being used. Click
the arrow to view more detailed host statistics.
Category Description
Tip You can also use the Disk Usage health monitor to monitor disk usage and alert on low disk space conditions.
Cpu(s)
Lists the following CPU usage information:
• user process usage percentage
• system process usage percentage
• nice usage percentage (CPU usage of processes that have a negative nice value, indicating a higher
priority). Nice values indicate the scheduled priority for system processes and can range between -20
(highest priority) and 19 (lowest priority).
• idle usage percentage
Mem
Lists the following memory usage information:
• total number of kilobytes in memory
• total number of used kilobytes in memory
Swap
Lists the following swap usage information:
• total number of kilobytes in swap
• total number of used kilobytes in swap
• total number of free kilobytes in swap
• total number of cached kilobytes in swap
The following table describes each column that appears in the Processes section.
Column Description
Column Description
Related Topics
System Daemons, on page 334
Executables and System Utilities, on page 336
System Daemons
Daemons continually run on an appliance. They ensure that services are available and spawn processes when
required. The following table lists daemons that you may see on the Process Status page and provides a brief
description of their functionality.
Note The table below is not an exhaustive list of all processes that may run on an appliance.
Daemon Description
Daemon Description
Daemon Description
Executable Description
SFDataCorrelator (FMC only) Analyzes binary files created by the system to generate
events, connection data, and network maps
Executable Description
Executable Description
Related Topics
Configure an Access List, on page 1112
binary files that are processed by the Data Correlator running on the Firepower Management Center. The Data
Correlator analyzes the information from the binary files, generates events, and creates network maps.
The statistics that appear for network discovery and the Data Correlator are averages for the current day, using
statistics gathered between 12:00 AM and 11:59 PM for each device.
The following table describes the statistics displayed for the Data Correlator process.
Category Description
CPU Usage — User (%) Average percentage of CPU time spent on user
processes for the current day
CPU Usage — System (%) Average percentage of CPU time spent on system
processes for the current day
Note The information in the Intrusion Event Information section of the Statistics page is based on intrusion events
stored on the managed device rather than those sent to the Firepower Management Center. No intrusion event
information is listed on this page if the managed device cannot (or is configured not to) store intrusion events
locally.
The following table describes the statistics displayed in the Intrusion Event Information section of the Statistics
page.
Statistic Description
Last Alert Was The date and time that the last event occurred
Statistic Description
Total Events Last Hour The total number of events that occurred in the past
hour
Total Events Last Day The total number of events that occurred in the past
twenty-four hours
Total Events in Database The total number of events in the events database
• Click the down arrow next to By Partition to expand it. If you have a malware storage pack installed, the
/var/storage partition usage is displayed.
Step 5 (Optional) Click the arrow next to Processes to view the information described in Process Status Fields, on page 332.
a) Enter a word or query in the filter field as described in Syntax for System Log Filters, on page 342.
Only Grep-compatible search syntax is supported.
Examples:
To search for all log entries that contain the user name “Admin,” use Admin.
To search for all log entries that are generated on November 27, use Nov[[:space:]]*27 or Nov.*27 (but not Nov
27 or Nov*27 ).
To search for all log entries that contain authorization debugging information on November 5, use
Nov[[:space:]]*5.*AUTH.*DEBUG.
b) To make your search case-sensitive, select Case-sensitive. (By default, filters are not case-sensitive.)
c) To search for all system log messages that do not meet the criteria you entered, select Exclusion.
d) Click Go.
* Matches zero or more instances of ab* matches a, ab, abb, ca, cab, and
the character or expression it cabb
follows
[ab]* matches anything
Audit Records
Firepower Management Centers log read-only auditing information for user activity. Audit logs are presented
in a standard event view that allows you to view, sort, and filter audit log messages based on any item in the
audit view. You can easily delete and report on audit information and can view detailed reports of the changes
that users make.
The audit log stores a maximum of 100,000 entries. When the number of audit log entries exceeds 100,000,
the appliance prunes the oldest records from the database to reduce the number to 100,000.
Step 1 Access the audit log workflow using System > Monitoring > Audit.
Step 2 If no events appear, you may need to adjust the time range. For more information, see Event Time Constraints, on page
2386.
Note Events that were generated outside the appliance's configured time window (whether global or event-specific)
may appear in an event view if you constrain the event view by time. This may occur even if you configured
a sliding time window for the appliance.
• To navigate between pages in the current workflow, keeping the current constraints, click the appropriate page link
at the top left of the workflow page. For more information, see Using Workflows, on page 2370.
• To drill down to the next page in the workflow, see Using Drill-Down Pages, on page 2377.
• To constrain on a specific value, click a value within a row. If you click a value on a drill-down page, you move to
the next page and constrain on the value. Note that clicking a value within a row in a table view constrains the table
view and does not drill down to the next page. See Event View Constraints, on page 2392 for more information.
Tip Table views always include “Table View” in the page name.
• To delete audit records, check the check boxes next to events you want to delete, then click Delete, or click Delete
All to delete all events in the current constrained view.
• To bookmark the current page so you can quickly return to it, click Bookmark This Page. For more information,
see Bookmarks, on page 2395.
• To navigate to the bookmark management page, click View Bookmarks. For more information, see Bookmarks,
on page 2395.
• To generate a report based on the data in the current view, click Report Designer. For more information, see Creating
a Report Template from an Event View, on page 2250.
• To view a summary of a change recorded in the audit log, click Compare next to applicable events in the Message
column. For more information, see Using the Audit Log to Examine Changes, on page 346.
Related Topics
Event View Constraints, on page 2392
Field Description
Time Time and date that the appliance generated the audit
record.
User User name of the user that triggered the audit event.
Subsystem The full menu path the user followed to generate the
audit record. For example, System > Monitoring >
Audit is the menu path to view the audit log.
In a few cases where a menu path is not relevant, the
Subsystem field displays only the event type. For
example, Login classifies user login attempts.
Field Description
Message The action the user performed or the button the user
clicked on the page.
For example, Page View signifies that the user simply
viewed the page indicated in the Subsystem, while
Save means that the user clicked the Save button on
the page.
Changes made to the Firepower System appear with
a Compare icon that you can click to see a summary
of the changes.
Domain The current domain of the user when the audit event
was triggered. This field is only present if you have
ever configured the Firepower Management Center
for multitenancy.
Related Topics
Event Searches, on page 2399
Tip Table views always include “Table View” in the page name.
Related Topics
Using Workflows, on page 2370
In a multidomain deployment, you can view data for the current domain and for any descendant domains.
You cannot view data from higher level or sibling domains.
Caution Make sure that only authorized personnel have access to the appliance and to its admin account.
In the /etc/sf directory, create one or more AuditBlock files in the following form, where type is one of the types
described in Audit Block Types, on page 347:
AuditBlock.type
Note If you create an AuditBlock.type file for a specific type of audit message, but later decide that you no longer
want to suppress them, you must delete the contents of the AuditBlock.type file but leave the file itself on the
Firepower System.
Type Description
Type Description
Audited Subsystems
The following table lists audited subsystems.
Configuration export > config_type > config_name Importing configurations of a specific type and name
Rule Update Import Log Viewing the rule update import log
System Messages
When you need to track down problems occurring in the Firepower System, the Message Center is the place
to start your investigation. This feature allows you to view the messages that the Firepower System continually
generates about system activities and status.
To open the Message Center, click on the System Status icon, located next to the Deploy menu in the main
menu. This icon can take one of the following forms, depending on the system status:
• Indicates One or More Errors — Indicates one or more errors and any number of warnings are present
on the system.
• Indicates One or More Warnings — Indicates one or more warnings and no errors are present on the
system.
• Indicates No Warnings — Indicates no warnings or errors are present on the system.
If a number is displayed with the icon, it indicates the total current number of error or warning messages.
To close the Message Center, click anywhere outside of it within the Firepower System web interface.
In addition to the Message Center, the web interface displays pop-up notifications in immediate response to
your activities and ongoing system activities. Some pop-up notifications automatically disappear after five
seconds, while others are "sticky," meaning they display until you explicitly dismiss them by clicking Dismiss
( ). Click the Dismiss link at the top of the notifications list to dismiss all notifications at once.
Tip Hovering your cursor over a non-sticky pop-up notification causes it to be sticky.
The system determines which messages it displays to users in pop-up notifications and the Message Center
based on their licenses, domains, and access roles.
Message Types
The Message Center displays messages reporting system activities and status organized into three different
tabs:
Deployments
This tab displays current status related to configuration deployment for each appliance in your system,
grouped by domain. The Firepower System reports the following deployment status values on this tab.
You can get additional detail about the deployment jobs by clicking Show History.
• Running (Spinning) — The configuration is in the process of deploying.
• Success — The configuration has successfully been deployed.
• Warning ( ) — Warning deployment statuses contribute to the message count displayed with the
Warning System Status icon.
• Failure — The configuration has failed to deploy; see Out-of-Date Policies, on page 395. Failed
deployments contribute to the message count displayed with the Error System Status icon.
Health
This tab displays current health status information for each appliance in your system, grouped by domain.
Health status is generated by health modules as described in About Health Monitoring, on page 307. The
Firepower System reports the following health status values on this tab:
• Warning ( ) — Indicates that warning limits have been exceeded for a health module on an
appliance and the problem has not been corrected. The Health Monitoring page indicates these
conditions with a Yellow Triangle ( ). Warning statuses contribute to the message count displayed
with the Warning System Status icon.
• Critical ( ) — Indicates that critical limits have been exceeded for a health module on an appliance
and the problem has not been corrected. The Health Monitoring page indicates these conditions
with a Critical ( ) icon. Critical statuses contribute to the message count displayed with the Error
System Status icon.
• Error ( ) — Indicates that a health monitoring module has failed on an appliance and has not
been successfully re-run since the failure occurred. The Health Monitoring page indicates these
conditions with a Error icon. Error statuses contribute to the message count displayed with the
Error System Status icon.
You can click on links in the Health tab to view related detailed information on the Health Monitoring
page. If there are no current health status conditions, the Health tab displays no messages.
Tasks
In the Firepower System, you can perform certain tasks (such as configuration backups or update
installation) that can require some time to complete. This tab displays the status of these long-running
tasks, and can include tasks initiated by you or, if you have appropriate access, other users of the system.
The tab presents messages in reverse chronological order based on the most recent update time for each
message. Some task status messages include links to more detailed information about the task in question.
The Firepower System reports the following task status values on this tab:
• Waiting() — Indicates a task that is waiting to run until another in-progress task is complete. This
message type displays an updating progress bar.
• Running — Indicates a task that is in-progress. This message type displays an updating progress
bar.
• Retrying — Indicates a task that is automatically retrying. Note that not all tasks are permitted to
try again. This message type displays an updating progress bar.
• Success — Indicates a task that has completed successfully.
• Failure — Indicates a task that did not complete successfully. Failed tasks contribute to the message
count displayed with the Error System Status icon.
• Stopped or Suspended — Indicates a task that was interrupted due to a system update. Stopped
tasks cannot be resumed. After normal operations are restored, start the task again.
• Skipped — A process in progress prevented the task from starting. Try again to start the task.
New messages appear in this tab as new tasks are started. As tasks complete (status success, failure, or
stopped), this tab continues to display messages with final status indicated until you remove them. Cisco
recommends you remove messages to reduce clutter in the Tasks tab as well as the message database.
Message Management
From the Message Center you can:
• Configure pop-up notification behavior (choosing whether to display them).
• Display additional task status messages from the system database (if any are available that have not been
removed).
• Remove individual task status messages. (This affects all users who can view the removed messages.)
• Remove task status messages in bulk. (This affects all users who can view the removed messages.)
Tip Cisco recommends that you periodically remove accumulated task status messages from the Task tab to reduce
clutter in the display as well the database. When the number of messages in the database approaches 100,000,
the system automatically deletes task status messages that you have removed.
Step 4 Click show deployment history to view more detailed information about the deployment jobs.
The Deployment History table lists the deployment jobs in the left column in reverse chronological order.
a) Select a deployment job.
The table in the right column shows each device that was included in the job, and the deployment status per device.
b) To view responses from the device, and commands sent to the device during deployment, click download in the
Transcript column for the device.
The transcript includes the following sections:
• Snort Apply—If there are any failures or responses from Snort-related policies, messages appear in this section.
Normally, the section is empty.
• CLI Apply—This section covers features that are configured using commands sent to the Lina process.
• Infrastructure Messages—This section shows the status of different deployment modules.
In the CLI Apply section, the deployment transcript includes commands sent to the device, and any responses returned
from the device. These response can be informative messages or error messages. For failed deployments, look for
messages that indicate errors with the commands. Examining these errors can be particularly helpful if you are using
FlexConfig policies to configure customized features. These errors can help you correct the script in the FlexConfig
object that is trying to configure the commands.
Note There is no distinction made in the transcript between commands sent for managed features and those
generated from FlexConfig policies.
For example, the following sequence shows that Firepower Management Center (FMC) sent commands to configure
GigabitEthernet0/0 with the logical name outside. The device responded that it automatically set the security level
to 0. FTD does not use the security level for anything.
Related Topics
Deploy Configuration Changes, on page 385
Related Topics
About Health Monitoring, on page 307
• Hover your cursor over the relative time indicator for a message (e.g., 3 day(s) ago) to view the time of the most
recent update for that message.
• Click any link within a message to view more information about the task.
• If more task status messages are available for display, click Fetch more messages at the bottom of the message list
to retrieve them.
Note This setting affects all pop-up notifications and persists between login sessions.
Step 2 Click Cog ( ) in the upper right corner of the Message Center.
Step 3 To enable or disable pop-up notification display, click the Show notifications slider.
Two configurable thresholds for memory usage, Critical and Warning, can be set as a percentage of memory
used. When these thresholds are exceeded, a health alarm is generated with the severity level specified.
However, the health alarm system does not calculate these thresholds in an exact manner.
With high memory devices, certain processes are expected to use a larger percentage of total system memory
than in a low memory footprint device. The design is to use as much of the physical memory as possible while
leaving a small value of memory free for ancillary processes.
Compare two devices, one with 32 GB of memory and one with 4 GB of memory. In the device with 32 GB
of memory, 5% of memory (1.6GB) is a much larger value of memory to leave for ancillary processes than
in the device with 4 GB of memory (5% of 4GB = 200MB).
To account for the higher percentage use of system memory by certain processes, the FMC calculates the total
memory to include both total physical memory and total swap memory. Thus the enforced memory threshold
for the user-configured threshold input can result in a Health Event where the “Value” column of the event
does not match the value that was entered to determine the exceeded threshold.
The following table shows examples of user-input thresholds and the enforced thresholds, depending on the
installed system memory.
Note The values in this table are examples. You can use this information to extrapolate thresholds for devices that
do not match the installed RAM shown here, or you can contact Cisco TAC for more precise threshold
calculations.
4 GB 6 GB 32 GB 48 GB
Snort Performance and Configuration data and configuration settings related to Snort on the appliance
Hardware Performance and Logs data and logs related to the performance of the appliance hardware
System Configuration, Policy, and Logs configuration settings, data, and logs related to the current system
configuration of the appliance
Detection Configuration, Policy, and Logs configuration settings, data, and logs related to detection on the
appliance
Interface and Network Related Data configuration settings, data, and logs related to inline sets and
network configuration of the appliance
Discovery, Awareness, VDB Data, and Logs configuration settings, data, and logs related to the current
discovery and awareness configuration on the appliance
Upgrade Data and Logs data and logs related to prior upgrades of the appliance
All Database Data all database-related data that is included in a troubleshoot report
Caution Generating troubleshooting files for lower-memory devices can trigger Automatic Application Bypass (AAB)
when AAB is enabled, At a minimum, triggering AAB restarts the Snort process, temporarily interrupting
traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends
on how the target device handles traffic. See Snort® Restart Traffic Behavior, on page 390 for more information.
In some such cases, triggering AAB can render the device temporarily inoperable. If inoperability persists,
contact Cisco Technical Assistance Center (TAC), who can propose a solution appropriate to your deployment.
Susceptible devices include ASA 5508-X, 5516-X, and 5525-X; NGIPSv.
Step 1 Perform the steps in Viewing Appliance Health Monitors, on page 324.
Step 2 Click Generate Troubleshooting Files.
Step 3 Choose All Data to generate all possible troubleshooting date, or check individual boxes as described in Viewing Task
Messages, on page 356.
Step 4 Click OK.
Step 5 View task messages in the Message Center; see Viewing Task Messages, on page 356.
Step 6 Find the task that corresponds to the troubleshooting files you generated.
Step 7 After the appliance generated the troubleshooting files and the task status changes to Completed, click Click to retrieve
generated files.
Step 8 Follow your browser's prompts to download the file. (The troubleshooting files are downloaded in a single .tar.gz file.)
Step 9 Follow the directions from Support to send the troubleshooting files to Cisco.
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 324.
Step 2 Click Advanced Troubleshooting.
Step 3 In File Download, enter the file name supplied by Support.
Step 4 Click Download.
Step 5 Follow your browser's prompts to download the file.
Note For managed devices, the system renames the file by prepending the device name to the file name.
Step 6 Follow the directions from Support to send the troubleshooting files to Cisco.
General Troubleshooting
An internal power failure (hardware failure, power surge, and so on) or an external power failure (unplugged
cord) can result in an ungraceful shutdown or reboot of the system. This can result in data corruption.
Connection-based Troubleshooting
Connection-based troubleshooting or debugging provides uniform debugging across modules to collect
appropriate logs for a specific connection. It also supports level-based debugging up to seven levels and
enables uniform log collection mechanism across modules. Connection-based debugging supports the following:
• A common connection-based debugging subsystem to troubleshoot issues in Firepower Threat Defense
• Uniform format for debug messages across modules
• Persistent debug messages across reboots
• End-to-end debugging across modules based on an existing connection
• Debugging ongoing connections
For more information about the troubleshooting connections, see Troubleshoot a Connection , on page 361.
Troubleshoot a Connection
Step 1 Configure a filter to identify a connection using the debug packet-condition command.
Example:
Debug packet-condition match tcp 192.168.100.177 255.255.255.255 192.168.102.177
255.255.255.255
Step 2 Enable debugs for the interested modules and the corresponding levels. Enter the debug packet command.
Example:
Debug packet acl 5
Step 4 Fetch the debug messages from database to analyze the debug messages using the following command:
show packet-debugs
Note In deployments using Firepower Management Center high availability, this feature is available only in the
active Firepower Management Center.
For more information on the FTD CLI, see the Command Reference for Firepower Threat Defense.
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 324.
Step 2 Click Advanced Troubleshooting.
Step 3 Click Threat Defense CLI.
Step 4 From the Command drop-down list, select a command.
Step 5 Optionally, enter command parameters in the Parameters text box.
Step 6 Click Execute to view the command output.
Step 1 On the Firepower Management Center, choose Devices > Device Management.
Step 2 Select a device.
Step 3 Click troubleshooting.
The Health Monitor page appears.
Step 4 Click Advanced Troubleshooting.
Step 5 Click Packet Tracer.
Step 6 Select the Packet type for the trace, and specify the protocol characteristics:
• ICMP—Enter the ICMP type, ICMP code (0-255), and optionally, the ICMP identifier.
• TCP/UDP/SCTP—Enter the source and destination port numbers.
• IP—Enter the protocol number, 0-255.
member, Destination MAC Address is optional if you enter a VLAN ID value, but required if you do not enter a
VLAN ID value.
If the Firepower Threat Defense is running in routed firewall mode, VLAN ID and Destination MAC Address are
optional if the input interface is a bridge group member.
Note Capturing packet data requires packet copy. This operation may cause delays while processing packets and
may also degrade the packet throughput. Cisco recommends that you use packet filters to capture specific
traffic data.
The saved traffic data can be downloaded in pcap or ASCII file formats.
Step 1 On the Firepower Management Center, choose Devices > Device Management.
Step 2 Select a device.
Step 3 Click troubleshooting.
The Health Monitor page appears.
Step 4 Click Advanced Troubleshooting.
Step 5 Select Capture w/Trace.
Step 6 Click Add Capture.
Step 7 Enter the Name for capturing the trace.
Step 8 Select the Interface for the capturing the trace.
Step 9 Specify Match Criteria details:
a) Select the Protocol.
b) Enter the IP address for the Source Host.
c) Enter the IP address for the Destination Host.
d) (Optional) Check SGT number check box, and enter a Security Group Tag (SGT).
Step 10 Specify Buffer details:
a) (Optional) Enter a maximum Packet Size.
b) (Optional) Enter a minimum Buffer Size.
c) Select either Continuous Capture if you want the traffic captured without interruption, or Stop when full if you
want the capture to stop when the maximum buffer size is reached.
d) Select Trace if you want to capture the details for each packet.
e) (Optional) Check Trace Count check box. Default value is 50. You can enter values in the range of 1-1000.
Step 11 Click Save.
Feature-Specific Troubleshooting
See the following table for feature-specific troubleshooting tips and techniques.
User identity sources Troubleshoot the User Agent Identity Source, on page 2132
Troubleshoot the ISE/ISE-PIC Identity Source, on page 2103
Troubleshoot the TS Agent Identity Source, on page 2126
Troubleshoot the Captive Portal Identity Source, on page 2118
Troubleshoot the Remote Access VPN Identity Source, on page
2122
Troubleshooting LDAP Authentication Connections, on page 66
Realms and user data downloads Troubleshoot Realms and User Downloads, on page 2084
Custom Security Group Tag (SGT) rule conditions Troubleshooting Custom SGT Conditions, on page 433
Cisco Threat Intelligence Director (TID) Troubleshoot Cisco Threat Intelligence Director (TID), on page
1620
Note In an FMC that uses multi-tenancy, the SSO configuration can be applied only at the global domain level,
and applies to the global domain and all subdomains.
Domains Terminology
This documentation uses the following terms when describing domains and multidomain deployments:
Global Domain
In a multidomain deployment, the top-level domain. If you do not configure multitenancy, all devices,
configurations, and events belong to the Global domain. Administrators in the Global domain can manage
the entire Firepower System deployment.
Subdomain
A second or third-level domain.
Second-level domain
A child of the Global domain. Second-level domains can be leaf domains, or they can have subdomains.
Third-level domain
A child of a second-level domain. Third-level domains are always leaf domains.
Leaf domain
A domain with no subdomains. Each device must belong to a leaf domain.
Descendant domain
A domain descending from the current domain in the hierarchy.
Child domain
A domain’s direct descendant.
Ancestor domain
A domain from which the current domain descends.
Parent domain
A domain’s direct ancestor.
Sibling domain
A domain with the same parent.
Current domain
The domain you are logged into now. The system displays the name of the current domain before your
user name at the top right of the web interface. Unless your user role is restricted, you can edit
configurations in the current domain.
Domain Properties
To modify a domain's properties, you must have Administrator access in that domain's parent domain.
Name and Description
Each domain must have a unique name within its hierarchy. A description is optional.
Parent Domain
Second- and third-level domains have a parent domain. You cannot change a domain's parent after you
create the domain.
Devices
Only leaf domains may contain devices. In other words, a domain may contain subdomains or devices,
but not both. You cannot save a deployment where a non-leaf domain directly controls a device.
In the domain editor, the web interface displays available and selected devices according to their current
place in your domain hierarchy.
Host Limit
The number of hosts a Firepower Management Center can monitor, and therefore store in network maps,
depends on its model. In a multidomain deployment, leaf domains share the available pool of monitored
hosts, but have separate network maps.
To ensure that each leaf domain can populate its network map, you can set host limits at each subdomain
level. If you set a domain's host limit to 0, the domain shares in the general pool.
Setting the host limit has a different effect at each domain level:
• Leaf — For a leaf domain, a host limit is a simple limit on the number of hosts the leaf domain can
monitor.
• Second Level — For a second-level domain that manages third-level leaf domains, a host limit
represents the total number of hosts that the leaf domains can monitor. The leaf domains share the
pool of available hosts.
• Global — For the Global domain, the host limit is equal to the total number of hosts a Firepower
Management Center can monitor. You cannot change it
The sum of subdomains' host limits can add up to more than their parent domain's host limit. For example,
if the Global domain host limit is 150,000, you can configure multiple subdomains each with a host limit
of 100,000. Any of those domains, but not all, can monitor 100,000 hosts.
The network discovery policy controls what happens when you detect a new host after you reach the
host limit; you can drop the new host, or replace the host that has been inactive for the longest time.
Because each leaf domain has its own network discovery policy, each leaf domain governs its own
behavior when the system discovers a new host.
If you reduce the host limit for a domain and its network map contains more hosts than the new limit,
the system deletes the hosts that have been inactive the longest.
Related Topics
Firepower System Host Limit, on page 2010
Network Discovery Data Storage Settings, on page 2160
Supported Domains
Any
User Roles
• Admin
Managing Domains
To modify a domain's properties, you must have Administrator access in that domain's parent domain.
• Edit — Click Edit ( ) next to the domain you want to modify; see Domain Properties, on page 371.
• Delete — Click Delete ( ) next to the empty domain you want to delete, then confirm your choice. Move devices
from domains you want to delete by editing their destination domain.
Step 3 When you are done making changes to the domain structure and all devices are associated with leaf domains, click Save
to implement your changes.
Step 4 If prompted, make additional changes:
• If you changed a leaf domain to a parent domain, move or delete the old network map; see Moving Data Between
Domains, on page 374.
• If you moved devices between domains and must assign new policies and security zones or interface groups, see
Moving Devices Between Domains, on page 374.
What to do next
• Configure user roles and policies (access control, network discovery, and so on) for any new domains.
Update device properties as needed.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 8 When you are done making changes to the domain structure and all devices are associated with leaf domains, click Save
to implement your changes.
Step 9 If prompted, make additional changes:
• If you changed a leaf domain to a parent domain, move or delete the old network map; see Moving Data Between
Domains, on page 374.
• If you moved devices between domains and must assign new policies and security zones or interface groups, see
Moving Devices Between Domains, on page 374.
What to do next
• Configure user roles and policies (access control, network discovery, and so on) for any new domains.
Update device properties as needed.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 For each former leaf domain that is now a parent domain:
• Choose a new Leaf Domain to inherit the Parent Domain's events and network map.
• Choose None to delete the parent domain's network map, but retain old events.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
You can move the device into any child domain without deleting the enrolled certificate on the device.
Specifically:
• If the health policy applied to a moved device is inaccessible in the new domain, you can choose a new
health policy.
• If the access control policy assigned to a moved device is not valid or accessible in the new domain,
choose a new policy. Every device must have an assigned access control policy.
• If the interfaces on the moved device belong to a security zone that is inaccessible in the new domain,
you can choose a new zone.
• Interfaces are removed from:
• Security zones that are inaccessible in the new domain and not used in an access control policy.
• All interface groups.
If devices require a policy update but you do not need to move interfaces between zones, the system displays
a message stating that zone configurations are up to date. For example, if a device's interfaces belong to a
security zone configured in a common ancestor domain, you do not need to update zone configurations when
you move devices from subdomain to subdomain.
Step 1 In the Move Devices dialog box, under Select Device(s) to Configure, check the device you want to configure.
Check multiple devices to assign the same health and access control policies.
Step 2 Choose an Access Control Policy to apply to the device, or choose New Policy to create a new policy.
Step 3 Choose a Health Policy to apply to the device, or choose None to leave the device without a health policy.
Step 4 If prompted to assign interfaces to new zones, choose a New Security Zone for each listed interface, or choose None to
assign it later.
Step 5 After you configure all affected devices, click Save to save policy and zone assignments.
Step 6 Click Save to implement the domain configuration.
What to do next
• Update other configurations on the moved device that were affected by the move.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Supported Domains
Any
User Roles
• Admin
• Network Admin
• Security Approver
Policy Deployment
After you configure your deployment, and any time you change that configuration, you must deploy the
changes to affected devices. You can view deployment status in the Message Center.
Deploying updates the following components:
• Device and interface configurations
You can configure the system to deploy automatically by scheduling a deploy task or by setting the system
to deploy when importing intrusion rule updates. Automating policy deployment is especially useful if you
allow intrusion rule updates to modify system-provided base policies for intrusion and network analysis.
Intrusion rule updates can also modify default values for the advanced preprocessing and performance options
in your access control policies.
In a multidomain deployment, you can deploy changes for any domain where your user account belongs:
• Switch to an ancestor domain to deploy changes to all subdomains at the same time.
• Switch to a leaf domain to deploy changes to only that domain.
Do not exceed the capability of your devices. If you exceed the maximum number of rules or policies supported
by a target device, the system displays a warning. The maximum depends on a number of factors—not only
memory and the number of processors on the device, but also on policy and rule complexity. For information
on optimizing policies and rules, see Best Practices for Access Control Rules, on page 1332.
Caution We strongly recommend you deploy in a maintenance window or at a time when interruptions will have the
least impact.
For information on all configurations that restart the Snort process for all device types, see Configurations
that Restart the Snort Process When Deployed or Activated, on page 391.
Deployment Status
On the Deployment page, the Status column provides the deployment status for each device. If a deployment
is in progress, then the live status of the deployment progress is displayed, else one of the following statuses
is displayed:
• Pending—Indicates that there are changes in the device that are to be deployed.
• Warnings or errors—Indicates that the pre-deployment checks have identified warnings or errors for the
deployment, and you have not proceeded with the deployment. You can continue with the deployment
if there are any warnings, but not if there are any errors.
Note The status column provides the warning or error status only for a single user
session on the deployment page. If you navigate away from the page or refresh
the page, the status changes to pending.
• Failed—Indicates that the previous deployment attempt failed. Click on the status to view the details.
• In queue—Indicates that deployment is initiated, and the system is yet to start the deployment process.
• Completed—Indicates that deployment has completed successfully.
Deployment Estimate
The Estimate link is available on the Deployment page after you select a device, a policy, or a configuration.
Click the Estimate link to get an estimate of the deployment duration. The time duration is a rough estimate
(having around 70% accuracy), and the actual time taken for deployment may vary for a few scenarios. Refer
to the deployment duration estimate for deployments to a few FTDs. The estimate is dependable for deployments
of up to 20 FTD devices.
When an estimate is not available, it indicates that the data is not available, since the first successful deployment
on the selected device is pending. This situation could occur after an FMC version upgrade or after a fresh
installation.
Note The estimate is incorrect and unreliable for bulk policy changes (in case of bulk policy migrations), and
selective deployments because the estimate is based on the heuristic technique.
Deployment Preview
Preview provides a snapshot of all the policy and object changes to be deployed on the device. The policy
changes include the new policies, changes in the existing policies, and the deleted policies. The object changes
include the added and modified objects which are used in policies. The unused object changes are not displayed,
since they are not deployed on the device.
On the Deployment page, the Preview column provides a Preview ( ) for each listed device. On clicking
the preview icon, FMC displays a UI page listing all the policy and object changes. The left pane on the
preview page lists all the different policy types that have changed on the device, organized in a tree structure.
The right pane lists all the additions, changes, or deletions in the policy, or the object selected in the left pane.
The two columns on the right pane provide the last deployed configuration settings (in the Deployed Version
column) versus the changes that are due for deployment (in the Pending Version column). The last deployed
configuration settings are derived from a snapshot of the last saved deployment in the FMC and not from the
device. The background colors of the settings are color-coded as per the legend available on the top-right of
the page.
Note • To preview the deploy changes, you require access from the Firepower REST API to the Firepower
Management Center. To enable the REST API access, follow the steps in Enabling REST API Access,
on page 1138.
• The preview does not show the reordering of rules across policies.
• The preview shows all the default values, even when they are not altered, along with the other configured
settings when an interface or a platform settings policy is added for the first time. Similarly, the high
availability-related policies and default values for settings are shown, even when they are not altered, in
the first preview after a high availability pair is configured or disrupted.
• Preview is not supported for some of the objects.
• Object additions and attribute changes are displayed in the preview only if the objects are associated
with any device or interface. Object deletions are not displayed.
• Preview is not supported for the following policies:
• High availability
• Network discovery
• Network analysis
• Device settings
• Flex config
On the deployment page, after you click Expand Arrow ( ) to view device-specific configuration changes,
Policy selection ( ) is visible. The policy selection icon allows you to select individual policies or
configurations to deploy while withholding the remaining listed changes without deploying them. This option
is available only for FTDs and not for sensors. You can also view the interdependent changes for a certain
policy or configuration using this option. The FMC dynamically detects dependencies in-between policies
(for example, between an access control policy and an intrusion policy), and between the shared objects and
the policies. Interdependent changes are indicated using color-coded tags to identify a set of interdependent
deployment changes. When one of the deployment changes is selected, the interdependent changes are
automatically selected.
Note • When the changes in shared objects are deployed, the impacted policies should also be deployed along
with them. When you select a shared object during deployment, the impacted policies are automatically
selected.
• Selective deployment is not supported for scheduled deployments and deployments using REST APIs.
You can only opt for complete deployment of all the changes in these cases.
• The pre-deployment checks for warnings and errors are performed not only on the selected policies, but
on all the policies that are out-of-date. Therefore, the warnings or errors list shows the unselected policies
as well.
• Similarly, the Inspect Interruption column indication on the Deployment page considers all out-of-date
policies and not just the selected policies. For information on the Inspect Interruption column, see
Restart Warnings for Firepower Threat Defense Devices, on page 379.
There are certain limitations to selectively deploying policies. Follow the contents in the table below to
understand when selective policy deployment can be used.
Full deployment Full deployment is necessary for Scenarios wherein a full deployment is required
specific deploy scenarios, and FMC are:
does not support selective
• The first deployment after you have upgraded
deployment in such scenarios. If
the FTD or FMC.
you encounter an error in such
scenarios, you may choose to • The first deployment after you have restored
proceed by selecting all the changes an FTD.
for deployment on the device.
• The first deployment after modifications in
the FTD interface settings.
• The first deployment after modifications in
the virtual router settings.
• When an FTD device is moved to a new
domain (global to sub-domain or sub-domain
to global).
Associated policy The FMC identifies interdependent Scenarios wherein an associated policy is
deployment policies which are interlinked. automatically selected:
When one of the interlinked policies
• When a new object is associated with an
is selected, the remaining
existing policy.
interlinked policies are
automatically selected. • When an existing policy's object is modified.
Access Policy Access Policy Group policies are The scenarios and the expected behavior for Access
Group listed together in the preview Policy Group policies are:
specifications window under Access Policy
• If the access control policy is out-of-date, all
Group when you click Show or
other out-of-date policies under this group are
Hide Policy ( ). deployed when the Access Policy Group is
selected for deployment.
For example, if an access control policy and
an intrusion policy are out-of-date in the
Access Policy Group, both the policies are
deployed together.
• If no access control policy is out-of-date, other
out-of-date policies in this group can be
selected and deployed individually.
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on how the target
device handles traffic. See Snort® Restart Traffic Behavior, on page 390 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 391.
Step 1 On the Firepower Management Center menu bar, click Deploy and then select Deployment.
The GUI page lists the devices with out-of-date configurations having the pending status.
• The Inspect Interruption column indicates if traffic inspection interruption may be caused in the device during
deployment.
See Restart Warnings for Firepower Threat Defense Devices, on page 379 for information to help you identify
configurations that interrupt traffic inspection and might interrupt traffic when deployed to Firepower Threat Defense
devices.
If the entry is blank in this column for a device, then it indicates that there will be no traffic inspection interruptions
on that device during deployment.
• The Last Modified Time column specifies when you last made the configuration changes.
• The Preview column allows you to preview the changes for the next deployment. For more information, see
Deployment Preview, on page 381.
• The Status column provides the status for each deployment. For more information, see Deployment Status, on page
380.
Step 2 Identify and choose the devices on which you want to deploy configuration changes.
• Search—Search for the device name, type, domain, group, or status in the search box.
• Expand—Click Expand Arrow ( ) to view device-specific configuration changes to be deployed.
By selecting the device check box, all the changes for the device, which are listed under the device, are pushed for
deployment. However, you can use the Policy selection ( ) to select individual policies or configurations to deploy
while withholding the remaining changes without deploying them. For details, see Selective Policy Deployment, on
page 382.
Optionally, use Show or Hide Policy ( ) to selectively view or hide the associated unmodified policies.
Note • When the status in the Inspect Interruption column indicates (Yes) that deploying will interrupt
inspection, and perhaps traffic, on a Firepower Threat Defense device, the expanded list indicates
the specific configurations causing the interruption with the Inspect Interruption ( ).
• When there are changes to interface groups, security zones, or objects, the impacted devices are
shown as out-of-date on the Firepower Management Center (FMC). To ensure that these changes
take effect, the policies with these interface groups, security zones, or objects, also need to be deployed
along with these changes. The impacted policies are shown as out-of-date on the Preview page on
the FMC.
Step 3 (Optional) Click Estimate to get a rough estimate of the deployment duration.
For more details, see Deployment Estimate, on page 381.
What to do next
• (Optional) Monitor deployment status; see Viewing Deployment Messages, on page 355.
• If deploy fails, see Best Practices for Deploying Configuration Changes, on page 378.
• During deployment, if there is a deployment failure due to any reason, there is a possibility that the failure
may impact traffic. However, it depends on certain conditions. If there are specific configuration changes
in the deployment, the deployment failure may lead to traffic being interrupted. See the following table
to know what configuration changes may cause traffic interruption when deployment fails.
Note The configuration changes interrupting traffic during deployment is valid only
if both the FMC and FTD are of version 6.2.3 or higher.
Related Topics
Snort® Restart Scenarios, on page 388
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on how the target
device handles traffic. See Snort® Restart Traffic Behavior, on page 390 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 391.
What to do next
• (Optional) Monitor deployment status; see Viewing Deployment Messages, on page 355.
• If deploy fails, see Best Practices for Deploying Configuration Changes, on page 378.
Related Topics
Snort® Restart Scenarios, on page 388
Step 1 On the Firepower Management Center menu bar, click Deploy and then select Deployment History.
A list of all the previous deployment and rollback jobs is displayed in reverse chronological order.
Step 2 Click Expand Arrow ( ) next to the required deployment job to view the devices included in the job and their deployment
statuses.
Step 3 (Optional) Click Transcript Details ( ) to view the commands sent to the device and the responses received.
The transcript includes the following sections:
• Snort Apply—If there are any failures or responses from Snort-related policies, then the messages are displayed in
this section. Normally, the section is empty.
• CLI Apply—This section covers features that are configured using commands that are sent to the device.
• Infrastructure Messages—This section shows the status of different deployment modules.
In the CLI Apply section, the deployment transcript includes commands that are sent to the device, and any responses
returned from the device. These responses can be informative messages or error messages. For failed deployments, look
for messages that indicate errors with the commands. Examining these errors can be particularly helpful if you are using
FlexConfig policies to configure customized features. These errors can help you correct the script in the FlexConfig
object that is trying to configure the commands.
Note There is no distinction that is made in the transcript between commands that are sent for managed features and
those generated from FlexConfig policies.
For example, the following sequence shows that Firepower Management Center (FMC) sent commands to configure
GigabitEthernet0/0 with the logical name outside. The device responded that it automatically set the security level to 0.
FTD does not use the security level for anything.
390 for more information. Additionally, resource demands may result in a small number of packets dropping
without inspection when you deploy, regardless of whether the Snort process restarts.
Any of the scenarios in the following table cause the Snort process to restart.
Deploying a specific configuration that requires the Configurations that Restart the Snort Process When
Snort process to restart. Deployed or Activated, on page 391
Modifying a configuration that immediately restarts Changes that Immediately Restart the Snort Process,
the Snort process. on page 393
Traffic-activation of the currently deployed Automatic Configure Automatic Application Bypass, on page
Application Bypass (AAB) configuration. 269
Related Topics
Access Control Policy Advanced Settings, on page 1349
Configurations that Restart the Snort Process When Deployed or Activated, on page 391
The following graphic illustrates how Snort restarts can occur when you enable or disable Inspect traffic
during policy apply.
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on how the target
device handles traffic. See Snort® Restart Traffic Behavior, on page 390 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 391.
routed, transparent (including EtherChannel, existing TCP/UDP flows: passed without inspection
redundant, subinterface): preserve-connection
new TCP/UDP flows and all non-TCP/UDP flows:
enabled (configure snort preserve-connection
dropped
enable; default)
Note that the following traffic drops even when
For more information, see Cisco Firepower Threat
preserve-connection is enabled:
Defense Command Reference.
• when Snort goes down before the system tags
traffic that would have matched a Do not decrypt
SSL rule or default policy action
(tagging occurs after a few handshake packet
exchanges)
• plaintext, passthrough prefilter tunnel traffic that
matches an Analyze rule action or an Analyze
all tunnel traffic default policy action
• decrypted TLS/SSL traffic
• a safe search flow
• a captive portal flow
Note In addition to traffic handling when the Snort process is down while it restarts, traffic can also pass without
inspection or drop when the Snort process is busy, depending on the configuration of the Failsafe option (see
Inline Sets on the Firepower System, on page 556) or the Snort Fail Open Busy option (see Configure an Inline
Set, on page 687). A device supports either the Failsafe option or the Snort Fail Open option, but not both.
Note When the Snort process is busy but not down during configuration deployment, some packets may drop on
routed, switched, or transparent interfaces if the total CPU load exceeds 60 percent.
File Policy
Deploy the first or last of any one of the following configurations; note that while otherwise deploying these
file policy configurations does not cause a restart, deploying non-file-policy configurations can cause restarts.
• Take either of the following actions:
• Enable or disable Inspect Archives when the deployed access control policy includes at least one
file policy.
• Add the first or remove the last file policy rule when Inspect Archives is enabled (note that at least
one rule is required for Inspect Archives to be meaningful).
Note that access control rules that deploy these file policy configurations to security zones or tunnel zones
cause a restart only when your configuration meets the following conditions:
• Source or destination security zones in your access control rule must match the security zones associated
with interfaces on the target devices.
• Unless the destination zone in you access control rule is any, a source tunnel zone in the rule must match
a tunnel zone assigned to a tunnel rule in the prefilter policy.
Identity Policy
• When SSL decryption is disabled (that is, when the access control policy does not include an SSL policy),
add the first or remove the last active authentication rule.
An active authentication rule has either an Active Authentication rule action, or a Passive Authentication
rule action with Use active authentication if passive or VPN identity cannot be established selected.
Network Discovery
• Enable or disable non-authoritative, traffic-based user detection over the HTTP, FTP, or MDNS protocols,
using the network discovery policy.
Device Management
• MTU: Change the highest MTU value among all non-management interfaces on a device.
• Automatic Application Bypass (AAB): The currently deployed AAB configuration activates when a
malfunction of the Snort process or a device misconfiguration causes a single packet to use an excessive
amount of processing time. The result is a partial restart of the Snort process to alleviate extremely high
latency or prevent a complete traffic stall. This partial restart causes a few packets to pass without
inspection, or drop, depending on how the device handles traffic.
Updates
• System update: Deploy configurations the first time after a software update that includes a new version
of the Snort binary or data acquisition library (DAQ).
• VDB: Deploy configurations the first time after installing a vulnerability database (VDB) update that
includes changes applicable to managed devices. For these, a message warns you when you select the
Firepower Management Center to begin installing. The deploy dialog provides additional warnings for
Firepower Threat Defense devices when VDB changes are pending. VDB updates that apply only to the
Firepower Management Center do not cause restarts, and you cannot deploy them.
Related Topics
Deploy Configuration Changes, on page 385
Snort® Restart Scenarios, on page 388
A message warns you that continuing restarts the Snort process, and allows you to cancel; the restart
occurs on any managed device in the current domain or in any of its child domains.
• Create or break a Firepower Threat Defense high availability pair—A message warns you that continuing
to create a high availability pair restarts the Snort process on the primary and secondary devices and
allows you to cancel.
Policy Comparison
To review policy changes for compliance with your organization's standards or to optimize system performance,
you can examine the differences between two policies or between a saved policy and the running configuration.
You can compare the following policy types:
• DNS
• File
• Health
• Identity
• Intrusion
• Network Analysis
• SSL
The comparison view displays both policies in a side-by-side format. Differences between the two policies
are highlighted:
• Blue indicates that the highlighted setting is different in the two policies, and the difference is noted in
red text.
• Green indicates that the highlighted setting appears in one policy but not the other.
Comparing Policies
You can compare policies only if you have access rights and any required licenses for the specific policy, and
you are in the correct domain for configuring the policy.
Step 1 Access the management page for the policy you want to compare:
• DNS—Policies > Access Control > DNS
• File—Policies > Access Control > Malware & File
• Health—System > Health > Policy
• Identity—Policies > Access Control > Identity
• Intrusion—Policies > Access Control > Intrusion
• Network Analysis—Policies > Access Control, then click Network Analysis Policy or Policies > Access Control >
Intrusion, then click Network Analysis Policy
Note If your custom user role limits access to the first path listed here, use the second path to access the policy.
Step 4 Depending on the comparison type you choose, you have the following choices:
• If you are comparing two different policies, choose the policies you want to compare from the Policy A and Policy
B drop-down lists.
• If you are comparing the running configuration to another policy, choose the second policy from the Policy B
drop-down list.
Policy Reports
For most policies, you can generate two kinds of reports. A report on a single policy provides details on the
policy's current saved configuration, while a comparison report lists only the differences between two policies.
You can generate a single-policy report for all policy types except health.
Note Intrusion policy reports combine the settings in the base policy with the settings of the policy layers, and make
no distinction between which settings originated in the base policy or policy layer.
Step 1 Access the management page for the policy for which you want to generate a report:
• Access Control—Policies > Access Control
• DNS—Policies > Access Control > DNS
• File—Policies > Access Control > Malware & File
• Health—System > Health > Policy
• Identity—Policies > Access Control > Identity
• Intrusion—Policies > Access Control > Intrusion
• Network Analysis—Policies > Access Control, then click Network Analysis Policy or Policies > Access Control >
Intrusion, then click Network Analysis Policy
Note If your custom user role limits access to the first path listed here, use the second path to access the policy.
Step 2 Click Report ( ) next to the policy for which you want to generate a report.
Out-of-Date Policies
The Firepower System marks out-of-date policies with red status text that indicates how many of its targeted
devices need a policy update. To clear this status, you must re-deploy the policy to the devices.
Configuration changes that require a policy re-deploy include:
• Modifying an access control policy: any changes to access control rules, the default action, policy targets,
Security Intelligence filtering, advanced options including preprocessing, and so on.
• Modifying any of the policies that the access control policy invokes: the SSL policy, network analysis
policies, intrusion policies, file policies, identity policies, or DNS policies.
• Changing any reusable object or configuration used in an access control policy or policies it invokes:
• Updating the system software, intrusion rules, or the vulnerability database (VDB).
Keep in mind that you can change some of these configurations from multiple places in the web interface.
For example, you can modify security zones using the object manager (Objects > Object Management), but
modifying an interface type in a device’s configuration (Devices > Device Management) can also change a
zone and require a policy re-deploy.
Note that the following updates do not require policy re-deploy:
• automatic updates to Security Intelligence feeds and additions to the Security Intelligence global Block
or Allow list using the context menu
• automatic updates to URL filtering data
• scheduled geolocation database (GeoDB) updates
However, if your organization is interested in performing only IPS, or only discovery, there are a few
configurations that can optimize the performance of the system.
ports on those hosts. You can also configure managed devices to monitor user activity on your network. You
can use discovery data to perform traffic profiling, assess network compliance, and respond to policy violations.
In a basic deployment (discovery and simple, network-based access control only), you can improve a device’s
performance by following a few important guidelines when configuring its access control policy.
Note You must use an access control policy, even if it simply allows all traffic. The network discovery policy can
only examine traffic that the access control policy allows to pass.
First, make sure your access control policy does not require complex processing and uses only simple,
network-based criteria to handle network traffic. You must implement all of the following guidelines;
misconfiguring any one of these options eliminates the performance benefit:
• Do not use the Security Intelligence feature. Remove any populated global Block or Allow list from the
policy’s Security Intelligence configuration.
• Do not include access control rules with Monitor or Interactive Block actions. Use only Allow, Trust,
and Block rules. Keep in mind that allowed traffic can be inspected by discovery; trusted and blocked
traffic cannot.
• Do not include access control rules with application, user, URL, ISE attribute, or geolocation-based
network conditions. Use only simple network-based conditions: zone, IP address, VLAN tag, and port.
• Do not include access control rules that perform file, malware, or intrusion inspection. In other words,
do not associate a file policy or intrusion policy with any access control rule.
• In the Advanced settings for the access control policy, make sure that Intrusion Policy used before
Access Control rule is determined is set to No Rules Active.
• Select Network Discovery Only as the policy’s default action. Do not choose a default action for the
policy that performs intrusion inspection.
In conjunction with the access control policy, you can configure and deploy the network discovery policy,
which specifies the network segments, ports, and zones that the system examines for discovery data, as well
as whether hosts, applications, and users are discovered on the segments, ports, and zones.
Related Topics
Inspection of Packets That Pass Before Traffic Is Identified, on page 1848
• Disable network and URL-based Security Intelligence by deleting all Allow lists and Block lists from
your access control policy's Security Intelligence configuration, including the default Global lists.
• Disable DNS-based Security Intelligence by deleting or disabling all rules in the associated DNS policy,
including the default Global Allow List for DNS and Global Block List for DNS rules.
After you deploy, new discovery halts on target devices. The system gradually deletes information in the
network map according to your timeout preferences. Or, you can purge all discovery data immediately.
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
Introduction to Rules
Rules in various policies exert granular control over network traffic. The system evaluates traffic against rules
in the order that you specify, using a first-match algorithm.
Although these rules may include other configurations that are not consistent across policies, they share many
basic characteristics and configuration mechanics, including:
• Conditions: Rule conditions specify the traffic that each rule handles. You can configure each rule with
multiple conditions. Traffic must match all conditions to match the rule.
• Action: A rule's action determines how the system handles matching traffic. Note that even if a rule does
not have an Action list you can choose from, the rule still has an associated action. For example, a custom
network analysis rule uses a network analysis policy as its "action." As another example, QoS rules do
not have an explicit action because all QoS rules do the same thing: rate limit traffic.
• Position: A rule's position determines its evaluation order. When using a policy to evaluate traffic, the
system matches traffic to rules in the order you specify. Usually, the system handles traffic according to
the first rule where all the rule’s conditions match the traffic. (Monitor rules, which are designed to track
and log, are an exception.) Proper rule order reduces the resources required to process network traffic,
and prevents rule preemption.
• Category: To organize some rule types, you can create custom rule categories in each parent policy.
• Logging: For many rules, logging settings govern whether and how the system logs connections handled
by the rule. Some rules (such as identity and network analysis rules) do not include logging settings
because the rules neither determine the final disposition of connections, nor are they specifically designed
to log connections. As another example, QoS rules do not include logging settings; you cannot log a
connection simply because it was rate limited.
• Comments: For some rule types, each time you save changes, you can add comments. For example, you
might summarize the overall configuration for the benefit of other users, or note when you change a rule
and the reason for the change.
Tip A right-click menu in many policy editors provides shortcuts to many rule management options, including
editing, deleting, moving, enabling, and disabling.
Interface Conditions, on page 408 Source and destination interfaces, Access control rules
and where supported, tunnel zones
Tunnel rules
Prefilter rules
SSL rules
DNS rules
Identity rules
Network analysis rules
QoS rules
Network Conditions, on page 410 Source and destination IP address, Access control rules
and where supported, geographical
Prefilter rules
location or originating client
SSL rules
DNS rules
Identity rules
Network analysis rules
QoS rules
Tunnel rules
Prefilter rules
SSL rules
DNS rules
Identity rules
Network analysis rules
Port and ICMP Code Conditions, Source and destination ports, Access control rules
on page 415 protocols, and ICMP codes
Prefilter rules
SSL rules
Identity rules
QoS rules
URL Conditions (URL Filtering), URL, and where supported, URL Access control rules
on page 426 characteristic (category and
SSL rules
reputation)
QoS rules
User, Realm, and ISE Attribute Logged-in authoritative user of a Access control rules
Conditions (User Control), on page host, or that user's realm, group, or
SSL rules (no ISE attributes)
426 ISE attributes
QoS rules
Custom SGT Conditions, on page Custom Security Group Tag (SGT) Access control rules
431
QoS rules
Caution Failure to set up your access control rules properly can have unexpected results, including traffic being allowed
that should be blocked. In general, application control rules should be lower in your access control list because
it takes longer for those rules to match than rules based on IP address, for example.
Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before
rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect
(OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data
link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session,
presentation, and application) should be ordered later in your access control rules. For more information about
the OSI model, see this Wikipedia article.
• Choose Item—Click an item or check its check box. Often you can use Ctrl or Shift to choose multiple
items, or right-click to Select All.
• Search—Enter criteria in the search field. The list updates as you type. The system searches item names
and, for objects and object groups, their values. Click Reload ( ) or Clear ( ) to clear the search.
• Add Predefined Item—After you choose one or more available items, click an Add button or drag and
drop. The system prevents you from adding invalid items: duplicates, invalid combinations, and so on.
• Add Manual Item—Click the field under the Selected items list, enter a valid value, and click Add. When
you add ports, you may also choose a protocol from the drop-down list.
• Create Object—Click Add ( ) to create a new, reusable object that you can immediately use in the
condition you are building, then manage in the object manager. When using this method to add application
filters on the fly, you cannot save a filter that includes another user-created filter.
• Delete—Click the Delete ( ) for an item, or choose one or more items and right-click to Delete Selected.
Interface Conditions
Interface rule conditions control traffic by its source and destination interfaces.
Depending on the rule type and the devices in your deployment, you can use predefined interface objects
called security zones or interface groups to build interface conditions. Interface objects segment your network
to help you manage and classify traffic flow by grouping interfaces across multiple devices; see Interface
Objects: Interface Groups and Security Zones, on page 456.
Tip Constraining rules by interface is one of the best ways to improve system performance. If a rule excludes all
of a device’s interfaces, that rule does not affect that device's performance.
Just as all interfaces in an interface object must be of the same type (all inline, passive, switched, routed, or
ASA FirePOWER), all interface objects used in an interface condition must be of the same type. Because
devices deployed passively do not transmit traffic, in passive deployments you cannot constrain rules by
destination interface.
Note If a configuration supports tunnel zone constraints, a rezoned connection—a connection with an assigned
tunnel zone—does not match security zone constraints. For more information, see Tunnel Zones and
Prefiltering, on page 1425.
Rule Type Supports Security Zones? Supports Tunnel Zones? Supports Interface
Groups?
SSL yes no no
Identity yes no no
Note You are not required to group all internal (or external) interfaces into a single zone. Choose the
grouping that makes sense for your deployment and security policies.
Then, configure an access control rule with a destination zone condition set to Internal. This simple
rule matches traffic that leaves the device from any interface in the Internal zone. To inspect matching
traffic for intrusions and malware, choose a rule action of Allow, then associate the rule with an
intrusion and a file policy.
Step 1 In the rule editor, click the following for interface conditions:
• Interface groups and security zones (tunnel, prefilter, QoS)—Click Interface Objects.
• Security zones (access control, SSL, DNS, identity, network analysis)—Click Zones.
• Tunnel zones (access control)—Click Zones.
Step 2 Find and choose the interfaces you want to add from the Available Interface Objects or Available Zones list.
(Access control only) To match connections in rezoned tunnels, choose tunnel zones instead of security zones. You cannot
use tunnel and security zones in the same rule. For more information, see Tunnel Zones and Prefiltering, on page 1425.
What to do next
• (Access control only) If you rezoned tunnels during prefiltering, configure additional rules if necessary
to ensure complete coverage. Connections in rezoned tunnels do not match rules with security zone
constraints. For more information, see Using Tunnel Zones, on page 1426.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Network Conditions
Network rule conditions control traffic by its source and destination IP address, using inner headers. Tunnel
rules, which use outer headers, have tunnel endpoint conditions instead of network conditions.
You can use predefined objects to build network conditions, or manually specify individual IP addresses or
address blocks.
Note 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. Using override-enabled objects
allows descendant domain administrators to tailor Global configurations to their local environments.
Leave matching criteria empty whenever possible, especially those for security zones, network objects, and
port objects. When you specify multiple criteria, the system must match against every combination of the
contents of the criteria you specify.
Traffic matches the rule if the proxy's IP address matches the rule's source network constraint, and the original
client's IP address matches the rule's original client constraint. For example, to allow traffic from a specific
original client address, but only if it uses a specific proxy, create three access control rules:
Access Control Rule 1: Blocks non-proxied traffic from a specific IP address (209.165.201.1)
Source Networks: 209.165.201.1
Original Client Networks: none/any
Action: Block
Access Control Rule 2: Allows proxied traffic from the same IP address, but only if the proxy server for that
traffic is one you choose (209.165.200.225 or 209.165.200.238)
Source Networks: 209.165.200.225 and 209.165.200.238
Original Client Networks: 209.165.201.1
Action: Allow
Access Control Rule 3: Blocks proxied traffic from the same IP address if it uses any other proxy server.
Source Networks: any
Original Client Networks: 209.165.201.1
Action: Block
Prefilter no no
SSL yes no
Identity yes no
Network analysis no no
Step 3 (Optional) If the rule supports original client constraints, under Source Networks, configure the rule to handle proxied
traffic based on its original client:
Step 4 Click Add to Source, Add to Original Client, or Add to Destination, or drag and drop.
Step 5 Add networks that you want to specify manually. Enter a source, original client, or destination IP address or address
block, then click Add.
Note 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. Using override-enabled objects allows
descendant domain administrators to tailor Global configurations to their local environments.
In this example, a network object group called Private Networks (that comprises the IPv4 and IPv6
Private Networks network objects, not shown) represents your internal networks. The example also
manually specifies the example.com IP address, and uses a system-provided North Korea geolocation
object to represent North Korea IP addresses.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note 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. Using override-enabled objects
allows descendant domain administrators to tailor Global configurations to their local environments.
Step 4 Add endpoints that you want to specify manually. Enter a source or destination IP address or address block, then click
Add.
Note 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. Using override-enabled objects allows
descendant domain administrators to tailor Global configurations to their local environments.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
VLAN Conditions
VLAN rule conditions control VLAN-tagged traffic, including Q-in-Q (stacked VLAN) traffic. The system
uses the innermost VLAN tag to filter VLAN traffic, with the exception of the prefilter policy, which uses
the outermost VLAN tag in its rules.
Note the following Q-in-Q support:
• NGIPSv—Supports Q-in-Q for all interface types.
• ASA FirePOWER module—Does not support Q-in-Q (supports only one VLAN tag).
• FTD on Firepower 4100/9300—Does not support Q-in-Q (supports only one VLAN tag).
• FTD on all other models:
• Inline sets and passive interfaces—Supports Q-in-Q, up to 2 VLAN tags.
• Firewall interfaces—Does not support Q-in-Q (supports only one VLAN tag).
You can use predefined objects to build VLAN conditions, or manually enter any VLAN tag from 1 to 4094.
Use a hyphen to specify a range of VLAN tags.
You can specify a maximum of 50 VLAN conditions.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
VLAN tags to constrain this configuration can have unexpected results. Using override-enabled objects allows
descendant domain administrators to tailor Global configurations to their local environments.
Note VLAN tags in access rules only apply to inline sets; they cannot be used in access
rules applied to firewall interfaces.
Leave matching criteria empty whenever possible, especially those for security zones, network objects, and
port objects. When you specify multiple criteria, the system must match against every combination of the
contents of the criteria you specify.
•
Caution Adding the first or removing the last active authentication rule when SSL
decryption is disabled (that is, when the access control policy does not include
an SSL policy) restarts the Snort process when you deploy configuration changes,
temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on how the target device
handles traffic. See Snort® Restart Traffic Behavior, on page 390 for more
information.
Note that an active authentication rule has either an Active Authentication rule
action, or a Passive Authentication rule action with Use active authentication
if passive or VPN identity cannot be established selected.
• IMCP echo—A destination ICMP port with the type set to 0 or a destination ICMPv6 port with the type
set to 129 only matches unsolicited echo replies. ICMP echo replies sent in response to ICMP echo
requests are ignored. For a rule to match on any ICMP echo, use ICMP type 8 or ICMPv6 type 128.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Encapsulation Conditions
Encapsulation conditions are specific to tunnel rules.
These conditions control certain types of plaintext, passthrough tunnels by their encapsulation protocol. You
must choose at least one protocol to match before you can save the rule. You can choose:
• GRE (47)
• IP-in-IP (4)
• IPv6-in-IP (41)
• Teredo (UDP (17)/3455)
Caution Failure to set up your access control rules properly can have unexpected results, including traffic being allowed
that should be blocked. In general, application control rules should be lower in your access control list because
it takes longer for those rules to match than rules based on IP address, for example.
Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before
rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect
(OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data
link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session,
presentation, and application) should be ordered later in your access control rules. For more information about
the OSI model, see this Wikipedia article.
Related Topics
Overview: Application Detection, on page 2051
Step 2 (Optional) For an access control rule, enable content restriction features by clicking dimmed for Safe search ( ) or
YouTube EDU ( ) and setting related options.
For additional configuration requirements, see Using Access Control Rules to Enforce Content Restriction, on page 1443.
In most cases, enabling content restriction populates the condition's Selected Applications and Filters list with the
appropriate values. The system does not automatically populate the list if applications or filters related to content restriction
are already present in the list when you enable content restriction.
Continue with the procedure to refine your application and filter selections, or skip to saving the rule.
Step 3 Find and choose the applications you want to add from the Available Applications list.
To constrain the applications displayed in Available Applications, choose one or more Application Filters or search
for individual applications.
Tip
Click Information ( ) next to an application to display summary information and internet search links. Unlock
marks applications that the system can identify only in decrypted traffic.
When you choose filters, singly or in combination, the Available Applications list updates to display only the applications
that meet your criteria. You can choose system-provided filters in combination, but not user-defined filters.
• Multiple filters for the same characteristic (risk, business relevance, and so on)—Application traffic must match
only one of the filters. For example, if you choose both the medium and high-risk filters, the Available Applications
list displays all medium and high-risk applications.
• Filters for different application characteristics—Application traffic must match both filter types. For example, if
you choose both the high-risk and low business relevance filters, the Available Applications list displays only
applications that meet both criteria.
The web interface lists filters added to a condition above and separately from individually added applications.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Application Characteristics
The system characterizes each application that it detects using the criteria described in the following table.
Use these characteristics as application filters.
Type Application protocols represent HTTP and SSH are application protocols.
communications between hosts.
Web browsers and email clients are clients.
Clients represent software running on a
MPEG video and Facebook are web
host.
applications.
Web applications represent the content or
requested URL for HTTP traffic.
Risk The likelihood that the application is being Peer-to-peer applications tend to have a
used for purposes that might be against your very high risk.
organization’s security policy.
Business Relevance The likelihood that the application is being Gaming applications tend to have a very
used within the context of your low business relevance.
organization’s business operations, as
opposed to recreationally.
Category A general classification for the application Facebook is in the social networking
that describes its most essential function. category.
Each application belongs to at least one
category.
Tag Additional information about the Video streaming web applications often are
application. Applications can have any tagged high bandwidth and
number of tags, including none. displays ads.
Configure Your Policy to Examine the Packets That Must Pass Before an Application Is Identified
The system cannot perform application control, including Intelligent Application Bypass (IAB) and rate
limiting, before both of the following occur:
• A monitored connection is established between a client and server
• The system identifies the application in the session
This identification should occur in 3 to 5 packets, or after the server certificate exchange in the SSL handshake
if the traffic is encrypted.
Important! To ensure that your system examines these initial packets, see Specify a Policy to Handle Packets
That Pass Before Traffic Identification, on page 1848.
If early traffic matches all other criteria but application identification is incomplete, the system allows the
packet to pass and the connection to be established (or the SSL handshake to complete). After the system
completes its identification, the system applies the appropriate action to the remaining session traffic.
Rules that include both application and URL criteria should come after application-only or URL-only rules,
unless the application+URL rule is acting as an exception to a more general application-only or URL-only
rule.
Caution Failure to set up your access control rules properly can have unexpected results, including traffic being allowed
that should be blocked. In general, application control rules should be lower in your access control list because
it takes longer for those rules to match than rules based on IP address, for example.
Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before
rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect
(OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data
link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session,
presentation, and application) should be ordered later in your access control rules. For more information about
the OSI model, see this Wikipedia article.
The following table provides an example of how to set up your access control rules:
Type of control Action Zones, Users Applications Ports URLs SGT/ISE Inspection,
Networks, Attributes Logging,
VLAN Tags Comments
Application Your Destination Any Do not set Available Any Use only Any
from more choice zones or Ports : with
secure to less (Allow in networks SSH ISE/ISE-PIC.
secure network this using the
Add to
when example) outside
Selected
application interface
Destination
uses a port (for
Ports
example, SSH)
Application Your Destination Any Do not set Selected Do Use only Any
from more choice zones or Destination not with
secure to less (Allow in networks Ports set ISE/ISE-PIC.
secure network this using the Protocol:
when example) outside ICMP
application interface
Type: Any
does not use a
port (for
example,
ICMP)
Application Your Your Choose a Choose the Do not set Do Use only Your
access by a choice choice user group name of the not with choice
user group (Block in (Contractors application set ISE/ISE-PIC.
this group in ( Facebook
example) this in this
example) example)
• Zoho:
See Best Practices for Application Control, on page 421
• Evasive applications such as Bittorrent, Tor, Psiphon, and Ultrasurf:
For evasive applications, only the highest-confidence scenarios are detected by default. If you need to
take action on this traffic (such as block or implement QoS), it may be necessary to configure more
aggressive detection with better effectiveness. To do this, contact TAC to review your configurations as
these changes may result in false positives.
• WeChat:
It is not possible to selectively block WeChat Media if you allow WeChat.
Caution Failure to set up your access control rules properly can have unexpected results, including traffic being allowed
that should be blocked. In general, application control rules should be lower in your access control list because
it takes longer for those rules to match than rules based on IP address, for example.
Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before
rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect
(OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data
link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session,
presentation, and application) should be ordered later in your access control rules. For more information about
the OSI model, see this Wikipedia article.
The following table provides an example of how to set up your access control rules:
Type of control Action Zones, Users Applications Ports URLs SGT/ISE Inspection,
Networks, Attributes Logging,
VLAN Tags Comments
Application Your Destination Any Do not set Available Any Use only Any
from more choice zones or Ports : with
secure to less (Allow in networks SSH ISE/ISE-PIC.
secure network this using the
Add to
when example) outside
Selected
application interface
Destination
uses a port (for
Ports
example, SSH)
Application Your Destination Any Do not set Selected Do Use only Any
from more choice zones or Destination not with
secure to less (Allow in networks Ports set ISE/ISE-PIC.
secure network this using the Protocol:
when example) outside ICMP
application interface
Type: Any
does not use a
port (for
example,
ICMP)
Application Your Your Choose a Choose the Do not set Do Use only Your
access by a choice choice user group name of the not with choice
user group (Block in (Contractors application set ISE/ISE-PIC.
this group in ( Facebook
example) this in this
example) example)
host until the user logs off (as reported by an identity source), a realm times out the session, or you delete the
user data from the system's database.
For information on the authoritative user identity sources supported in your version of the Firepower System,
see About User Identity Sources, on page 2004.
You can use the following rule conditions to perform user control:
• User and realm conditions—Match traffic based on the logged-in authoritative user of a host. You can
control traffic based on realms, individual users, or the groups those users belong to.
• ISE attribute conditions—Match traffic based on a user's ISE-assigned Security Group Tag (SGT), Device
Type (also referred to as Endpoint Profile), or Location IP (also referred to as Endpoint Location).
Requires that you configure ISE as an identity source.
Note The ISE-PIC identity source does not provide ISE attribute data.
Note In some rules, custom SGT conditions can match traffic tagged with SGT attributes that were not assigned
by ISE. This is not considered user control, and only works if you are not using ISE as an identity source; see
Custom SGT Conditions, on page 431.
Rule Type Supports User and Realm Conditions? Supports ISE Attribute Conditions?
SSL yes no
Related Topics
The User Agent Identity Source, on page 2129
The ISE/ISE-PIC Identity Source, on page 2089
The Terminal Services (TS) Agent Identity Source, on page 2125
The Captive Portal Identity Source, on page 2107
If you configure an ISE/ISE/PIC , user agent, or TS Agent device to monitor a large number of user groups,
or if you have a very large number of users mapped to hosts on your network, the system may drop user
mappings based on groups, due to your Firepower Management Center user limit. As a result, rules with
realm, user, or user group conditions may not match traffic as expected.
Configure Realms
Configure a realm for each AD or LDAP server you want to monitor, including your ISE/ISE-PIC, User
Agent, and TS Agent servers, and perform a user download. For more information, see Create a Realm, on
page 2073.
Note If you are configuring an ISE SGT attribute rule condition, configuring a realm is optional. The ISE SGT
attribute rule condition can be configured in policies with or without an associated identity policy (where
realms are invoked).
When you configure a realm, you specify the users and user groups whose activity you want to monitor.
Including a user group automatically includes all of that group’s members, including members of any secondary
groups. However, if you want to use the secondary group as a rule criterion, you must explicitly include the
secondary group in the realm configuration.
For each realm, you can enable automatic download of user data to refresh authoritative data for users and
user groups.
Step 2 (Optional) Find and choose the realm you want to use from the Available Realms.
Step 3 (Optional) Further constrain the rule by choosing users and groups from the Available Users list.
Step 4 Click Add to Rule, or drag and drop.
Step 5 Save or continue editing the rule.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the rule editor, click the following for ISE attribute conditions:
• Access control—Click SGT/ISE Attributes.
You can use ISE-assigned Security Group Tags (SGTs) to constrain ISE attribute conditions. To use custom SGTs in
access control rules, see Custom SGT Conditions, on page 431.
Step 2 Find and choose the ISE attributes you want to use from the Available Attributes list:
• Security Group Tag (SGT)
• Device Type (also referred to as Endpoint Profile)
Step 3 Further constrain the rule by choosing attribute metadata from the Available Metadata list. Or, keep the default: any.
Step 4 Click Add to Rule, or drag and drop.
Step 5 (Optional) Constrain the rule with an IP address in the Add a Location IP Address field, then click Add.
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.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Rules targeting realms, users, or user groups are not matching traffic
If you configure a TS Agent, user agent, or ISE/ISE-PIC device to monitor a large number of user groups, or
if you have a very large number of users mapped to hosts on your network, the system may drop user records
due to your Firepower Management Center user limit. As a result, rules with user conditions may not match
traffic as expected.
Rules targeting user groups or users within user groups are not matching traffic as expected
If you configure a rule with a user group condition, your LDAP or Active Directory server must have user
groups configured. The system cannot perform user group control if the server organizes the users in basic
object hierarchy.
Rules targeting users in secondary groups are not matching traffic as expected
If you configure a rule with a user group condition that includes or excludes users who are members of a
secondary group on your Active Directory server, your server may be limiting the number of users it reports.
By default, Active Directory servers limit the number of users they report from secondary groups. You must
customize this limit so that all of the users in your secondary groups are reported to the Firepower Management
Center and eligible for use in rules with user conditions.
Rules are not matching users when seen for the first time
After the system detects activity from a previously-unseen user, the system retrieves information about them
from the server. Until the system successfully retrieves this information, activity seen by this user is not
handled by matching rules. Instead, the user session is handled by the next rule it matches (or the policy's
default action, if applicable).
For example, this might explain when:
• Users who are members of user groups are not matching rules with user group conditions.
• Users who were reported by a TS Agent, user agent, or ISE/ISE-PIC device are not matching rules,
when the server used for user data retrieval is an Active Directory server.
Note that this might also cause the system to delay the display of user data in event views and analysis tools.
Note If you use ISE SGTs to match traffic, even if a packet does not have an assigned SGT attribute, the packet
still matches an ISE SGT rule if the SGT associated with the packet's source IP address is known in ISE.
ISE SGT ISE identity source SGTs obtained by querying the ISE server, with
automatically updated metadata
Related Topics
User, Realm, and ISE Attribute Conditions (User Control), on page 426
If you configure ISE, Cisco recommends that you delete or disable existing rules with custom SGT conditions.
Instead, use ISE attribute conditions to match traffic with SGT attributes.
Related Topics
Configure ISE/ISE-PIC for User Control, on page 2100
Step 3 In the Available Metadata list, find and choose a custom SGT object.
If you choose Any, the rule matches all traffic with an SGT attribute. For example, you might choose this value if you
want an access control rule to block traffic from hosts that are not configured for TrustSec.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 (Optional) Assign a local time zone to each device. By default, devices use the UTC time zone.
Go to Devices > Platform Settings and create and assign time zone objects.
Step 3 (Other rule types) Click Search Rules, enter a complete or partial search string, then press Enter.
The matching value is highlighted for each matching rule. A status message displays the current match and the total
number of matches.
Step 4 View the rules you are interested in.
To navigate between matching rules, click Next-Match or Previous-Match .
(Access control rules only) To display either a list of only matching rules or a list of all rules with matching rules
highlighted, click Search Rules ( )
What to do next
• Before you begin a new search, click Clear ( ) to clear the search and any highlighting.
Step 1 In the policy editor, click Rules, then click Filter by Device.
A list of targeted devices and device groups appears.
Step 2 Check one or more check boxes to display only the rules that apply to those devices or groups. Or, check All to reset and
display all of the rules.
Tip Hover your pointer over a rule criterion to see its value. If the criterion represents an object with device-specific
overrides, the system displays the override value when you filter the rules list by only that device. If the criterion
represents an object with domain-specific overrides, the system displays the override value when you filter the
rules list by devices in that domain.
Related Topics
Create and Edit Access Control Rules, on page 1361
Configure Prefiltering, on page 1421
Configuring QoS Rules, on page 708
Configure NAT for Threat Defense, on page 1227
Important The system does not flag rules that partially match other rules, which may also prevent some subsequent rules
from matching.
Step 4 To view issue details, hover your pointer over the icon.
Step 5 Look for duplications that are not flagged because they are only partial matches and address them.
Step 6 If you make changes, you must click Save or deselect and reselect Show Rule Conflicts to evaluate the changed rules
for conflicts.
What to do next
• Address any issues you see by removing or modifying the problematic rule.
• Examine your SSL and QoS policies for similar errors and warnings and address those issues.
Tip Hover your pointer over an icon to read the warning, error, or informational text.
Errors ( ) If a rule or configuration has an A rule that performs category and reputation-based
error, you cannot deploy until you URL filtering is valid until you target a device that
error correct the issue, even if you does not have a URL Filtering license. At that point,
disable any affected rules. an error icon appears next to the rule, and you cannot
deploy until you edit or delete the rule, retarget the
policy, or enable the license.
You can deploy a policy that Preempted rules or rules that cannot match traffic due
Warning ( )
displays rule or other warnings. to misconfiguration have no effect. This includes
warning However, misconfigurations conditions using empty object groups, application
marked with warnings have no filters that match no applications, excluded LDAP
effect. users, invalid ports, and so on.
If you disable a rule with a However, if a warning icon marks a licensing error
warning, the warning icon or model mismatch, you cannot deploy until you
disappears. It reappears if you correct the issue.
enable the rule without correcting
the underlying issue.
Information Information icons convey helpful With application control, the system might skip
information about configurations matching the first few packets of a connection against
( )
that may affect the flow of traffic. some rules, until the system identifies the application
information These issues do not prevent you or web traffic in that connection. This allows
from deploying. connections to be established so that applications and
HTTP requests can be identified.
Related Topics
Best Practices for Application Control, on page 421
Best Practices for URL Filtering, on page 1371
View object details from prefilter policies 6.6 You can now view source and destination
network (IP address), port, and VLAN Tag
objects and object groups from rules in
prefilter policies: Right-click an eligible
object and choose Object Details.
New/modified pages: Prefilter rules page.
Supported platforms: FMC
Enhanced searching on configured rules 6.6 You can now search configured rules on
multiple columns (Access control policies
only.)
New/modified pages: Access control rules
page.
Supported platforms: FMC
Time range support for prefilter rules 6.6 Ability to specify an absolute or recurring
time or time range for a rule to be applied.
The rule is applied based on the time zone
of the device that processes the traffic.
New/modified pages: Prefilter rule
configuration page.
Supported platforms: FTD devices only
Moved information about URL conditions 6.3 Moved information about URL filtering,
to a new URL Filtering chapter including dedicated topics about URL
conditions, to URL Filtering, on page 1369.
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.
Interface: no no
• Security Zone
• Interface Group
Tunnel Zone no no
Application Filter no no
Geolocation no no
Time Range no no
Variable Set no no
Sinkhole no no
File List no no
SLA Monitor no no
AS Path no yes
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.
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.
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.
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.
• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides,
on page 447. You can change this setting only for objects that belong to the current domain.
• If you want to add override values to this object, expand the Override section and click Add; see Adding Object
Overrides, on page 447.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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.
• Objects > Object Management > Interface. Click the binoculars button Find Usage ( ) for an interface object.
• Policies > Access Control > Rules. Click Networks, VLAN Tag, Ports, or URLs.
• Devices > Device Management > Routing. Choose any of the routing objects.
Step 2 Select the desired objects, right-click, and then choose Object Details.
The Object Details window lists the selected objects.
Sorting 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.
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.
• 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 447.
What to do next
• If an active policy references your object group, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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
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)
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 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 447.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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:
209.165.200.225
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:
209.165.200.225-209.165.200.250
IPv6 example:
2001:db8:0:cd30::1-2001:db8:0:cd30::1000
Network
An address block, also known as a subnet.
IPv4 example:
209.165.200.224/27
IPv6 example:
2001:DB8:0:CD30::/60
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:
www.example.com
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
508 and the DNS platform settings in Configure DNS, on page 1157.
Group
A group of network objects or other network object groups.
For example:
209.165.200.225
209.165.201.1
209.165.202.129
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.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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:
• http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml
• http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml
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
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.
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.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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, on page 1425.
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), on page 417.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
Step 2 Choose 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, on page 385.
Related Topics
Autotransition from Custom SGTs to ISE SGTs, on page 432
Custom SGT Conditions, on page 431
ISE SGT vs Custom SGT Rule Conditions, on page 431
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, on page 1380.
Each URL object you configure represents a single URL or IP address. You can use URL objects and groups
in various places in the system’s web interface, including access control policies and event searches.
The system makes a simple substring match on any URL that you enter, which may not necessarily be what
you expect. See matching example URLs at Manual URL Filtering Options, on page 1380.
When creating URL objects, especially if you do not configure SSL inspection to decrypt or block encrypted
traffic, keep the following points in mind:
• 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 example.com rather than www.example.com.
• When matching web traffic using access control rules with URL conditions, 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 refine the rule. When creating
a URL object, you do not need to specify the protocol when creating an object. For example, use
example.com rather than http://example.com/.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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).
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, on page 385.
Although tunnel zones are not interface objects, you can use them in place of security zones in certain
configurations; see Tunnel Zones and Prefiltering, on page 1425.
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.
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.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
What to do next
Configure time ranges in any of the following:
• Access control rules
• Prefilter rules
• Tunnel rules
• VPN group policy
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 524 and Group Policy Advanced Options, on page 529.
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.
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 471
Managing Variable Sets, on page 470
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:
• 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.
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.
Defines Domain Name Service (DNS) Not required in current rule set.
$DNS_SERVERS
servers. If you create a rule that affects
DNS servers specifically, you can use the
$DNS_SERVERS variable as a destination or
source IP address.
Defines the network that the Firepower Yes, you should adequately define
$EXTERNAL_NET
System views as the unprotected network, $HOME_NET and then exclude $HOME_NET as
and is used in many rules to define the the value for $EXTERNAL_NET.
external network.
Defines the ports of FTP servers on your Yes, if your FTP servers use ports other
$FTP_PORTS
network, and is used for FTP server exploit than the default ports (you can view the
rules. default ports in the web interface).
Defines the network that the associated Yes, to include the IP addresses for your
$HOME_NET
intrusion policy monitors, and is used in internal network.
many rules to define the internal network.
Defines the ports of web servers on your Yes, if your web servers use ports other
$HTTP_PORTS
network, and is used for web server exploit than the default ports (you can view the
rules. default ports in the web interface).
Defines the web servers on your network. Yes, if you run HTTP servers.
$HTTP_SERVERS
Used in web server exploit rules.
Defines Oracle database server ports on Yes, if you run Oracle servers.
$ORACLE_PORTS
your network, and is used in rules that scan
for attacks on Oracle databases.
Defines SIP servers on your network, and Yes, if you run SIP servers, you should
$SIP_SERVERS
is used in rules that address SIP-targeted adequately define $HOME_NET and then
exploits. include $HOME_NET as the value for
$SIP_SERVERS.
Defines SMTP servers on your network, Yes, if you run SMTP servers.
$SMTP_SERVERS
and is used in rules that address exploits
that target mail servers.
Defines SNMP servers on your network, Yes, if you run SNMP servers.
$SNMP_SERVERS
and is used in rules that scan for attacks on
SNMP servers.
Identifies a legacy advanced variable that No, you can only view or delete this
$SNORT_BPF
appears only when it existed on your system variable. You cannot edit it or recover it
in a Firepower System software release after deleting it.
before Version 5.3.0 that you subsequently
upgraded to Version 5.3.0 or greater.
Defines database servers on your network, Yes, if you run SQL servers.
$SQL_SERVERS
and is used in rules that address
database-targeted exploits.
Defines the ports of SSH servers on your Yes, if your SSH servers use ports other
$SSH_PORTS
network, and is used for SSH server exploit than the default port (you can view the
rules. default ports in the web interface).
Defines SSH servers on your network, and Yes, if you run SSH servers, you should
$SSH_SERVERS
is used in rules that address SSH-targeted adequately define $HOME_NET and then
exploits. include $HOME_NET as the value for
$SSH_SERVERS.
Defines known Telnet servers on your Yes, if you run Telnet servers.
$TELNET_SERVERS
network, and is used in rules that address
Telnet server-targeted exploits.
Provides a general tool that allows you to No, only as instructed in a feature
$USER_CONF
configure one or more features not description or with the guidance of Support.
otherwise available via the web interface.
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
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 192.168.1.1 specifies any IP address other than 192.168.1.1, 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 192.168.1.1 and 192.168.1.5 includes any IP address other than 192.168.1.1 or 192.168.1.5.
That is, the system interprets this as “not 192.168.1.1 and not 192.168.1.5,” 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 192.168.5.0/24 and exclude 192.168.6.0/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
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.
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.
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.
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
You can customize the value of Var1 in any set. In Custom Set 2 where Var1 has not been customized, its
value is 192.168.1.0/24. In Custom Set 1 the customized value 192.168.2.0/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.
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 192.168.1.0/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 192.168.1.0/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.
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.
• 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 442.
• 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 471.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
Managing 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.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
• Edit — Click Edit ( ) next to the variable you want to edit; see Editing Variables, on page 473.
• 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, on page 385.
Adding Variables
You must have the Threat license (for FTD devices) or the Protection license (all other device types).
• 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, on page 385.
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.
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.
• 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 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, on page 385.
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)
These lists are empty until you populate them with your custom information. To build and implement these
lists, use the Whitelist Now and Blacklist Now actions in supported policies. For information, see Blacklist
Now, Whitelist Now, and Global Lists, on page 476.
By default, access control and DNS policies use Global Block lists and Allow 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 480.
Custom Lists
Custom lists can augment and fine-tune feeds and the Global lists.
See Custom Security Intelligence Lists, on page 481.
Default (but custom-populated) Add entries using the context menu. No after adding entries.
Allow lists and Block lists: Global,
Delete entries using the object Yes after deleting entries.
descendant, and domain-specific
manager.
Custom Allow lists and Block lists Upload new and replacement lists Yes
using the object manager.
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 Allow list does not automatically trust
or fastpath matching traffic. For more information, see About Security Intelligence, on page 1393.
Blacklist HTTP/S Connections to URL Now A URL Global Block List for URL
Whitelist HTTP/S Connections to URL Now Global Allow List for URL
Blacklist HTTP/S Connections to Domain An entire domain Global Block List for URL
Now
Global Allow List for URL
Whitelist HTTP/S Connections to Domain
Now
Blacklist DNS Requests to Domain Now DNS requests for an entire Global Block List for DNS
domain
Whitelist DNS Requests to Domain Now Global Allow List for DNS
In a multidomain deployment, you can choose the Firepower System domains where you want to enforce
blocking or allowing by adding items to Domain lists as well as the Global lists; see Security Intelligence
Lists and Multitenancy, on page 477.
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
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 Allow list - Company A
• Domain Block list for DNS - Company A, Domain Allow list for DNS - Company A
• Domain Block list for URL - Company A, Domain Allow 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 Allow list or 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.
For example, the Global domain has the following Descendant Domain lists:
• Descendant Block lists - Global, Descendant Allow lists - Global
• Descendant Block lists for URL - Global, Descendant Allow lists for URL - Global
• Descendant Block lists for URL - Global, Descendant Allow lists for URL - Global
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.
Note Security Intelligence is updated on managed devices every 30 minutes. You cannot modify this frequency.
If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.
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 www.example.* matches both www.example.com and www.example.co.
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.
Invalid examples:
• example*.com
• example.com/*
• 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.*.*.
Note You cannot add address blocks to Allow lists or 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.
When you configure a feed, you specify its location using a URL; the URL cannot be Punycode-encoded. By
default, the system downloads the entire feed source on the interval you configure, then automatically updates
its managed devices.
See additional requirements at Custom Lists and Feeds: Requirements, on page 478.
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. The md5 checksum must be stored in a simple text file with only the checksum. Comments are not
supported.
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.
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.
Note You cannot add address blocks to an Allow list or 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.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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, on page 385.
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.
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.
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.
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.
• 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.
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, on page 385.
Note After configuration changes are deployed, the system no longer queries the AMP cloud for files on the list.
If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
Note After you deploy configuration changes, the system no longer queries the AMP cloud for files on the list.
If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
Note After you deploy the policies, the system no longer queries the AMP cloud for files on the list.
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.
If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to modify the
object.
• Click Edit ( ) next to the SHA-256 value you want to change, and modify the SHA-256 or Description values as
desired.
• Click Delete ( ) next to the SHA-256 value you want to delete.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
Note After configuration changes are deployed, the system no longer queries the AMP cloud for files on the list.
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.
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.
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, on page 385.
on whether the client and server negotiated the SSL session using a server certificate with the distinguished
name as subject or issuer.
Your distinguished name object can contain the common name attribute (CN). If you add a common name
without “CN=” then the system prepends “CN=” before saving the object.
You can also add a distinguished name with one of each attribute listed in the following table, separated by
commas.
You can define one or more asterisks (*) as wild cards in an attribute. In a common name attribute, you can
define one or more asterisks per domain name label. Wild cards match only within that label, though you can
define multiple labels with wild cards. See the following table for examples.
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 489 separated by commas.
• If you add a common name, you can include multiple labels and wild cards.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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
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
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.
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.
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.
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.
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, on page 385.
You can only reference an internal CA object in an SSL rule if it contains a signed certificate.
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 495
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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.
In a multidomain deployment, click View ( ) to download the certificate and private key for an object in an ancestor
domain.
• 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.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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.
Note Adding a CRL to an object has no effect when the object is used in your ISE/ISE-PIC integration configuration.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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.
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, on page 385.
• 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.
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.
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 , on page
923.
• 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.
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 446 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 502. Then install the certificate on
each managed, headend device.
Related Topics
Installing a Certificate Using Self-Signed Enrollment , on page 539
Installing a Certificate Using SCEP Enrollment, on page 540
Installing a Certificate Using Manual Enrollment, on page 540
Installing a Certificate Using a PKCS12 File, on page 541
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 503.
• 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 FTD 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.
Step 4 (Optional) Open the Certificate Parameters tab and specify the certificate contents. See Certificate Enrollment Object
Certificate Parameters, on page 504.
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
505.
Step 6 (Optional) Click the Revocation tab, and specify the revocation options: See Certificate Enrollment Object Revocation
Options, on page 505.
Step 7 Allow Overrides of this object if desired. See Object Overrides, on page 446 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 , on page 539
Installing a Certificate Using SCEP Enrollment, on page 540
Installing a Certificate Using Manual Enrollment, on page 540
Installing a Certificate Using a PKCS12 File, on page 541
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 http://CA_name:port, 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/pkiclient.exe), you must also include
the nonstandard script location in the URL, in the form of http://CA_name:port/script_location, 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: http://URLHostName/certsrv/mscep/mscep.dll. 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.
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: http://<URLHostName>/certsrv/mscep/mscep.dll.
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.
• 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.
Fields
• Key Type—RSA (default, and only supported option) or 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 an RSA key pair, 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 1024. 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.
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.
Note The Consider the certificate valid if revocation information can not be reached
check box setting is applicable only for FTD 6.4 and lower versions. For FTD
6.5 and later versions, this setting is ignored and bypass will not work.
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.
• 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.
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.
• The start lifetime for accept or send lifetime must be earlier than the respective end lifetime.
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.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
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.
A maximum of 6 DNS servers can belong to one group.
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, on page 1157.
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).
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 457. 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.
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.
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 447.
Step 12 Click Save.
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 447.
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.
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.
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.
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.
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 FTD 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” 10.100.10.1, but “block” the rest of 10.100.10.0/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.
Step 1 Select Objects > Object Management and choose Access Control Lists > Extended from the table of contents.
Step 2 Do one of the following:
• Click Add Extended ACL to create a new 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.
The right-click menu also includes options to cut, copy, and paste entries, or to delete them.
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 10.100.10.5 or 2001:DB8::0DB8:800:200C:417A), or a subnet (in 10.100.10.0/24 or 10.100.10.0
255.255.255.0 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.
Step 4 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides, on
page 447.
Step 5 Click Save.
Step 1 Select Objects > Object Management and choose Access Control Lists > Standard from the table of contents.
Step 2 Do one of the following:
• Click Add Standard ACL to create a new 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.
The right-click menu also includes options to cut, copy, and paste entries, or to delete them.
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.
Step 4 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object Overrides, on
page 447.
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
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 FTD 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 447.
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 FTD 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.
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 447.
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 FTD 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
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 447.
Step 13 Click Save.
VPN Objects
You can use the following VPN objects on FTD 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.
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, on page 915.
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 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, on page 921.
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 VPN.For a
full explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to Use, on page 922.
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 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.
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 VPN.For a full explanation of the options,
see Deciding Which Hash Algorithms to Use, on page 921.
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, on page 921.
• 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.
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 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, on page 921.
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.
Step 3 Enter a Name for this Proposal
Step 5 Choose the ESP Hash method, the hash or integrity algorithm to use in the Proposal for authentication.
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, on page 921.
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, on page
921.
Note There is no group policy attribute inheritance on the FTD. 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 524
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 4 Specify the General parameters for this Group Policy as described in Group Policy General Options, on page 525.
Step 5 Specify the AnyConnect parameters for this Group Policy as described in Group Policy AnyConnect Options, on page
527.
Step 6 Specify the Advanced parameters for this Group Policy as described in Group Policy Advanced Options, on page 529.
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.
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.
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
2. RADIUS attribute for Group Policy
3. Address Pool in Group Policy mapped to a Connection Profile
4. IPv4Address Pool in Connection Profile
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 the IPv4 address of the DHCP
Network for this group. This setting does not support IPv6, address ranges, or subnet specifications. If
not set properly, deployment of the VPN policy fails.
• Default Domain—Name of the default domain. Specify a top-level domain, for example, example.com.
• 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 514 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 524
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 FTD File Objects, on
page 530 for object creation details.
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.
• 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.
• 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 524
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.
Related Topics
Configure Group Policy Objects, on page 524
Navigation Path
Objects > Object Management > VPN > AnyConnect File.
Fields
• Name and Description—Enter the name, up to 128 characters, and an optional description to identify
this file object.
• 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, on page 968
Group Policy AnyConnect Options, on page 527
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.
• Value—The value of the matching rule. The value entered is associated with the selected component
and operator.
Related Topics
Configure Certificate Maps, on page 970
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 FTD 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: 10.10.147.100-10.10.147.177.
FlexConfig Objects
Use FlexConfig policy objects in FlexConfig policies to provide customized configuration of features on FTD
devices that you cannot otherwise configure using Firepower Management Center. For more information on
FlexConfig policies, see FlexConfig Policy Overview, on page 1033.
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, on page 1059.
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, on page
1055.
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.
Step 2 Choose and edit a listed RADIUS Server Group object, or add a new one.
See RADIUS Server Options, on page 534 and RADIUS Server Group Options, on page 533 to configure this object.
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 534.
Related Topics
RADIUS Server Groups, on page 533
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 RADIUS server is done
using routing or specific interface. Select Routing for the RADIUS server connectivity is established by
a path resolved by routing table. Or select Specific Interface and choose an interface from the list or
add a new interface/security zone.
Firepower Threat Defense to RADIUS server connectivity is established via a specified interface, which
is part of a security zone or an interface group. If no interface is selected from the list, diagnostic interface
is used as the default interface.
See Interface Objects: Interface Groups and Security Zones, on page 456.
• Redirect ACL—Select the redirect ACL from the list or add a new one.
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 533
RADIUS Server Group Options, on page 533
See the policies in which interface objects 6.6 See the policies in which interface objects
are used are used.
New/Modified Screens: The Interface
object page in Objects > Object
Management has a new Find Usage ( )
button.
Supported platforms: Firepower
Management Center
Time zone objects introduced 6.6 You can assign time zones to FTD devices,
for use when applying time-based policies.
New/Modified Screens: New Time Zone
Object in Objects > Object Management.
Supported platforms: Firepower
Management Center
Time-based objects can now be used in 6.6 Use time range objects in conjunction with
access control and prefilter policies new time zone objects for applying
time-based rules in access control and
prefilter policies.
You can specify an absolute or recurring
time or time range for a rule to be applied.
The rule is applied based on the time zone
of the device that processes the traffic.
View Object Details from prefilter rule 6.6 Feature introduced: Option to view details
page for an object or object group when viewing
prefilter rules.
New options: Right-clicking a value in any
of the following columns in the prefilter
rule list offers options to view object
details: Source Networks, Destination
Networks, Source Port, Destination Port,
and VLAN Tag.
Supported platforms: Firepower
Management Center
Supported Domains
Any
User Roles
Admin
Network Admin
Step 2 Choose (+) Add to associate and install an enrollment object on a device.
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 and SCEP enrollment types, meaning it does not require any
additional administrator action. Manual certificate enrollment requires extra administrator action.
Note The certificate enrollment on a device does not block the user interface and the enrollment process gets executed
in the background, enabling the user to perform certificate enrollment on other devices in parallel. The progress
of these parallel operations can be monitored on the same user interface. The respective icons display the
certificate enrollment status.
Related Topics
Installing a Certificate Using Self-Signed Enrollment , on page 539
Installing a Certificate Using SCEP Enrollment, on page 540
Installing a Certificate Using Manual Enrollment, on page 540
Installing a Certificate Using a PKCS12 File, on page 541
Step 4 Press Add to start the Self Signed, automatic, enrollment process.
For self signed enrollment type trustpoints, the CA Certificate status will always be displayed, since the managed device
is acting as its own CA and does not need a CA certificate to generate its own Identity Certificate.
The Identity Certificate will go from InProgress to Available as the device creates its own self signed identity certificate.
Step 5 Click the magnifying glass to view the self-signed Identity Certificate created for this device.
What to do next
When enrollment is complete, a trustpoint exists on the device with the same name as the certificate enrollment
object. Use this trustpoint in the configuration of your Site to Site and Remote Access VPN Authentication
Method
Note Using SCEP enrollment establishes a direct connection between the managed device and the CA server. So
be sure your device is connected to the CA server before beginning the enrollment process.
Step 1 On the Devices > Certificates screen, choose Add to open the Add New Certificate dialog.
Step 2 Choose a device from the Device drop-down list.
Step 3 Associate a certificate enrollment object with this device in one of the following ways:
• Choose a Certificate Enrollment Object of the type SCEP from the drop-down list.
• Click (+), to add a new Certificate Enrollment Object, see Adding Certificate Enrollment Objects, on page 502.
Step 5 Click the magnifying glass to view the Identity Certificate created and installed on this device.
What to do next
When enrollment is complete, a trustpoint exists on the device with the same name as the certificate enrollment
object. Use this trustpoint in the configuration of your Site to Site and Remote Access VPN Authentication
Method
Step 7 Click the magnifying glass to view the Identity Certificate for this device.
What to do next
When enrollment is complete, a trustpoint exists on the device with the same name as the certificate enrollment
object. Use this trustpoint in the configuration of your Site to Site and Remote Access VPN Authentication
Method
Step 5 Once Available, click the magnifying glass to view the Identity Certificate for this device.
What to do next
The certificate (trustpoint) on the managed device is named the same as the PKCS#12 file. Use this certificate
in your VPN authentication configuration.
RequirementsandPrerequisitesforClassicDeviceManagement
Model Support
Classic models as indicated in the procedures.
Supported Domains
Leaf unless indicated otherwise.
User Roles
• Admin
• Network Admin
Although Cisco strongly recommends that you keep the default setting, you can choose a different port if the
management port conflicts with other communications on your network. Usually, changes to the management
port are made during installation.
Caution If you change the management port, you must change it for all appliances in your deployment that need to
communicate with each other.
What to do next
Repeat this procedure for every appliance in your deployment that must communicate with this appliance.
Field Description
Name Each interface type is represented by a unique icon that indicates its type and link state
(if applicable). You can hover your pointer over the name or the icon to view a tooltip
with additional information. The interface icons are described in Interface Icons, on
page 547.
The icons use a badging convention to indicate the current link state of the interface,
which may be one of three states:
• Error
• Fault
• Not available
ASA FirePOWER modules do not display link state. Note that disabled interfaces are
represented by semi-transparent icons.
Interface names, which appear to the right of the icons, are auto-generated with the
exception of ASA FirePOWER interfaces, which are user-defined. Note that for ASA
FirePOWER interfaces, the system displays only interfaces that are enabled, named,
and have link.
ASA FirePOWER interfaces display the name of the security context and the name of
the interface if there are multiple security contexts. If there is only one security context,
the system displays only the name of the interface.
Security Zone The security zone where the interface is assigned. To add or edit a security zone, click
Edit ( ).
MAC Address For NGIPSv devices, the MAC address is displayed so that you can match the network
adapters configured on your device to the interfaces that appear on the Interfaces page.
Interface Icons
Table 65: Interface Icon Types and Descriptions
Inline Inline Sensing interface configured to handle Configuring Inline Interfaces, on page
traffic in an inline deployment. 555
ASA ASA FirePOWER Interface configured on an ASA device Managing Cisco ASA FirePOWER
FirePOWER with the ASA FirePOWER module Interfaces, on page 549
installed.
Note The Firepower Management Center does not display ASA interfaces when the ASA FirePOWER is deployed
in SPAN port mode.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Disabling Interfaces
You can disable an interface by setting the interface type to None. Disabled interfaces appear grayed out in
the interface list.
This procedure applies to NGIPSv.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note You cannot change the type of ASA FirePOWER interface, nor can you disable the interface from the Firepower
Management Center.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note The system trims 18 bytes from the configured MTU value. Do not set the IPv4 MTU lower than 594 or the
IPv6 MTU lower than 1298.
Related Topics
About the MTU, on page 670
Step 3 For each interface logging duplicate connection events, change the Security Zone to another zone, click Save, then
change it back to the desired zone, and click Save again.
Step 4 Repeat steps 2 through 3 for each device logging duplicate events. You must edit all devices before you continue.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Caution Do not deploy configuration changes to any device until you edit the zone setting for interfaces on all devices
you want to sync. You must deploy to all managed devices at the same time.
Classic License
Protection
Supported Domains
Leaf.
User Roles
• Admin
• Network Admin
Note Outbound traffic includes flow control packets. Because of this, passive interfaces on your appliances may
show outbound traffic and, depending on your configuration, generate events; this is expected behavior.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 390 for more information.
Related Topics
MTU Ranges for NGIPSv, on page 549
Snort® Restart Scenarios, on page 388
Step 3 Click Edit ( ) next to the interface you want to configure as a passive interface.
Step 4 Click Passive.
Step 5 If you want to associate the passive interface with a security zone, do one of the following:
• Choose an existing security zone from the Security Zone drop-down list.
• Choose New to add a new security zone; see Creating Security Zone and Interface Group Objects, on page 457.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note For the system to affect traffic, you must deploy relevant configurations to managed devices using routed,
switched, or transparent interfaces, or inline interface pairs.
You can configure the interfaces on your managed device to route traffic between a host on your network and
external hosts through different inline interface pairs, depending on whether the device traffic is inbound or
outbound. This is an asynchronous routing configuration. If you deploy asynchronous routing but you include
only one interface pair in an inline set, the device might not correctly analyze your network traffic because it
might see only half of the traffic.
Adding multiple inline interface pairs to the same inline interface set allows the system to identify the inbound
and outbound traffic as part of the same traffic flow. For passive interfaces only, you can also achieve this by
including the interface pairs in the same security zone.
When the system generates a connection event from traffic passing through an asynchronous routing
configuration, the event may identify an ingress and egress interface from the same inline interface pair. The
configuration in the following diagram, for example, would generate a connection event identifying eth3 as
the ingress interface and eth2 as the egress interface. This is expected behavior in this configuration.
Note If you assign multiple interface pairs to a single inline interface set but you experience issues with duplicate
traffic, reconfigure to help the system uniquely identify packets. For example, you could reassign your interface
pairs to separate inline sets or modify your security zones.
For devices with inline sets, a software bridge is automatically set up to transport packets after the device
restarts. If the device is restarting, there is no software bridge running anywhere. If you enable bypass mode
on the inline set, it goes into hardware bypass while the device is restarting. In that case, you may lose a few
seconds of packets as the system goes down and comes back up, due to renegotiation of link with the device.
However, the system will pass traffic while Snort is restarting.
Related Topics
MTU Ranges for NGIPSv, on page 549
Snort® Restart Scenarios, on page 388
Step 6 Choose an existing inline set from the Inline Set drop-down list, or choose New to add a new inline set.
Note If you add a new inline set, you must configure it after you set up the inline interface; see Adding Inline Sets,
on page 557.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
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.
Name
The name of the inline set.
Interfaces
A list of all inline interface pairs assigned to the inline set. A pair is not available when you disable either
interface in the pair from the Interfaces tab.
MTU
The maximum transmission unit for the inline set. The range of MTU values can vary depending on the model
of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 390 for more information.
Failsafe
Behavior of the interface on a NGIPSv device when the Snort process is busy or down.
• Enabled—New and existing flows pass without inspection when the Snort process is busy or down.
• Disabled—New and existing flows drop when the Snort process is busy and pass without inspection
when the Snort process is down.
The Snort process can be busy when traffic buffers are full, indicating that there is more traffic than the
managed device can handle, or because of other software issues.
The Snort process goes down when you deploy a configuration that requires it to restart. See Configurations
that Restart the Snort Process When Deployed or Activated, on page 391 for more information.
Note When traffic passes without inspection, features that rely on the Snort process do not function. These include
application control and deep inspection. The system performs only basic access control using simple, easily
determined transport and network layer characteristics.
Related Topics
MTU Ranges for NGIPSv, on page 549
Snort® Restart Scenarios, on page 388
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 390 for more information.
Step 8 If you want to specify that traffic is allowed to bypass detection and continue through the device when the Snort process
is busy or down, choose Failsafe. See Inline Sets on the Firepower System, on page 556 for more information.
Enabling Failsafe on a device with inline sets greatly decreases the risk of dropped packets if the internal traffic buffers
are full, but your device may still drop packets in certain conditions. In the worst case, the device may experience a
temporary network outage.
Step 9 Optionally, configure advanced settings; see Advanced Inline Set Options, on page 558.
Step 10 Click OK.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
MTU Ranges for NGIPSv, on page 549
Snort® Restart Scenarios, on page 388
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 4 Next to the inline set you want to delete, click Delete ( ).
Step 5 When prompted, confirm that you want to delete the inline set.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note The firewall mode only affects regular firewall interfaces, and not IPS-only interfaces such as inline sets or
passive interfaces. IPS-only interfaces can be used in both firewall modes. See Inline Sets and Passive Interfaces
for Firepower Threat Defense, on page 681 for more information about IPS-only interfaces. Inline sets might
be familiar to you as "transparent inline sets," but the inline interface type is unrelated to the transparent
firewall mode described in this chapter or the firewall-type interfaces.
Diagnostic Interface
In addition to each Bridge Virtual Interface (BVI) IP address, you can add a separate Diagnostic slot/port
interface that is not part of any bridge group, and that allows only management traffic to the Firepower Threat
Defense device.
If you do not name the BVI in routed mode, then the Firepower Threat Defense device does not route bridge
group traffic. This configuration replicates transparent firewall mode for the bridge group. If you do not need
clustering or EtherChannel or redundant member interfaces, you might consider using routed mode instead.
In routed mode, you can have one or more isolated bridge groups like in transparent mode, but also have
normal routed interfaces as well for a mixed deployment.
you can control communication between multiple segments on the same network, and not just between inside
and outside. For example, if you have three inside segments that you do not want to communicate with each
other, you can put each segment on a separate interface, and only allow them to communicate with the outside
interface. Or you can customize the access rules between interfaces to allow only as much access as desired.
The following figure shows two networks connected to the Firepower Threat Defense device, which has two
bridge groups.
Figure 8: Transparent Firewall Network with Two Bridge Groups
Figure 9: Routed Firewall Network with an Inside Bridge Group and an Outside Routed Interface
BPDU Handling
To prevent loops using the Spanning Tree Protocol, BPDUs are passed by default.
By default BPDUs are also forwarded for advanced inspection, which is unnecessary for this type of packet,
and which can cause problems if they are blocked due to an inspection restart, for example. We recommend
that you always exempt BPDUs from advanced inspection. To do so, use FlexConfig to configure an EtherType
ACL that trusts BPDUs and exempts them from advanced inspection on each member interface. See FlexConfig
Policies for Firepower Threat Defense, on page 1033.
The FlexConfig object should deploy the following commands, where you replace <if-name> with an interface
name. Add as many access-group commands as needed to cover each bridge group member interface on the
device. You can also choose a different name for the ACL.
• Traffic at least one hop away for which the Firepower Threat Defense device performs NAT—Configure
a static route on the Firepower Threat Defense device for traffic destined for the remote network. You
also need a static route on the upstream router for traffic destined for the mapped addresses to be sent to
the Firepower Threat Defense device.
This routing requirement is also true for embedded IP addresses for VoIP and DNS with NAT enabled,
and the embedded IP addresses are at least one hop away. The Firepower Threat Defense device needs
to identify the correct egress interface so it can perform the translation.
Feature Description
Dynamic DNS —
Feature Description
Dynamic routing protocols You can, however, add static routes for traffic
originating on the Firepower Threat Defense device
for bridge group member interfaces. You can also
allow dynamic routing protocols through the
Firepower Threat Defense device using an access rule.
Multicast IP routing You can allow multicast traffic through the Firepower
Threat Defense device by allowing it in an access rule.
QoS —
VPN termination for through traffic The transparent firewall supports site-to-site VPN
tunnels for management connections only on bridge
group member interfaces. It does not terminate VPN
connections for traffic through the Firepower Threat
Defense device. You can pass VPN traffic through
the ASA using an access rule, but it does not terminate
non-management connections.
Feature Description
Dynamic DNS —
DHCP relay The routed firewall can act as a DHCPv4 server, but
it does not support DHCP relay on BVIs or bridge
group member interfaces.
Dynamic routing protocols You can, however, add static routes for BVIs. You
can also allow dynamic routing protocols through the
Firepower Threat Defense device using an access rule.
Non-bridge group interfaces support dynamic routing.
Multicast IP routing You can allow multicast traffic through the Firepower
Threat Defense device by allowing it in an access rule.
Non-bridge group interfaces support multicast routing.
Feature Description
VPN termination for through traffic You cannot terminate a VPN connection on the BVI.
Non-bridge group interfaces support VPN.
Bridge group member interfaces support site-to-site
VPN tunnels for management connections only. It
does not terminate VPN connections for traffic
through the Firepower Threat Defense device. You
can pass VPN traffic through the bridge group using
an access rule, but it does not terminate
non-management connections.
Default Settings
Bridge Group Defaults
By default, all ARP packets are passed within the bridge group.
• For the Firepower 4100/9300, data-sharing interfaces are not supported as bridge group members.
• In transparent mode, you must use at least 1 bridge group; data interfaces must belong to a bridge group.
• In transparent mode, do not specify the BVI IP address as the default gateway for connected devices;
devices need to specify the router on the other side of the Firepower Threat Defense device as the default
gateway.
• In transparent mode, the default route, which is required to provide a return path for management traffic,
is only applied to management traffic from one bridge group network. This is because the default route
specifies an interface in the bridge group as well as the router IP address on the bridge group network,
and you can only define one default route. If you have management traffic from more than one bridge
group network, you need to specify a regular static route that identifies the network from which you
expect management traffic.
• In transparent mode, PPPoE is not supported for the Diagnostic interface.
• In routed mode, to route between bridge groups and other routed interfaces, you must name the BVI.
• In routed mode, FTD-defined EtherChannel interfaces are not supported as bridge group members.
EtherChannels on the Firepower 4100/9300 can be bridge group members.
• Bidirectional Forwarding Detection (BFD) echo packets are not allowed through the FTD when using
bridge group members. If there are two neighbors on either side of the FTD running BFD, then the FTD
will drop BFD echo packets because they have the same source and destination IP address and appear
to be part of a LAND attack.
You can set the firewall mode when you perform the initial system setup at the CLI. We recommend setting
the firewall mode during setup because changing the firewall mode erases your configuration to ensure you
do not have incompatible settings. If you need to change the firewall mode later, you must do so from the
CLI.
Interface Types
Each interface can be one of the following types:
• Data—Use for regular data. Data interfaces cannot be shared between logical devices, and logical devices
cannot communicate over the backplane to other logical devices. For traffic on Data interfaces, all traffic
must exit the chassis on one interface and return on another interface to reach another logical device.
• Data-sharing—Use for regular data. Only supported with container instances, these data interfaces can
be shared by one or more logical devices/container instances (FTD-using-FMC only). Each container
instance can communicate over the backplane with all other instances that share this interface. Shared
interfaces can affect the number of container instances you can deploy. Shared interfaces are not supported
for bridge group member interfaces (in transparent mode or routed mode), inline sets, passive interfaces,
clusters, or failover links.
• Mgmt—Use to manage application instances. These interfaces can be shared by one or more logical
devices to access external hosts; logical devices cannot communicate over this interface with other logical
devices that share the interface. You can only assign one management interface per logical device. For
ASA: You can later enable management from a data interface; but you must assign a Management
interface to the logical device even if you don't intend to use it after you enable data management. For
information about the separate chassis management interface, see Chassis Management Interface, on
page 575.
• Firepower-eventing—Use as a secondary management interface for FTD-using-FMC devices. To use
this interface, you must configure its IP address and other parameters at the FTD CLI. For example, you
can separate management traffic from events (such as web events). See the FMC configuration guide for
more information. Firepower-eventing interfaces can be shared by one or more logical devices to access
external hosts; logical devices cannot communicate over this interface with other logical devices that
share the interface.
• Cluster—Use as the cluster control link for a clustered logical device. By default, the cluster control link
is automatically created on Port-channel 48. The Cluster type is only supported on EtherChannel interfaces.
For multi-instance clustering, you cannot share a Cluster-type interface across devices. You can add
VLAN subinterfaces to the Cluster EtherChannel to provide separate cluster control links per cluster. If
you add subinterfaces to a Cluster interface, you cannot use that interface for a native cluster. FDM does
not support clustering.
See the following table for interface type support for FTD and ASA applications in standalone and cluster
deployments.
VLAN Subinterfaces
For all logical devices, you can create VLAN subinterfaces within the application.
For container instances in standalone mode only, you can also create VLAN subinterfaces in FXOS (on
interfaces without FXOS subinterfaces). Multi-instance clusters do not support subinterfaces in FXOS except
on the Cluster-type interface. Application-defined subinterfaces are not subject to the FXOS limit. Choosing
in which operating system to create subinterfaces depends on your network deployment and personal preference.
For example, to share a subinterface, you must create the subinterface in FXOS. Another scenario that favors
FXOS subinterfaces comprises allocating separate subinterface groups on a single interface to multiple
instances. For example, you want to use Port-channel1 with VLAN 2–11 on instance A, VLAN 12–21 on
instance B, and VLAN 22–31 on instance C. If you create these subinterfaces within the application, then you
would have to share the parent interface in FXOS, which may not be desirable. See the following illustration
that shows the three ways you can accomplish this scenario:
Figure 11: VLANs in FXOS vs. the Application for Container Instances
If you do not share the same set of subinterfaces with a group of instances, your configuration can cause
more resource usage (more VLAN groups). For example, share Port-Channel1.2, 3, and 4 with instances
1, 2, and 3 (one VLAN group) instead of sharing Port-Channel1.2 and 3 with instances 1 and 2, while
sharing Port-Channel1.3 and 4 with instance 3 (two VLAN groups).
Figure 13: Good: Sharing Multiple Subinterface Groups on One Parent
Table 69: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with Three SM-44s
32: 0 4: 16%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4
30: 0 2: 14%
• 15 • Instance 1
• 15 • Instance 2
30: 1 6: 25%
• 30 (1 ea.) • Instance 1-Instance 6
30: 3: 6: 23%
• 10 (5 ea.) •1 • Instance 1-Instance2
• 10 (5 ea.) •1 • Instance 2-Instance 4
• 10 (5 ea.) •1 • Instance 5-Instance 6
30: 2 5: 28%
• 30 (6 ea.) • Instance 1-Instance 5
30: 4: 5: 26%
• 12 (6 ea.) •2 • Instance 1-Instance2
• 18 (6 ea.) •2 • Instance 2-Instance 5
24: 7 4: 44%
•6 • Instance 1
•6 • Instance 2
•6 • Instance 3
•6 • Instance 4
The following table applies to three SM-44 security modules on a 9300 using subinterfaces on a single parent
physical interface. For example, create a large EtherChannel to bundle all of your like-kind interfaces together,
and then share subinterfaces of that EtherChannel. Sharing multiple physical interfaces uses more forwarding
table resources than sharing multiple subinterfaces.
Each SM-44 module can support up to 14 instances. Instances are split between modules as necessary to stay
within limits.
Table 70: Subinterfaces on One Parent and Instances on a Firepower 9300 with Three SM-44s
Table 71: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with One SM-44
32: 0 4: 16%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4
30: 0 2: 14%
• 15 • Instance 1
• 15 • Instance 2
32: 1 4: 21%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4
32: 2 4: 20%
• 16 (8 ea.) • Instance 1-Instance 2
• 16 (8 ea.) • Instance 3-Instance 4
32: 2 4: 25%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4
32: 4: 4: 24%
• 16 (8 ea.) •2 • Instance 1-Instance 2
• 16 (8 ea.) •2 • Instance 3-Instance 4
24: 8 3: 37%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
10: 10 5: 69%
• 10 (2 ea.) • Instance 1-Instance 5
14: 10 7: 109%
• 12 (2 ea.) • Instance 1-Instance 7 DISALLOWED
The following table applies to the Firepower 9300 with one SM-44 using subinterfaces on a single parent
physical interface. For example, create a large EtherChannel to bundle all of your like-kind interfaces together,
and then share subinterfaces of that EtherChannel. Sharing multiple physical interfaces uses more forwarding
table resources than sharing multiple subinterfaces.
The Firepower 9300 with one SM-44 can support up to 14 instances.
Table 72: Subinterfaces on One Parent and Instances on a Firepower 9300 with One SM-44
Inline Set Link State Propagation for the Firepower Threat Defense
An inline set acts like a bump on the wire, and binds two interfaces together to slot into an existing network.
This function allows the system to be installed in any network environment without the configuration of
adjacent network devices. Inline interfaces receive all traffic unconditionally, but all traffic received on these
interfaces is retransmitted out of an inline set unless explicitly dropped.
When you configure an inline set in the FTD application and enable link state propagation, the FTD sends
inline set membership to the FXOS chassis. Link state propagation means that the chassis automatically brings
down the second interface in the inline interface pair when one of the interfaces in an inline set goes down.
When the downed interface comes back up, the second interface automatically comes back up, also. In other
words, if the link state of one interface changes, the chassis senses the change and updates the link state of
the other interface to match it. Note that the chassis requires up to 4 seconds to propagate link state changes.
Link state propagation is especially useful in resilient network environments where routers are configured to
reroute traffic automatically around network devices that are in a failure state.
Note For the Firepower 9300, you can install different application types (ASA and FTD) on separate modules in
the chassis. You can also run different versions of an application instance type on separate modules.
• Cluster—A clustered logical device lets you group multiple units together, providing all the convenience
of a single device (management, integration into a network) while achieving the increased throughput
and redundancy of multiple devices. Multiple module devices, like the Firepower 9300, support
intra-chassis clustering. For the Firepower 9300, all three modules must participate in the cluster, for
both native and container instances. FDM does not support clustering.
Note Multi-instance capability is similar to ASA multiple context mode, although the
implementation is different. Multiple context mode partitions a single application
instance, while multi-instance capability allows independent container instances.
Container instances allow hard resource separation, separate configuration
management, separate reloads, separate software updates, and full Firepower
Threat Defense feature support. Multiple context mode, due to shared resources,
supports more contexts on a given platform. Multiple context mode is not available
on the Firepower Threat Defense.
For the Firepower 9300, you can use a native instance on some modules, and container instances on the other
module(s).
instance without unique MAC addresses. You can also set the MAC addresses manually when you
configure each interface within the application.
Note If the destination MAC address is a multicast or broadcast MAC address, the packet is duplicated and delivered
to each instance.
Classification Examples
The following figure shows multiple instances sharing an outside interface. The classifier assigns the packet
to Instance C because Instance C includes the MAC address to which the router sends the packet.
Figure 16: Packet Classification with a Shared Interface Using MAC Addresses
Note that all new incoming traffic must be classified, even from inside networks. The following figure shows
a host on the Instance C inside network accessing the internet. The classifier assigns the packet to Instance C
because the ingress interface is Ethernet 1/2.3, which is assigned to Instance C.
For transparent firewalls, you must use unique interfaces. The following figure shows a packet destined to a
host on the Instance C inside network from the internet. The classifier assigns the packet to Instance C because
the ingress interface is Ethernet 1/2.3, which is assigned to Instance C.
For inline sets, you must use unique interfaces and they must be physical interfaces or EtherChannels. The
following figure shows a packet destined to a host on the Instance C inside network from the internet. The
classifier assigns the packet to Instance C because the ingress interface is Ethernet 1/5, which is assigned to
Instance C.
For example:
3 2 3 2
• High Availability—High Availability is only supported between same-type modules on the Firepower
9300. However, the two chassis can include mixed modules. For example, each chassis has an SM-36,
SM-40, and SM-44. You can create High Availability pairs between the SM-36 modules, between the
SM-40 modules, and between the SM-44 modules.
• ASA and FTD application types—You can install different application types on separate modules in the
chassis. For example, you can install ASA on module 1 and module 2, and FTD on module 3.
• ASA or FTD versions—You can run different versions of an application instance type on separate
modules, or as separate container instances on the same module. For example, you can install FTD 6.3
on module 1, FTD 6.4 on module 2, and FTD 6.5 on module 3.
Model Max. Container Available CPU Cores Available RAM Available Disk Space
Instances
Model Max. Container Available CPU Cores Available RAM Available Disk Space
Instances
• High Availability is only supported between same-type modules on the Firepower 9300; but the two
chassis can include mixed modules. For example, each chassis has an SM-36, SM-40, and SM-44. You
can create High Availability pairs between the SM-36 modules, between the SM-40 modules, and between
the SM-44 modules.
• For container instances, each unit must use the same resource profile attributes.
• For other High Availability system requirements, see High Availability System Requirements, on page
713.
Note If you assign a parent interface to a container instance, it only passes untagged
(non-VLAN) traffic. Do not assign the parent interface unless you intend to pass
untagged traffic. For Cluster type interfaces, the parent interface cannot be used.
• Subinterfaces are supported on Data or Data-sharing type interfaces, as well as Cluster type interfaces.
If you add subinterfaces to a Cluster interface, you cannot use that interface for a native cluster.
• For multi-instance clustering, subinterfaces are not supported on Data interfaces. However, subinterfaces
are supported for the cluster control link, so you can use either a dedicated EtherChannel or a subinterface
of an EtherChannel for the cluster control link.
• You can create up to 500 VLAN IDs.
• See the following limitations within the logical device application; keep these limitations in mind when
planning your interface allocation.
• You cannot use subinterfaces for an FTD inline set or as a passive interface.
• If you use a subinterface for the failover link, then all subinterfaces on that parent, and the parent
itself, are restricted for use as failover links. You cannot use some subinterfaces as failover links,
and some as regular data interfaces.
Data-sharing Interfaces
• You cannot use a data-sharing interface with a native instance.
• Maximum 14 instances per shared interface. For example, you can allocate Ethernet1/1 to Instance1
through Instance14.
Maximum 10 shared interfaces per instance. For example, you can allocate Ethernet1/1.1 through
Ethernet1/1.10 to Instance1.
Hardware Bypass
• Supported for the FTD; you can use them as regular interfaces for the ASA.
• The FTD only supports Hardware Bypass with inline sets.
• Hardware Bypass-capable interfaces cannot be configured for breakout ports.
• You cannot include Hardware Bypass interfaces in an EtherChannel and use them for Hardware Bypass;
you can use them as regular interfaces in an EtherChannel.
• Hardware Bypass is not supported with High Availability.
High Availability
• Configure high availability within the application configuration.
• You can use any data interfaces as the failover and state links. Data-sharing interfaces are not supported.
• Multi-instance capability with container instances is only available for the FTD using FMC.
• For FTD container instances, a single Firepower Management Center must manage all instances on a
security module/engine.
• For FTD container instances, the following features are not supported:
• Radware DefensePro link decorator
• FTD configuration backup and restore using FMC
• FMC UCAPL/CC mode
Configure Interfaces
By default, physical interfaces are disabled. You can enable interfaces, add EtherChannels, add VLAN
subinterfaces, and edit interface properties.
Step 2 To enable the interface, click the disabled Slider disabled ( ) so that it changes to the enabled Slider enabled ( ).
Click Yes to confirm the change. The corresponding interface in the visual representation changes from gray to green.
Step 3 To disable the interface, click the enbled Slider enabled ( ) so that it changes to the disabled Slider disabled ( ).
Click Yes to confirm the change. The corresponding interface in the visual representation changes from green to gray.
Step 2 Click Edit in the row for the interface you want to edit to open the Edit Interface dialog box.
Step 3 To enable the interface, check the Enable check box. To disable the interface, uncheck the Enable check box.
Step 4 Choose the interface Type:
See Interface Types, on page 576 for details about interface type usage.
• Data
• Data-sharing—For container instances only.
• Mgmt
• Firepower-eventing—For FTD only.
• Cluster—Do not choose the Cluster type; by default, the cluster control link is automatically created on Port-channel
48.
Step 5 (Optional) Choose the speed of the interface from the Speed drop-down list.
Step 6 (Optional) If your interface supports Auto Negotiation, click the Yes or No radio button.
Step 7 (Optional) Choose the duplex of the interface from the Duplex drop-down list.
Step 8 Click OK.
Note It may take up to three minutes for an EtherChannel to come up to an operational state if you change its mode
from On to Active or from Active to On.
• The EtherChannel is added as a management interface or cluster control link for a logical device that is
part of a cluster
• The EtherChannel is added as a data interface for a logical device that is part of a cluster and at least one
unit has joined the cluster
Note that the EtherChannel does not come up until you assign it to a logical device. If the EtherChannel is
removed from the logical device or the logical device is deleted, the EtherChannel will revert to a Suspended
or Down state.
Step 2 Click Add Port Channel above the interfaces table to open the Add Port Channel dialog box.
Step 3 Enter an ID for the port channel in the Port Channel ID field. Valid values are between 1 and 47.
Port-channel 48 is reserved for the cluster control link when you deploy a clustered logical device. If you do not want
to use Port-channel 48 for the cluster control link, you can delete it and configure a Cluster type EtherChannel with a
different ID.You can add multiple Cluster type EtherChannels and add VLAN subinterfaces for use with multi-instance
clustering. For intra-chassis clustering, do not assign any interfaces to the Cluster EtherChannel.
Step 4 To enable the port channel, check the Enable check box. To disable the port channel, uncheck the Enable check box.
Step 5 Choose the interface Type:
See Interface Types, on page 576 for details about interface type usage.
• Data
• Data-sharing—For container instances only.
• Mgmt
• Firepower-eventing—For FTD only.
• Cluster
Step 6 Set the required Admin Speed for the member interfaces from the drop-down list.
If you add a member interface that is not at the specified speed, it will not successfully join the port channel.
Step 7 For Data or Data-sharing interfaces, choose the LACP port-channel Mode, Active or On.
For non-Data or non-Data-sharing interfaces, the mode is always active.
Step 8 Set the required Admin Duplex for the member interfaces, Full Duplex or Half Duplex.
If you add a member interface that is configured with the specified duplex, it will not successfully join the port channel.
Step 9 To add an interface to the port channel, select the interface in the Available Interface list and click Add Interface to
move the interface to the Member ID list.
You can add up to 16 member interfaces of the same media type and capacity. The member interfaces must be set to
the same speed and duplex, and must match the speed and duplex that you configured for this port channel. The media
type can be either RJ-45 or SFP; SFPs of different types (copper and fiber) can be mixed. You cannot mix interface
capacities (for example 1GB and 10GB interfaces) by setting the speed to be lower on the larger-capacity interface.
Tip You can add multiple interfaces at one time. To select multiple individual interfaces, click on the desired
interfaces while holding down the Ctrl key. To select a range of interfaces, select the first interface in the
range, and then, while holding down the Shift key, click to select the last interface in the range.
Step 10 To remove an interface from the port channel, click the Delete button to the right of the interface in the Member ID
list.
Step 11 Click OK.
Step 2 Click Add New > Subinterface to open the Add Subinterface dialog box.
Step 3 Choose the interface Type:
See Interface Types, on page 576 for details about interface type usage.
• Data
• Data-sharing
• Cluster—If you add subinterfaces to a Cluster interface, you cannot use that interface for a native cluster.
For Data and Data-sharing interfaces: The type is independent of the parent interface type; you can have a Data-sharing
parent and a Data subinterface, for example.
Note Instances with a smaller number of cores might experience relatively higher CPU
utilization than those with larger numbers of cores. Instances with a smaller
number of cores are more sensitive to traffic load changes. If you experience
traffic drops, try assigning more cores.
• You can assign cores as an even number (6, 8, 10, 12, 14 etc.) up to the maximum. Note that we do not
recommend using 8 cores; performance for 8 cores is only slightly better than for 6 cores.
• The maximum number of cores available depends on the security module/chassis model; see Requirements
and Prerequisites for Container Instances, on page 599.
The chassis includes a default resource profile called "Default-Small," which includes the minimum number
of cores. You can change the definition of this profile, and even delete it if it is not in use. Note that this profile
is created when the chassis reloads and no other profile exists on the system.
You cannot change the resource profile settings if it is currently in use. You must disable any instances that
use it, then change the resource profile, and finally reenable the instance. If you resize instances in an established
High Availability pair or cluster, then you should make all members the same size as soon as possible.
If you change the resource profile settings after you add the FTD instance to the FMC, then update the inventory
for each unit on the FMC Devices > Device Management > Device > System > Inventory dialog box.
Step 1 Choose Platform Settings > Resource Profiles , and click Add.
The Add Resource Profile dialog box appears.
• Name—Sets the name of the profile between 1 and 64 characters. Note that you cannot change the name of this
profile after you add it.
• Description—Sets the description of the profile up to 510 characters.
• Number of Cores—Sets the number of cores for the profile, between 6 and the maximum, depending on your
chassis, as an even number.
Note For the Firepower 9300, you can install different application types (ASA and
FTD) on separate modules in the chassis. You can also run different versions of
an application instance type on separate modules.
• Configure a management interface to use with the logical device. The management interface is required.
Note that this management interface is not the same as the chassis management port that is used only for
chassis management (and that appears at the top of the Interfaces tab as MGMT).
• You must also configure at least one Data type interface. Optionally, you can also create a
firepower-eventing interface to carry all event traffic (such as web events). See Interface Types, on page
576 for more information.
• For container instances, if you do not want to use the default profile, add a resource profile according to
Add a Resource Profile for Container Instances, on page 608.
• For container instances, before you can install a container instance for the first time, you must reinitialize
the security module/engine so that the disk has the correct formatting. Choose Security Modules or
Security Engine, and click the Reinitialize icon. An existing logical device will be deleted and then
reinstalled as a new device, losing any local application configuration. If you are replacing a native
instance with container instances, you will need to delete the native instance in any case. You cannot
automatically migrate a native instance to a container instance.
• Gather the following information:
• Interface IDs for this device
• Management interface IP address and network mask
• Gateway IP address
• FMC IP address and/or NAT ID of your choosing
• DNS server IP address
• FTD hostname and domain name
Step 3 Expand the Data Ports area, and click each interface that you want to assign to the device.
You can only assign data and data-sharing interfaces that you previously enabled on the Interfaces page. You will later
enable and configure these interfaces in FMC, including setting the IP addresses.
You can only assign up to 10 data-sharing interfaces to a container instance. Also, each data-sharing interface can be
assigned to at most 14 container instances. A data-sharing interface is indicated by the sharing icon ( ).
Hardware Bypass-capable ports are shown with the following icon: . For certain interface modules, you can enable
the Hardware Bypass feature for Inline Set interfaces only (see the FMC configuration guide). Hardware Bypass ensures
that traffic continues to flow between an inline interface pair during a power outage. This feature can be used to maintain
network connectivity in the case of software or hardware failures. If you do not assign both interfaces in a Hardware
Bypass pair, you see a warning message to make sure your assignment is intentional. You do not need to use the
Hardware Bypass feature, so you can assign single interfaces if you prefer.
a) (For the Firepower 9300) Under Security Module Selection click the security module that you want to use for this
logical device.
b) For a container instance, specify the Resource Profile.
If you later assign a different resource profile, then the instance will reload, which can take approximately 5 minutes.
Note that for established High Availability pairs or clusters, if you assign a different-sized resource profile, be sure
to make all members the same size as soon as possible.
c) Choose the Management Interface.
This interface is used to manage the logical device. This interface is separate from the chassis management port.
d) Choose the management interface Address Type: IPv4 only, IPv6 only, or IPv4 and IPv6.
e) Configure the Management IP address.
Set a unique IP address for this interface.
f) Enter a Network Mask or Prefix Length.
g) Enter a Network Gateway address.
Step 6 On the Settings tab, complete the following:
a) For a native instance, in the Management type of application instance drop-down list, choose FMC.
Native instances also support FDM as a manager. After you deploy the logical device, you cannot change the
manager type.
b) Enter the Firepower Management Center IP of the managing FMC. If you do not know the FMC IP address,
leave this field blank and enter a passphrase in the Firepower Management Center NAT ID field.
c) For a container instance, Permit Expert mode from FTD SSH sessions: Yes or No. Expert Mode provides FTD
shell access for advanced troubleshooting.
If you choose Yes for this option, then users who access the container instance directly from an SSH sesssion can
enter Expert Mode. If you choose No, then only users who access the container instance from the FXOS CLI can
enter Expert Mode. We recommend choosing No to increase isolation between instances.
Use Expert Mode only if a documented procedure tells you it is required, or if the Cisco Technical Assistance
Center asks you to use it. To enter this mode, use the expert command in the FTD CLI.
d) Enter the Search Domains as a comma-separated list.
e) Choose the Firewall Mode: Transparent or Routed.
In routed mode, the FTD is considered to be a router hop in the network. Each interface that you want to route
between is on a different subnet. A transparent firewall, on the other hand, is a Layer 2 firewall that acts like a
“bump in the wire,” or a “stealth firewall,” and is not seen as a router hop to connected devices.
The firewall mode is only set at initial deployment. If you re-apply the bootstrap settings, this setting is not used.
f) Enter the DNS Servers as a comma-separated list.
The FTD uses DNS if you specify a hostname for the FMC, for example.
g) Enter the Fully Qualified Hostname for the FTD.
h) Enter a Registration Key to be shared between the FMC and the device during registration.
You can choose any text string for this key between 1 and 37 characters; you will enter the same key on the FMC
when you add the FTD.
i) Enter a Password for the FTD admin user for CLI access.
j) Choose the Eventing Interface on which Firepower events should be sent. If not specified, the management
interface will be used.
This interface must be defined as a Firepower-eventing interface.
k) For a container instance, set the Hardware Crypto as Enabled or Disabled.
This setting enables TLS crypto acceleration in hardware, and improves performance for certain types of traffic.
This feature is enabled by default. You can enable TLS crypto acceleration for up to 16 instances per security
module. This feature is always enabled for native instances. To view the percentage of hardware crypto resources
allocated to this instance, enter the show hw-crypto command.
Step 7 On the Agreement tab, read and accept the end user license agreement (EULA).
Step 8 Click OK to close the configuration dialog box.
Step 9 Click Save.
The chassis deploys the logical device by downloading the specified software version and pushing the bootstrap
configuration and management interface settings to the application instance. Check the Logical Devices page for the
status of the new logical device. When the logical device shows its Status as online, you can start configuring the
security policy in the application.
Step 10 See the FMC configuration guide to add the FTD as a managed device and start configuring your security policy.
links; the state link requires the most bandwidth. You cannot use the management-type interface for the failover or state
link. We recommend that you use a switch between the chassis, with no other device on the same network segment as
the failover interfaces.
For container instances, data-sharing interfaces are not supported for the failover link. We recommend that you create
subinterfaces on a parent interface or EtherChannel, and assign a subinterface for each instance to use as a failover link.
Note that you must use all subinterfaces on the same parent as failover links. You cannot use one subinterface as a failover
link and then use other subinterfaces (or the parent interface) as regular data interfaces.
Step 3 Enable High Availability on the logical devices. See High Availability for Firepower Threat Defense, on page 713.
Step 4 If you need to make interface changes after you enable High Availability, perform the changes on the standby unit first,
and then perform the changes on the active unit.
Step 3 Allocate a new data interface by selecting the interface in the Data Ports area.
Do not delete any interfaces yet.
i) Select the devices and click Deploy to deploy the policy to the assigned devices. The changes are not active until
you deploy them.
Step 7 In Firepower Chassis Manager, unallocate a data interface by de-selecting the interface in the Data Ports area.
Step 1 Connect to the module CLI using a console connection or a Telnet connection.
connect module slot_number {console | telnet}
To connect to the security engine of a device that does not support multiple security modules, always use 1 as the
slot_number.
The benefits of using a Telnet connection is that you can have multiple sessions to the module at the same time, and the
connection speed is faster.
Example:
Firepower-module1>
Support for VLAN subinterfaces on a 6.6 For use with multi-instance clusters, you can now create VLAN
Cluster type interface (multi-instance subinterfaces on cluster type interfaces. Because each cluster requires
use only) a unique cluster control link, VLAN subinterfaces provide a simple
method to fulfill this requirement. You can alternatively assign a
dedicated EtherChannel per cluster. Multiple cluster interfaces are now
allowed.
New/Modified Firepower Chassis Manager screens:
Interfaces > All Interfaces > Add New drop-down menu >
Subinterface > Type field
New/Modified FXOS commands: set port-type cluster
Note Requires FXOS 2.8.1.
TLS crypto acceleration for multiple 6.5 TLS crypto acceleration is now supported on multiple container
container instances instances (up to 16) on a Firepower 4100/9300 chassis. Previously,
you could enable TLS crypto acceleration for only one container
instance per module/security engine.
New instances have this feature enabled by default. However, the
upgrade does not enable acceleration on existing instances. Instead,
use the enter hw-crypto and then the set admin-state enabled FXOS
commands.
New/Modified Firepower Chassis Manager screens:
Logical Devices > Add Device > Settings > Hardware Crypto
drop-down menu
Note Requires FXOS 2.7.1.
FTD on the Firepower 4115, 4125, and 6.4 We introduced the Firepower 4115, 4125, and 4145.
4145
Note Requires FXOS 2.6.1.157.
Firepower 9300 SM-40, SM-48, and 6.4 We introduced the following three security modules: SM-40, SM-48,
SM-56 support and SM-56.
Note Requires FXOS 2.6.1.157.
Support for ASA and FTD on separate 6.4 You can now deploy ASA and FTD logical devices on the same
modules of the same Firepower 9300 Firepower 9300.
Note Requires FXOS 2.6.1.157.
Support for SSL hardware acceleration 6.4 You can now enable SSL hardware acceleration for one container
on one FTD container instance on a instance on a module/security engine. SSL hardware acceleration is
module/security engine disabled for other container instances, but enabled for native instances.
New/Modified FXOS commands: config hwCrypto enable
No modified screens.
Note Requires FXOS 2.6.1.157.
Multi-instance capability for Firepower 6.3 You can now deploy multiple logical devices, each with a Firepower
Threat Defense on the Firepower Threat Defense container instance, on a single security engine/module.
4100/9300 Formerly, you could only deploy a single native application instance.
To provide flexible physical interface use, you can create VLAN
subinterfaces in FXOS and also share interfaces between multiple
instances. Resource management lets you customize performance
capabilities for each instance.
You can use High Availability using a container instance on 2 separate
chassis. Clustering is not supported.
Note Multi-instance capability is similar to ASA multiple context
mode, although the implementation is different. Multiple
context mode is not available on the Firepower Threat
Defense.
Cluster control link customizable IP 6.3 By default, the cluster control link uses the 127.2.0.0/16 network. You
Address for the Firepower 4100/9300 can now set the network when you deploy the cluster in FXOS. The
chassis auto-generates the cluster control link interface IP address for
each unit based on the chassis ID and slot ID: 127.2.chassis_id.slot_id.
However, some networking deployments do not allow 127.2.0.0/16
traffic to pass. Therefore, you can now set a custom /16 subnet for the
cluster control link in FXOS except for loopback (127.0.0.0/8) and
multicast (224.0.0.0/4) addresses.
New/modified Firepower Chassis Manager screens:
• Logical Devices > Add Device > Cluster Information > CCL
Subnet IP field
Support for data EtherChannels in On 6.3 You can now set data and data-sharing EtherChannels to either Active
mode LACP mode or to On mode. Other types of EtherChannels only support
Active mode.
New/Modified Firepower Chassis Manager screens:
• Interfaces > All Interfaces > Edit Port Channel > Mode
Support for EtherChannels in FTD 6.2 You can now use EtherChannels in a FTD inline set.
inline sets
Supported platforms: Firepower 4100/9300
Inter-chassis clustering for 6 FTD 6.2 You can now enable inter-chassis clustering for the FTD. You can
modules include up to 6 modules in up to 6 chassis.
New/modified Firepower Chassis Manager screens:
• Logical Devices > Configuration
Hardware bypass support on the 6.1 Hardware Bypass ensures that traffic continues to flow between an
Firepower 4100/9300 for supported inline interface pair during a power outage. This feature can be used
network modules to maintain network connectivity in the case of software or hardware
failures.
New/Modified screens:
• Devices > Device Management > Interfaces > Edit Physical
Interface
Inline set link state propagation support 6.1 When you configure an inline set in the FTD application and enable
for the FTD link state propagation, the FTD sends inline set membership to the
FXOS chassis. Link state propagation means that the chassis
automatically brings down the second interface in the inline interface
pair when one of the interfaces in an inline set goes down.
New/Modified FXOS commands: show fault |grep link-down, show
interface detail
Supported platforms: Firepower 4100/9300
Support for intra-chassis clustering on 6.0.1 The Firepower 9300 supports intra-chassis clustering with the FTD
the FTD on the Firepower 9300 application.
New/Modified Firepower Chassis Manager screens:
• Logical Devices > Configuration
Management/Diagnostic Interface
The physical management interface is shared between the Diagnostic logical interface and the Management
logical interface.
Management Interface
The Management logical interface is separate from the other interfaces on the device. It is used to set up and
register the device to the Firepower Management Center. It uses its own IP address and static routing. You
can configure its settings at the CLI using the configure network command. If you change the IP address at
the CLI after you add it to the Firepower Management Center, you can match the IP address in the Firepower
Management Center in the Devices > Device Management > Devices > Management area.
Diagnostic Interface
The Diagnostic logical interface can be configured along with the rest of the data interfaces on the Devices >
Device Management > Interfaces screen. Using the Diagnostic interface is optional (see the routed and
transparent mode deployments for scenarios). The Diagnostic interface only allows management traffic, and
does not allow through traffic. It does not support SSH; you can SSH to data interfaces or to the Management
interface only. The Diagnostic interface is useful for SNMP or syslog monitoring.
IPS-Only Mode
IPS-only mode interfaces bypass many firewall checks and only support IPS security policy. You might want
to implement IPS-only interfaces if you have a separate firewall protecting these interfaces and do not want
the overhead of firewall functions.
Note The firewall mode only affects regular firewall interfaces, and not IPS-only interfaces such as inline sets or
passive interfaces. IPS-only interfaces can be used in both firewall modes.
begin dropping suspicious traffic without having to reconfigure the cabling between the FTD and the
network.
Note Tap mode significantly impacts FTD performance, depending on the traffic.
Note Inline sets might be familiar to you as "transparent inline sets," but the inline
interface type is unrelated to the transparent firewall mode or the firewall-type
interfaces.
• Passive or ERSPAN Passive—Passive interfaces monitor traffic flowing across a network using a switch
SPAN or mirror port. The SPAN or mirror port allows for traffic to be copied from other ports on the
switch. This function provides the system visibility within the network without being in the flow of
network traffic. When you configure the FTD in a passive deployment, the FTD cannot take certain
actions such as blocking or shaping traffic. Passive interfaces receive all traffic unconditionally. and no
traffic received on these interfaces is retransmitted. Encapsulated remote switched port analyzer (ERSPAN)
interfaces allow you to monitor traffic from source ports distributed over multiple switches, and uses
GRE to encapsulate the traffic. ERSPAN interfaces are only allowed when the FTD is in routed firewall
mode.
Some policies only support security zones, while other policies support zones and groups. For specifics, see
Interface Objects: Interface Groups and Security Zones, on page 456. You can create security zones and
interface groups on the Objects page. You can also add a zone when you are configuring the interface. You
can only add interfaces to the correct zone type for your interface, either Passive, Inline, Routed, or Switched
zone types.
The Diagnostic/Management interface does not belong to a zone or interface group.
Auto-MDI/MDIX Feature
For RJ-45 interfaces, the default auto-negotiation setting also includes the Auto-MDI/MDIX feature.
Auto-MDI/MDIX eliminates the need for crossover cabling by performing an internal crossover when a
straight cable is detected during the auto-negotiation phase. Either the speed or duplex must be set to
auto-negotiate to enable Auto-MDI/MDIX for the interface. If you explicitly set both the speed and duplex
to a fixed value, thus disabling auto-negotiation for both settings, then Auto-MDI/MDIX is also disabled. For
Gigabit Ethernet, when the speed and duplex are set to 1000 and full, then the interface always auto-negotiates;
therefore Auto-MDI/MDIX is always enabled and you cannot disable it.
Note For the Firepower 4100/9300, you can administratively enable and disable interfaces in both the chassis and
in the FMC. For an interface to be operational, the interface must be enabled in both operating systems.
Because the interface state is controlled independently, you may have a mismatch between the chassis and
FMC.
This procedure only covers a small subset of Interface settings. Refrain from setting other parameters at this
point. For example, you cannot name an interface that you want to use as part of an EtherChannel or redundant
interface.
Note For the Firepower 4100/9300, you configure basic interface settings in FXOS. See Configure a Physical
Interface, on page 604 for more information.
Note For Firepower 1010 switch ports, see Configure Firepower 1010 Switch Ports, on page 634.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 Enable the interface by checking the Enabled check box.
Step 4 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.
Step 5 (Optional) Set the duplex and speed by clicking Hardware Configuration.
• Duplex—Choose Auto to have the interface negotiate the duplex (Auto is only available for RJ-45 interfaces), or
pick a specific duplex: Half, Full.
• Speed—Choose Auto to have the interface negotiate the speed (Auto is only available for RJ-45 interfaces), or pick
a specific speed: 10, 100, 1000, 10000 Mbps. For SFP interfaces, depending on your hardware, you can select No
Negotiate to set the speed to 1000 and disable link negotiation.
SyncInterfaceChangeswiththeFirepowerManagementCenter
Interface configuration changes on the device can cause the FMC and the device to get out of sync. The FMC
can detect interface changes by one of the following methods:
• Event sent from the device
• Sync when you deploy from the FMC
If the FMC detects interface changes when it attempts to deploy, the deploy will fail. You must first
accept the interface changes.
• Manual sync
When the FMC detects changes, the Interface page shows status (removed, changed, or added) to the left of
each interface.
Adding a new interface, or deleting an unused interface has minimal impact on the FTD configuration.
However, deleting an interface that is used in your security policy will impact the configuration. Interfaces
can be referenced directly in many places in the FTD configuration, including access rules, NAT, SSL, identity
rules, VPN, DHCP server, and so on. Deleting an interface will delete any configuration associated with that
interface. Policies that refer to security zones are not affected. You can also edit the membership of an allocated
EtherChannel without affecting the logical device or requiring a sync on the FMC.
This procedure describes how to manually sync device changes if required and how to acknowledge the
detected changes. If device changes are temporary, you should not save the changes in the FMC; you should
wait until the device is stable, and then re-sync.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 If required, click Sync Device on the top left of Interfaces.
Step 3 After the changes are detected, see the following steps.
a) You will see a red banner on Interfaces indicating that the interface configuration has changed. Click the Click to
know more link to view the interface changes.
b) Click Validate Changes to make sure your policy will still work with the interface changes.
If there are any errors, you need to change your policy and rerun the validation.
c) Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices.
Note For initial interface configuration on the Firepower 4100/9300, see Configure Interfaces, on page 604.
User Roles
• Admin
• Access Admin
• Network Admin
Auto-MDI/MDIX Feature
For all Firepower 1010 interfaces, the default auto-negotiation setting also includes the Auto-MDI/MDIX
feature. Auto-MDI/MDIX eliminates the need for crossover cabling by performing an internal crossover when
a straight cable is detected during the auto-negotiation phase. Either the speed or duplex must be set to
auto-negotiate to enable Auto-MDI/MDIX for the interface. If you explicitly set both the speed and duplex
to a fixed value, thus disabling auto-negotiation for both settings, then Auto-MDI/MDIX is also disabled.
When the speed and duplex are set to 1000 and full, then the interface always auto-negotiates; therefore
Auto-MDI/MDIX is always enabled and you cannot disable it.
Bridge Groups
You cannot mix logical VLAN interfaces and physical firewall interfaces in the same bridge group.
• Multicast routing
• Equal-Cost Multi-Path routing (ECMP)
• Inline sets or Passive interfaces
• EtherChannels
• Redundant Interfaces; the Firepower 1010 does not support redundant interfaces for any interface type.
• Failover and state link
• Security group tagging (SGT)
Default Settings
• Ethernet 1/1 is a firewall interface.
• Ethernet 1/2 through Ethernet 1/8 are switch ports assigned to VLAN 1.
• Default Speed and Duplex—By default, the speed and duplex are set to auto-negotiate.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Set the switch port mode by clicking the slider in the SwitchPort column so it shows as Slider enabled ( ) or Slider
disabled ( ).
By default, switch ports are set to access mode in VLAN 1. You must manually add a logical VLAN 1 interface (or
whichever VLAN you set for these switch ports) for traffic to be routed and to participate in the FTD security policy (see
Configure a VLAN Interface, on page 637). You cannot set the Diagnostic interface to switch port mode. When you
change the switch port mode, all unsupported configuration is removed:
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Add Interfaces > VLAN Interface.
Step 3 On General, set the following VLAN-specific parameters:
If you are editing an existing VLAN interface, the Associated Interface table shows switch ports on this VLAN.
a) Set the VLAN ID, between 1 and 4070.
You cannot change the VLAN ID after you save the interface; the VLAN ID is both the VLAN tag used, and the
interface ID in your configuration.
b) (Optional) Choose a VLAN ID for Disable Forwarding on Interface VLAN to disable forwarding to another VLAN.
For example, you have one VLAN assigned to the outside for internet access, one VLAN assigned to an inside
business network, and a third VLAN assigned to your home network. The home network does not need to access the
business network, so you can disable forwarding on the home VLAN; the business network can access the home
network, but the home network cannot access the business network.
Step 4 To complete the interface configuration, see one of the following procedures:
• Configure Routed Mode Interfaces, on page 657
• Configure General Bridge Group Member Interface Parameters, on page 660
Note The Firepower 1010 does not support Spanning Tree Protocol for loop detection in the network. Therefore
you must ensure that any connection with the FTD does not end up in a network loop.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 7 (Optional) Check the Protected check box to set this switch port as protected, so you can prevent the switch port from
communicating with other protected switch ports on the same VLAN.
You might want to prevent switch ports from communicating with each other if: the devices on those switch ports are
primarily accessed from other VLANs; you do not need to allow intra-VLAN access; and you want to isolate the devices
from each other in case of infection or other security breach. For example, if you have a DMZ that hosts three web
servers, you can isolate the web servers from each other if you enable Protected on each switch port. The inside and
outside networks can both communicate with all three web servers, and vice versa, but the web servers cannot
communicate with each other.
Step 8 (Optional) Set the duplex and speed by clicking Hardware Configuration.
Check the Auto-negotiation check box (the default) to auto-detect the speed and duplex. If you uncheck it, you can
set the speed and duplex manually:
• Duplex—Choose Full or Half.
• Speed—Choose 10mbps, 100mbps, or 1gbps.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 7 In the Allowed VLAN IDs field, enter the VLANs for this trunk port between 1 and 4070.
You can identify up to 20 IDs in one of the following ways:
• A single number (n)
• A range (n-x)
• Numbers and ranges separated by commas, for example:
5,7-10,13,45-100
You can enter spaces instead of commas.
If you include the native VLAN in this field, it is ignored; the trunk port always removes the VLAN tagging when
sending native VLAN traffic out of the port. Moreover, it will not receive traffic that still has native VLAN tagging.
Step 8 (Optional) Check the Protected check box to set this switch port as protected, so you can prevent the switch port from
communicating with other protected switch ports on the same VLAN.
You might want to prevent switch ports from communicating with each other if: the devices on those switch ports are
primarily accessed from other VLANs; you do not need to allow intra-VLAN access; and you want to isolate the devices
from each other in case of infection or other security breach. For example, if you have a DMZ that hosts three web
servers, you can isolate the web servers from each other if you enable Protected on each switch port. The inside and
outside networks can both communicate with all three web servers, and vice versa, but the web servers cannot
communicate with each other.
Step 9 (Optional) Set the duplex and speed by clicking Hardware Configuration.
Check the Auto-negotiation check box (the default) to auto-detect the speed and duplex. If you uncheck it, you can
set the speed and duplex manually:
• Duplex—Choose Full or Half.
• Speed—Choose 10mbps, 100mbps, or 1gbps.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for Ethernet1/7 or 1/8.
Step 3 Click PoE.
Step 5 (Optional) Uncheck the Auto Negotiate Consumption Wattage check box, and enter the Consumption Wattage if you
know the exact wattage you need.
By default, PoE delivers power automatically to the powered device using a wattage appropriate to the class of the powered
device. The Firepower 1010 uses LLDP to further negotiate the correct wattage. If you know the specific wattage and
want to disable LLDP negotiation, enter a value from 4000 to 30000 milliwatts.
Note For the Firepower 4100/9300, you configure EtherChannels in FXOS. See Add an EtherChannel (Port Channel),
on page 605 for more information.
Note Only ASA 5500-X models support redundant interfaces; Firepower models do not support them.
About EtherChannels
An 802.3ad EtherChannel is a logical interface (called a port-channel interface) consisting of a bundle of
individual Ethernet links (a channel group) so that you increase the bandwidth for a single network. A port
channel interface is used in the same way as a physical interface when you configure interface-related features.
You can configure up to 48 EtherChannels, depending on how many interfaces your model supports.
If you use the FTD in an Active/Standby failover deployment, then you need to create separate EtherChannels
on the switches in the VSS/vPC, one for each FTD. On each FTD, a single EtherChannel connects to both
switches. Even if you could group all switch interfaces into a single EtherChannel connecting to both FTD
(in this case, the EtherChannel will not be established because of the separate FTD system IDs), a single
EtherChannel would not be desirable because you do not want traffic sent to the standby FTD.
Figure 22: Active/Standby Failover and VSS/vPC
LACP coordinates the automatic addition and deletion of links to the EtherChannel without user intervention.
It also handles misconfigurations and checks that both ends of member interfaces are connected to the correct
channel group. “On” mode cannot use standby interfaces in the channel group when an interface goes down,
and the connectivity and configurations are not checked.
Load Balancing
The FTD distributes packets to the interfaces in the EtherChannel by hashing the source and destination IP
address of the packet (this criteria is configurable). The resulting hash is divided by the number of active links
in a modulo operation where the resulting remainder determines which interface owns the flow. All packets
with a hash_value mod active_links result of 0 go to the first interface in the EtherChannel, packets with a
result of 1 go to the second interface, packets with a result of 2 go to the third interface, and so on. For example,
if you have 15 active links, then the modulo operation provides values from 0 to 14. For 6 active links, the
values are 0 to 5, and so on.
If an active interface goes down and is not replaced by a standby interface, then traffic is rebalanced between
the remaining links. The failure is masked from both Spanning Tree at Layer 2 and the routing table at Layer
3, so the switchover is transparent to other network devices.
High Availability
• When you use a redundant or EtherChannel interface as a High Availability link, it must be pre-configured
on both units in the High Availability pair; you cannot configure it on the primary unit and expect it to
replicate to the secondary unit because the High Availability link itself is required for replication.
• If you use a redundant or EtherChannel interface for the state link, no special configuration is required;
the configuration can replicate from the primary unit as normal. For the Firepower 4100/9300 chassis,
all interfaces, including EtherChannels, need to be pre-configured on both units.
• You can monitor redundant or EtherChannel interfaces for High Availability. When an active member
interface fails over to a standby interface, this activity does not cause the redundant or EtherChannel
interface to appear to be failed when being monitored for device-level High Availability. Only when all
physical interfaces fail does the redundant or EtherChannel interface appear to be failed (for an
EtherChannel interface, the number of member interfaces allowed to fail is configurable).
• If you use an EtherChannel interface for a High Availability or state link, then to prevent out-of-order
packets, only one interface in the EtherChannel is used. If that interface fails, then the next interface in
the EtherChannel is used. You cannot alter the EtherChannel configuration while it is in use as a High
Availability link. To alter the configuration, you need to temporarily disable High Availability, which
prevents High Availability from occurring for the duration.
Model Support
• You cannot add EtherChannels in FMC for the Firepower 4100/9300 or FTDv. The Firepower 4100/9300
supports EtherChannels, but you must perform all hardware configuration of EtherChannels in FXOS
on the chassis.
• Redundant interfaces are only supported on the ASA 5500-X platform; they are not supported on the
Firepower 1000, Firepower 2100, Firepower 4100/9300, and FTDv.
• You cannot use Firepower 1010 switch ports or VLAN interfaces in EtherChannels.
• ASA 5500-X models, Firepower 1000, and Firepower 2100 do not support LACP rate fast; LACP always
uses the normal rate. This setting is not configurable. Note that the Firepower 4100/9300, which configures
EtherChannels in FXOS, has the LACP rate set to fast by default; on these platforms, the rate is
configurable.
• In Cisco IOS software versions earlier than 15.1(1)S2, the FTD did not support connecting an EtherChannel
to a switch stack. With default switch settings, if the FTD EtherChannel is connected cross stack, and if
the primary switch is powered down, then the EtherChannel connected to the remaining switch will not
come up. To improve compatibility, set the stack-mac persistent timer command to a large enough
value to account for reload time; for example, 8 minutes or 0 for indefinite. Or, you can upgrade to more
a more stable switch software version, such as 15.1(1)S2.
• All FTD configuration refers to the logical EtherChannel interface instead of the member physical
interfaces.
• You cannot use a redundant interface as part of an EtherChannel, nor can you use an EtherChannel as
part of a redundant interface. You cannot use the same physical interfaces in a redundant interface and
an EtherChannel interface. You can, however, configure both types on the FTD if they do not use the
same physical interfaces.
A logical redundant interface consists of a pair of physical interfaces: an active and a standby interface. When
the active interface fails, the standby interface becomes active and starts passing traffic. You can configure a
redundant interface to increase the FTD reliability. By default, redundant interfaces are enabled.
• You can configure up to 8 redundant interface pairs.
• Both member interfaces must be of the same physical type. For example, both must be GigabitEthernet.
Note Redundant interfaces are not supported on the Firepower platform; only ASA 5500-X models support redundant
interfaces.
Caution If you are using a physical interface already in your configuration, removing the
name will clear any configuration that refers to the interface.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Enable the member interfaces according to Enable the Physical Interface and Configure Ethernet Settings, on page 628.
Step 3 Click Add Interfaces > Redundant Interface.
Step 4 On the General tab, set the following parameters:
a) Redundant ID—Set an integer between 1 and 8.
b) Primary Interface—Choose an interface from the drop-down list. After you add the interface, any configuration for
it (such as an IP address) is removed.
c) Secondary Interface—The second interface must be the same physical type as the first interface.
Step 5 Click OK.
Step 6 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Step 7 (Optional) Add a VLAN subinterface. See Add a Subinterface, on page 652.
Step 8 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on page 657 or
Configure Bridge Group Interfaces, on page 659.
Configure an EtherChannel
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Admin
Access Admin
Network Admin
This section describes how to create an EtherChannel port-channel interface, assign interfaces to the
EtherChannel, and customize the EtherChannel.
Guidelines
• You can configure up to 48 EtherChannels, depending on the number of interfaces for your model.
• Each channel group can have up to 16 active interfaces, except for the Firepower 1000 or 2100, which
supports 8 active interfaces. For switches that support only 8 active interfaces, you can assign up to 16
interfaces to a channel group: while only 8 interfaces can be active, the remaining interfaces can act as
standby links in case of interface failure.
• All interfaces in the channel group must be the same type, speed, and duplex. Half duplex is not supported.
Note For the Firepower 4100/9300, you configure EtherChannels in FXOS. See Add an EtherChannel (Port Channel),
on page 605 for more information.
Note If you are using a physical interface already in your configuration, removing the
name will clear any configuration that refers to the interface.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Enable the member interfaces according to Enable the Physical Interface and Configure Ethernet Settings, on page 628.
Step 3 Click Add Interfaces > Ether Channel Interface.
Step 4 On the General tab, set the Ether Channel ID to a number between 1 and 48 (1 and 8 for the Firepower 1010).
Step 5 In the Available Interfaces area, click an interface and then click Add to move it to the Selected Interfaces area.
Repeat for all interfaces that you want to make members.
Make sure all interfaces are the same type and speed. The first interface you add determines the type and speed of the
EtherChannel. Any non-matching interfaces you add will be put into a suspended state. The FMC does not prevent you
from adding non-matching interfaces.
Step 6 (Optional) Click the Advanced tab to customize the EtherChannel. Set the following parameters on the Information
sub-tab:
• (ASA 5500-X models only) Load Balancing—Select the criteria used to load balance the packets across the group
channel interfaces. By default, the FTD device balances the packet load on interfaces according to the source and
destination IP address of the packet. If you want to change the properties on which the packet is categorized,
choose a different set of criteria. For example, if your traffic is biased heavily towards the same source and
destination IP addresses, then the traffic assignment to interfaces in the EtherChannel will be unbalanced. Changing
to a different algorithm can result in more evenly distributed traffic. For more information about load balancing,
see Load Balancing, on page 646.
• LACP Mode—Choose Active, Passive, or On. We recommend using Active mode (the default).
• (ASA 5500-X models only) Active Physical Interface: Range—From the left drop-down list, choose the minimum
number of active interfaces required for the EtherChannel to be active, between 1 and 16. The default is 1. From
the right drop-down list, choose the maximum number of active interfaces allowed in the EtherChannel, between
1 and 16. The default is 16. If your switch does not support 16 active interfaces, be sure to set this command to 8
or fewer.
• Active Mac Address—Set a manual MAC address if desired. The mac_address is in H.H.H format, where H is
a 16-bit hexadecimal digit. For example, the MAC address 00-0C-F1-42-4C-DE is entered as 000C.F142.4CDE.
Step 7 (Optional) Click the Hardware Configuration tab and set the Duplex and Speed to override these settings for all
member interfaces. This method provides a shortcut to set these parameters because these parameters must match for
all interfaces in the channel group.
Step 8 Click OK.
Step 9 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Step 10 (Optional) Add a VLAN subinterface. See Add a Subinterface, on page 652.
Step 11 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on page 657 or
Configure Bridge Group Interfaces, on page 659.
High Availability
You cannot use a subinterface for the failover or state link. The exception is that you can use a subinterface
defined on the Firepower 4100/9300 chassis for container instances.
Additional Guidelines
• Preventing untagged packets on the physical interface—If you use subinterfaces, you typically do not
also want the physical interface to pass traffic, because the physical interface passes untagged packets.
This property is also true for the active physical interface in a redundant interface pair and for EtherChannel
links. Because the physical, redundant, or EtherChannel interface must be enabled for the subinterface
to pass traffic, ensure that the physical, redundant, or EtherChannel interface does not pass traffic by not
configuring a name for the interface. If you want to let the physical, redundant, or EtherChannel interface
pass untagged packets, you can configure the name as usual.
• You cannot configure subinterfaces on the Diagnostic interface.
• All subinterfaces on the same parent interface must be either bridge group members or routed interfaces;
you cannot mix and match.
• The FTD does not support the Dynamic Trunking Protocol (DTP), so you must configure the connected
switch port to trunk unconditionally.
• You might want to assign unique MAC addresses to subinterfaces defined on the FTD, because they use
the same burned-in MAC address of the parent interface. For example, your service provider might
perform access control based on the MAC address. Also, because IPv6 link-local addresses are generated
based on the MAC address, assigning unique MAC addresses to subinterfaces allows for unique IPv6
link-local addresses, which can avoid traffic disruption in certain instances on the FTD.
Firepower 1010 60
ASA 5508-X 50
Add a Subinterface
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Admin
Access Admin
Network Admin
Note The parent physical interface passes untagged packets. You may not want to pass untagged packets, so be
sure not to include the parent interface in your security policy.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Enable the parent interface according to Enable the Physical Interface and Configure Ethernet Settings, on page 628.
Step 3 Click Add Interfaces > Sub Interface.
Step 4 On General, set the following parameters:
a) Interface—Choose the physical, redundant, or port-channel interface to which you want to add the subinterface.
b) Sub-Interface ID—Enter the subinterface ID as an integer between 1 and 4294967295. The number of subinterfaces
allowed depends on your platform. You cannot change the ID after you set it.
c) VLAN ID—Enter the VLAN ID between 1 and 4094 that will be used to tag the packets on this subinterface.
This VLAN ID must be unique.
Step 7 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on page 657 or
Configure Bridge Group Interfaces, on page 659.
To cable the above scenario on the ASA 5508-X, or ASA 5516-X, see the following:
If you configure the Diagnostic IP address, then you need an inside router:
Or you can deploy with an inside router, in which case you can use the Diagnostic interface with an IP address
for additional management access:
IPv6
• IPv6 is supported on all interfaces.
• You can only configure IPv6 addresses manually in transparent mode.
• The Firepower Threat Defense device does not support IPv6 anycast addresses.
Model Guidelines
• For the Firepower Threat Defense Virtual on VMware with bridged ixgbevf interfaces, bridge groups
are not supported.
• For the Firepower 2100 series, bridge groups are not supported in routed mode.
• In transparent mode, do not specify the BVI IP address as the default gateway for connected devices;
devices need to specify the router on the other side of the Firepower Threat Defense device as the default
gateway.
• In transparent mode, the default route, which is required to provide a return path for management traffic,
is only applied to management traffic from one bridge group network. This is because the default route
specifies an interface in the bridge group as well as the router IP address on the bridge group network,
and you can only define one default route. If you have management traffic from more than one bridge
group network, you need to specify a regular static route that identifies the network from which you
expect management traffic.
• In transparent mode, PPPoE is not supported for the Diagnostic interface.
• In routed mode, to route between bridge groups and other routed interfaces, you must name the BVI.
• In routed mode, FTD-defined EtherChannel interfaces are not supported as bridge group members.
EtherChannels on the Firepower 4100/9300 can be bridge group members.
• Bidirectional Forwarding Detection (BFD) echo packets are not allowed through the FTD when using
bridge group members. If there are two neighbors on either side of the FTD running BFD, then the FTD
will drop BFD echo packets because they have the same source and destination IP address and appear
to be part of a LAND attack.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 Enable the interface by checking the Enabled check box.
Step 5 (Optional) Set this interface to Management Only to limit traffic to management traffic; through-the-box traffic is not
allowed.
Step 6 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.
Step 8 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
The routed interface is a Routed-type interface, and can only belong to Routed-type zones.
Step 9 See Configure the MTU, on page 674 for information about the MTU.
Step 10 Click the IPv4 tab. To set the IP address, use one of the following options from the IP Type drop-down list.
High Availability and clustering interfaces only support static IP address configuration; DHCP and PPPoE are not
supported.
• Use Static IP—Enter the IP address and subnet mask. For High Availabilty, you can only use a static IP address.
Set the standby IP address on the Devices > Device Management > High Availability tab in the Monitored
Interfaces area. If you do not set the standby IP address, the active unit cannot monitor the standby interface using
network tests; it can only track the link state.
• Use DHCP—Configure the following optional parameters:
• Obtain default route using DHCP—Obtains the default route from the DHCP server.
• DHCP route metric—Assigns an administrative distance to the learned route, between 1 and 255. The default
administrative distance for the learned routes is 1.
• Use PPPoE—If the interface is connected to a DSL, cable modem, or other connection to your ISP, and your ISP
uses PPPoE to provide your IP address, configure the following parameters:
• VPDN Group Name—Specify a group name of your choice to represent this connection.
• PPPoE User Name—Specify the username provided by your ISP.
• PPPoE Password/Confirm Password—Specify and confirm the password provided by your ISP.
• PPP Authentication—Choose PAP, CHAP, or MSCHAP.
PAP passes a cleartext username and password during authentication and is not secure. With CHAP, the
client returns the encrypted [challenge plus password], with a cleartext username in response to the server
challenge. CHAP is more secure than PAP, but it does not encrypt data. MSCHAP is similar to CHAP but
is more secure because the server stores and compares only encrypted passwords rather than cleartext passwords
as in CHAP. MSCHAP also generates a key for data encryption by MPPE.
• PPPoE route metric—Assign an administrative distance to the learned route. Valid values are from 1 to
255. By default, the administrative distance for the learned routes is 1.
• Enable Route Settings—To manually configure the PPPoE IP address, check this box and then enter the IP
Address.
If you select the Enable Route Settings check box and leave the IP Address blank, the ip address pppoe
setroute command is applied as shown in this example:
interface GigabitEthernet0/2
nameif inside2_pppoe
cts manual
propagate sgt preserve-untag
policy static sgt disabled trusted
security-level 0
pppoe client vpdn group test
pppoe client route distance 10
ip address pppoe setroute
• Store Username and Password in Flash—Stores the username and password in flash memory.
The FTD device stores the username and password in a special location of NVRAM.
Step 11 (Optional) See Configure IPv6 Addressing, on page 664 to configure IPv6 addressing on the IPv6 tab.
Step 12 (Optional) See Configure the MAC Address, on page 675 to manually configure the MAC address on the Advanced
tab.
Step 13 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.
• Duplex—Choose Full, Half, or Auto. Auto is the default when the interface supports it. For example, you cannot
select Auto for the SFP interfaces on a Firepower 2100 series device.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default. The type of interface limits the options you can select.
For example, on Firepower 2100 series devices, you can select 10, 100, or 1000 (1Gbps) for GigabitEthernet ports,
and 1000 or 10000 (10 Gpbs) for SFP ports. Note that the SFP interfaces on Firepower 2100 series devices do not
support Auto.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 Enable the interface by checking the Enabled check box.
Step 5 (Optional) Set this interface to Management Only to limit traffic to management traffic; through-the-box traffic is not
allowed.
Step 6 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.
Step 8 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
The bridge group member interface is a Switched-type interface, and can only belong to Switched-type zones. Do not
configure any IP address settings for this interface. You will set the IP address for the Bridge Virtual Interface (BVI)
only. Note that the BVI does not belong to a zone, and you cannot apply access control policies to the BVI.
Step 9 See Configure the MTU, on page 674 for information about the MTU.
Step 10 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.
• Duplex—Choose Full, Half, or Auto. Auto is the default when the interface supports it. For example, you cannot
select Auto for the SFP interfaces on a Firepower 2100 series device.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default. The type of interface limits the options you can select.
For example, on Firepower 2100 series devices, you can select 10, 100, or 1000 (1Gbps) for GigabitEthernet ports,
and 1000 or 10000 (10 Gpbs) for SFP ports. Note that the SFP interfaces on Firepower 2100 series devices do not
support Auto.
Step 11 (Optional) See Configure IPv6 Addressing, on page 664 to configure IPv6 addressing on the IPv6 tab.
Step 12 (Optional) See Configure the MAC Address, on page 675 to manually configure the MAC address on the Advanced
tab.
Step 13 Click OK.
Step 14 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Note For a separate Diagnostic interface, a non-configurable bridge group (ID 301) is automatically added to your
configuration. This bridge group is not included in the bridge group limit.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Choose Add Interfaces > Bridge Group Interface.
Step 3 (Routed Mode) In the Name field, enter a name up to 48 characters in length.
You must name the BVI if you want to route traffic outside the bridge group members, for example, to the outside
interface or to members of other bridge groups. The name is not case-sensitive.
Step 4 In the Bridge Group ID field, enter the bridge group ID between 1 and 250.
Step 5 In the Description field, enter a description for this bridge group.
Step 6 On the Interfaces tab, click an interface and then click Add to move it to the Selected Interfaces area. Repeat for all
interfaces that you want to make members of the bridge group.
Step 7 (Transparent Mode) Click the IPv4 tab. In the IP Address field, enter the IPv4 address and subnet mask.
Do not assign a host address (/32 or 255.255.255.255) to the BVI. Also, do not use other subnets that contain fewer
than 3 host addresses (one each for the upstream router, downstream router, and transparent firewall) such as a /30
subnet (255.255.255.252). The FTD device drops all ARP packets to or from the first and last addresses in a subnet.
For example, if you use a /30 subnet and assign a reserved address from that subnet to the upstream router, then the
FTD device drops the ARP request from the downstream router to the upstream router.
For High Availabilty, set the standby IP address on the Devices > Device Management > High Availability tab in the
Monitored Interfaces area. If you do not set the standby IP address, the active unit cannot monitor the standby interface
using network tests; it can only track the link state.
Step 8 (Routed Mode) Click the IPv4 tab. To set the IP address, use one of the following options from the IP Type drop-down
list.
High Availability and clustering interfaces only support static IP address configuration; DHCP is not supported.
• Use Static IP—Enter the IP address and subnet mask. For High Availabilty, you can only use a static IP address.
Set the standby IP address on the Devices > Device Management > High Availability tab in the Monitored
Interfaces area. If you do not set the standby IP address, the active unit cannot monitor the standby interface using
network tests; it can only track the link state.
• Use DHCP—Configure the following optional parameters:
• Obtain default route using DHCP—Obtains the default route from the DHCP server.
• DHCP route metric—Assigns an administrative distance to the learned route, between 1 and 255. The default
administrative distance for the learned routes is 1.
Step 9 (Optional) See Configure IPv6 Addressing, on page 664 to configure IPv6 addressing.
Step 10 (Optional) See Add a Static ARP Entry, on page 675 and Add a Static MAC Address and Disable MAC Learning for
a Bridge Group, on page 676 (for transparent mode only) to configure the ARP and MAC settings.
Step 11 Click OK.
Step 12 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the Diagnostic interface.
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 Click the IPv4 tab. To set the IP address, use one of the following options from the IP Type drop-down list.
• Use Static IP—Enter the IP address and subnet mask.
• Use DHCP—Configure the following optional parameters:
• Obtain default route using DHCP—Obtains the default route from the DHCP server.
• DHCP route metric—Assigns an administrative distance to the learned route, between 1 and 255. The default
administrative distance for the learned routes is 1.
Step 5 (Optional) See Configure IPv6 Addressing, on page 664 to configure IPv6 addressing.
Step 6 (Optional) On the Advanced tab, configure optional settings.
• See Configure the MAC Address, on page 675.
• See Add a Static ARP Entry, on page 675.
• See Set Security Configuration Parameters, on page 677.
About IPv6
This section includes information about IPv6.
IPv6 Addressing
You can configure two types of unicast addresses for IPv6:
• Global—The global address is a public address that you can use on the public network. For a bridge
group, this address needs to be configured for the BVI, and not per member interface. You can also
configure a global IPv6 address for the management interface in transparent mode.
• Link-local—The link-local address is a private address that you can only use on the directly-connected
network. Routers do not forward packets using link-local addresses; they are only for communication
on a particular physical network segment. They can be used for address configuration or for the Neighbor
Discovery functions such as address resolution. In a bridge group, only member interfaces have link-local
addresses; the BVI does not have a link-local address.
At a minimum, you need to configure a link-local address for IPv6 to operate. If you configure a global address,
a link-local address is automatically configured on the interface, so you do not also need to specifically
configure a link-local address. For bridge group member interfaces, when you configure the global address
on the BVI, the Firepower Threat Defense device automatically generates link-local addresses for member
interfaces. If you do not configure a global address, then you need to configure the link-local address, either
automatically or manually.
The address format verification is only performed when a flow is created. Packets from an existing flow are
not checked. Additionally, the address verification can only be performed for hosts on the local link.
Note Configuring the global address automatically configures the link-local address, so you do not need to configure
it separately. For bridge groups, configuring the global address on the BVI automatically configures link-local
addresses on all member interfaces.
For subinterfaces defined on the FTD, we recommend that you also set the MAC address manually, because
they use the same burned-in MAC address of the parent interface. IPv6 link-local addresses are generated
based on the MAC address, so assigning unique MAC addresses to subinterfaces allows for unique IPv6
link-local addresses, which can avoid traffic disruption in certain instances on the FTD. See Configure the
MAC Address, on page 675.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 Click the IPv6 page.
For routed mode, the Basic page is selected by default. For transparent mode, the Address page is selected by default.
For High Availabilty (if you did not set Enforce EUI 64), set the standby IP address on the Devices > Device
Management > High Availability page in the Monitored Interfaces area. If you do not set the standby IP
address, the active unit cannot monitor the standby interface using network tests; it can only track the link state.
Step 6 For Routed interfaces, you can optionally set the following values on the Basic page:
• To enforce the use of Modified EUI-64 format interface identifiers in IPv6 addresses on a local link, check the
Enforce EUI-64 check box.
• To manually set the link-local address, enter an address in the Link-Local address field.
A link-local address should start with FE8, FE9, FEA, or FEB, for example fe80::20d:88ff:feee:6a82. If you do not
want to configure a global address, and only need to configure a link-local address, you have the option of manually
defining the link-local address. Note that we recommend automatically assigning the link-local address based on
the Modified EUI-64 format. For example, if other devices enforce the use of the Modified EUI-64 format, then a
manually-assigned link-local address may cause packets to be dropped.
• Check the Enable DHCP for address config check box to set the Managed Address Config flag in the IPv6 router
advertisement packet.
This flag in IPv6 router advertisements informs IPv6 autoconfiguration clients that they should use DHCPv6 to
obtain addresses, in addition to the derived stateless autoconfiguration address.
• Check the Enable DHCP for non-address config check box to set the Other Address Config flag in the IPv6 router
advertisement packet.
This flag in IPv6 router advertisements informs IPv6 autoconfiguration clients that they should use DHCPv6 to
obtain additional information from DHCPv6, such as the DNS server address.
Step 7 For Routed interfaces, see Configure IPv6 Neighbor Discovery, on page 667 to configure settings on the Prefixes and
Settings pages. For BVI interfaces, see the following parameters on the Settings page:
• DAD attempts—The maximum number of DAD attempts, between 1 and 600. Set the value to 0 to disable duplicate
address detection (DAD) processing. This setting configures the number of consecutive neighbor solicitation messages
that are sent on an interface while DAD is performed on IPv6 addresses. 1 attempt is the default.
• NS Interval—The interval between IPv6 neighbor solicitation retransmissions on an interface, between 1000 and
3600000 ms. The default value is 1000 ms.
• Reachable Time—The amount of time that a remote IPv6 node is considered reachable after a reachability
confirmation event has occurred, between 0 and 3600000 ms. The default value is 0 ms. When 0 is used for the
value, the reachable time is sent as undetermined. It is up to the receiving devices to set and track the reachable time
value. The neighbor reachable time enables detecting unavailable neighbors. Shorter configured times enable detecting
unavailable neighbors more quickly, however, shorter times consume more IPv6 network bandwidth and processing
resources in all IPv6 network devices. Very short configured times are not recommended in normal IPv6 operation.
The IPv6 neighbor discovery process uses ICMPv6 messages and solicited-node multicast addresses to
determine the link-layer address of a neighbor on the same network (local link), verify the readability of a
neighbor, and keep track of neighboring routers.
Nodes (hosts) use neighbor discovery to determine the link-layer addresses for neighbors known to reside on
attached links and to quickly purge cached values that become invalid. Hosts also use neighbor discovery to
find neighboring routers that are willing to forward packets on their behalf. In addition, nodes use the protocol
to actively keep track of which neighbors are reachable and which are not, and to detect changed link-layer
addresses. When a router or the path to a router fails, a host actively searches for functioning alternates.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 Click IPv6, and then Prefixes.
Step 4 (Optional) To configure which IPv6 prefixes are included in IPv6 router advertisements, perform the following steps:
a) Click Add Prefix.
b) In the Address field, enter the IPv6 address with the prefix length or check the Default check box to use the default
prefix.
c) (Optional) Uncheck the Advertisement check box to indicate that the IPv6 prefix is not advertised.
d) Check the Off Link check box to indicate that the specified prefix is assigned to the link. Nodes sending traffic to
addresses that contain the specified prefix consider the destination to be locally reachable on the link. This prefix
should not be used for on-link determination.
e) To use the specified prefix for autoconfiguration, check the Autoconfiguration check box.
f) For the Prefix Lifetime, click Duration or Expiration Date.
• Duration—Enter a Preferred Lifetime for the prefix in seconds. This setting is the amount of time that the
specified IPv6 prefix is advertised as being valid. The maximum value represents infinity. Valid values are
from 0 to 4294967295. The default is 2592000 (30 days). Enter a Valid Lifetime for the prefix in seconds.
This setting is the amount of time that the specified IPv6 prefix is advertised as being preferred. The maximum
value represents infinity. Valid values are from 0 to 4294967295. The default setting is 604800 (seven days).
Alternatively, check the Infinite checkbox to set an unlimited duration.
• Expiration Date—Choose a Valid and Preferred date and time.
g) Click OK.
Step 5 Click Settings.
Step 6 (Optional) Set the maximum number of DAD attempts, between 1 and 600. 1 attempt is the default. Set the value to
0 to disable duplicate address detection (DAD) processing.
This setting configures the number of consecutive neighbor solicitation messages that are sent on an interface while
DAD is performed on IPv6 addresses.
During the stateless autoconfiguration process, Duplicate Address Detection verifies the uniqueness of new unicast
IPv6 addresses before the addresses are assigned to interfaces.
When a duplicate address is identified, the state of the address is set to DUPLICATE, the address is not used, and the
following error message is generated:
If the duplicate address is the link-local address of the interface, the processing of IPv6 packets is disabled on the
interface. If the duplicate address is a global address, the address is not used.
Step 7 (Optional) Configure the interval between IPv6 neighbor solicitation retransmissions in the NS Interval field, between
1000 and 3600000 ms.
The default value is 1000 ms.
Neighbor solicitation messages (ICMPv6 Type 135) are sent on the local link by nodes attempting to discover the
link-layer addresses of other nodes on the local link. After receiving a neighbor solicitation message, the destination
node replies by sending a neighbor advertisement message (ICPMv6 Type 136) on the local link.
After the source node receives the neighbor advertisement, the source node and destination node can communicate.
Neighbor solicitation messages are also used to verify the reachability of a neighbor after the link-layer address of a
neighbor is identified. When a node wants to verifying the reachability of a neighbor, the destination address in a
neighbor solicitation message is the unicast address of the neighbor.
Neighbor advertisement messages are also sent when there is a change in the link-layer address of a node on a local
link.
Step 8 (Optional) Configure the amount of time that a remote IPv6 node is considered reachable after a reachability confirmation
event has occurred in the Reachable Time field, between 0 and 3600000 ms.
The default value is 0 ms. When 0 is used for the value, the reachable time is sent as undetermined. It is up to the
receiving devices to set and track the reachable time value.
The neighbor reachable time enables detecting unavailable neighbors. Shorter configured times enable detecting
unavailable neighbors more quickly, however, shorter times consume more IPv6 network bandwidth and processing
resources in all IPv6 network devices. Very short configured times are not recommended in normal IPv6 operation.
Step 9 (Optional) To suppress the router advertisement transmissions, uncheck the Enable RA check box. If you enable router
advertisement transmissions, you can set the RA lifetime and interval.
Router advertisement messages (ICMPv6 Type 134) are automatically sent in response to router solicitation messages
(ICMPv6 Type 133). Router solicitation messages are sent by hosts at system startup so that the host can immediately
autoconfigure without needing to wait for the next scheduled router advertisement message.
You may want to disable these messages on any interface for which you do not want the Firepower Threat Defense
device to supply the IPv6 prefix (for example, the outside interface).
• RA Lifetime—Configure the router lifetime value in IPv6 router advertisements, between 0 and 9000 seconds.
The default is 1800 seconds.
• RA Interval—Configure the interval between IPv6 router advertisement transmissions, between 3 and 1800
seconds.
The default is 200 seconds.
Note You might want to assign unique MAC addresses to subinterfaces defined on the FTD, because they use the
same burned-in MAC address of the parent interface. For example, your service provider might perform access
control based on the MAC address. Also, because IPv6 link-local addresses are generated based on the MAC
address, assigning unique MAC addresses to subinterfaces allows for unique IPv6 link-local addresses, which
can avoid traffic disruption in certain instances on the FTD.
Note For container instances, even if you are not sharing a subinterface, if you manually configure MAC addresses,
make sure you use unique MAC addresses for all subinterfaces on the same parent interface to ensure proper
classification.
MAC addresses, you can manually assign MAC addresses. See Configure the MAC Address, on page
675.
Transparent firewall mode: Each VLAN interface has a unique MAC address. You can override the
generated MAC addresses if desired by manually assigning MAC addresses. See Configure the MAC
Address, on page 675.
• Redundant interfaces—A redundant interface uses the MAC address of the first physical interface that
you add. If you change the order of the member interfaces in the configuration, then the MAC address
changes to match the MAC address of the interface that is now listed first. If you assign a MAC address
to the redundant interface, then it is used regardless of the member interface MAC addresses.
• EtherChannels (Firepower Models)—For an EtherChannel, all interfaces that are part of the channel
group share the same MAC address. This feature makes the EtherChannel transparent to network
applications and users, because they only see the one logical connection; they have no knowledge of the
individual links. The port-channel interface uses a unique MAC address from a pool; interface membership
does not affect the MAC address.
• EtherChannels (ASA Models)—The port-channel interface uses the lowest-numbered channel group
interface MAC address as the port-channel MAC address. Alternatively you can configure a MAC address
for the port-channel interface. We recommend configuring a unique MAC address in case the group
channel interface membership changes. If you remove the interface that was providing the port-channel
MAC address, then the port-channel MAC address changes to the next lowest numbered interface, thus
causing traffic disruption.
• Subinterfaces (FTD-defined)—All subinterfaces of a physical interface use the same burned-in MAC
address. You might want to assign unique MAC addresses to subinterfaces. For example, your service
provider might perform access control based on the MAC address. Also, because IPv6 link-local addresses
are generated based on the MAC address, assigning unique MAC addresses to subinterfaces allows for
unique IPv6 link-local addresses, which can avoid traffic disruption in certain instances on the FTD.
Default MTU
The default MTU on the Firepower Threat Defense device is 1500 bytes. This value does not include the
18-22 bytes for the Ethernet header, VLAN tagging, or other overhead.
Note The Firepower Threat Defense device can receive frames larger than the configured MTU as long as there is
room in memory.
Firepower Threat Defense device changes the MSS value in the TCP request packet to 1380. The server then
sends packets with 1380-byte payloads. The Firepower Threat Defense device can then add up to 120 bytes
of headers to the packet and still fit in the MTU size of 1500.
You can also configure the minimum TCP MSS; if a host or server requests a very small TCP MSS, the
Firepower Threat Defense device can adjust the value up. By default, the minimum TCP MSS is not enabled.
For to-the-box traffic, including for SSL VPN connections, this setting does not apply. The Firepower Threat
Defense device uses the MTU to derive the TCP MSS: MTU - 40 (IPv4) or MTU - 60 (IPv6).
• If there is a mismatch between the MAC address, the IP address, or the interface, then the Firepower
Threat Defense device drops the packet.
• If the ARP packet does not match any entries in the static ARP table, then you can set the Firepower
Threat Defense device to either forward the packet out all interfaces (flood), or to drop the packet.
Note The dedicated Diagnostic interface never floods packets even if this parameter
is set to flood.
Default Settings
• If you enable ARP inspection, the default setting is to flood non-matching packets.
• The default timeout value for dynamic MAC address table entries is 5 minutes.
• By default, each interface automatically learns the MAC addresses of entering traffic, and the Firepower
Threat Defense device adds corresponding entries to the MAC address table.
Customize the MTU on the interface, for example, to allow jumbo frames.
Caution Changing the highest MTU value on the device for a non-management/diagnostic interface restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management/diagnostic interfaces, not just the interface you modified. Whether this
interruption drops traffic or passes it without further inspection depends on the model of the managed device
and the interface type. See Snort® Restart Traffic Behavior, on page 390 for more information.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 On the General tab, set the MTU between 64 and 9198 bytes; the maximum is 9000 for the Firepower Threat Defense
Virtual and 9184 for the FTD on the Firepower 4100/9300 chassis.
The default is 1500 bytes.
Step 6 For ASA models, if you set the MTU above 1500 bytes, reload the system to enable jumbo frames.
You might need to manually assign a MAC address. You can also set the Active and Standby MAC addresses
on the Devices > Device Management > High Availability tab. If you set the MAC address for an interface
on both screens, the addresses on the Interfaces > Advanced tab take precedence.
Note For container instances, even if you are not sharing a subinterface, if you manually configure MAC addresses,
make sure you use unique MAC addresses for all subinterfaces on the same parent interface to ensure proper
classification.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 Click the Advanced tab.
The Information tab is selected.
Step 4 In the Active MAC Address field, enter a MAC address in H.H.H format, where H is a 16-bit hexadecimal digit.
For example, the MAC address 00-0C-F1-42-4C-DE would be entered as 000C.F142.4CDE. The MAC address must not
have the multicast bit set, that is, the second hexadecimal digit from the left cannot be an odd number.
Step 5 In the Standby MAC Address field, enter a MAC address for use with High Availability.
If the active unit fails over and the standby unit becomes active, the new active unit starts using the active MAC addresses
to minimize network disruption, while the old active unit uses the standby address.
By default, all ARP packets are allowed between bridge group members. You can control the flow of ARP
packets by enabling ARP inspection (see Configure ARP Inspection, on page 1155). ARP inspection compares
ARP packets with static ARP entries in the ARP table.
For routed interfaces, you can enter static ARP entries, but normally dynamic entries are sufficient. For routed
interfaces, the ARP table is used to deliver packets to directly-connected hosts. Although senders identify a
packet destination by an IP address, the actual delivery of the packet on Ethernet relies on the Ethernet MAC
address. When a router or host wants to deliver a packet on a directly connected network, it sends an ARP
request asking for the MAC address associated with the IP address, and then delivers the packet to the MAC
address according to the ARP response. The host or router keeps an ARP table so it does not have to send
ARP requests for every packet it needs to deliver. The ARP table is dynamically updated whenever ARP
responses are sent on the network, and if an entry is not used for a period of time, it times out. If an entry is
incorrect (for example, the MAC address changes for a given IP address), the entry needs to time out before
it can be updated with the new information.
For transparent mode, the FTD only uses dynamic ARP entries in the ARP table for traffic to and from the
FTD device, such as management traffic.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the ARP tab (called ARP and MAC for transparent mode).
Step 4 Click Add ARP Config.
The Add ARP Config dialog box appears.
Step 5 In the IP Address field, enter the IP address of the host.
Step 6 In the MAC Address field, enter the MAC address of the host; for example, 00e0.1e4e.3d8b.
Step 7 To perform proxy ARP for this address, check the Enable Alias check box.
If the FTD device receives an ARP request for the specified IP address, then it responds with the specified MAC address.
Step 8 Click OK, and then click OK again to exit the Advanced settings.
Step 9 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Add a Static MAC Address and Disable MAC Learning for a Bridge Group
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Admin
Access Admin
Network Admin
Normally, MAC addresses are added to the MAC address table dynamically as traffic from a particular MAC
address enters an interface. You can disable MAC address learning; however, unless you statically add MAC
addresses to the table, no traffic can pass through the FTD device. You can also add static MAC addresses to
the MAC address table. One benefit to adding static entries is to guard against MAC spoofing. If a client with
the same MAC address as a static entry attempts to send traffic to an interface that does not match the static
entry, then the FTD device drops the traffic and generates a system message. When you add a static ARP
entry (see Add a Static ARP Entry, on page 675), a static MAC address entry is automatically added to the
MAC address table.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the ARP and MAC tab.
Step 4 (Optional) Disable MAC learning by unchecking the Enable MAC Learning check box.
Step 5 To add a static MAC address, click Add MAC Config.
The Add MAC Config dialog box appears.
Step 6 In the MAC Address field, enter the MAC address of the host; for example, 00e0.1e4e.3d8b. Click OK.
Step 7 Click OK to exit the Advanced settings.
Step 8 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
This section describes how to prevent IP spoofing, allow full fragment reassembly, and override the default
fragment setting set for at the device level in Platform Settings .
Anti-Spoofing
This section lets you enable Unicast Reverse Path Forwarding on an interface. Unicast RPF guards against
IP spoofing (a packet uses an incorrect source IP address to obscure its true source) by ensuring that all packets
have a source IP address that matches the correct source interface according to the routing table.
Normally, the FTD device only looks at the destination address when determining where to forward the packet.
Unicast RPF instructs the device to also look at the source address; this is why it is called Reverse Path
Forwarding. For any traffic that you want to allow through the FTD device, the device routing table must
include a route back to the source address. See RFC 2267 for more information.
For outside traffic, for example, the FTD device can use the default route to satisfy the Unicast RPF protection.
If traffic enters from an outside interface, and the source address is not known to the routing table, the device
uses the default route to correctly identify the outside interface as the source interface.
If traffic enters the outside interface from an address that is known to the routing table, but is associated with
the inside interface, then the FTD device drops the packet. Similarly, if traffic enters the inside interface from
an unknown source address, the device drops the packet because the matching route (the default route) indicates
the outside interface.
Unicast RPF is implemented as follows:
• ICMP packets have no session, so each packet is checked.
• UDP and TCP have sessions, so the initial packet requires a reverse route lookup. Subsequent packets
arriving during the session are checked using an existing state maintained as part of the session. Non-initial
packets are checked to ensure they arrived on the same interface used by the initial packet.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the Security Configuration tab.
Step 4 To enable Unicast Reverse Path Forwarding, check the Anti-Spoofing check box.
Step 5 To enable full fragment reassembly, check the Full Fragment Reassembly check box.
Step 6 To change the number of fragments allowed per packet, check the Override Default Fragment Setting check box, and
set the following values:
• Size—Set the maximum number of packets that can be in the IP reassembly database waiting for reassembly. The
default is 200. Set this value to 1 to disable fragments.
• Chain—Set the maximum number of packets into which a full IP packet can be fragmented. The default is 24
packets.
• Timeout—Set the maximum number of seconds to wait for an entire fragmented packet to arrive. The timer starts
after the first fragment of a packet arrives. If all fragments of the packet do not arrive by the number of seconds
specified, all fragments of the packet that were already received will be discarded. The default is 5 seconds.
Firepower 1010 6.5 The Firepower 1010 supports setting each Ethernet interface to be a switch port or a firewall
hardware switch support interface.
New/Modified screens:
• Devices > Device Management > Interfaces
• Devices > Device Management > Interfaces > Edit Physical Interface
• Devices > Device Management > Interfaces > Add VLAN Interface
Firepower 1010 PoE+ 6.5 The Firepower 1010 supports Power over Ethernet+ (PoE+) on Ethernet 1/7 and Ethernet 1/8
support on Ethernet 1/7 when they are configured as switch ports.
and Ethernet 1/8
New/Modified screens:
Devices > Device Management > Interfaces > Edit Physical Interface > PoE
VLAN subinterfaces for 6.3.0 To provide flexible physical interface use, you can create VLAN subinterfaces in FXOS and
use with container also share interfaces between multiple instances.
instances
New/Modified Firepower Management Center screens:
Devices > Device Management > Edit icon > Interfaces tab
New/Modified Firepower Chassis Manager screens:
Interfaces > All Interfaces > Add New drop-down menu > Subinterface
New/Modified FXOS commands: create subinterface, set vlan, show interface,show
subinterface
Supported platforms: Firepower 4100/9300
Data-sharing interfaces 6.3.0 To provide flexible physical interface use, you can share interfaces between multiple instances.
for container instances
New/Modified Firepower Chassis Managerscreens:
Interfaces > All Interfaces > Type
New/Modified FXOS commands: set port-type data-sharing, show interface
Supported platforms: Firepower 4100/9300
Integrated Routing and 6.2.0 Integrated Routing and Bridging provides the ability to route between a bridge group and a
Bridging routed interface. A bridge group is a group of interfaces that the FTD bridges instead of routes.
The FTD is not a true bridge in that the FTD continues to act as a firewall: access control
between interfaces is controlled, and all of the usual firewall checks are in place. Previously,
you could only configure bridge groups in transparent firewall mode, where you cannot route
between bridge groups. This feature lets you configure bridge groups in routed firewall mode,
and to route between bridge groups and between a bridge group and a routed interface. The
bridge group participates in routing by using a Bridge Virtual Interface (BVI) to act as a gateway
for the bridge group. Integrated Routing and Bridging provides an alternative to using an external
Layer 2 switch if you have extra interfaces on the FTD to assign to the bridge group. In routed
mode, the BVI can be a named interface and can participate separately from member interfaces
in some features, such as access rules and DHCP server.
The following features that are supported in transparent mode are not supported in routed mode:
clustering. The following features are also not supported on BVIs: dynamic routing and multicast
routing.
New/Modified screens:
• Devices > Device Management > Interfaces > Edit Physical Interface
• Devices > Device Management > Interfaces > Add Interfaces > Bridge Group Interface
Supported platforms: All except for the Firepower 2100 and the Firepower Threat Defense
Virtual
Note The firewall mode only affects regular firewall interfaces, and not IPS-only interfaces such as inline sets or
passive interfaces. IPS-only interfaces can be used in both firewall modes.
With tap mode, the FTD is deployed inline, but the network traffic flow is undisturbed. Instead, the FTD
makes a copy of each packet so that it can analyze the packets. Note that rules of these types do generate
intrusion events when they are triggered, and the table view of intrusion events indicates that the triggering
packets would have dropped in an inline deployment. There are benefits to using tap mode with FTDs
that are deployed inline. For example, you can set up the cabling between the FTD and the network as
if the FTD were inline and analyze the kinds of intrusion events the FTD generates. Based on the results,
you can modify your intrusion policy and add the drop rules that best protect your network without
impacting its efficiency. When you are ready to deploy the FTD inline, you can disable tap mode and
begin dropping suspicious traffic without having to reconfigure the cabling between the FTD and the
network.
Note Tap mode significantly impacts FTD performance, depending on the traffic.
Note Inline sets might be familiar to you as "transparent inline sets," but the inline
interface type is unrelated to the transparent firewall mode or the firewall-type
interfaces.
• Passive or ERSPAN Passive—Passive interfaces monitor traffic flowing across a network using a switch
SPAN or mirror port. The SPAN or mirror port allows for traffic to be copied from other ports on the
switch. This function provides the system visibility within the network without being in the flow of
network traffic. When you configure the FTD in a passive deployment, the FTD cannot take certain
actions such as blocking or shaping traffic. Passive interfaces receive all traffic unconditionally. and no
traffic received on these interfaces is retransmitted. Encapsulated remote switched port analyzer (ERSPAN)
interfaces allow you to monitor traffic from source ports distributed over multiple switches, and uses
GRE to encapsulate the traffic. ERSPAN interfaces are only allowed when the FTD is in routed firewall
mode.
• Manual trigger
• Firepower chassis power loss
• Security Module power loss
Note Hardware bypass is intended for unplanned/unexpected failure scenarios, and is not automatically triggered
during planned software upgrades. Hardware bypass only engages at the end of a planned upgrade process,
when the FTD application reboots.
User Roles
• Admin
• Access Admin
• Network Admin
Note The ISA 3000 has a separate implementation for Hardware Bypass, which you can enable using FlexConfig
only (see FlexConfig Policies for Firepower Threat Defense, on page 1033). Do not use this chapter to configure
ISA 3000 Hardware Bypass.
The supported Hardware Bypass network modules for these models include:
• Firepower 6-port 1G SX FTW Network Module single-wide (FPR-NM-6X1SX-F)
• Firepower 6-port 10G SR FTW Network Module single-wide (FPR-NM-6X10SR-F)
• Firepower 6-port 10G LR FTW Network Module single-wide (FPR-NM-6X10LR-F)
• Firepower 2-port 40G SR FTW Network Module single-wide (FPR-NM-2X40G-F)
• Firepower 8-port 1G Copper FTW Network Module single-wide (FPR-NM-8X1G-F)
General Guidelines
• Inline sets and passive interfaces support physical interfaces and EtherChannels only, and cannot use
redundant interfaces, VLANs, and so on. Firepower 4100/9300 subinterfaces are also not supported for
IPS-only interfaces.
• Inline sets and passive interfaces are supported in intra-chassis and inter-chassis clustering.
• Bidirectional Forwarding Detection (BFD) echo packets are not allowed through the FTD when using
inline sets. If there are two neighbors on either side of the FTD running BFD, then the FTD will drop
BFD echo packets because they have the same source and destination IP address and appear to be part
of a LAND attack.
• For inline sets and passive interfaces, the FTD supports up to two 802.1Q headers in a packet (also known
as Q-in-Q support), with the exception of the Firepower 4100/9300, which only supports one 802.1Q
header. Note: Firewall-type interfaces do not support Q-in-Q, and only support one 802.1Q header.
• Set the interface mode to Passive or ERSPAN. For ERSPAN interfaces, you will set the ERSPAN
parameters and the IP address.
• Change the MTU. By default, the MTU is set to 1500 bytes. For more information about the MTU, see
About the MTU, on page 670.
• Set a specific speed and duplex (if available). By default, speed and duplex are set to Auto.
Note For the Firepower Threat Defense on the FXOS chassis, you configure basic interface settings on the Firepower
4100/9300 chassis. See Configure a Physical Interface, on page 604 for more information.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 In the Mode drop-down list, choose Passive or Erspan.
Step 4 Enable the interface by checking the Enabled check box.
Step 5 In the Name field, enter a name up to 48 characters in length.
Step 6 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
Step 7 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.
Step 8 (Optional) On General, set the MTU between 64 and 9198 bytes; for the Firepower Threat Defense Virtual and
Firepower Threat Defense on the FXOS chassis, the maximum is 9000 bytes.
The default is 1500 bytes.
Step 10 For ERSPAN interfaces, set the IPv4 address and mask on IPv4.
Step 11 (Optional) Set the duplex and speed by clicking Hardware Configuration.
The exact speed and duplex options depend on your hardware.
• Duplex—Choose Full, Half, or Auto. Auto is the default.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Note For the Firepower Threat Defense on the FXOS chassis, you configure basic interface settings on the Firepower
4100/9300 chassis. See Configure a Physical Interface, on page 604 for more information.
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is selected by
default.
Step 2 Click Edit ( ) for the interface you want to edit.
Step 3 In the Mode drop-down list, choose None.
After you add this interface to an inline set, this field will show Inline for the mode.
Step 7 (Optional) Set the duplex and speed by clicking Hardware Configuration.
The exact speed and duplex options depend on your hardware.
• Duplex—Choose Full, Half, or Auto. Auto is the default.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default.
Step 9 Click Edit ( ) for the second interface you want to add to the inline set.
Step 10 Configure the settings as for the first interface.
Step 15 (Optional) For the Bypass mode, choose one of the following options:
• Disabled—Set Hardware Bypass to disabled for interfaces where Hardware Bypass is supported, or use interfaces
where Hardware Bypass is not supported.
• Standby—Set Hardware Bypass to the standby state on supported interfaces. Only pairs of Hardware Bypass
interfaces are shown. In the standby state, the interfaces remain in normal operation until there is a trigger event.
• Bypass-Force—Manually forces the interface pair to go into a bypass state. Inline Sets shows Yes for any interface
pairs that are in Bypass-Force mode.
Step 16 In the Available Interfaces Pairs area, click a pair and then click Add to move it to the Selected Interface Pair area.
All possible pairings between named and enabled interfaces with the mode set to None show in this area.
• Snort Fail Open—Enable or disable either or both of the Busy and Down options if you want new and existing
traffic to pass without inspection (enabled) or drop (disabled) when the Snort process is busy or down.
By default, traffic passes without inspection when the Snort process is down, and drops when it is busy.
When the Snort process is:
• Busy—It cannot process traffic fast enough because traffic buffers are full, indicating that there is more traffic
than the device can handle, or because of other software resource issues.
• Down—It is restarting because you deployed a configuration that requires it to restart. See Configurations
that Restart the Snort Process When Deployed or Activated, on page 391.
When the Snort process is down and comes back up, it inspects new connections. To prevent false positives
and false negatives, it does not inspect existing connections on inline, routed, or transparent interfaces because
initial session information might have been lost while it was down.
Note When Snort fails open, features that rely on the Snort process do not function. These include application
control and deep inspection. The system performs only basic access control using simple, easily
determined transport and network layer characteristics.
Hardware bypass support on the Firepower 6.3.0 The Firepower 2100 now supports hardware
2100 for supported network modules bypass functionality when using the
hardware bypass network modules.
New/Modified screens:
Devices > Device Management >
Interfaces > Edit Physical Interface
Supported platforms: Firepower 2100
Support for EtherChannels in FTD inline 6.2.0 You can now use EtherChannels in a FTD
sets inline set.
Supported platforms: Firepower 4100/9300,
Firepower 2100 (6.2.1 and later)
Hardware bypass support on the Firepower 6.1.0 Hardware Bypass ensures that traffic
4100/9300 for supported network modules continues to flow between an inline
interface pair during a power outage. This
feature can be used to maintain network
connectivity in the case of software or
hardware failures.
New/Modified screens:
Devices > Device Management >
Interfaces > Edit Physical Interface
Supported platforms: Firepower 4100/9300
Inline set link state propagation support for 6.1.0 When you configure an inline set in the
the FTD FTD application and enable link state
propagation, the FTD sends inline set
membership to the FXOS chassis. Link
state propagation means that the chassis
automatically brings down the second
interface in the inline interface pair when
one of the interfaces in an inline set goes
down.
New/Modified FXOS commands: show
fault |grep link-down, show interface
detail
Supported platforms: Firepower 4100/9300,
Firepower 2100 (6.2.1 and later)
DHCP Options
DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. The
configuration parameters are carried in tagged items that are stored in the Options field of the DHCP message
and the data are also called options. Vendor information is also stored in Options, and all of the vendor
information extensions can be used as DHCP options.
For example, Cisco IP Phones download their configuration from a TFTP server. When a Cisco IP Phone
starts, if it does not have both the IP address and TFTP server IP address preconfigured, it sends a request
with option 150 or 66 to the DHCP server to obtain this information.
• DHCP option 150 provides the IP addresses of a list of TFTP servers.
• DHCP option 66 gives the IP address or the hostname of a single TFTP server.
A single request might include both options 150 and 66. In this case, the ASA DHCP server provides values
for both options in the response if they are already configured on the ASA.
You can use advanced DHCP options to provide DNS, WINS, and domain name parameters to DHCP clients;
DHCP option 15 is used for the DNS domain suffix.You can also use the DHCP automatic configuration
setting to obtain these values or define them manually. When you use more than one method to define this
information, it is passed to DHCP clients in the following sequence:
1. Manually configured settings.
2. Advanced DHCP options settings.
3. DHCP automatic configuration settings.
For example, you can manually define the domain name that you want the DHCP clients to receive and then
enable DHCP automatic configuration. Although DHCP automatic configuration discovers the domain together
with the DNS and WINS servers, the manually defined domain name is passed to DHCP clients with the
discovered DNS and WINS server names, because the domain name discovered by the DHCP automatic
configuration process is superseded by the manually defined domain name.
User Roles
• Admin
• Access Admin
• Network Admin
Firewall Mode
• DHCP Relay is not supported in transparent firewall mode or in routed mode on the BVI or bridge group
member interface.
• DHCP Server is supported in transparent firewall mode on a bridge group member interface. In routed
mode, the DHCP server is supported on the BVI interface, not the bridge group member interface. The
BVI must have a name for the DHCP server to operate.
• DDNS is not supported in transparent firewall mode or in routed mode on the BVI or bridge group
member interface.
IPv6
Does not support IPv6 for DHCP server; IPv6 for DHCP relay is supported.
DHCPv4 Server
• The maximum available DHCP pool is 256 addresses.
• You can configure only one DHCP server on each interface. Each interface can have its own pool of
addresses to use. However the other DHCP settings, such as DNS servers, domain name, options, ping
timeout, and WINS servers, are configured globally and used by the DHCP server on all interfaces.
• You cannot configure an interface as a DHCP client if that interface also has DHCP server enabled; you
must use a static IP address.
• You cannot configure both a DHCP server and DHCP relay on the same device, even if you want to
enable them on different interfaces; you can only configure one type of service.
• Firepower Threat Defense device does not support QIP DHCP servers for use with the DHCP proxy
service.
• The DHCP server does not support BOOTP requests.
DHCP Relay
• You can configure a maximum of 10 DHCPv4 relay servers, global and interface-specific servers
combined, with a maximum of 4 servers per interface.
• You can configure a maximum of 10 DHCPv6 relay servers. Interface-specific servers for IPv6 are not
supported.
• You cannot configure both a DHCP server and DHCP relay on the same device, even if you want to
enable them on different interfaces; you can only configure one type of service.
• DHCP relay services are not available in transparent firewall mode. You can, however, allow DHCP
traffic through using an access rule. To allow DHCP requests and replies through the Firepower Threat
Defense device, you need to configure two access rules, one that allows DCHP requests from the inside
interface to the outside (UDP destination port 67), and one that allows the replies from the server in the
other direction (UDP destination port 68).
• For IPv4, clients must be directly-connected to the Firepower Threat Defense device and cannot send
requests through another relay agent or a router. For IPv6, the Firepower Threat Defense device supports
packets from another relay server.
• The DHCP clients must be on different interfaces from the DHCP servers to which the Firepower Threat
Defense device relays requests.
• You cannot enable DHCP Relay on an interface in a traffic zone.
• DHCP relay is not supported on Virtual Tunnel Interfaces (VTIs).
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select DHCP > DHCP Server.
Step 3 Configure the following DHCP server options:
• Ping Timeout—The amount of time in milliseconds that Firepower Threat Defense device waits to time out a DHCP
ping attempt. Valid values range from 10 to 10000 milliseconds. The default value is 50 milliseconds.
To avoid address conflicts, the Firepower Threat Defense device sends two ICMP ping packets to an address before
assigning that address to a DHCP client.
• Lease Length—The amount of time in seconds that the client may use its allocated IP address before the lease
expires. Valid values range from 300 to 1048575 seconds. The default value is 3600 seconds (1 hour).
• (Routed mode) Auto-configuration—Enables DHCP auto configuration on the Firepower Threat Defense device.
Auto-configuration enables the DHCP server to provide the DHCP clients with the DNS server, domain name, and
WINS server information obtained from a DHCP client running on the specified interface. Otherwise, you can disable
auto configuration and add the values yourself in Step 4.
• (Routed mode) Interface—Specifies the interface to be used for auto configuration. For a device with virtual routing
capability, this interface can only be a global virtual router interface.
Step 5 Select Server, click Add, and configure the following options:
• Interface—Choose the interface from the drop-down list. In transparent mode, specify a named bridge group member
interface. In routed mode, specify a named routed interface or a named BVI; do not specify the bridge group member
interface. Note that each bridge group member interface for the BVI must also be named for the DHCP server to
operate.
• Address Pool—The range of IP addresses from lowest to highest that is used by the DHCP server. The range of IP
addresses must be on the same subnet as the selected interface and cannot include the IP address of the interface
itself.
• Type—DHCP option type. Available options include IP, ASCII, and HEX. If you chose IP, you must add IP
addresses in the IP Address fields. If you chose ASCII, you must add the ASCII value in the ASCII field. If you
chose HEX, you must add the HEX value in the HEX field.
• IP Address 1 and IP Address 2—The IP address(es) to be returned with this option code. To add a new IP address,
see Creating Network Objects, on page 450.
• ASCII—The ASCII value that is returned to the DHCP client. The string cannot include spaces.
• HEX—The HEX value that is returned to the DHCP client. The string must have an even number of digits and no
spaces. You do not need to use a 0x prefix.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select DHCP > DHCP Relay.
Step 3 In the Timeout field, enter the amount of time in seconds that the Firepower Threat Defense device waits to time out the
DHCP relay agent. Valid values range from 1 to 3600 seconds. The default value is 60 seconds.
The timeout is for address negotiation through the local DHCP Relay agent.
Step 4 On DHCP Relay Agent, click Add, and configure the following options:
• Interface—The interface connected to the DHCP clients.
• Enable IPv4 Relay—Enables IPv4 DHCP Relay for this interface.
• Set Route—(For IPv4) Changes the default gateway address in the DHCP message from the server to that of the
Firepower Threat Defense device interface that is closest to the DHCP client, which relayed the original DHCP
request. This action allows the client to set its default route to point to the Firepower Threat Defense device even if
the DHCP server specifies a different router. If there is no default router option in the packet, the Firepower Threat
Defense device adds one containing the interface address.
• Enable IPv6 Relay—Enables IPv6 DHCP Relay for this interface.
You can configure different ownership depending on your security needs and the requirements of the main
DNS server. For example, for a static address, the FTD should own the updates for both records.
The DDNS page also supports setting DHCP server settings relating to DDNS.
Note DDNS is not supported on the BVI or bridge group member interfaces.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose DHCP > DDNS.
Step 3 Configure a DDNS update method to enable DNS requests from the FTD.
You do not need to configure a DDNS update method if the DHCP server will perform all requests.
a) On DDNS Update Methods, click Add.
b) Set the Method Name.
c) (Optional) Configure the Update Interval between DNS requests. By default when all values are set to 0, update
requests are sent whenever the IP address or hostname changes. To send requests regularly, set the Days (0-364),
Hours, Minutes, and Seconds.
d) Set the Update Records you want the FTD to update.
This setting only affects the records you want to update directly from the FTD; to determine the records you want
the DHCP server to update, configure the DHCP client settings per interface or globally. See Step Step 4, on page
698.
• Not Defined—Disables DNS updates from the FTD.
• Both A and PTR Records—Sets the FTD to update both A and PTR RRs. Use this option for static or PPPoE
IP addressing.
• A Records—Sets the FTD to update the A RR only. Use this option if you want the DHCP server to update the
PTR RR.
e) Click OK.
f) Assign this method to the interface in Step Step 4, on page 698.
Step 4 Configure interface settings for DDNS, including setting the update method, DHCP client settings, and the hostname for
this interface.
a) On DDNS Interface Settings, click Add.
b) Choose the Interface from the drop-down list.
c) Choose the Method Name that you created on the DDNS Update Methods page.
You do not need to assign a method if you want the DHCP server to perform all updates.
d) Set the Host Name for this interface.
If you do not set the hostname, the device hostname is used. If you do not specify an FQDN, then the default domain
from the DNS server group is appended (for static or PPPoE IP addressing) or the domain name from the DHCP
server is appended (for DHCP IP addressing).
e) Configure the DHCP Client requests DHCP server to update requests to determine which records you want the
DHCP server to update.
The FTD sends DHCP client requests to the DHCP server. Note that the DHCP server must also be configured to
support DDNS. The server can be configured to honor the client requests, or it can override the client (in which case,
it will reply to the client so the client does not also try to perform updates that the server is performing).
For static or PPPoE IP addressing, these settings are ignored.
Note You can also set these values globally for all interfaces on the DDNS page. The per-interface settings take
precedence over the global settings.
• Not Selected—Disables DDNS requests to the DHCP server. Even if the client does not request DDNS updates,
the DHCP server can be configured to send updates anyway.
• No Update—Requests the DHCP server not to perform updates. This setting works in conjunction with a DDNS
update method with Both A and PTR Records enabled.
• Only PTR—Requests that the DHCP server perform the PTR RR update. This setting works in conjunction
with a DDNS update method with A Records enabled.
• Both A and PTR Records—Requests that the DHCP server perform both A and PTR RR updates. This setting
does not require a DDNS update method to be associated with the interface.
f) Click OK.
Note The Dynamic DNS Update settings relate to DHCP server settings when you enable a DHCP server on the
FTD. See Step Step 5, on page 698 for more information.
Step 5 If you enable the DHCP server on an FTD, you can configure DHCP server settings for DDNS.
To enable the DHCP server, see Configure the DHCP Server, on page 694). You can configure the server behavior when
DHCP clients use the standard DDNS update method. If the server performs any updates, then if the client lease expires
(and is not renewed), the server will request that the DNS server remove the RRs for which it was responsible.
a) You can configure server settings globally or per interface. For global settings, see the main DDNS page. For
per-interface settings, see the DDNS Interface Settings page. Interface settings take precedence over global settings.
b) Configure which DNS RRs you want the DHCP server to update under Dynamic DNS Update.
• Not Selected—DDNS updates are disabled, even if the client requests them.
• Only PTR—Enables DDNS updates. If you enable the Override DHCP Client Requests setting, then the
server will only update the PTR RR. Otherwise, the server will update RRs that the client requests. If the client
does not send an update request with the FQDN option, the server will request an update for both A and PTR
RRs using the hostname discovered in DHCP option 12.
• Both A and PTR Records—Enables DDNS updates. If you enable the Override DHCP Client Requests
setting, then the server will update both the A and PTR RRs. Otherwise, the server will update RRs that the
client requests. If the client does not send an update request with the FQDN option, the server will request an
update for both A and PTR RRs using the hostname discovered in DHCP option 12.
c) To override the update actions requested by the DHCP client, check Override DHCP Client Requests.
The server will reply to the client that the request was overridden, so the client does not also try to perform updates
that the server is performing.
Step 6 (Optional) Configure general DHCP client settings. These settings are not related to DDNS, but are related to how the
DHCP client behaves.
a) On the DDNS page, check Enable DHCP Client Broadcast to request that the DHCP server broadcast the DHCP
reply (DHCP option 1).
b) To force a MAC address to be stored inside a DHCP request packet for option 61 instead of the default internally
generated string, on DDNS > DHCP Client ID Interface, choose the interface from the Available Interfaces list,
and then click Add to move it to the Selected Interfaces list.
Some ISPs expect option 61 to be the interface MAC address. If the MAC address is not included in the DHCP request
packet, then an IP address will not be assigned. This setting does not directly relate to DDNS, but is a general DHCP
client setting.
The Firepower 1000/2100 chassis supports SNMPv1, SNMPv2c and SNMPv3. Both SNMPv1 and SNMPv2c
use a community-based form of security.
EnablingSNMPandConfiguringSNMPPropertiesforFirepower
1000/2100
Note This procedure only applies to Firepower 2100 and Firepower 1000 series devices.
Name Description
Admin State check box Whether SNMP is enabled or disabled. Enable this service only if your system
includes integration with an SNMP server.
Port field The port on which the Firepower chassis communicates with the SNMP host.
You cannot change the default port.
Community field The default SNMP v1 or v2 community name or SNMP v3 username the
Firepower chassis includes on any trap messages it sends to the SNMP host.
Enter an alphanumeric string between 1 and 32 characters. Do not use @ (at
sign), \ (backslash), " (double quote), ? (question mark) or an empty space. The
default is public.
Note that if the Community field is already set, the text to the right of the empty
field reads Set: Yes. If the Community field is not yet populated with a value,
the text to the right of the empty field reads Set: No.
System Admin Name field The contact person responsible for the SNMP implementation.
Enter a string of up to 255 characters, such as an email address or a name and
telephone number.
Location field The location of the host on which the SNMP agent (server) runs.
Enter an alphanumeric string up to 510 characters.
What to do next
Create SNMP traps and users.
Note This procedure only applies to Firepower 2100 and Firepower 1000 series devices.
Step 4 In the SNMP Trap Configuration dialog box, complete the following fields:
Name Description
Host Name field The hostname or IP address of the SNMP host to which the Firepower chassis
should send the trap.
Community field The SNMP v1 or v2 community name or the SNMP v3 username the Firepower
chassis includes when it sends the trap to the SNMP host. This must be the same
as the community or username that is configured for the SNMP service.
Enter an alphanumeric string between 1 and 32 characters. Do not use @ (at
sign), \ (backslash), " (double quote), ? (question mark) or an empty space.
Port field The port on which the Firepower chassis communicates with the SNMP host
for the trap.
Enter an integer between 1 and 65535.
Version field The SNMP version and model used for the trap. This can be one of the following:
• V1
• V2
• V3
Type field If you select V2 or V3 for the version, the type of trap to send. This can be one
of the following:
• Traps
• Informs
Privilege field If you select V3 for the version, the privilege associated with the trap. This can
be one of the following:
• Auth—Authentication but no encryption
• Noauth—No authentication or encryption
• Priv—Authentication and encryption
Note This procedure only applies to Firepower 2100 and Firepower 1000 series devices.
Name Description
Username field The username assigned to the SNMP user.
Enter up to 32 letters or numbers. The name must begin with a letter and you
can also specify _ (underscore), . (period), @ (at sign), and - (hyphen).
Introduction to QoS
Quality of Service, or QoS, rate limits (polices) network traffic that is allowed or trusted by access control.
The system does not rate limit traffic that was fastpathed.
QoS is supported for routed interfaces on Firepower Threat Defense devices only.
You must constrain QoS rules by source or destination (routed) interfaces. The system enforces rate limiting
independently on each of those interfaces; you cannot specify an aggregate rate limit for a set of interfaces.
QoS rules can also rate limit traffic by other network characteristics, as well as contextual information such
as application, URL, user identity, and custom Security Group Tags (SGTs).
You can rate limit download and upload traffic independently. The system determines download and upload
directions based on the connection initiator.
Note QoS is not subordinate to a main access control configuration; you configure QoS independently. However,
the access control and QoS policies deployed to the same device share identity configurations; see Associating
Other Policies with Access Control, on page 1352.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
Step 3 Configure QoS rules; see Configuring QoS Rules, on page 708 and Rule Management: Common Characteristics, on page
403.
The Rules in the QoS policy editor lists each rule in evaluation order, and displays a summary of the rule conditions and
rate limiting configurations. A right-click menu provides rule management options, including moving, enabling, and
disabling.
Helpful in larger deployments, you can Filter by Device to display only the rules that affect a specfic device or group of
devices. You can also search for and within rules; the system matches text you enter in the Search Rules field to rule
names and condition values, including objects and object groups.
Note Properly creating and ordering rules is a complex task, but one that is essential to building an effective
deployment. If you do not plan carefully, rules can preempt other rules, require additional licenses, or contain
invalid configurations. Icons represent comments, warnings, and errors. If issues exist, click Show Warnings
to display a list. For more information, see Best Practices for Access Control Rules, on page 1332.
Step 4 Click Policy Assignments to identify the managed devices targeted by the policy; see Setting Target Devices for a QoS
Policy, on page 708.
If you identified target devices during policy creation, verify your choices.
What to do next
• Configure and deploy the QoS policy; see Rate Limiting with QoS Policies, on page 706.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• Comments—Click Comments. To add a comment click New Comment, enter a comment, and click OK. You can
edit or delete this comment until you save the rule.
For detailed information on rule components, see QoS Rule Components, on page 709.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Best Practices for Access Control Rules, on page 1332
State (Enabled/Disabled)
By default, rules are enabled. If you disable a rule, the system does not use it and stops generating warnings
and errors for that rule.
Conditions
Conditions specify the specific traffic the rule handles. You can configure each rule with multiple conditions.
Traffic must match all conditions to match the rule. Each condition type has its own tab in the rule editor.
You can rate limit traffic using:
• Interface Conditions, on page 408 (routed only; required)
• Network Conditions, on page 410
• Port and ICMP Code Conditions, on page 415
• Application Conditions (Application Control), on page 417
• URL Filtering, on page 1369
• User, Realm, and ISE Attribute Conditions (User Control), on page 426
• Custom SGT Conditions, on page 431
Comments
Each time you save changes to a rule you can add comments. For example, you might summarize the overall
configuration for the benefit of other users, or note when you change a rule and the reason for the change.
In the policy editor, the system displays how many comments a rule has. In the rule editor, use the Comments
tab to view existing comments and add new ones.
Rate limit increased 6.2.1 Raised the maximum rate limit from 1,000 Mbps to 100,000 Mbps.
Modified screen: QoS rule editor
Supported platforms: Firepower Threat Defense
Custom SGT and original client 6.2.1 QoS can now rate limit traffic using custom Security Group Tags (SGTs)
network filtering and original client network information (XFF, True-Client-IP, or
custom-defined HTTP headers).
Modified screen: QoS rule editor
Supported platforms: Firepower Threat Defense
Note High availability is not supported on Firepower Threat Defense Virtual running in the public cloud.
Hardware Requirements
The two units in a High Availability configuration must:
• Be the same model. In addition, for container instances, they must use the same resource profile attributes.
For the Firepower 9300, High Availability is only supported between same-type modules; but the two
chassis can include mixed modules. For example, each chassis has an SM-36 and SM-44. You can create
High Availability pairs between the SM-36 modules and between the SM-44 modules.
If you change the resource profile after you add the High Availability pair to the FMC, update the
inventory for each unit on the Devices > Device Management > Device > System > Inventory dialog
box.
• Have the same number and types of interfaces.
For the Firepower 4100/9300 chassis, all interfaces must be preconfigured in FXOS identically before
you enable High Availability. If you change the interfaces after you enable High Availability, make the
interface changes in FXOS on the Standby unit, and then make the same changes on the Active unit.
If you are using units with different flash memory sizes in your High Availability configuration, make sure
the unit with the smaller flash memory has enough space to accommodate the software image files and the
configuration files. If it does not, configuration synchronization from the unit with the larger flash memory
to the unit with the smaller flash memory will fail.
Software Requirements
The two units in a High Availability configuration must:
• Be in the same firewall mode (routed or transparent).
• Have the same software version.
• Be in the same domain or group on the Firepower Management Center.
• Have the same NTP configuration. See Configure NTP Time Synchronization for Threat Defense, on
page 1192.
• Be fully deployed on the Firepower Management Center with no uncommitted changes.
• Not have DHCP or PPPoE configured in any of their interfaces.
• (Firepower 4100/9300) Have the same flow offload mode, either both enabled or both disabled.
Failover Link
The two units in a failover pair constantly communicate over a failover link to determine the operating status
of each unit.
Note When using an EtherChannel or Redundant Interface as the failover or state link, you must confirm that the
same EtherChannel or Redundant interface with the same member interfaces exists on both devices before
establishing high availability.
For a redundant interface used as the failover link, see the following benefits for added redundancy:
• When a failover unit boots up, it alternates between the member interfaces to detect an active unit.
• If a failover unit stops receiving keepalive messages from its peer on one of the member interfaces, it
switches to the other member interface.
For an EtherChannel used as the failover link, to prevent out-of-order packets, only one interface in the
EtherChannel is used. If that interface fails, then the next interface in the EtherChannel is used. You cannot
alter the EtherChannel configuration while it is in use as a failover link.
If you do not use a switch between the units, if the interface fails, the link is brought down on both peers. This
condition may hamper troubleshooting efforts because you cannot easily determine which unit has the failed
interface and caused the link to come down.
Scenario 2—Recommended
We recommend that failover links not use the same switch as the data interfaces. Instead, use a different switch
or use a direct cable to connect the failover link, as shown in the following figures.
Figure 25: Connecting with a Different Switch
Scenario 3—Recommended
If the Firepower Threat Defense data interfaces are connected to more than one set of switches, then a failover
link can be connected to one of the switches, preferably the switch on the secure (inside) side of network, as
shown in the following figure.
Figure 27: Connecting with a Secure Switch
Scenario 4—Recommended
The most reliable failover configurations use a redundant interface on the failover link, as shown in the
following figures.
Note Although recommended, the standby address is not required. Without a standby IP address, the active unit
cannot perform network tests to check the standby interface health; it can only track the link state. You also
cannot connect to the standby unit on that interface for management purposes.
The IP address and MAC address for the state link do not change at failover.
However, if the secondary unit boots without detecting the primary unit, then the secondary unit becomes the
active unit and uses its own MAC addresses, because it does not know the primary unit MAC addresses. When
the primary unit becomes available, the secondary (active) unit changes the MAC addresses to those of the
primary unit, which can cause an interruption in your network traffic. Similarly, if you swap out the primary
unit with new hardware, a new MAC address is used.
Virtual MAC addresses guard against this disruption, because the active MAC addresses are known to the
secondary unit at startup, and remain the same in the case of new primary unit hardware. If you do not configure
virtual MAC addresses, you might need to clear the ARP tables on connected routers to restore traffic flow.
The Firepower Threat Defense device does not send gratuitous ARPs for static NAT addresses when the MAC
address changes, so connected routers do not learn of the MAC address change for these addresses.
Stateful Failover
During Stateful Failover, the active unit continually passes per-connection state information to the standby
unit. After a failover occurs, the same connection information is available at the new active unit. Supported
end-user applications are not required to reconnect to keep the same communication session.
Supported Features
For Stateful Failover, the following state information is passed to the standby Firepower Threat Defense
device:
• NAT translation table.
• TCP and UDP connections and states, including HTTP connection states. Other types of IP protocols,
and ICMP, are not parsed by the active unit, because they get established on the new active unit when a
new packet arrives.
• Snort connection states, inspection results, and pin hole information, including strict TCP enforcement.
Note Routes are synchronized only for link-up or link-down events on an active unit.
If the link goes up or down on the standby unit, dynamic routes sent from the
active unit may be lost. This is normal, expected behavior.
• DHCP Server—DHCP address leases are not replicated. However, a DHCP server configured on an
interface will send a ping to make sure an address is not being used before granting the address to a
DHCP client, so there is no impact to the service. State information is not relevant for DHCP relay or
DDNS.
• Access control policy decisions—Decisions related to traffic matching (including URL, URL category,
geolocation, and so forth), intrusion detection, malware, and file type are preserved during failover.
However, for connections being evaluated at the moment of failover, there are the following caveats:
• AVC—App-ID verdicts are replicated, but not detection states. Proper synchronization occurs as
long as the App-ID verdicts are complete and synchronized before failover occurs.
• Intrusion detection state—Upon failover, once mid-flow pickup occurs, new inspections are
completed, but old states are lost.
• File malware blocking—The file disposition must become available before failover.
• File type detection and blocking—The file type must be identified before failover. If failover occurs
while the original active device is identifying the file, the file type is not synchronized. Even if your
file policy blocks that file type, the new active device downloads the file.
• User identity decisions from the identity policy, including the user-to-IP address mappings gathered
passively through the User Agent and ISE Session Directory, and active authentication through captive
portal. Users who are actively authenticating at the moment of failover might be prompted to authenticate
again.
• Network AMP—Cloud lookups are independent from each device, so failover does not affect this feature
in general. Specifically:
• Signature Lookup—If failover occurs in the middle of a file transmission, no file event is generated
and no detection occurs.
• File Storage—If failover occurs when the file is being stored, it is stored on the original active
device. If the original active device went down while the file was being stored, the file does not get
stored.
• File Pre-classification (Local Analysis)—If failover occurs in the middle of pre-classification,
detection fails.
• File Dynamic Analysis (Connectivity to the cloud)—If failover occurs, the system might submit
the file to the cloud.
• Archive File Support—If failover occurs in the middle of an analysis, the system loses visibility
into the file/archive.
• Custom Blocking—If failover occurs, no events are generated.
• Security Intelligence decisions. However, DNS-based decisions that are in process at the moment of
failover are not completed.
• RA VPN—Remote access VPN end users do not have to reauthenticate or reconnect the VPN session
after a failover. However, applications operating over the VPN connection could lose packets during the
failover process and not recover from the packet loss.
Unsupported Features
For Stateful Failover, the following state information is not passed to the standby Firepower Threat Defense
device:
• Sessions inside plaintext tunnels such as GRE or IP-in-IP. Sessions inside tunnels are not replicated and
the new active node will not be able to reuse existing inspection verdicts to match the correct policy
rules.
• Decrypted TLS/SSL connections—The decryption states are not synchronized, and if the active unit
fails, then decrypted connections will be reset. New connections will need to be established to the new
active unit. Connections that are not decrypted (they match a do-not-decrypt rule) are not affected and
are replicated correctly.
• TCP state bypass connections
• Multicast routing.
interface interface_id
spanning-tree portfast
The PortFast feature immediately transitions the port into STP forwarding mode upon linkup. The port
still participates in STP. So if the port is to be a part of the loop, the port eventually transitions into STP
blocking mode.
• If the switch port is in Trunk mode, or you cannot enable STP PortFast, then you can use one of the
following less desirable workarounds that impacts failover functionality or STP stability:
• Disable interface monitoring on the bridge group and member interfaces.
• Increase the interface hold time in the failover criteria to a high value that will allow STP to converge
before the unit fails over.
• Decrease the STP timers on the switch to allow STP to converge faster than the interface hold time.
Interface Monitoring
When a unit does not receive hello messages on a monitored interface for 15 seconds, it runs interface tests.
If one of the interface tests fails for an interface, but this same interface on the other unit continues to
successfully pass traffic, then the interface is considered to be failed, and the device stops running tests.
If the threshold you define for the number of failed interfaces is met (see Devices > Device Management >
High Availability > Failover Trigger Criteria), and the active unit has more failed interfaces than the standby
unit, then a failover occurs. If an interface fails on both units, then both interfaces go into the “Unknown”
state and do not count towards the failover limit defined by failover interface policy.
An interface becomes operational again if it receives any traffic. A failed device returns to standby mode if
the interface failure threshold is no longer met.
If an interface has IPv4 and IPv6 addresses configured on it, the device uses the IPv4 addresses to perform
the health monitoring. If an interface has only IPv6 addresses configured on it, then the device uses IPv6
neighbor discovery instead of ARP to perform the health monitoring tests. For the broadcast ping test, the
device uses the IPv6 all nodes address (FE02::1).
Interface Tests
The Firepower Threat Defense device uses the following interface tests. The duration of each test is
approximately 1.5 seconds.
1. Link Up/Down test—A test of the interface status. If the Link Up/Down test indicates that the interface
is down, then the device considers it failed, and testing stops. If the status is Up, then the device performs
the Network Activity test.
2. Network Activity test—A received network activity test. At the start of the test, each unit clears its received
packet count for its interfaces. As soon as a unit receives any eligible packets during the test, then the
interface is considered operational. If both units receive traffic, then testing stops. If one unit receives
traffic and the other unit does not, then the interface on the unit that does not receive traffic is considered
failed, and testing stops. If neither unit receives traffic, then the device starts the ARP test.
3. ARP test—A test for successful ARP replies. Each unit sends a single ARP request for the IP address in
the most recent entry in its ARP table. If the unit receives an ARP reply or other network traffic during
the test, then the interface is considered operational. If the unit does not receive an ARP reply, then the
device sends a single ARP request for the IP address in the next entry in the ARP table. If the unit receives
an ARP reply or other network traffic during the test, then the interface is considered operational. If both
units receive traffic, then testing stops. If one unit receives traffic, and the other unit does not, then the
interface on the unit that does not receive traffic is considered failed, and testing stops. If neither unit
receives traffic, then the device starts the Broadcast Ping test.
4. Broadcast Ping test—A test for successful ping replies. Each unit sends a broadcast ping, and then counts
all received packets. If the unit receives any packets during the test, then the interface is considered
operational. If both units receive traffic, then testing stops. If one unit receives traffic, and the other unit
does not, then the interface on the unit that does not receive traffic is considered failed, and testing stops.
If neither unit receives traffic, then testing starts over again with the ARP test. If both units continue to
receive no traffic from the ARP and Broadcast Ping tests, then these tests will continue running in
perpetuity.
Interface Status
Monitored interfaces can have the following status:
• Unknown—Initial status. This status can also mean the status cannot be determined.
• Normal—The interface is receiving traffic.
• Normal (Waiting)—The interface is up, but has not yet received a hello packet from the corresponding
interface on the peer unit.
• Normal (Not-Monitored)—The interface is up, but is not monitored by the failover process.
• Testing—Hello messages are not heard on the interface for five poll times.
• Link Down—The interface or VLAN is administratively down.
• Link Down (Waiting)—The interface or VLAN is administratively down and has not yet received a hello
packet from the corresponding interface on the peer unit.
• Link Down (Not-Monitored)—The interface or VLAN is administratively down, but is not monitored
by the failover process.
• No Link—The physical link for the interface is down.
• No Link (Waiting)—The physical link for the interface is down and has not yet received a hello packet
from the corresponding interface on the peer unit.
• No Link (Not-Monitored)—The physical link for the interface is down, but is not monitored by the
failover process.
• Failed—No traffic is received on the interface, yet traffic is heard on the peer interface.
Table 76:
Command Purpose
The following table shows the failover triggering events and associated failure detection timing. If failover
occurs, you can view the reason for the failover in the Message Center, along with various operations pertaining
to the high availability pair. You can configure these thresholds to a value within the specified
minimum-maximum range.
• If both units boot simultaneously, then the primary unit becomes the active unit, and the secondary unit
becomes the standby unit.
Failover Events
In Active/Standby failover, failover occurs on a unit basis.
The following table shows the failover action for each failure event. For each failure event, the table shows
the failover policy (failover or no failover), the action taken by the active unit, the action taken by the standby
unit, and any special notes about the failover condition and actions.
Failure Event Policy Active Unit Action Standby Unit Action Notes
Active unit failed (power Failover n/a Become active No hello messages are
or hardware) received on any
Mark active as failed
monitored interface or the
failover link.
Standby unit failed No failover Mark standby as failed n/a When the standby unit is
(power or hardware) marked as failed, then the
active unit does not
attempt to fail over, even
if the interface failure
threshold is surpassed.
Failover link failed No failover Mark failover link as Mark failover link as You should restore the
during operation failed failed failover link as soon as
possible because the unit
cannot fail over to the
standby unit while the
failover link is down.
Failover link failed at No failover Become active Become active If the failover link is
startup down at startup, both
Mark failover link as Mark failover link as
units become active.
failed failed
Interface failure on active Failover Mark active as failed Become active None.
unit above threshold
Failure Event Policy Active Unit Action Standby Unit Action Notes
Interface failure on No failover No action Mark standby as failed When the standby unit is
standby unit above marked as failed, then the
threshold active unit does not
attempt to fail over even
if the interface failure
threshold is surpassed.
Supported Domains
Any
User Roles
Admin
Network Admin
Note On Firepower 1010 devices on which version 6.5 or above is freshly installed
and managed by Firepower Management Center version 6.5 or later, the default
interfaces will be of switch port type. Since the switch port functionality is not
supported for failover, turn off switch port on those interfaces, do a deployment,
and then create failover. For Firepower 1010 systems that are upgraded from
versions prior to 6.5, the default interfaces will be the same as those in the previous
version.
Additional Guidelines
• When the active unit fails over to the standby unit, the connected switch port running Spanning Tree
Protocol (STP) can go into a blocking state for 30 to 50 seconds when it senses the topology change. To
avoid traffic loss while the port is in a blocking state, you can enable the STP PortFast feature on the
switch:
interface interface_id spanning-tree portfast
This workaround applies to switches connected to both routed mode and bridge group interfaces. The
PortFast feature immediately transitions the port into STP forwarding mode upon linkup. The port still
participates in STP. So if the port is to be a part of the loop, the port eventually transitions into STP
blocking mode.
• You cannot enable failover if a local CA server is configured. Remove the CA configuration using the
no crypto ca server command.
• Configuring port security on the switch(es) connected to the Firepower Threat Defense failover pair can
cause communication problems when a failover event occurs. This problem occurs when a secure MAC
address configured or learned on one secure port moves to another secure port, a violation is flagged by
the switch port security feature.
• For Active/Standby High Availability and a VPN IPsec tunnel, you cannot monitor both the active and
standby units using SNMP over the VPN tunnel. The standby unit does not have an active VPN tunnel,
and will drop traffic destined for the NMS. You can instead use SNMPv3 with encryption so the IPsec
tunnel is not required.
Note The system uses the failover link to sync configuration, while the stateful failover link is used to sync application
content between peers. The failover link and the stateful failover link are in a private IP space and are only
used for communication between peers in a high availability pair.After high availability is established, selected
interface links and encryption settings cannot be modified without breaking the high availability pair and
reconfiguring it.
Caution Creating or breaking a Firepower Threat Defense high availability pair immediately restarts the Snort process
on the primary and secondary devices, temporarily interrupting traffic inspection on both devices. Whether
traffic drops during this interruption or passes without further inspection depends on how the target device
handles traffic. See Snort® Restart Traffic Behavior, on page 390 for more information. The system warns
you that continuing to create a high availability pair restarts the Snort process on the primary and secondary
devices and allows you to cancel.
Note The High Availability formation is possible between the two Firepower Threat Defense devices when the
certificate available on the primary device is not present on the secondary device. When High Availability is
formed, the certificate will be synched on the secondary device.
Step 1 Add both devices to the Firepower Management Center according to Add a Device to the FMC, on page 260.
Step 2 Choose Devices > Device Management.
Step 3 From the Add drop-down menu, choose High Availability.
Step 4 Enter a display Name for the high availability pair.
Step 5 Under Device Type, choose Firepower Threat Defense.
Step 6 Choose the Primary Peer device for the high availability pair.
Step 7 Choose the Secondary Peer device for the high availability pair.
Step 8 Click Continue.
Step 9 Under LAN Failover Link, choose an Interface with enough bandwidth to reserve for failover communications.
Note Only interfaces that do not have a logical name and do not belong to a security zone,will be listed in the
Interface drop-down in the Add High Availability Pair dialog.
Step 16 Optionally, choose Enabled and choose the Key Generation method for IPsec Encryption between the failover links.
Step 17 Click OK. This process takes a few minutes as the process synchronizes system data.
What to do next
Ensure to back up the devices. You can use the backup to quickly replace the devices when they fail and to
restore the high availability service without being delinked from the Firepower Management Center. For more
information, see Backup and Restore, on page 175.
By default, monitoring is enabled on all physical interfaces, and for the Firepower 1010 all VLAN interfaces,
with logical names configured. You might want to exclude interfaces attached to less critical networks from
affecting your failover policy. Firepower 1010 switch ports are not elegible for interface monitoring.
Step 7 If you configured the IPv6 address manually, on the IPv6 tab, click the Edit ( ) next to the active IP address, enter the
Standby IP Address, and click OK.
This address must be a free address on the same network as the active IP address. For autogenerated and Enforce EUI
64 addresses, the standby address is automatically generated.
If active and standby MAC addresses are configured in both locations, the addresses defined during interface
configuration takes preference for failover.
You can minimize loss of traffic during failover by designating active and standby mac addresses to the
physical interface. This feature offers redundancy against IP address mapping for failover.
Switch the Active Peer in a Firepower Threat Defense High Availability Pair
After you establish a Firepower Threat Defense high availability pair, you can manually switch the active and
standby units, effectively forcing failover for reasons such as persistent fault or health events on the current
active unit. Both units should be fully deployed before you complete this procedure.
Step 2 Next to the high availability pair where you want to change the active peer, click the Switch Active Peer.
Step 3 You can:
• Click Yes to immediately make the standby device the active device in the high availability pair.
• Click No to cancel and return to the Device Management page.
When you suspend high availability, you stop the pair of devices from behaving as a failover unit. The currently
active device remains active, handling all user connections. However, failover criteria are no longer monitored,
and the system will never fail over to the now pseudo-standby device. The standby device will retain its
configuration, but it will remain inactive.
The key difference between suspending HA and breaking HA is that on a suspended HA device, the high
availability configuration is retained. When you break HA, the configuration is erased. Thus, you have the
option to resume HA on a suspended system, which enables the existing configuration and makes the two
devices function as a failover pair again.
To suspend HA, use the configure high-availability suspend command.
high-availability.
Please enter 'YES' to continue if there is no deployment operation in
progress and 'NO' if you wish to abort: YES
Successfully suspended high-availability.
If you suspend high availability from the active unit, the configuration is suspended on both the active and
standby unit. If you suspend it from the standby unit, it is suspended on the standby unit only, but the active
unit will not attempt to fail over to a suspended unit.
To resume failover, use the configure high-availability resume command.
You can resume a unit only if it is in Suspended state. The unit will negotiate active/standby status with the
peer unit.
Note Suspending high availability is a temporary state. If you reload a unit, it resumes the high-availability
configuration automatically and negotiates the active/standby state with the peer.
Caution Creating or breaking a Firepower Threat Defense high availability pair immediately restarts the Snort process
on the primary and secondary devices, temporarily interrupting traffic inspection on both devices. Whether
traffic drops during this interruption or passes without further inspection depends on how the target device
handles traffic. See Snort® Restart Traffic Behavior, on page 390 for more information. The system warns
you that continuing to create a high availability pair restarts the Snort process on the primary and secondary
devices and allows you to cancel.
Step 1 Choose Force Break to separate the high availability pair; see Separate Units in a High Availability Pair, on page 735.
Note The break operation removes all the configuration related to HA from Firepower Threat Defense and Firepower
Management Center, and you need to recreate it manually later. To successfully configure the same HA pair,
ensure that you save the IPs, MAC addresses, and monitoring configuration of all the interfaces/subinterfaces
prior to executing the HA break operation.
Step 2 Unregister the failed primary Firepower Threat Defense device from the Firepower Management Center; see Delete a
Device from the FMC, on page 264.
Step 3 Register the replacement Firepower Threat Defense to the Firepower Management Center; see Add a Device to the FMC,
on page 260.
Step 4 Configure high availability, using the existing secondary/active unit as the primary device and the replacement device
as the secondary/standby device during registration; see Add a Firepower Threat Defense High Availability Pair, on page
728.
Caution Creating or breaking a Firepower Threat Defense high availability pair immediately restarts the Snort process
on the primary and secondary devices, temporarily interrupting traffic inspection on both devices. Whether
traffic drops during this interruption or passes without further inspection depends on how the target device
handles traffic. See Snort® Restart Traffic Behavior, on page 390 for more information. The system warns
you that continuing to create a high availability pair restarts the Snort process on the primary and secondary
devices and allows you to cancel.
Step 1 Choose Force Break to separate the high availability pair; see Separate Units in a High Availability Pair, on page 735.
Note The break operation removes all the configuration related to HA from Firepower Threat Defense and Firepower
Management Center, and you need to recreate it manually later. To successfully configure the same HA pair,
ensure that you save the IPs, MAC addresses, and monitoring configuration of all the interfaces/subinterfaces
prior to executing the HA break operation.
Step 2 Unregister the secondary Firepower Threat Defense device from the Firepower Management Center; see Delete a Device
from the FMC, on page 264.
Step 3 Register the replacement Firepower Threat Defense to the Firepower Management Center; see Add a Device to the FMC,
on page 260.
Step 4 Configure high availability, using the existing primary/active unit as the primary device and the replacement device as
the secondary/standby device during registration; see Add a Firepower Threat Defense High Availability Pair, on page
728.
Policies that were not deployed to the active device prior to the break operation continue to remain un-deployed
after the break operation is complete. Deploy the policies on the standalone device, after the break operation
is complete.
Tip An exception to this is the FlexConfig policy. A FlexConfig policy deployed on the active device may show
a deployment failure after the break HA operation. You must alter and re-deploy the FlexConfig policy on
the active device.
Note If you cannot reach the high availability pair using the Firepower Management Center, use the CLI command
configure high-availability disable to remove the failover configuration from both devices.
What to do next
(Optional) If you are using a flex-config policy on the active device, alter and re-deploy the flex-config policy
to eliminate deployment errors.
Step 2 Next to the high-availability pair you want to unregister, click Delete ( ).
Step 3 Click Yes. The device high availability pair is deleted.
Step 4 On each unit, access the Firepower Threat Defense CLI, and enter the following command:
configure high-availability disable
If you do not enter this command, you cannot re-register the units and form a new HA pair.
Note Enter this command before you change the firewall mode; if you change the mode, the unit will not later let
you enter the configure high-availability disable command, and the Firepower Management Center cannot
re-form the HA pair without this command.
Note Some features are not supported when using clustering. See Unsupported Features with Clustering, on page
776.
Note Individual interfaces are not supported, with the exception of a management
interface.
The following sections provide more detail about clustering concepts and implementation. See also Reference
for Clustering, on page 776.
Bootstrap Configuration
When you deploy the cluster, the Firepower 4100/9300 chassis supervisor pushes a minimal bootstrap
configuration to each unit that includes the cluster name, cluster control link interface, and other cluster
settings.
Cluster Members
Cluster members work together to accomplish the sharing of the security policy and traffic flows.
One member of the cluster is the control unit. The control unit is determined automatically. All other members
are data units.
You must perform all configuration on the control unit only; the configuration is then replicated to the data
units.
Some features do not scale in a cluster, and the control unit handles all traffic for those features. See Centralized
Features for Clustering, on page 776.
For a 2-member inter-chassis cluster, do not directly connect the cluster control link from one chassis to the
other chassis. If you directly connect the interfaces, then when one unit fails, the cluster control link fails, and
thus the remaining healthy unit fails. If you connect the cluster control link through a switch, then the cluster
control link remains up for the healthy unit.
Cluster control link traffic includes both control and data traffic.
A higher-bandwidth cluster control link helps the cluster to converge faster when there are membership changes
and prevents throughput bottlenecks.
Note If your cluster has large amounts of asymmetric (rebalanced) traffic, then you should increase the cluster
control link size.
Management Network
We recommend connecting all units to a single management network. This network is separate from the cluster
control link.
Management Interface
You must assign a Management type interface to the cluster. This interface is a special individual interface
as opposed to a Spanned interface. The management interface lets you connect directly to each unit. This
Management logical interface is separate from the other interfaces on the device. It is used to set up and
register the device to the Firepower Management Center. It uses its own local authentication, IP address, and
static routing. Each cluster member uses a separate IP address on the management network that you set as
part of the bootstrap configuration.
The management interface is shared between the Management logical interface and the Diagnostic logical
interface. The Diagnostic logical interface is optional and is not configured as part of the bootstrap configuration.
The Diagnostic interface can be configured along with the rest of the data interfaces. If you choose to configure
the Diagnostic interface, configure a Main cluster IP address as a fixed address for the cluster that always
belongs to the current control unit. You also configure a range of addresses so that each unit, including the
current control unit, can use a Local address from the range. The Main cluster IP address provides consistent
diagnostic access to an address; when a control unit changes, the Main cluster IP address moves to the new
control unit, so access to the cluster continues seamlessly. For outbound management traffic such as TFTP
or syslog, each unit, including the control unit, uses the Local IP address to connect to the server.
Cluster Interfaces
For intra-chassis clustering, you can assign both physical interfaces or EtherChannels (also known as port
channels) to the cluster. Interfaces assigned to the cluster are Spanned interfaces that load-balance traffic
across all members of the cluster.
For inter-chassis clustering, you can only assign data EtherChannels to the cluster. These Spanned
EtherChannels include the same member interfaces on each chassis; on the upstream switch, all of these
interfaces are included in a single EtherChannel, so the switch does not know that it is connected to multiple
devices.
Individual interfaces are not supported, with the exception of a management interface.
Spanned EtherChannels
You can group one or more interfaces per chassis into an EtherChannel that spans all chassis in the cluster.
The EtherChannel aggregates the traffic across all the available active interfaces in the channel. A Spanned
EtherChannel can be configured in both routed and transparent firewall modes. In routed mode, the
EtherChannel is configured as a routed interface with a single IP address. In transparent mode, the IP address
is assigned to the BVI, not to the bridge group member interface. The EtherChannel inherently provides load
balancing as part of basic operation.
For multi-instance clusters, each cluster requires dedicated data EtherChannels; you cannot use shared interfaces
or VLAN subinterfaces.
Configuration Replication
All units in the cluster share a single configuration. You can only make configuration changes on the control
unit, and changes are automatically synced to all other units in the cluster.
Note If you add the cluster before the FMC is licensed (and running in Evaluation mode), then when you license
the FMC, you can experience traffic disruption when you deploy policy changes to the cluster. Changing to
licensed mode causes all data units to leave the cluster and then rejoin.
User Roles
• Admin
• Access Admin
• Network Admin
• Must run the identical FXOS software except at the time of an image upgrade.
• Must include the same interface configuration for interfaces you assign to the cluster, such as the same
Management interface, EtherChannels, active interfaces, speed and duplex, and so on. You can use
different network module types on the chassis as long as the capacity matches for the same interface IDs
and interfaces can successfully bundle in the same spanned EtherChannel. Note that all data interfaces
must be EtherChannels in inter-chassis clustering. If you change the interfaces in FXOS after you enable
clustering (by adding or removing interface modules, or configuring EtherChannels, for example), then
perform the same changes on each chassis, starting with the data units, and ending with the control unit.
• Must use the same NTP server. For Firepower Threat Defense, the Firepower Management Center must
also use the same NTP server. Do not set the time manually.
• Mix and match clusters and standalone instances—Not all container instances on a security module/engine
need to belong to a cluster. You can use some instances as standalone or High Availability units. You
can also create multiple clusters using separate instances on the same security module/engine.
• All 3 modules in a Firepower 9300 must belong to the cluster—For the Firepower 9300, a cluster requires
a single container instance on all 3 modules. You cannot create a cluster using instances on module 1
and 2, and then use a native instance on module 3, or example.
• Match resource profiles—We recommend that each unit in the cluster use the same resource profile
attributes; however, mismatched resources are allowed when changing cluster units to a different resource
profile, or when using different models.
• Dedicated cluster control link—For inter-chassis clustering, each cluster needs a dedicated cluster control
link. For example, each cluster can use a separate subinterface on the same cluster-type EtherChannel,
or use separate EtherChannels.
• No shared interfaces—Shared-type interfaces are not supported with clustering. However, the same
Management and Eventing interfaces can used by multiple clusters.
• Mix chassis models—We recommend that you use the same security module or chassis model for each
cluster instance. However, you can mix and match container instances on different Firepower 9300
security module types or Firepower 4100 models in the same cluster if required. You cannot mix Firepower
9300 and 4100 instances in the same cluster. For example, you can create a cluster using an instance on
a Firepower 9300 SM-56, SM-40, and SM-36. Or you can create a cluster on a Firepower 4140 and a
4150.
command). Do not use a vlan keyword in the load-balance algorithm because it can cause unevenly
distributed traffic to the devices in a cluster.
• If you change the load-balancing algorithm of the EtherChannel on the switch, the EtherChannel interface
on the switch temporarily stops forwarding traffic, and the Spanning Tree Protocol restarts. There will
be a delay before traffic starts flowing again.
• Some switches do not support dynamic port priority with LACP (active and standby links). You can
disable dynamic port priority to provide better compatibility with Spanned EtherChannels.
• Switches on the cluster control link path should not verify the L4 checksum. Redirected traffic over the
cluster control link does not have a correct L4 checksum. Switches that verify the L4 checksum could
cause traffic to be dropped.
• Port-channel bundling downtime should not exceed the configured keepalive interval.
• On Supervisor 2T EtherChannels, the default hash distribution algorithm is adaptive. To avoid asymmetric
traffic in a VSS design, change the hash algorithm on the port-channel connected to the cluster device
to fixed:
router(config)# port-channel id hash-distribution fixed
Do not change the algorithm globally; you may want to take advantage of the adaptive algorithm for the
VSS peer link.
• Firepower 4100/9300 clusters support LACP graceful convergence. So you can leave LACP graceful
convergence enabled on connected Cisco Nexus switches.
• When you see slow bundling of a Spanned EtherChannel on the switch, you can enable LACP rate fast
for an individual interface on the switch. FXOS EtherChannels have the LACP rate set to fast by default.
Note that some switches, such as the Nexus series, do not support LACP rate fast when performing
in-service software upgrades (ISSUs), so we do not recommend using ISSUs with clustering.
Additional Guidelines
• When adding a unit to an existing cluster, or when reloading a unit, there will be a temporary, limited
packet/connection drop; this is expected behavior. In some cases, the dropped packets can hang
connections; for example, dropping a FIN/ACK packet for an FTP connection will make the FTP client
hang. In this case, you need to reestablish the FTP connection.
• If you use a Windows 2003 server connected to a Spanned EtherChannel interface, when the syslog
server port is down, and the server does not throttle ICMP error messages, then large numbers of ICMP
messages are sent back to the cluster. These messages can result in some units of the cluster experiencing
high CPU, which can affect performance. We recommend that you throttle ICMP error messages.
• We recommend connecting EtherChannels to a VSS or vPC for redundancy.
• Within a chassis, you cannot cluster some security modules and run other security modules in standalone
mode; you must include all security modules in the cluster.
• For decrypted TLS/SSL connections, the decryption states are not synchronized, and if the connection
owner fails, then decrypted connections will be reset. New connections will need to be established to a
new unit. Connections that are not decrypted (they match a do-not-decrypt rule) are not affected and are
replicated correctly.
Defaults
• The cluster health check feature is enabled by default with the holdtime of 3 seconds. Interface health
monitoring is enabled on all interfaces by default.
• The cluster auto-rejoin feature for a failed cluster control link is set to unlimited attempts every 5 minutes.
• The cluster auto-rejoin feature for a failed data interface is set to 3 attempts every 5 minutes, with the
increasing interval set to 2.
• Connection replication delay of 5 seconds is enabled by default for HTTP traffic.
Configure Clustering
You can easily deploy the cluster from the Firepower 4100/9300 chassis supervisor. All initial configuration
is automatically generated for each unit. You can then add the units to the FMC and group them into a cluster.
• For container instances, before you can install a container instance for the first time, you must reinitialize
the security module/engine so that the disk has the correct formatting. Choose Security Modules or
Security Engine, and click the Reinitialize icon ( ). An existing logical device will be deleted and then
reinstalled as a new device, losing any local application configuration. If you are replacing a native
instance with container instances, you will need to delete the native instance in any case. You cannot
automatically migrate a native instance to a container instance.
• Gather the following information:
• Management interface ID, IP addresses, and network mask
• Gateway IP address
• FMC IP address and/or NAT ID of your choosing
• DNS server IP address
• FTD hostname and domain name
Add the same member interfaces on each chassis. The cluster control link is a device-local EtherChannel on each
chassis. Use separate EtherChannels on the switch per device. See Clustering Guidelines and Limitations, on page
748 for more information about EtherChannels for inter-chassis clustering.
For multi-instance clustering, you can create additional Cluster type EtherChannels. Unlike the Management
interface, the cluster control link is not sharable across multiple devices, so you will need a Cluster interface for
each cluster. However, we recommend using VLAN subinterfaces instead of multiple EtherChannels; see the next
step to add a VLAN subinterface to the Cluster interface.
d) For multi-instance clustering, add VLAN subinterfaces to the cluster EtherChannel so you have a subinterface for
each cluster. See Add a VLAN Subinterface for Container Instances, on page 607.
If you add subinterfaces to a Cluster interface, you cannot use that interface for a native cluster.
e) (Optional) Add a Firepower-eventing interface. See Add an EtherChannel (Port Channel), on page 605 or Configure
a Physical Interface, on page 604.
This interface is a secondary management interface for FTD devices. To use this interface, you must configure its
IP address and other parameters at the FTD CLI. For example, you can separate management traffic from events
(such as web events). See the configure network commands in the Firepower Threat Defense command reference.
For inter-chassis clustering, add the same eventing interface on each chassis.
For native mode clustering: All valid interfaces are assigned by default. If you defined multiple Cluster type interfaces,
deselect all but one.
For multi-instance clustering: Choose each data interface you want to assign to the cluster, and also choose the Cluster
type port-channel or port-channel subinterface.
A dialog box appears where you can configure initial bootstrap settings. These settings are meant for initial deployment
only, or for disaster recovery. For normal operation, you can later change most values in the application CLI configuration.
a) (Container Instance for the Firepower 9300 only) In the Security Module (SM) and Resource Profile Selection
area, you can set a different resource profile per module; for example, if you are using different security module
types, and you want to use more CPUs on a lower-end model.
b) For inter-chassis clustering, in the Chassis ID field, enter a chassis ID. Each chassis in the cluster must use a unique
ID.
This field only appears if you added a member interface to cluster control link Port-Channel 48.
c) For inter-site clustering, in the Site ID field, enter the site ID for this chassis between 1 and 8. FlexConfig feature.
Additional inter-site cluster customizations to enhance redundancy and stability, such as director localization, site
redundancy, and cluster flow mobility, are only configurable using the Firepower Management Center FlexConfig
feature.
d) In the Cluster Key field, configure an authentication key for control traffic on the cluster control link.
The shared secret is an ASCII string from 1 to 63 characters. The shared secret is used to generate the key. This
option does not affect datapath traffic, including connection state update and forwarded packets, which are always
sent in the clear.
e) Set the Cluster Group Name, which is the cluster group name in the logical device configuration.
The name must be an ASCII string from 1 to 38 characters.
f) Choose the Management Interface.
This interface is used to manage the logical device. This interface is separate from the chassis management port.
If you assign a Hardware Bypass-capable interface as the Management interface, you see a warning message to
make sure your assignment is intentional.
g) (Optional) Set the CCL Subnet IP as a.b.0.0.
By default, the cluster control link uses the 127.2.0.0/16 network. However, some networking deployments do not
allow 127.2.0.0/16 traffic to pass. In this case, specify any /16 network address on a unique network for the cluster,
except for loopback (127.0.0.0/8) and multicast (224.0.0.0/4) addresses. If you set the value to 0.0.0.0, then the
default network is used.
The chassis auto-generates the cluster control link interface IP address for each unit based on the chassis ID and
slot ID: a.b.chassis_id.slot_id.
a) In the Registration Key field, enter the key to be shared between the Firepower Management Center and the cluster
members during registration.
You can choose any text string for this key between 1 and 37 characters; you will enter the same key on the FMC
when you add the FTD.
b) Enter a Password for the FTD admin user for CLI access.
c) In the Firepower Management Center IP field, enter the IP address of the managing Firepower Management
Center. If you do not know the FMC IP address, leave this field blank and enter a passphrase in the Firepower
Management Center NAT ID field.
d) (Optional) For a container instance, Permit Expert mode from FTD SSH sessions: Yes or No. Expert Mode
provides FTD shell access for advanced troubleshooting.
If you choose Yes for this option, then users who access the container instance directly from an SSH sesssion can
enter Expert Mode. If you choose No, then only users who access the container instance from the FXOS CLI can
enter Expert Mode. We recommend choosing No to increase isolation between instances.
Use Expert Mode only if a documented procedure tells you it is required, or if the Cisco Technical Assistance
Center asks you to use it. To enter this mode, use the expert command in the FTD CLI.
e) (Optional) In the Search Domains field, enter a comma-separated list of search domains for the management
network.
f) (Optional) From the Firewall Mode drop-down list, choose Transparent or Routed.
In routed mode, the FTD is considered to be a router hop in the network. Each interface that you want to route
between is on a different subnet. A transparent firewall, on the other hand, is a Layer 2 firewall that acts like a
“bump in the wire,” or a “stealth firewall,” and is not seen as a router hop to connected devices.
The firewall mode is only set at initial deployment. If you re-apply the bootstrap settings, this setting is not used.
g) (Optional) In the DNS Servers field, enter a comma-separated list of DNS servers.
The FTD uses DNS if you specify a hostname for the FMC, for example.
h) (Optional) In the Firepower Management Center NAT ID field, enter a passphrase that you will also enter on
the FMC when you add the cluster as a new device.
Normally, you need both IP addresses (along with a registration key) for both routing purposes and for authentication:
the FMC specifies the device IP address, and the device specifies the FMC IP address. However, if you only know
one of the IP addresses, which is the minimum requirement for routing purposes, then you must also specify a
unique NAT ID on both sides of the connection to establish trust for the initial communication and to look up the
correct registration key. You can specify any text string as the NAT ID, from 1 to 37 characters. The FMC and
device use the registration key and NAT ID (instead of IP addresses) to authenticate and authorize for initial
registration.
i) (Optional) In the Fully Qualified Hostname field, enter a fully qualified name for the FTD device.
Valid characters are the letters from a to z, the digits from 0 to 9, the dot (.), and the hyphen (-); maximum number
of characters is 253.
j) (Optional) From the Eventing Interface drop-down list, choose the interface on which Firepower events should
be sent. If not specified, the management interface will be used.
To specify a separate interface to use for Firepower events, you must configure an interface as a firepower-eventing
interface. If you assign a Hardware Bypass-capable interface as the Eventing interface, you see a warning message
to make sure your assignment is intentional.
Step 8 On the Interface Information page, configure a management IP address for each security module in the cluster. Select
the type of address from the Address Type drop-down list and then complete the following for each security module.
Note You must set the IP address for all 3 module slots in a chassis, even if you do not have a module installed.
If you do not configure all 3 modules, the cluster will not come up.
Step 12 For inter-chassis clustering, add the next chassis to the cluster:
a) On the first chassis Firepower Chassis Manager, click the Show Configuration icon at the top right; copy the
displayed cluster configuration.
b) Connect to the Firepower Chassis Manager on the next chassis, and add a logical device according to this procedure.
c) Choose I want to: > Join an Existing Cluster.
d) Click OK.
e) In the Copy Cluster Details box, paste in the cluster configuration from the first chassis, and click OK.
f) Click the device icon in the center of the screen. The cluster information is mostly pre-filled, but you must change
the following settings:
• Chassis ID—Enter a unique chassis ID.
• Site ID—For inter-site clustering, enter the site ID for this chassis between 1 and 8. Additional inter-site cluster
customizations to enhance redundancy and stability, such as director localization, site redundancy, and cluster
flow mobility, are only configurable using the Firepower Management Center FlexConfig feature.
• Cluster Key—(Not prefilled) Enter the same cluster key.
• Management IP—Change the management address for each module to be a unique IP address on the same
network as the other cluster members.
Click OK.
g) Click Save.
The chassis deploys the logical device by downloading the specified software version and pushing the bootstrap
configuration and management interface settings to the application instance. Check the Logical Devices page for
each cluster member for the status of the new logical device. When the logical device for each cluster member
shows its Status as online, you can start configuring the cluster in the application. You may see the "Security
module not responding" status as part of the process; this status is normal and is temporary.
Step 13 Add the control unit to the Firepower Management Center using the management IP address.
All cluster units must be in a successfully-formed cluster on FXOS prior to adding them to Firepower Management
Center.
The Firepower Management Center then automatically detects the data units.
Note The FXOS steps in this procedure only apply to adding a new chassis; if you are adding a new module to a
Firepower 9300 where clustering is already enabled, the module will be added automatically. However, you
must still add the new module to the Firepower Management Center; skip to the Firepower Management
Center steps.
Step 1 On an existing cluster chassis Firepower Chassis Manager, choose Logical Devices to open the Logical Devices page.
Step 2 Click the Show Configuration icon at the top right; copy the displayed cluster configuration.
Step 3 Connect to the Firepower Chassis Manager on the new chassis, and click Add > Cluster.
Step 4 For the Device Name, provide a name for the logical device.
Step 5 Click OK.
Step 6 In the Copy Cluster Details box, paste in the cluster configuration from the first chassis, and click OK.
Step 7 Click the device icon in the center of the screen. The cluster information is mostly pre-filled, but you must change the
following settings:
• Chassis ID—Enter a unique chassis ID.
• Site ID—For inter-site clustering, enter the site ID for this chassis between 1 and 8. This feature is only configurable
using the Firepower Management Center FlexConfig feature.
• Cluster Key—(Not prefilled) Enter the same cluster key.
• Management IP—Change the management address for each module to be a unique IP address on the same network
as the other cluster members.
Click OK.
• All cluster units must be in a successfully-formed cluster on FXOS prior to adding the cluster to the
Management Center. You should also check which unit is the control unit. Refer to the Firepower Chassis
Manager Logical Devices screen or use the Firepower Threat Defense show cluster info command.
Step 1 In the FMC, choose Devices > Device Management, and then choose Add > Add Device to add the control unit using
the unit's management IP address you assigned when you deployed the cluster.
a) In the Host field, enter the IP address or hostname of the control unit.
We recommend adding the control unit for the best performance, but you can add any unit of the cluster.
If you used a NAT ID during device setup, you may not need to enter this field. For more information, see NAT
Environments, on page 254.
b) In the Display Name field, enter a name for the control unit as you want it to display in the FMC.
This display name is not for the cluster; it is only for the control unit you are adding. You can later change the name
of other cluster members and the cluster display name.
c) In the Registration Key field, enter the same registration key that you used when you deployed the cluster in FXOS.
The registration key is a one-time-use shared secret.
d) In a multidomain deployment, regardless of your current domain, assign the device to a leaf Domain.
If your current domain is a leaf domain, the device is automatically added to the current domain. If your current
domain is not a leaf domain, post-registration, you must switch to the leaf domain to configure the device.
e) (Optional) Add the device to a device Group.
f) Choose an initial Access Control Policy to deploy to the device upon registration, or create a new policy.
If you create a new policy, you create a basic policy only. You can later customize the policy as needed.
You can monitor cluster unit registration by clicking the Notifications icon and choosing Tasks. The FMC updates
the Cluster Registration task as each unit registers. If any units fail to register, see Reconcile Cluster Members, on
page 773.
Step 2 Configure device-specific settings by clicking the Edit ( ) for the cluster.
Most configuration can be applied to the cluster as a whole, and not member units in the cluster. For example, you can
change the display name per unit, but you can only configure interfaces for the whole cluster.
Step 3 On the Devices > Device Management > Cluster screen, you see General, License, System, and Health settings.
• General > Name—Change the cluster display name by clicking the Edit ( ).
• General > View cluster status—Click the View cluster status link to open the Cluster Status dialog box.
The Cluster Status dialog box also lets you retry data unit registration by clicking Reconcile.
Step 4 On the Devices > Device Management > Devices, you can choose each member in the cluster from the top right drop-down
menu and configure the following settings.
• General > Name—Change the cluster member display name by clicking the Edit ( ).
• Management > Host—If you change the management IP address in the device configuration, you must match the
new address in the FMC so that it can reach the device on the network; edit the Host address in the Management
area.
Note When using Spanned EtherChannels for inter-chassis clustering, the port-channel interface will not come up
until clustering is fully enabled. This requirement prevents traffic from being forwarded to a unit that is not
an active unit in the cluster.
Step 1 Choose Devices > Device Management, and click Edit ( ) next to the cluster.
Step 2 Click Interfaces.
Step 3 Configure the cluster control link.
For inter-chassis clustering, set the cluster control link MTU to be at least 100 bytes higher than the highest MTU of the
data interfaces. Because the cluster control link traffic includes data packet forwarding, the cluster control link needs to
accommodate the entire size of a data packet plus cluster traffic overhead. We suggest setting the MTU to the maximum
of 9184; the minimum value is 1400 bytes. For example, because the maximum MTU is 9184, then the highest data
interface MTU can be 9084, while the cluster control link can be set to 9184.
For native clusters: The cluster control link interface is Port-Channel48 by default.
d) For inter-chassis clusters, set a manual global MAC address for the EtherChannel. Click Advanced, and in the Active
Mac Address field, enter a MAC address in H.H.H format, where H is a 16-bit hexadecimal digit.
For example, the MAC address 00-0C-F1-42-4C-DE would be entered as 000C.F142.4CDE. The MAC address must
not have the multicast bit set, that is, the second hexadecimal digit from the left cannot be an odd number.
Do not set the Standby Mac Address; it is ignored.
You must configure a MAC address for a Spanned EtherChannel to avoid potential network connectivity problems.
With a manually-configured MAC address, the MAC address stays with the current control unit. If you do not configure
a MAC address, then if the control unit changes, the new control unit uses a new MAC address for the interface,
which can cause a temporary network outage.
e) Click OK. Repeat the above steps for other data interfaces.
Step 5 (Optional) Configure the Diagnostic interface.
The Diagnostic interface is the only interface that can run in Individual interface mode. You can use this interface for
syslog messages or SNMP, for example.
a) Choose Objects > Object Management > Address Pools to add an IPv4 and/or IPv6 address pool. See Address
Pools, on page 531.
Include at least as many addresses as there are units in the cluster. The Virtual IP address is not a part of this pool,
but needs to be on the same network. You cannot determine the exact Local address assigned to each unit in advance.
b) On Devices > Device Management > Interfaces, click Edit ( ) for the Diagnostic interface.
c) On the IPv4, enter the IP Address and mask. This IP address is a fixed address for the cluster, and always belongs
to the current control unit.
d) From the IPv4 Address Pool drop-down list, choose the address pool you created.
e) On IPv6 > Basic, from the IPv6 Address Pool drop-down list, choose the address pool you created.
f) Configure other interface settings as normal.
Step 6 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Temporary Removal
A cluster unit will be automatically removed from the cluster due to a hardware or network failure, for example.
This removal is temporary until the conditions are rectified, and it can rejoin the cluster. You can also manually
disable clustering.
To check whether a device is currently in the cluster, check the cluster status on the Firepower Chassis Manager
Logical Devices page:
For FTD using FMC, you should leave the device in the FMC device list so that it can resume full functionality
after you reenable clustering.
• Disable clustering in the application—You can disable clustering using the application CLI. Enter the
cluster remove unit name command to remove any unit other than the one you are logged into. The
bootstrap configuration remains intact, as well as the last configuration synced from the control unit, so
you can later re-add the unit without losing your configuration. If you enter this command on a data unit
to remove the control unit, a new control unit is elected.
When a device becomes inactive, all data interfaces are shut down; only the Management interface can
send and receive traffic. To resume traffic flow, re-enable clustering. The Management interface remains
up using the IP address the unit received from the bootstrap configuration. However if you reload, and
the unit is still inactive in the cluster , the Management interface is disabled.
To reenable clustering, on the FTD enter cluster enable.
• Disable the application instance—In Firepower Chassis Manager on the Logical Devices page, click the
Slider enabled ( ). You can later reenable it using the Slider disabled ( ).
• Shut down the security module/engine—In Firepower Chassis Manager on the Security Module/Engine
page, click the Power Off icon.
• Shut down the chassis—In Firepower Chassis Manager on the Overview page, click the Shut Down
icon.
Permanent Removal
You can permanently remove a cluster member using the following methods.
For FTD using FMC, be sure to remove the unit from the FMC device list after you disable clustering on the
chassis.
• Delete the logical device—In Firepower Chassis Manager on the Logical Devices page, click the Delete
( ). You can then deploy a standalone logical device, a new cluster, or even add a new logical device
to the same cluster.
• Remove the chassis or security module from service—If you remove a device from service, you can add
replacement hardware as a new member of the cluster.
Step 1 Add the new unit to the cluster in FXOS. See the FXOS configuration guide.
Wait for the new unit to be added to the cluster. Refer to the Firepower Chassis Manager Logical Devices screen or use
the Firepower Threat Defense show cluster info command to view cluster status.
Step 2 The new cluster member is added automatically. To monitor the registration of the replacement unit, view the following:
• Cluster Status dialog box (Devices > Device Management > Cluster > General area > Current Cluster Summary
link)—A unit that is joining the cluster on the chassis shows "Joining cluster..." After it joins the cluster, the FMC
attempts to register it, and the status changes to "Available for Registration". After it completes registration, the
status changes to "In Sync." If the registration fails, the unit will stay at "Available for Registration". In this case,
force a re-registration by clicking Reconcile.
• System status > Tasks —The FMC shows all registration events and failures.
• Devices > Device Management—When you expand the cluster on the devices listing page, you can see when a unit
is registering when it has the loading icon to the left.
Step 1 For a new chassis, if possible, backup and restore the configuration from the old chassis in FXOS.
If you are replacing a module in a Firepower 9300, you do not need to perform these steps.
If you do not have a backup FXOS configuration from the old chassis, first perform the steps in Add a New Cluster
Member, on page 771.
For information about all of the below steps, see the FXOS configuration guide.
a) Use the configuration export feature to export an XML file containing logical device and platform configuration
settings for your Firepower 4100/9300 chassis.
b) Import the configuration file to the replacement chassis.
c) Accept the license agreement.
d) If necessary, upgrade the logical device application instance version to match the rest of the cluster.
Step 2 In the Firepower Management Center, choose , and click Delete ( ) next to the old unit.
Step 3 Confirm that you want to delete the unit.
The unit is removed from the cluster and from the FMC devices list.
Step 4 The new or reinitialized cluster member is added automatically. To monitor the registration of the replacement unit, view
the following:
• Cluster Status dialog box (Devices > Device Management > Cluster > Devices > Device ManagementGeneral
area > Current Cluster Summary link)—A unit that is joining the cluster on the chassis shows "Joining cluster..."
After it joins the cluster, the FMC attempts to register it, and the status changes to "Available for Registration". After
it completes registration, the status changes to "In Sync." If the registration fails, the unit will stay at "Available for
Registration". In this case, force a re-registration by clicking Reconcile.
• System status > Tasks—The FMC shows all registration events and failures.
• Devices > Device Management—When you expand the cluster on the devices listing page, you can see when a unit
is registering when it has the loading icon to the left.
Step 1 Make sure the unit is ready to be deleted from the FMC.
a) Choose Devices > Device Management, and click Edit ( ) for the cluster.
b) On the Devices > Device Management > Cluster > General area, click the Current Cluster Summary link to
open the Cluster Status dialog box.
c) Ensure that the devices you want to delete are in the "Available for Deletion" state.
If the status is stale, click Reconcile to force an update.
Step 2 In the FMC, choose Devices > Device Management, and click Delete ( ) next to the data unit.
Step 3 Confirm that you want to delete the unit.
The unit is removed from the cluster and from the FMC devices list.
Step 1 Choose Devices > Device Management, and click Edit ( ) for the cluster.
Step 2 On the Cluster > General area, click the Current Cluster Summary link to open the Cluster Status dialog box.
Step 3 Click Reconcile.
For more information about the cluster status, see FMC: Monitoring the Cluster, on page 775.
Deactivate a Member
To deactivate a member other than the unit you are logged into, perform the following steps at the FTD CLI.
This procedure is meant to temporarily deactivate a member, and you should keep the unit in the FMC device
list.
Note When a unit becomes inactive, all data interfaces are shut down; only the Management interface can send and
receive traffic. To resume traffic flow, reenable clustering. The Management interface remains up using the
IP address the unit received from the bootstrap configuration. However if you reload, and the unit is still
inactive in the cluster, the management interface is disabled. You must use the console for any further
configuration.
Step 1 Access the CLI of the unit that needs to rejoin the cluster, either from the console port or using SSH to the Management
interface. Log in with the username admin and the password you set during initial setup.
Step 2 Enable clustering:
cluster enable
Note To view FlexConfig features that are also not supported with clustering, for example WCCP inspection, see
the ASA general operations configuration guide. FlexConfig lets you configure many ASA features that are
not present in the FMC GUI. See FlexConfig Policies for Firepower Threat Defense, on page 1033.
Note Traffic for centralized features is forwarded from member units to the control unit over the cluster control
link.
If you use the rebalancing feature, traffic for centralized features may be rebalanced to non-control units before
the traffic is classified as a centralized feature; if this occurs, the traffic is then sent back to the control unit.
For centralized features, if the control unit fails, all connections are dropped, and you have to re-establish the
connections on the new control unit.
• TFTP
• XDMCP
• Dynamic routing
• Static route monitoring
After the data units learn the routes from the control unit, each unit makes forwarding decisions independently.
The OSPF LSA database is not synchronized from the control unit to data units. If there is a control unit
switchover, the neighboring router will detect a restart; the switchover is not transparent. The OSPF process
picks an IP address as its router ID. Although not required, you can assign a static router ID to ensure a
consistent router ID is used across the cluster. See the OSPF Non-Stop Forwarding feature to address the
interruption.
Connection Settings
Connection limits are enforced cluster-wide. Each unit has an estimate of the cluster-wide counter values
based on broadcast messages. Due to efficiency considerations, the configured connection limit across the
cluster might not be enforced exactly at the limit number. Each unit may overestimate or underestimate the
cluster-wide counter value at any given time. However, the information will get updated over time in a
load-balanced cluster.
• NAT pool address distribution for dynamic PAT—The control unit evenly pre-distributes addresses
across the cluster. If a member receives a connection and they have no addresses assigned, then the
connection is forwarded to the control unit for PAT. If a cluster member leaves the cluster (due to failure),
a backup member will get the PAT IP address, and if the backup exhausts its normal PAT IP address, it
can make use of the new address. Make sure to include at least as many NAT addresses as there are units
in the cluster, plus at least one extra address, to ensure that each unit receives an address, and that a failed
unit can get a new address if its old address is in use by the member that took over the address. Use the
show nat pool cluster command in the device CLI to see the address allocations.
• Reusing a PAT pool in multiple rules—To use the same PAT pool in multiple rules, you must be careful
about the interface selection in the rules. You must either use specific interfaces in all rules, or "any" in
all rules. You cannot mix specific interfaces and "any" across the rules, or the system might not be able
to match return traffic to the right node in the cluster. Using unique PAT pools per rule is the most reliable
option.
VPN functionality is limited to the control unit and does not take advantage of the cluster high availability
capabilities. If the control unit fails, all existing VPN connections are lost, and VPN users will see a disruption
in service. When a new control unit is elected, you must reestablish the VPN connections.
When you connect a VPN tunnel to a Spanned interface address, connections are automatically forwarded to
the control unit.
VPN-related keys and certificates are replicated to all units.
For example, for TCP throughput, the Firepower 9300 with 3 SM-44 modules can handle approximately 135
Gbps of real world firewall traffic when running alone. For 2 chassis, the maximum combined throughput
will be approximately 80% of 270 Gbps (2 chassis x 135 Gbps): 216 Gbps.
Note You can manually force a unit to become the control unit. For centralized features, if you force a control unit
change, then all connections are dropped, and you have to re-establish the connections on the new control
unit.
Chassis-Application Monitoring
Chassis-application health monitoring is always enabled. The Firepower 4100/9300 chassis supervisor checks
the Firepower Threat Defense application periodically (every second). If the Firepower Threat Defense device
is up and cannot communicate with the Firepower 4100/9300 chassis supervisor for 3 seconds, the Firepower
Threat Defense device generates a syslog message and leaves the cluster.
If the Firepower 4100/9300 chassis supervisor cannot communicate with the application after 45 seconds, it
reloads the Firepower Threat Defense device. If the Firepower Threat Defense device cannot communicate
with the supervisor, it removes itself from the cluster.
Interface Monitoring
Each unit monitors the link status of all hardware interfaces in use, and reports status changes to the control
unit. For inter-chassis clustering, Spanned EtherChannels use the cluster Link Aggregation Control Protocol
(cLACP). Each chassis monitors the link status and the cLACP protocol messages to determine if the port is
still active in the EtherChannel, and informs the Firepower Threat Defense application if the interface is down.
All physical interfaces are monitored by default (including the main EtherChannel for EtherChannel interfaces).
Only named interfaces that are in an Up state can be monitored. For example, all member ports of an
EtherChannel must fail before a named EtherChannel is removed from the cluster.
If a monitored interface fails on a particular unit, but it is active on other units, then the unit is removed from
the cluster. The amount of time before the Firepower Threat Defense device removes a member from the
cluster depends on whether the unit is an established member or is joining the cluster. The Firepower Threat
Defense device does not monitor interfaces for the first 90 seconds that a unit joins the cluster. Interface status
changes during this time will not cause the Firepower Threat Defense device to be removed from the cluster.
For an established member, the unit is removed after 500 ms.
For inter-chassis clustering, if you add or delete an EtherChannel from the cluster, interface health-monitoring
is suspended for 95 seconds to ensure that you have time to make the changes on each chassis.
Note When the FTD becomes inactive and fails to automatically rejoin the cluster, all data interfaces are shut down;
only the Management/Diagnostic interface can send and receive traffic.
SNMP Engine ID No —
Connection Roles
See the following roles defined for each connection:
• Owner—Usually, the unit that initially receives the connection. The owner maintains the TCP state and
processes packets. A connection has only one owner. If the original owner fails, then when new units
receive packets from the connection, the director chooses a new owner from those units.
• Backup owner—The unit that stores TCP/UDP state information received from the owner, so that the
connection can be seamlessly transferred to a new owner in case of a failure. The backup owner does
not take over the connection in the event of a failure. If the owner becomes unavailable, then the first
unit to receive packets from the connection (based on load balancing) contacts the backup owner for the
relevant state information so it can become the new owner.
As long as the director (see below) is not the same unit as the owner, then the director is also the backup
owner. If the owner chooses itself as the director, then a separate backup owner is chosen.
For inter-chassis clustering on the Firepower 9300, which can include up to 3 cluster units in one chassis,
if the backup owner is on the same chassis as the owner, then an additional backup owner will be chosen
from another chassis to protect flows from a chassis failure.
• Director—The unit that handles owner lookup requests from forwarders. When the owner receives a new
connection, it chooses a director based on a hash of the source/destination IP address and ports, and sends
a message to the director to register the new connection. If packets arrive at any unit other than the owner,
the unit queries the director about which unit is the owner so it can forward the packets. A connection
has only one director. If a director fails, the owner chooses a new director.
As long as the director is not the same unit as the owner, then the director is also the backup owner (see
above). If the owner chooses itself as the director, then a separate backup owner is chosen.
• Forwarder—A unit that forwards packets to the owner. If a forwarder receives a packet for a connection
it does not own, it queries the director for the owner, and then establishes a flow to the owner for any
other packets it receives for this connection. The director can also be a forwarder. Note that if a forwarder
receives the SYN-ACK packet, it can derive the owner directly from a SYN cookie in the packet, so it
does not need to query the director. (If you disable TCP sequence randomization, the SYN cookie is not
used; a query to the director is required.) For short-lived flows such as DNS and ICMP, instead of
querying, the forwarder immediately sends the packet to the director, which then sends them to the owner.
A connection can have multiple forwarders; the most efficient throughput is achieved by a good
load-balancing method where there are no forwarders and all packets of a connection are received by
the owner.
• Fragment Owner—For fragmented packets, cluster units that receive a fragment determine a fragment
owner using a hash of the fragment source and destination IP addresses. All fragments are then forwarded
to the fragment owner over the cluster control link. Fragments may be load-balanced to different cluster
units, because only the first fragment includes the 5-tuple used in the switch load balance hash. Other
fragments do not contain the source and destination ports and may be load-balanced to other cluster units.
The fragment owner temporarily reassembles the packet so it can determine the director based on a hash
of the source/destination IP address and ports. If it is a new connection, the fragment owner will register
to be the connection owner. If it is an existing connection, the fragment owner forwards all fragments to
the provided connection owner over the cluster control link. The connection owner will then reassemble
all fragments.
1. The SYN packet originates from the client and is delivered to one FTD (based on the load balancing
method), which becomes the owner. The owner creates a flow, encodes owner information into a SYN
cookie, and forwards the packet to the server.
2. The SYN-ACK packet originates from the server and is delivered to a different FTD (based on the load
balancing method). This FTD is the forwarder.
3. Because the forwarder does not own the connection, it decodes owner information from the SYN cookie,
creates a forwarding flow to the owner, and forwards the SYN-ACK to the owner.
4. The owner sends a state update to the director, and forwards the SYN-ACK to the client.
5. The director receives the state update from the owner, creates a flow to the owner, and records the TCP
state information as well as the owner. The director acts as the backup owner for the connection.
6. Any subsequent packets delivered to the forwarder will be forwarded to the owner.
7. If packets are delivered to any additional units, it will query the director for the owner and establish a
flow.
8. Any state change for the flow results in a state update from the owner to the director.
Multi-instance clustering 6.6 You can now create a cluster using container instances. On the
Firepower 9300, you must include one container instance on each
module in the cluster. You cannot add more than one container instance
to the cluster per security engine/module. We recommend that you use
the same security module or chassis model for each cluster instance.
However, you can mix and match container instances on different
Firepower 9300 security module types or Firepower 4100 models in
the same cluster if required. You cannot mix Firepower 9300 and 4100
instances in the same cluster.
New/Modified FXOS commands: set port-type cluster
New/modified Firepower Chassis Manager screens:
• Logical Devices > Add Cluster
• Interfaces > All Interfaces > Add New drop-down menu >
Subinterface > Type field
Configuration sync to data units in 6.6 The control unit now syncs configuration changes with data units in
parallel parallel by default. Formerly, synching occurred sequentially.
New/Modified screens: none.
Messages for cluster join failure or 6.6 New messages were added to the show cluster history command for
eviction added to show cluster history when a cluster unit either fails to join the cluster or leaves the cluster.
New/Modified commands: show cluster history
New/Modified screens: none.
Initiator and responder information for 6.5 If you enable Dead Connection Detection (DCD), you can use the show
Dead Connection Detection (DCD), and conn detail command to get information about the initiator and
DCD support in a cluster. responder. Dead Connection Detection allows you to maintain an
inactive connection, and the show conn output tells you how often the
endpoints have been probed. In addition, DCD is now supported in a
cluster.
New/Modified commands: show conn (output only).
Supported platforms: Firepower Threat Defense on the Firepower
4100/9300
Improved Firepower Threat Defense 6.3 You can now add any unit of a cluster to the Firepower Management
cluster addition to the Firepower Center, and the other cluster units are detected automatically. Formerly,
Management Center you had to add each cluster unit as a separate device, and then group
them into a cluster in the Management Center. Adding a cluster unit
is also now automatic. Note that you must delete a unit manually.
New/Modified screens:
Devices > Device Management > Add drop-down menu > Device >
Add Device dialog box
Devices > Device Management > Cluster tab > General area >
Cluster Registration Status > Current Cluster Summary link >
Cluster Status dialog box
Supported platforms: Firepower Threat Defense on the Firepower
4100/9300
Support for Site-to-Site VPN with 6.2.3.3 You can now configure site-to-site VPN with clustering. Site-to-site
clustering as a centralized feature VPN is a centralized feature; only the control unit supports VPN
connections.
Supported platforms: Firepower Threat Defense on the Firepower
4100/9300
Automatically rejoin the cluster after an 6.2.3 Formerly, many internal error conditions caused a cluster unit to be
internal failure removed from the cluster, and you were required to manually rejoin
the cluster after resolving the issue. Now, a unit will attempt to rejoin
the cluster automatically at the following intervals: 5 minutes, 10
minutes, and then 20 minutes. Internal failures include: application
sync timeout; inconsistent application statuses; and so on.
New/Modified command: show cluster info auto-join
No modified screens.
Supported platforms: Firepower Threat Defense on the Firepower
4100/9300
Inter-chassis clustering for 6 modules; 6.2 With FXOS 2.1.1, you can now enable inter-chassis clustering on the
Firepower 4100 support Firepower 9300 and 4100. For the Firepower 9300, you can include
up to 6 modules. For example, you can use 1 module in 6 chassis, or
2 modules in 3 chassis, or any combination that provides a maximum
of 6 modules. For the Firepower 4100, you can include up to 6 chassis.
Note Inter-site clustering is also supported. However,
customizations to enhance redundancy and stability, such
as site-specific MAC and IP addresses, director localization,
site redundancy, and cluster flow mobility, are only
configurable using the FlexConfig feature.
No modified screens.
Supported platforms: Firepower Threat Defense on the Firepower
4100/9300
Intra-chassis Clustering for the 6.0.1 You can cluster up to 3 security modules within the Firepower 9300
Firepower 9300 chassis. All modules in the chassis must belong to the cluster.
New/Modified screens:
Devices > Device Management > Add > Add Cluster
Devices > Device Management > Cluster
Supported platforms: Firepower Threat Defense on the Firepower 9300
Path Determination
Routing protocols use metrics to evaluate what path will be the best for a packet to travel. A metric is a standard
of measurement, such as path bandwidth, that is used by routing algorithms to determine the optimal path to
a destination. To aid the process of path determination, routing algorithms initialize and maintain routing
tables, which include route information. Route information varies depending on the routing algorithm used.
Routing algorithms fill routing tables with a variety of information. Destination or next hop associations tell
a router that a particular destination can be reached optimally by sending the packet to a particular router
representing the next hop on the way to the final destination. When a router receives an incoming packet, it
checks the destination address and attempts to associate this address with a next hop.
Routing tables also can include other information, such as data about the desirability of a path. Routers compare
metrics to determine optimal routes, and these metrics differ depending on the design of the routing algorithm
used.
Routers communicate with one another and maintain their routing tables through the transmission of a variety
of messages. The routing update message is one such message that generally consists of all or a portion of a
routing table. By analyzing routing updates from all other routers, a router can build a detailed picture of
network topology. A link-state advertisement, another example of a message sent between routers, informs
other routers of the state of the sender links. Link information also can be used to build a complete picture of
network topology to enable routers to determine optimal routes to network destinations.
The primary advantage of hierarchical routing is that it mimics the organization of most companies and
therefore supports their traffic patterns well. Most network communication occurs within small company
groups (domains). Because intradomain routers need to know only about other routers within their domain,
their routing algorithms can be simplified, and, depending on the routing algorithm being used, routing update
traffic can be reduced accordingly.
Routing Table
The FTD uses separate routing tables for data traffic (through-the-device) and for management traffic
(from-the-device). This section decribes how the routing tables work. For information about the management
routing table, see also Routing Table for Management Traffic, on page 797.
Even though OSPF routes have the better administrative distance, both routes are installed in the routing
table because each of these routes has a different prefix length (subnet mask). They are considered
different destinations and the packet forwarding logic determines which route to use.
• If the FTD learns about multiple paths to the same destination from a single routing protocol, such as
RIP, the route with the better metric (as determined by the routing protocol) is entered into the routing
table.
Metrics are values associated with specific routes, ranking them from most preferred to least preferred.
The parameters used to determine the metrics differ for different routing protocols. The path with the
lowest metric is selected as the optimal path and installed in the routing table. If there are multiple paths
to the same destination with equal metrics, load balancing is done on these equal cost paths.
• If the FTD learns about a destination from more than one routing protocol, the administrative distances
of the routes are compared, and the routes with lower administrative distance are entered into the routing
table.
is not always possible to determine the best path for two routes to the same destination that were generated
by different routing protocols.
Each routing protocol is prioritized using an administrative distance value. The following table shows the
default administrative distance values for the routing protocols supported by the Firepower Threat Defense
device.
Connected interface 0
Static route 1
External BGP 20
Internal EIGRP 90
OSPF 110
IS-IS 115
RIP 120
Unknown 255
The smaller the administrative distance value, the more preference is given to the protocol. For example, if
the Firepower Threat Defense device receives a route to a certain network from both an OSPF routing process
(default administrative distance - 110) and a RIP routing process (default administrative distance - 120), the
Firepower Threat Defense device chooses the OSPF route because OSPF has a higher preference. In this case,
the router adds the OSPF version of the route to the routing table.
In this example, if the source of the OSPF-derived route was lost (for example, due to a power shutdown),
the Firepower Threat Defense device would then use the RIP-derived route until the OSPF-derived route
reappears.
The administrative distance is a local setting. For example, if you change the administrative distance of routes
obtained through OSPF, that change would only affect the routing table for the Firepower Threat Defense
device on which the command was entered. The administrative distance is not advertised in routing updates.
Administrative distance does not affect the routing process. The routing processes only advertise the routes
that have been discovered by the routing process or redistributed into the routing process. For example, the
RIP routing process advertises RIP routes, even if routes discovered by the OSPF routing process are used in
the routing table.
maintenance process calls each routing protocol process that has registered a backup route and requests them
to reinstall the route in the routing table. If there are multiple protocols with registered backup routes for the
failed route, the preferred route is chosen based on administrative distance.
Because of this process, you can create floating static routes that are installed in the routing table when the
route discovered by a dynamic routing protocol fails. A floating static route is simply a static route configured
with a greater administrative distance than the dynamic routing protocols running on the Firepower Threat
Defense device. When the corresponding route discovered by a dynamic routing process fails, the static route
is installed in the routing table.
For example, a packet destined for 192.168.32.1 arrives on an interface with the following routes in the routing
table:
• 192.168.32.0/24 gateway 10.1.1.2
• 192.168.32.0/19 gateway 10.1.1.3
In this case, a packet destined to 192.168.32.1 is directed toward 10.1.1.2, because 192.168.32.1 falls within
the 192.168.32.0/24 network. It also falls within the other route in the routing table, but 192.168.32.0/24 has
the longest prefix within the routing table (24 bits verses 19 bits). Longer prefixes are always preferred over
shorter ones when forwarding a packet.
Note Existing connections continue to use their established interfaces even if a new similar connection would result
in different behavior due to a change in routes.
After the data unit learn the routes from the control unit, each unit makes forwarding decisions independently.
The OSPF LSA database is not synchronized from the control unit to data units. If there is a control unit
switchover, the neighboring router will detect a restart; the switchover is not transparent. The OSPF process
picks an IP address as its router ID. Although not required, you can assign a static router ID to ensure a
consistent router ID is used across the cluster. See the OSPF Non-Stop Forwarding feature to address the
interruption.
If you need from-the-box traffic to go out an interface that isn't in its default routing table, then you might
need to specify that interface when you configure it, rather than relying on the fall back to the other table. The
FTD checks the correct routing table for routes for that interface. For example, if you need a ping to go out
a management-only interface, then specify the interface in the ping function. Otherwise, if there is a default
route in the data routing table, then it will match the default route and never fall back to the management
routing table.
The management routing table supports dynamic routing separate from the data interface routing table. A
given dynamic routing process must run on either the management-only interface or the data interface; you
cannot mix both types.
Management-only interfaces include any Diagnostic x/x interfaces as well as any interfaces that you have
configured to be management-only.
Note This routing table does not affect the special FTD Management logical interface that it uses to communicate
with the FMC; that interface has its own routing table. The Diagnostic logical interface, on the other hand,
uses the management-only routing table described in this section.
In this case, traffic is load-balanced on the outside interface between 10.1.1.2, 10.1.1.3, and 10.1.1.4. Traffic
is distributed among the specified gateways based on an algorithm that hashes the source and destination IP
addresses, incoming interface, protocol, source and destination ports.
Note Use FlexConfig to configure traffic zones with the zone and zone-member commands.
If you configure traffic zones to contain a group of interfaces, you can have up to 8 equal cost static or dynamic
routes across up to 8 interfaces within each zone. For example, you can configure multiple default routes
across three interfaces in the zone:
Similarly, your dynamic routing protocol can automatically configure equal cost routes. The Firepower Threat
Defense device load-balances traffic across the interfaces with a more robust load balancing mechanism.
When a route is lost, the device seamlessly moves the flow to a different route.
These are some of the differences between route maps and ACLs:
• Route maps are more flexible than ACLs and can verify routes based on criteria which ACLs can not
verify. For example, a route map can verify if the type of route is internal.
• Each ACL ends with an implicit deny statement, by design convention. If the end of a route map is
reached during matching attempts, the result depends on the specific application of the route map. Route
maps that are applied to redistribution behave the same way as ACLs: if the route does not match any
clause in a route map then the route redistribution is denied, as if the route map contained a deny statement
at the end.
For each route that is being redistributed, the router first evaluates the match criteria of a clause in the route
map. If the match criteria succeeds, then the route is redistributed or rejected as dictated by the permit or deny
clause, and some of its attributes might be modified by the values set from the set commands. If the match
criteria fail, then this clause is not applicable to the route, and the software proceeds to evaluate the route
against the next clause in the route map. Scanning of the route map continues until a clause is found that
matches the route or until the end of the route map is reached.
A match or set value in each clause can be missed or repeated several times, if one of these conditions exists:
• If several match entries are present in a clause, all must succeed for a given route in order for that route
to match the clause (in other words, the logical AND algorithm is applied for multiple match commands).
• If a match entry refers to several objects in one entry, either of them should match (the logical OR
algorithm is applied).
• If a match entry is not present, all routes match the clause.
• If a set entry is not present in a route map permit clause, then the route is redistributed without modification
of its current attributes.
Note Do not configure a set entry in a route map deny clause because the deny clause prohibits route
redistribution—there is no information to modify.
A route map clause without a match or set entry does perform an action. An empty permit clause allows a
redistribution of the remaining routes without modification. An empty deny clause does not allow a
redistribution of other routes (this is the default action if a route map is completely scanned, but no explicit
match is found).
Note that there are separate management and data routing tables per virtual router. For example, if you assign
a management-only interface to a virtual router, then the routing table for that interface is separate from the
data interfaces assigned to the virtual router.
EIGRP, ISIS, and PBR are supported through Flex Config in FMC (see Predefined FlexConfig Objects, on
page 1044). Configure only global virtual router interfaces for these features.
DHCP server auto-configuration uses WINS/DNS server that is learned from an interface. This interface can
only be a global virtual router interface.
You can configure the following features separately for each user-defined virtual router:
• Static routes and their SLA monitors
• OSPFv2
• BGPv4
• Integrated Routing and Bridging (IRB)
Following features are used by the system when querying or communicating with the remote system
(from-the-box traffic). These features use interfaces in the global virtual router only. That means, if you
configure an interface for the feature, it must belong to the global virtual router. As a rule, anytime, if the
system must look up a route to reach an external server for its own management purposes, it does the route
lookup in the global virtual router.
• DNS server when used to resolve fully qualified names used in access control rules, or for resolving
names for the ping command. If you specify any as the interface for a DNS server, the system considers
interfaces in the global virtual router only.
• AAA server or identity realm when used with VPN. You can configure VPN on interfaces in the global
virtual router only. Thus, the external AAA servers that are used for VPN, such as Active Directory,
must be reachable through an interface in the global virtual router.
• Syslog server.
• SNMP.
If you use overlapping address spaces in your virtual routers, you should use security zones to ensure that the
right policies get applied. For example, if you use the 192.168.1.0/24 address space in two separate virtual
routers, an access control rule that simply specifies the 192.168.1.0/24 network will apply to traffic in both
virtual routers. If that is not the desired outcome, you can limit the application of the rule by also specifying
the source/destination security zones for just one of the virtual routers.
Overlapping IP Addresses
Virtual router creates multiple instances of routing tables that are independent, thereby, the same or overlapping
IP addresses can be used without conflicts. FTD allows the same network to be part of two or more virtual
routers. This involves multiple policies to be applied at the interface or at the virtual router level.
Other than few exceptions, the routing functions and most of the NGFW and IPS capability does not get
impacted by the overlapping IP addresses. The following section describes the features that have limitations
with overlapping IP addresses and the suggestions or recommendations to overcome them.
For the following features, you need to apply rules on specific interfaces to ensure that different policies are
applied on overlapping IP segments:
• Access Policy
• Prefilter Policy
• QoS/Rate Limit
• SSL Policy
ASA 5508-X 10
ASA 5516-X 10
ASA 5525-X 10
ASA 5545-X 20
ASA 5555-X 20
Firepower 1120 5
Firepower 1140 10
Firepower 1150 10
Firepower 2110 10
Firepower 2120 20
Firepower 2130 30
Firepower 2140 40
Firepower 4110 60
Firepower 4112 60
Firepower 4115 80
Firepower 4120 80
Related Topics
Requirements and Prerequisites for Container Instances, on page 599
Supported Domains
Any
User Roles
Admin
Network Admin
Security Approver
Device Guidelines
• Virtual routers are supported only on routed Firepower Threat Defense devices of version 6.6 and higher.
Though Firepower Management Center release 6.6 supports FTD versions earlier than 6.6, you cannot
enable virtual routers on such devices.
• Snort3 enabled devices do not support virtual router features. So, before proceeding to switch a Snort2
device that is enabled with a user-defined virtual router to a Snort3 engine, remove the device from the
virtual router.
Interface Guidelines
• You can assign an interface to only one virtual router.
• A virtual router can have any number of interfaces that are assigned to it.
• Only routed interfaces with logical names can be assigned to a user-defined virtual router.
• Named BVIs can also be assigned to a user-defined router and are supported by IRB in virtual routing.
• Diagnostic and management-only interfaces can also be assigned to a user-defined virtual router.
• If you want to change a virtual router interface to a non-routed mode, remove the interface from the
virtual router, and then change its mode.
• You can assign an interface to a virtual router, either from a global virtual router or from another
user-defined virtual router.
• If a route using the interface that is being moved or its virtual router is deleted, exist in source or destination
virtual router table, remove the routes before the interface movement or virtual router deletion.
• As separate routing tables are maintained for each virtual router, when an interface is moved from one
virtual router to another virtual router, be it global or user-defined, the system removes the IP address
configured on the interface temporarily. All existing connections on the interface are terminated. Thus,
moving interfaces between virtual routers have drastic effect on the network traffic. Hence take
precautionary measures before you move interfaces.
Additional Guidelines
• Security Intelligence Policy—The Security Intelligence policy is not virtual-router-aware. If you add an
IP address, URL, or DNS name to the block list, it is blocked for all virtual routers. This limitation is
applicable on the interface having security zones.
• NAT Rules—Do not mix interfaces in NAT rules. In virtual routing, if the specified source and destination
interface objects (interface groups or security zones) have interfaces that belong to different virtual
routers, the NAT rule diverts traffic from one virtual router through another virtual router. The NAT
does the route lookup in the virtual router table for the inbound interface only. If necessary, define static
routes in the source virtual router for the destination interface. If you leave the interface as any, the rule
applies to all interfaces regardless of virtual router membership.
For devices using virtual routing, the left pane of the Routing page displays the following:
• Manage Virtual Routers—allows you to create and manage virtual routers.
• List of virtual routing protocols—lists routing protocols that you can configure for the virtual routers.
• General Settings—allows you to configure BGP general settings that are applicable for all the virtual
routers. Select the Enable BGP check box in order to define other BGP settings. To configure other
BGP settings for a virtual router, navigate to BGP in the virtual routing protocols .
What to do next
• Configure a Virtual Router.
You can assign interfaces to a user-defined virtual router and configure the routing policies for the device.
Though you cannot manually add or remove interfaces for a global virtual router, you can configure the routing
policies for the device interfaces.
Step 1 From the Devices > Device Management page, edit the virtual-router supported device. Navigate to Routing. For
information on the modifications to the routing page, see Modifications to FMC Web Interface - Routing Page, on page
808.
Step 2 From the drop-down list, select the desired virtual router.
Step 3 In the Virtual Router Properties page, you can modify the description.
Step 4 To add interfaces, select the interface under the Available Interfaces box, and then click Add.
Remember the following:
• Only interfaces with a logical name are listed under the Available Interfaces box. You can edit the interface and
provide a logical name in Interfaces. Remember to save the changes for the settings to take effect.
• Only interfaces of global virtual routers are available for assigning. In other words, the Available Interfaces box
lists only interfaces that are not assigned to any other user-defined virtual routers.
For information on configuring BGP settings, see BGP for Firepower Threat Defense, on page 875.
• Static Route—Use this setting to define where to send traffic for a specific destination network. You can also use
this setting to create an inter-virtual router static route. You can create a leak of connected or static route by using
the interfaces of user-defined or global virtual routers. FMC prefixes to an interface to indicate that it is belonging
to another virtual router and can be used for a route leak. For the route leak to be successful, do not specify next hop
gateway.
The Static Route table displays the virtual router whose interface is used for a route leak in the Leaked from Virtual
Router column. If it is not a route leak, the column displays N/A.
Irrespective of which virtual router the static route belongs, a Null0 interface is listed along with the interfaces of
the same virtual router to which the static route belongs.
For information on static route settings, see Static and Default Routes for Firepower Threat Defense, on page 843.
• Multicast—You can configure multicast routing policies only for a global virtual router. For information on multicast
settings, see Multicast Routing for Firepower Threat Defense, on page 897.
What to do next
• Modify a Virtual Router.
• Remove a Virtual Router .
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 Click Manage Virtual Routers.
All virtual routers along with the assigned interfaces are displayed in the Virtual Routers page.
Step 4 To modify a virtual router, click Edit ( ) against the desired virtual router.
Note You cannot modify the general settings of the global virtual router. Hence, edit is not available for the global
router; instead a View ( ) is provided to view the settings.
What to do next
• Remove a Virtual Router .
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 Click Manage Virtual Routers.
All virtual routers along with the mapped interfaces are displayed in the Virtual Routers page.
Step 4 To remove a virtual router, click Delete ( ) against the desired virtual router.
Step 5 To save the changes, click Save.
Step 1 Configure the inside interface (Gi0/1) of the device to be assigned to Sales virtual router:
a) Choose Devices > Device Management > Interfaces.
b) Edit the Gi0/1 interface:
• Name—For this example, VR-Sales.
• Select the Enabled checkbox.
• In IPV4, for IP Type, choose Use Static IP.
• IP Address—Enter 10.30.0.1/24.
c) Click Ok.
d) Click Save.
Step 2 Configure the inside interface (Gi0/2) of the device to be assigned to Warehouse virtual router:
a) Choose Devices > Device Management > Interfaces.
b) Edit the Gi0/2 interface:
• Name—For this example, VR-Warehouse.
c) Click Ok.
d) Click Save.
Step 3 Create Sales and Warehouse virtual routers and assign their interfaces:
a) Choose Devices > Device Management, and edit the FTD device.
b) Choose Routing > Manage Virtual Routers.
c) Click Add Virtual Router and create Sales.
d) Click Add Virtual Router and create Warehouse.
e) Select Sales from virtual router drop-down, in Virtual Router Properties, add VR-Sales as Selected Interface and
save.
f) Select Warehouse from virtual router drop-down, in Virtual Router Properties, add VR-Warehouse as Selected
Interface and save.
Step 4 Revisit the VR-Warehouse interface configuration:
a) Choose Devices > Device Management > Interfaces.
b) Click Edit against VR-Warehouse interface. Specify the IP Address as 10.30.0.1/24. The system now allows you to
configure with same IP address of VR-Sales, because the interfaces are seperately assigned to two different virtual
routers.
c) Click Ok.
d) Click Save.
Step 5 Create network objects for the warehouse server—10.50.0.0/24, and for the warehouse gateway— 10.40.0.2/30:
a) Choose Object > Object Management.
b) Choose Add Network > Add Object:
• Name—For this example, Warehouse-Server.
• Network—Click Network and enter 10.50.0.0/24.
c) Click Save.
d) Choose Add Network > Add Object:
• Name—For this example, Warehouse-Gateway.
• Network—Click Host and enter 10.40.0.2.
e) Click Save.
Step 6 Define the route leak in Sales that points to the VR-Warehouse interface:
a) Choose Devices > Device Management, and edit the FTD device.
b) Choose Routing.
c) Choose Sales virtual router from the drop-down, and then click Static Route.
d) Click Add Route. In Add Static Route Configuration, specify the following:
• Interface—Select VR-Warehouse.
• Network—Select the Warehouse-Server object.
• Gateway—Leave it blank. When leaking a route into another virtual router, do not select the gateway.
e) Click Ok.
f) Click Save.
Step 7 In the Warehouse virtual router, define the route that points to the Warehouse Router 2 gateway:
a) Choose Warehouse virtual router from the drop-down, and then click Static Route.
b) Click Add Route. In Add Static Route Configuration, specify the following:
• Interface—Select VR-Warehouse.
• Network—Select the Warehouse-Server object.
• Gateway—Select the Warehouse-Gateway object.
c) Click Ok.
d) Click Save.
Step 8 Configure access control rule that allows access to the warehouse server. For creating the access control rule, you need
to create security zones. Use Object > Object Management > Interface. Choose Add > Security Zone and create
security zones for VR-Sales and VR-Warehouse; for Warehouse-Server network object, create a Warehouse-Server
interface group (Choose Add > Interface Group).
Step 9 Choose Policies > Access Control and configure an access control rule to allow traffic from the source interfaces in the
Sales virtual router to the destination interfaces in the Warehouse virtual router for the destination Warehouse-Server
network object.
For example, if the interfaces in Sales are in the Sales-Zone security zone, and those in Warehouse are in the
Warehouse-Zone security zone, the access control rule would look similar to the following:
Note Even if you have some interfaces within virtual routers that does not use overlapping address spaces, define
the NAT rule with the source interface to make troubleshooting easier, and to ensure a cleaner separation
between traffic from the virtual routers that is Internet-bound.
c) Click Ok.
d) Click Save.
Step 2 Configure the inside interface of the device for VR2:
a) Choose Devices > Device Management > Interfaces.
c) Click Ok.
d) Click Save.
Step 3 Configure VR1 and the static default route leak to the outside interface:
a) Choose Devices > Device Management, and edit the FTD device.
b) Choose Routing > Manage Virtual Routers. Click Add Virtual Router and create VR1.
c) For VR1, in Virtual Router Properties, assign vr1-inside and save.
d) Click Static Route.
e) Click Add Route. In Add Static Route Configuration, specify the following:
• Interface—Select the outside interface of the global router.
• Network—Select the any-ipv4 object. This network is the default route for any traffic that cannot be routed
within VR1.
• Gateway—Leave it blank. When leaking a route into another virtual router, do not provide a Gateway.
f) Click Ok.
g) Click Save.
Step 4 Configure VR2 and the static default route leak to the outside interface:
a) Choose Devices > Device Management, and edit the FTD device.
b) Choose Routing > Manage Virtual Routers. Click Add Virtual Router and create VR2.
c) For VR2, in Virtual Router Properties, assign vr2-inside and save.
d) Click Static Route.
e) Click Add Route. In Add Static Route Configuration, specify the following:
• Interface—Select the outside interface of the global router.
• Network—Select the any-ipv4 object. This network is the default route for any traffic that cannot be routed
within VR2.
• Gateway—Leave it blank. When leaking a route into another virtual router, do not select the Gateway.
f) Click Ok.
g) Click Save.
Step 5 Configure IPv4 static default route, namely 172.16.1.2 on the outside interface of the global router:
a) Choose Devices > Device Management, and edit the FTD device.
b) Choose Routing and edit global router properties.
c) Click Static Route.
d) Click Add Route. In Add Static Route Configuration, specify the following:
• Interface—Select the outside interface of the global router.
• Network—Select the any-ipv4 object. This will be the default route for any IPv4 traffic.
• Gateway—If already created, select the host name from the drop-down. If the object is not yet created, click
Add and define the host object for the IP address of the gateway at the other end of the network link on the
outside interface, in this example, 172.16.1.2. After you create the object, select it in the Gateway field.
e) Click Ok.
f) Click Save.
Step 6 Revisit the vr2-inside interface configuration:
a) Choose Devices > Device Management > Interfaces.
b) Click Edit against vr2-inside interface. Specify the IP Address as 192.168.1.1/24. The system now allows you to
configure with same IP address of vr1-inside, because the interfaces are separately assigned to two different virtual
routers.
c) Click Ok.
d) Click Save.
Step 7 Create the NAT rule to PAT inside to outside traffic of VR1 to 10.100.10.1.
a) Choose Devices > NAT.
b) Click New Policy > Threat Defense NAT.
c) Enter InsideOutsideNATRule as the NAT policy name, and select the FTD device. Click Save.
d) In InsideOutsideNATRule page, click Add Rule and define the following:
• NAT Rule—Select Manual NAT Rule.
• Type—Select Dynamic.
• Insert—Above, if any dynamic NAT rule exists.
• Click Enabled.
• In Interface Objects, select vr1-interface object and click Add to Source (If the object is not available, create
one in Object > Object Management > Interface), and select outside as Add to Destination.
• In Translation, for Original Source, select any-ipv4. For Translated Source, click Add and define host
object VR1-PAT-Pool with 10.100.10.1. Select VR1-PAT-Pool as shown in the figure below:
e) Click Ok.
f) Click Save.
Step 8 Add NAT rule to PAT inside to outside traffic of VR2 to 10.100.10.2.
a) Choose Devices > NAT.
b) Edit InsideOutsideNATRule to define the VR2 NAT rule:
• NAT Rule—Select Manual NAT Rule.
• Type—Select Dynamic.
• Insert—Above, if any dynamic NAT rule exists.
• Click Enabled.
• In Interface Objects, select vr2-interface object and click Add to Source (If the object is not available, create
one in Object > Object Management > Interface), and select outside as Add to Destination.
• In Translation, for Original Source, select any-ipv4. For Translated Source, click Add and define host
object VR2-PAT-Pool with 10.100.10.2. Select VR2-PAT-Pool as shown in the figure below:
c) Click Ok.
d) Click Save.
Step 9 To configure the access control policy that allows traffic from the vr1-inside and vr2-inside interfaces to the outside
interface, you need to create security zones. Use Object > Object Management > Interface. Choose Add > Security
Zone and create security zones for vr1-inside, vr2-inside, and outside interfaces.
Step 10 Choose Policies > Access Control and configure an access control rule to allow traffic from vr1-inside-zone and vr2-
inside-zone to outside-zone.
Assuming that you create zones named after the interfaces, a basic rule that allows all traffic to flow to the Internet will
look like the following. You can apply other parameters to this access control policy:
Step 1 Configure route leak from Global virtual router to the user-defined VR1:
a) Choose Devices > Device Management, and edit the FTD device.
b) Click Routing. By default, the Global routing properties page appears.
c) Click Static Route.
d) Click Add Route. In Add Static Route Configuration, specify the following:
• Interface—Select the VR1 inside interface.
• Network—Select the VR1 virtual router network object. You can create one using the Add Object option.
• Gateway—Leave it blank. When leaking a route into another virtual router, does not select the gateway.
The route leak allows AnyConnect Clients assigned IP addresses in the VPN pool to access the 192.168.1.0/24 network
in the VR1 virtual router.
e) Click Ok.
Step 2 Configure the route leak from VR1 to the Global virtual router:
a) Choose Devices > Device Management, and edit the FTD device.
b) Click Routing and from the drop-down, select VR1.
The configured static route allows endpoints on the 192.168.1.0/24 network (VR1) to initiate connections to
AnyConnect Clients assigned IP addresses in the VPN pool.
e) Click Ok.
What to do next
If RA VPN address pool and the IP addresses in the user-defined virtual router overlap, you must also use
static NAT rules on the IP addresses to enable proper routing. Alternatively, you can change your RA VPN
address pool so that there is no overlap.
Step 1 Configure route leak from the Global virtual router to the user-defined VR1:
a) Choose Devices > Device Management, and edit the FTD device.
b) Click Routing. By default, the Global routing properties page appears.
c) Click Static Route.
d) Click Add Route. In Add Static Route Configuration, specify the following:
• Interface—Select the VR1 inside interface.
• Network—Select the VR1 virtual router network object. You can create one using the Add Object option.
• Gateway—Leave it blank. When leaking a route into another virtual router, do not select the gateway.
The route leak allows endpoints protected by the external (remote) end of the site-to-site VPN to access the
192.168.1.0/24 network in the VR1 virtual router.
e) Click Ok.
Step 2 Configure the route leak from VR1 to the Global virtual router:
a) Choose Devices > Device Management, and edit the FTD device.
b) Click Routing and from the drop-down, select VR1.
c) Click Static Route.
d) Click Add Route. In Add Static Route Configuration, specify the following:
• Interface—Select the outside interface of the global router.
• Network—Select the global virtual router network object.
• Gateway—Leave it blank. When leaking a route into another virtual router, do not select the gateway.
This static route allows endpoints on the 192.168.1.0/24 network (VR1) to initiate connections that will traverse the
site-to-site VPN tunnel. For this example, the remote endpoint that is protecting the 172.16.20.0/24 network.
e) Click Ok.
Step 3 Add the 192.168.1.0/24 network to the site-to-site VPN connection profile:
a) Choose Devices > VPN > Site To Site, and edit the VPN Topology.
b) In Endpoints, edit Node A endpoint.
c) In Edit Endpoint, in the Protected Networks field, click Add New Network Object.
d) Add the VR1 network object with 192.168.1.0 network:
How to Route Traffic between Two Overlapping Network Host in Virtual Routing
You can configure hosts on the virtual routers that have same network address. If the hosts want to communicate,
you can configure twice NAT. This example provides the procedure to configure the NAT rules to manage
the overlapping network host.
In the following example, two hosts Host A and Host B belong to different virtual routers: VRG (interface
vrg-inside), VRB (interface vrb-inside) respectively with the same subnet 10.1.1.0/24. For both the hosts to
communicate, create a NAT policy where, VRG-Host interface object would use a mapped NAT address -
20.1.1.1, and VRB-Host interface object would use a mapped NAT address - 30.1.1.1. Thus, Host A uses
30.1.1.1 to communicate to Host B; Host B uses 20.1.1.1 to reach Host A.
• vrg-inside and vrb-inside interfaces are associated with virtual routers: VRG and VRB respectively and
vrg-inside and vrb-inside interfaces configured with same subnet address (say, 10.1.1.0/24).
• Interfaces zones VRG-Inf, VRB-Inf created with vrg-inside and vrb-inside interfaces respectively.
• Host A in VRG with vrg-inside as default gateway; Host B in VRB with vrb-inside as default gateway.
Step 1 Create the NAT rule to handle traffic from Host A to Host B. Choose Devices > NAT.
Step 2 Click New Policy > Threat Defense NAT.
Step 3 Enter a NAT policy name, and select the FTD device. Click Save.
Step 4 In the NAT page, click Add Rule and define the following:
• NAT Rule—Select Manual NAT Rule.
• Type—Select Static.
• Insert—Select Above, if any NAT rule exists.
• Click Enabled.
• In Interface Objects, select VRG-Inf object and click Add to Source (If the object isn’t available, create one in
Object > Object Management > Interface), and select VRB-Inf object and click Add to Destination.
• In Translation, select the following:
• Original Source, select vrg-inside.
• Original Destination, click Add and define object VRB-Mapped-Host with 30.1.1.1. Select VRB-Mapped-Host.
• Translated Source, click Add and define object, VRG-Mapped-Host with 20.1.1.1. Select VRG-Mapped-Host.
• Translated Destination, select vrb-inside as shown in the following figure:
When you run the show nat detail command on the FTD device, you will see an output similar to this:
firepower(config-service-object-group)# show nat detail
Manual NAT Policies (Section 1)
1 (2001) to (3001) source static vrg-inside VRG-MAPPED-HOST destination static VRB-MAPPED-HOST
vrb-inside
translate_hits = 0, untranslate_hits = 0
Source - Origin: 10.1.1.1/24, Translated: 20.1.1.1/24
Destination - Origin: 30.1.1.1/24, Translated: 10.1.1.1/24
Step 1 Choose Devices > Device Management. Edit the required device.
Step 2 In Interfaces, choose Add Interfaces > Bridge Group Interface.
a) Enter the following details for BVI-G:
• Name—For this example, BVI-G.
• Bridge Group ID—For this example, 1.
• Available Interface—Select the interfaces.
• In IPV4, for IP Type, choose Use Static IP.
• IP Address—Enter 10.10.10.5/24.
b) Click Ok.
c) Click Save.
a) Enter the following details for BVI-B:
• Name—For this example, BVI-B.
• Bridge Group ID—For this example, 2.
• Available Interface—Select the sub interfaces.
• In IPV4, for IP Type, choose Use Static IP.
• IP Address—Leave this field empty as the system does not allow two interfaces to have overlapping IP address.
You can revisit the Bridge Group and provide the same IP address after aligning it under a virtual router.
b) Click Ok.
c) Click Save.
Step 3 Create virtual router, say VRG, and select BVI-G as its network:
a) Choose Devices > Device Management.
b) Edit the device, and choose Routing > Manage Virtual Routers.
c) Click Add Virtual Router. Enter a name for the virtual router and click Ok.
d) In Virtual Routing Properties, select BVI-G and click Add.
e) Click Save.
Step 4 Create virtual router, say VRB, and select BVI-B as its network:
a) Choose Devices > Device Management.
b) Edit the device, and choose Routing > Manage Virtual Routers.
c) Click Add Virtual Router. Enter a name for the virtual router and click Ok.
e) Click Save.
Step 5 Revisit the BVI-B configuration:
a) Choose Devices > Device Management > Interfaces.
b) Click Edit against BVI-B interface. Specify the IP Address as 10.10.10.5/24. The system now allows you to configure
with same IP address of BVI-G, because the interfaces are seperately assigned to two different virtual routers.
c) Click Ok.
d) Click Save.
If you want to enable inter-BVI communication, use an external router as default gateway. In overlapping BVI scenarios,
as in this example, use twice NAT external router as gateway to establish inter-BVI traffic. When configuring NAT for
the members of a bridge group, you specify the member interface. You cannot configure NAT for the bridge group
interface (BVI) itself. When doing NAT between bridge group member interfaces, you must specify the real and mapped
addresses. You cannot specify “any” as the interface.
c) Click Ok.
d) Click Save.
Step 2 Configure the inside interface of the device for VRB:
a) Choose Devices > Device Management > Interfaces.
b) Edit the interfaces that you want to assign to VRB:
• Name—For this example, VRB-inside.
• Select the Enabled checkbox.
• In IPV4, for IP Type, choose Use Static IP.
• IP Address—Leave it blank. The system doesn’t allow you to configure interfaces with same IP address, as
you’re yet to create user-defined virtual routers.
c) Click Ok.
d) Click Save.
Step 3 Configure VRG and the static default route leak to the inside interface of the Global router for the VRG users to access
the common server 172.16.10.1:
a) Choose Devices > Device Management, and edit the FTD device.
b) Choose Routing > Manage Virtual Routers. Click Add Virtual Router and create VRG.
c) For VRG, in Virtual Router Properties, assign VRG-inside and save.
f) Click Ok.
g) Click Save.
Step 4 Configure VRB and the static default route leak to the inside interface of the Global router for the VRB users to access
the shared server 172.16.10.x:
a) Choose Devices > Device Management, and edit the FTD device.
b) Choose Routing > Manage Virtual Routers. Click Add Virtual Router and create VRB.
c) For VRB, in Virtual Router Properties, assign VRB-inside and save.
f) Click Ok.
g) Click Save.
Step 5 Revisit the VRB-inside interface configuration:
a) Choose Devices > Device Management > Interfaces.
b) Click Edit against VRB-inside interface. Specify the IP Address as 192.168.1.1/24. The system now allows you
to configure with the same IP address as that of VRG-inside, because the interfaces are seperately assigned to two
different virtual routers.
c) Click Ok.
d) Click Save.
Step 6 Add NAT rules for the source objects VRG and VRB. Click Devices > NAT.
Step 7 Click New Policy > Threat Defense NAT.
Step 8 Enter a NAT policy name, and select the FTD device. Click Save.
Step 9 In the NAT page, click Add Rule and define the following source NAT for VRG:
• NAT Rule—Select Manual NAT Rule.
• Type—Select Static.
• Insert—Select Above, if any NAT rule exists.
• Click Enabled.
• In Interface Objects, select VRG-Inside object and click Add to Source (If the object is not available, create one
in Object > Object Management > Interface), and select Global-Inside object and click Add to Destination.
• In Translation, select the following:
• Original Source, select VRG-Users.
• Translated Source, click Add and define object, VRG-NAT with 10.1.1.1. Select VRG-NAT as shown in
the following figure:
Step 13 Add the two unique AD servers in FMC one for each VRG and VRB users—choose System > Integration > Realms.
Step 14 Click New Realm and complete the fields. For detailed information on the fields, see Realm Fields, on page 2074.
Step 15 For controlling the access from VRG and VRB users, define 2 Active Directories, see Configure a Realm Directory,
on page 2080.
Step 16 Add ISE in FMC—choose System > Integration > Identity Sources.
Step 17 Click Identity Services Engine and complete the fields. For detailed information on the fields, see How to Configure
ISE/ISE-PIC for User Control Using a Realm, on page 2094.
Step 18 Create Identity policy, rules, and then define access control policy for controlling access of overlapping users from
VRG and VRB.
Default Route
The simplest option is to configure a default static route to send all traffic to an upstream router, relying on
the router to route the traffic for you. A default route identifies the gateway IP address to which the FTD
device sends all IP packets for which it does not have a learned or static route. A default static route is simply
a static route with 0.0.0.0/0 (IPv4) or ::/0 (IPv6) as the destination IP address.
You should always define a default route.
Because the FTD uses separate routing tables for data traffic and for management traffic, you can optionally
configure a default route for data traffic and another default route for management traffic. Note that
from-the-device traffic uses either the management or data routing table by default depending on the type (see
Routing Table for Management Traffic, on page 797), but will fall back to the other routing table if a route is
not found. Default routes will always match traffic, and will prevent a fall back to the other routing table. In
this case, you must specify the interface you want to use for egress traffic if that interface is not in the default
routing table.
Static Routes
You might want to use static routes in the following cases:
Route Priorities
• Routes that identify a specific destination take precedence over the default route.
• When multiple routes exist to the same destination (either static or dynamic), then the administrative
distance for the route determines priority. Static routes are set to 1, so they typically are the highest
priority routes.
• When you have multiple static routes to the same destination with the same administrative distance, see
Equal-Cost Multi-Path (ECMP) Routing, on page 798.
• For traffic emerging from a tunnel with the Tunneled option, this route overrides any other configured
or learned default routes.
You can configure static route tracking for statically defined routes or default routes obtained through DHCP
or PPPoE. You can only enable PPPoE clients on multiple interfaces with route tracking configured.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
IPv6
• Static route tracking is not supported for IPv6.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 (For virtual-router-aware devices) From the virtual routers drop-down list, select the virtual router for which you are
configuring a static route.
Step 4 Select Static Route.
Step 5 Click Add Routes.
Step 6 Click IPv4 or IPv6 depending on the type of static route that you are adding.
Step 7 Choose the Interface to which this static route applies.
For transparent mode, choose a bridge group member interface name. For routed mode with bridge groups, you can
choose either the bridge group member interface for the BVI name. To “black hole” unwanted traffic, choose the Null0
interface.
For a device using virtual routing, you can select an interface that belongs to another virtual router. You can create
such a static route if you want to leak traffic from this virtual router into the other virtual router. For more information,
see Interconnecting Virtual Routers, on page 804.
Step 9 In the Gateway or IPv6 Gateway field, enter or choose the gateway router which is the next hop for this route. You
can provide an IP address or a Networks/Hosts object. When you are using static route configuration for virtual routers
to leak routes, do not specify the next hop gateway.
Step 10 In the Metric field, enter the number of hops to the destination network. Valid values range from 1 to 255; the default
value is 1. The metric is a measurement of the “expense” of a route, based on the number of hops (hop count) to the
network on which a specific host resides. Hop count is the number of networks that a network packet must traverse,
including the destination network, before it reaches its final destination. The metric is used to compare routes among
different routing protocols. The default administrative distance for static routes is 1, giving it precedence over routes
discovered by dynamic routing protocols but not directly connected routes. The default administrative distance for
routes discovered by OSPF is 110. If a static route has the same administrative distance as a dynamic route, the static
route takes precedence. Connected routes always take precedence over static or dynamically discovered routes.
Step 11 (Optional) For a default route, click the Tunneled checkbox to define a separate default route for VPN traffic.
You can define a separate default route for VPN traffic if you want your VPN traffic to use a different default route
than your non VPN traffic. For example, traffic incoming from VPN connections can be easily directed towards internal
networks, while traffic from internal networks can be directed towards the outside. When you create a default route
with the tunneled option, all traffic from a tunnel terminating on the device that cannot be routed using learned or static
routes, is sent to this route. You can configure only one default tunneled gateway per device. ECMP for tunneled traffic
is not supported.
Step 12 (IPv4 static route only) To monitor route availability, enter or choose the name of an SLA (service level agreement)
Monitor object that defines the monitoring policy, in the Route Tracking field.
See SLA Monitor Objects, on page 509.
About OSPF
OSPF is an interior gateway routing protocol that uses link states rather than distance vectors for path selection.
OSPF propagates link-state advertisements rather than routing table updates. Because only LSAs are exchanged
instead of the entire routing tables, OSPF networks converge more quickly than RIP networks.
OSPF uses a link-state algorithm to build and calculate the shortest path to all known destinations. Each router
in an OSPF area contains an identical link-state database, which is a list of each of the router usable interfaces
and reachable neighbors.
The advantages of OSPF over RIP include the following:
• OSPF link-state database updates are sent less frequently than RIP updates, and the link-state database
is updated instantly, rather than gradually, as stale information is timed out.
• Routing decisions are based on cost, which is an indication of the overhead required to send packets
across a certain interface. The Firepower Threat Defense device calculates the cost of an interface based
on link bandwidth rather than the number of hops to the destination. The cost can be configured to specify
preferred paths.
The disadvantage of shortest path first algorithms is that they require a lot of CPU cycles and memory.
The Firepower Threat Defense device can run two processes of OSPF protocol simultaneously on different
sets of interfaces. You might want to run two processes if you have interfaces that use the same IP addresses
(NAT allows these interfaces to coexist, but OSPF does not allow overlapping addresses). Or you might want
to run one process on the inside and another on the outside, and redistribute a subset of routes between the
two processes. Similarly, you might need to segregate private addresses from public addresses.
You can redistribute routes into an OSPF routing process from another OSPF routing process, a RIP routing
process, or from static and connected routes configured on OSPF-enabled interfaces.
The Firepower Threat Defense device supports the following OSPF features:
• Intra-area, inter-area, and external (Type I and Type II) routes.
• Virtual links.
• LSA flooding.
• Authentication to OSPF packets (both password and MD5 authentication).
• Configuring the Firepower Threat Defense device as a designated router or a designated backup router.
The Firepower Threat Defense device also can be set up as an ABR.
• Stub areas and not-so-stubby areas.
• Area boundary router Type 3 LSA filtering.
OSPF supports MD5 and clear text neighbor authentication. Authentication should be used with all routing
protocols when possible because route redistribution between OSPF and other protocols (such as RIP) can
potentially be used by attackers to subvert routing information.
If NAT is used, if OSPF is operating on public and private areas, and if address filtering is required, then you
need to run two OSPF processes—one process for the public areas and one for the private areas.
A router that has interfaces in multiple areas is called an Area Border Router (ABR). A router that acts as a
gateway to redistribute traffic between routers using OSPF and routers using other routing protocols is called
an Autonomous System Boundary Router (ASBR).
An ABR uses LSAs to send information about available routes to other OSPF routers. Using ABR Type 3
LSA filtering, you can have separate private and public areas with the ASA acting as an ABR. Type 3 LSAs
(inter-area routes) can be filtered from one area to other, which allows you to use NAT and OSPF together
without advertising private networks.
Note Only Type 3 LSAs can be filtered. If you configure the Firepower Threat Defense device as an ASBR in a
private network, it will send Type 5 LSAs describing private networks, which will get flooded to the entire
AS, including public areas.
If NAT is employed but OSPF is only running in public areas, then routes to public networks can be redistributed
inside the private network, either as default or Type 5 AS external LSAs. However, you need to configure
static routes for the private networks protected by the Firepower Threat Defense device. Also, you should not
mix public and private networks on the same Firepower Threat Defense device interface.
You can have two OSPF routing processes, one RIP routing process, and one EIGRP routing process running
on the Firepower Threat Defense device at the same time.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
IPv6 Guidelines
• OSPFv2 does not support IPv6.
• OSPFv3 supports IPv6.
• OSPFv3 uses IPv6 for authentication.
• The Firepower Threat Defense device installs OSPFv3 routes into the IPv6 RIB, provided it is the best
route.
Clustering Guidelines
• OSPFv3 encryption is not supported. An error message appears if you try to configure OSPFv3 encryption
in a clustering environment.
• In Spanned interface mode, dynamic routing is not supported on management-only interfaces.
• When a control role change occurs in the cluster, the following behavior occurs:
• In spanned interface mode, the router process is active only on the control unit and is in a suspended
state on the data units. Each cluster unit has the same router ID because the configuration has been
synchronized from the control unit. As a result, a neighboring router does not notice any change in
the router ID of the cluster during a role change.
Additional Guidelines
• OSPFv2 and OSPFv3 support multiple instances on an interface.
• OSPFv3 supports encryption through ESP headers in a non-clustered environment.
• OSPFv3 supports Non-Payload Encryption.
• OSPFv2 supports Cisco NSF Graceful Restart and IETF NSF Graceful Restart mechanisms as defined
in RFCs 4811, 4812 & 3623 respectively.
• OSPFv3 supports Graceful Restart mechanism as defined in RFC 5187.
• There is a limit to the number of intra area (type 1) routes that can be distributed. For these routes, a
single type-1 LSA contains all prefixes. Because the system has a limit of 35 KB for packet size, 3000
routes result in a packet that exceeds the limit. Consider 2900 type 1 routes to be the maximum number
supported.
• For a device using virtual routing, you can configure OSPFv2 and OSPFv3 for a global virtual router.
However, you can configure only OSPFv2 for a user-defined virtual router.
Configure OSPFv2
This section describes the tasks involved in configuring an OSPFv2 routing process. For a device using virtual
routing, you can configure OSPFv2 for global as well as for user-defined virtual routers.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 (For a virtual-router-aware device) From the virtual routers drop-down list, choose the virtual router for which you are
configuring OSPF.
Step 4 Click OSPF.
Step 5 Select Process 1. You can enable up to two OSPF process instances for each context/virtual router. You must choose
an OSPF process to be able to configure the Area parameters.
If the device is using virtual routing, the ID fields display the unique process IDs generated for the chosen virtual router.
Step 6 Choose the OSPF role from the drop-down list, and enter a description for it in the next field. The options are Internal,
ABR, ASBR, and ABR and ASBR. See About OSPF, on page 849 for a description of the OSPF roles.
Step 7 Select Area > Add.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 8 Configure the following area options for each OSPF process:
• OSPF Process—Choose the process ID. For a device using virtual routing, the drop-down lists the unique process
IDs generated for the selected virtual router.
• Metric Value—The metric used for generating the default route. The default value is 10. Valid metric values
range from 0 through 16777214.
• Metric Type—The metric type is the external link type that is associated with the default route that is advertised
into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2 for a Type 2 external
route.
• Available Network—Choose one of the available networks and click Add, or click Add ( ) to add a new network
object. See Network Objects, on page 448 for the procedure for adding networks.
• Authentication—Choose the OSPF authentication:
• None—(Default) Disables OSPF area authentication.
• Password—Provides a clear text password for area authentication, which is not recommended where security
is a concern.
• MD5—Allows MD5 authentication.
• Default Cost—The default cost for the OSPF area, which is used to determine the shortest paths to the destination.
Valid values range from 0 through 65535. The default value is 1.
• Click Add ( ) to add a new network object. See Network Objects, on page 448 for the procedure for adding
networks.
• Peer Router—Choose the IP address of the peer router. To add a new peer router, click Add ( ). See Network
Objects, on page 448 for the procedure for adding networks.
• Hello Interval—The time in seconds between the hello packets sent on an interface. The hello interval is an
unsigned integer that is to be advertised in the hello packets. The value must be the same for all routers and access
servers on a specific network. Valid values range from 1 through 65535. The default is 10.
The smaller the hello interval, the faster topological changes are detected, but the more traffic is sent on the
interface.
• Transmit Delay—The estimated time in seconds that is required to send an LSA packet on the interface. The
integer value must be greater than zero. Valid values range from 1 through 8192. The default is 1.
LSAs in the update packet have their own ages incremented by this amount before transmission. If the delay is
not added before transmission over a link, the time in which the LSA propagates over the link is not considered.
The value assigned should take into account the transmission and propagation delays for the interface. This setting
has more significance on very low-speed links.
• Retransmit Interval—The time in seconds between LSA retransmissions for adjacencies that belong to the
interface. The retransmit interval is the expected round-trip delay between any two routers on the attached network.
The value must be greater than the expected round-trip delay, and can range from 1 through 65535. The default
is 5.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment message. If
the router receives no acknowledgment, it resends the LSA. Be conservative when setting this value, or needless
retransmission can result. The value should be larger for serial lines and virtual links.
• Dead Interval—The time in seconds that hello packets are not seen before a neighbor indicates that the router is
down. The dead interval is an unsigned integer. The default is four times the hello interval, or 40 seconds. The
value must be the same for all routers and access servers that are attached to a common network. Valid values
range from 1 through 65535.
• Authentication—Choose the OSPF virtual link authentication from the following:
• None—(Default) Disables virtual link area authentication.
• Area Authentication—Enables area authentication using MD5. Click Add, and enter the key ID, key, confirm
the key, and then click OK.
• Password—Provides a clear text password for virtual link authentication, which is not recommended where
security is a concern.
• MD5—Allows MD5 authentication. Click Add, and enter the key ID, key, confirm the key, and then click
OK.
Note Ensure to enter only numbers as the MD5 key ID.
• Key Chain—Allows key chain authentication. Click Add, and create the key chain, and then click Save. For
detailed procedure, see Creating Key Chain Objects, on page 507. Use the same authentication type (MD5 or
Key Chain) and key ID for the peers to establish a successful adjacency.
What to do next
Continue with Configure OSPF Redistribution.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 (For a virtual-router-aware device) From the virtual routers drop-down list, choose the virtual router for which you are
configuring OSPF.
Step 4 Click OSPF.
Step 5 Select Distribution > Add.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 6 Configure the following redistribution options for each OSPF process:
• OSPF Process—Choose the process ID. For a device using virtual routing, this drop-down list displays the unique
process IDs generated for the selected virtual router.
• Route Type—Choose one of the following types:
• Static—Redistributes static routes to the OSPF routing process.
• Connected—Redistributes connected routes (routes established automatically by virtue of having the IP address
enabled on the interface) to the OSPF routing process. Connected routes are redistributed as external to the
device. You can select whether to use subnets under the Optional list.
• OSPF—Redistributes routes from another OSPF routing process, for example, internal, external 1 and 2, NSSA
external 1 and 2, or whether to use subnets. You can select these options under the Optional list.
• BGP—Redistribute routes from the BGP routing process. Add the AS number and whether to use subnets.
• RIP—Redistributes routes from the RIP routing process. You can select whether to use subnets under the
Optional list.
Note As a user-defined virtual router does not support RIP, you cannot redistribute routes from RIP.
• Metric Value—Metric value for the routes being distributed. The default value is 10. Valid values range from 0 to
16777214.
When redistributing from one OSPF process to another OSPF process on the same device, the metric will be carried
through from one process to the other if no metric value is specified. When redistributing other processes to an OSPF
process, the default metric is 20 when no metric value is specified.
• Metric Type—The metric type is the external link type that is associated with the default route that is advertised
into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2 for a Type 2 external
route.
• Tag Value—Tag specifies the 32-bit decimal value attached to each external route that is not used by OSPF itself,
but which may be used to communicate information between ASBRs. If none is specified, then the remote autonomous
system number is used for routes from BGP and EGP. For other protocols, zero is used. Valid values are from 0 to
4294967295.
• RouteMap—Checks for filtering the importing of routes from the source routing protocol to the current routing
protocol. If this parameter is not specified, all routes are redistributed. If this parameter is specified, but no route
map tags are listed, no routes are imported. Or you can add a new route map by clicking Add ( ). See Route Maps
to add a new route map.
What to do next
Continue with Configure OSPF Inter-Area Filtering, on page 858.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 (For a virtual-router-aware device) From the virtual routers drop-down list, choose the virtual router for which you are
configuring OSPF.
Step 4 Click OSPF.
Step 5 Select InterArea > Add.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete inter-areas.
Step 6 Configure the following inter-area filtering options for each OSPF process:
• OSPF Process—For a device using virtual routing, the drop-down lists the unique process IDs generated for the
selected virtual router.
• Area ID—The area for which routes are to be summarized.
• PrefixList—The name of the prefix. To add a new prefix list object, see Step 5.
• Traffic Direction—Inbound or outbound. Choose Inbound to filter LSAs coming into an OSPF area, or Outbound
to filter LSAs coming out of an OSPF area. If you are editing an existing filter entry, you cannot modify this
setting.
Step 7 Click Add ( ), and enter a name for the new prefix list, and whether to allow overrides.
You must configure a prefix list before you can configure a prefix rule.
Step 8 Click Add to configure prefix rules, and configure the following parameters:
• Action—Select Block or Allow for the redistribution access.
• Sequence No—The routing sequence number. By default, sequence numbers are automatically generated in
increments of 5, beginning with 5.
• IP Address—Specify the prefix number in the format of IP address/mask length.
• Min Prefix Length—(Optional) The minimum prefix length.
• Max Prefix Length—(Optional) The maximum prefix length.
What to do next
Continue with Configure OSPF Filter Rules, on page 859.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 (For a virtual-router-aware device) From the virtual routers drop-down list, choose the virtual router for which you are
configuring OSPF.
Step 4 Click OSPF.
Step 5 Select Filter Rule > Add.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete filter rules.
Step 6 Configure the following filter rule options for each OSPF process:
• OSPF Process— For a device using virtual routing, the drop-down lists the unique process IDs generated for the
selected virtual router.
• Access List—The access list for this OSPF process. To add a new standard access list object, click Add ( ) and
see Configure Standard ACL Objects, on page 516.
• Traffic Direction—Choose In or Out for the traffic direction being filtered. Choose In to filter LSAs coming into
an OSPF area, or Out to filter LSAs coming out of an OSPF area. If you are editing an existing filter entry, you
cannot modify this setting.
What to do next
Continue with Configure OSPF Summary Addresses, on page 860.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 (For a virtual-router-aware device) From the virtual routers drop-down list, choose the virtual router for which you are
configuring OSPF.
Step 4 Click OSPF.
Step 5 Select Summary Address > Add.
You can click Edit ( ) to edit, or use the right-click menu to cut, copy, past, insert, and delete summary addresses.
Step 6 Configure the following summary address options for each OSPF process:
• OSPF Process— For a device using virtual routing, the drop-down lists the unique process IDs generated for the
selected virtual router.
• Available Network—The IP address of the summary address. Select one from the Available networks list and click
Add, or to add a new network, click Add ( ). See Network Objects, on page 448 for the procedure for adding
networks.
• Tag—A 32-bit decimal value that is attached to each external route. This value is not used by OSPF itself, but may
be used to communicate information between ASBRs.
• Advertise—Advertises the summary route. Uncheck this check box to suppress routes that fall under the summary
address. By default, this check box is checked.
What to do next
Continue with Configure OSPF Interfaces and Neighbors, on page 861.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 (For a virtual-router-aware device) From the virtual routers drop-down list, choose the virtual router for which you are
configuring OSPF.
Step 4 Click OSPF.
Step 5 Select Interface > Add.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 6 Configure the following Interface options for each OSPF process:
• Interface—The interface you are configuring.
Note If the device is using virtual routing, this drop-down list displays only those interfaces that belong to
the router.
• Default Cost—The cost of sending a packet through the interface. The default value is 10.
• Priority—Determines the designated router for a network. Valid values range from 0 to 255. The default value
is 1. Entering 0 for this setting makes the router ineligible to become the designated router or backup designated
router.
When two routers connect to a network, both attempt to become the designated router. The device with the higher
router priority becomes the designated router. If there is a tie, the router with the higher router ID becomes the
designated router. This setting does not apply to interfaces that are configured as point-to-point interfaces.
• MTU Ignore—OSPF checks whether neighbors are using the same MTU on a common interface. This check is
performed when neighbors exchange DBD packets. If the receiving MTU in the DBD packet is higher than the
IP MTU configured on the incoming interface, OSPF adjacency is not established.
• Database Filter—Use this setting to filter the outgoing LSA interface during synchronization and flooding. By
default, OSPF floods new LSAs over all interfaces in the same area, except the interface on which the LSA arrives.
In a fully meshed topology, this flooding can waste bandwidth and lead to excessive link and CPU usage. Checking
this check box prevents OSPF flooding of the LSA on the selected interface.
• Hello Interval—Specifies the interval, in seconds, between hello packets sent on an interface. Valid values range
1–8192 seconds. The default value is 10 seconds.
The smaller the hello interval, the faster topological changes are detected, but more traffic is sent on the interface.
This value must be the same for all routers and access servers on a specific interface.
• Transmit Delay—Estimated time in seconds to send an LSA packet on the interface. Valid values range 1–65535
seconds. The default is 1 second.
LSAs in the update packet have their ages increased by the amount specified by this field before transmission. If
the delay is not added before transmission over a link, the time in which the LSA propagates over the link is not
considered. The value assigned should take into account the transmission and propagation delays for the interface.
This setting has more significance on very low-speed links.
• Retransmit Interval—Time in seconds between LSA retransmissions for adjacencies that belong to the interface.
The time must be greater than the expected round-trip delay between any two routers on the attached network.
Valid values range from 1 to 65535 seconds. The default is 5 seconds.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment message. If
the router receives no acknowledgment, it resends the LSA. Be conservative when setting this value, or needless
retransmission can result. The value should be larger for serial lines and virtual links.
• Dead Interval—Time period in seconds for which hello packets must not be seen before neighbors indicate that
the router is down. The value must be the same for all nodes on the network and can range 1–65535.
• Hello Multiplier—Specifies the number of Hello packets to be sent per second. Valid values are 3–20.
• Point-to-Point—Lets you transmit OSPF routes over VPN tunnels.
• Authentication—Choose the OSPF interface authentication from the following:
• None—(Default) Disables interface authentication.
• Area Authentication—Enables interface authentication using MD5. Click Add, and enter the key ID, key,
confirm the key, and then click OK.
• Password—Provides a clear text password for virtual link authentication, which is not recommended where
security is a concern.
• MD5—Allows MD5 authentication. Click Add, and enter the key ID, key, confirm the key, and then click
OK.
Note Ensure to enter only numbers as the MD5 key ID.
• Key Chain—Allows key chain authentication. Click Add, and create the key chain, and then click Save. For
detailed procedure, see Creating Key Chain Objects, on page 507. Use the same authentication type (MD5 or
Key Chain) and key ID for the peers to establish a successful adjacency.
• Enter Password—The password you configure if you choose Password as the type of authentication.
• Confirm Password—Confirm the password that you chose.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
• Neighbor—Choose one of the neighbors in the drop-down list, or click Add ( ) to add a new neighbor; enter
the name, description, network, whether to allow overrides, and then click Save.
• Interface—Choose the interface associated with the neighbor.
Configuring the NSF graceful-restart feature involves two steps; configuring capabilities and configuring
a device as NSF-capable or NSF-aware. A NSF-capable device can indicate its own restart activities to
neighbors and a NSF-aware device can help a restarting neighbor.
A device can be configured as NSF-capable or NSF-aware, depending on some conditions:
• A device can be configured as NSF-aware irrespective of the mode in which it is.
• A device has to be in either Failover or Spanned Etherchannel (L2) cluster mode to be configured
as NSF-capable.
• For a device to be either NSF-aware or NSF-capable, it should be configured with the capability of
handling opaque Link State Advertisements (LSAs)/ Link Local Signaling (LLS) block as required.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click Routing.
Step 3 (For a virtual-router-aware device) From the virtual routers drop-down list, choose the virtual router for which you are
configuring OSPF.
Step 4 Click OSPF > Advanced Settings.
Step 5 Select General, and configure the following:
• Router ID—Choose Automatic or IP address for the router ID. If you choose IP address, enter the IP address in
the IP Address field.
• Ignore LSA MOSPF—Suppresses syslog messages when the route receives unsupported LSA Type 6 multicast
OSPF (MOSPF) packets.
• RFC 1583 Compatible—Configures RFC 1583 compatibility as the method used to calculate summary route costs.
Routing loops can occur with RFC 1583 compatibility enabled. Disable it to prevent routing loops. All OSPF routers
in an OSPF routing domain should have RFC compatibility set identically.
• Adjacency Changes—Defines the adjacency changes that cause syslog messages to be sent.
By default, a syslog message is generated when an OSPF neighbor goes up or down. You can configure the router
to send a syslog message when an OSPF neighbor goes down and also a syslog for each state.
• Log Adjacency Changes—Causes the Firepower Threat Defense device to send a syslog message whenever
an OSPF neighbor goes up or down. This setting is checked by default.
• Log Adjacency Change Details—Causes the Firepower Threat Defense device to send a syslog message
whenever any state change occurs, not just when a neighbor goes up or down. This setting is unchecked by
default.
• Administrative Route Distance—Allows you to modify the settings that were used to configure administrative
route distances for inter-area, intra-area, and external IPv6 routes. The administrative route distance is an integer
from 1 to 254. The default is 110.
• LSA Group Pacing—Specifies the interval in seconds at which LSAs are collected into a group and refreshed,
check summed, or aged. Valid values range from 10 to 1800. The default value is 240.
• Enable Default Information Originate—Check the Enable check box to generate a default external route into an
OSPF routing domain and configure the following options:
• Always advertise the default route—Ensures that the default route is always advertised.
• Metric Value—Metric used for generating the default route. Valid metric values range from 0 to 16777214.
The default value is 10.
• Metric Type—The external link type that is associated with the default route that is advertised into the OSPFv3
routing domain. Valid values are 1 (Type 1 external route) and 2 (Type 2 external route). The default is Type
2 external route.
• RouteMap—Choose the routing process that generates the default route if the route map is satisfied or click
Add ( ) to add a new one. See Route Maps to add a new route map.
a) Check the Enable Cisco Non Stop Forwarding Capability check box.
b) (Optional) Check the Cancel NSF restart when non-NSF-aware neighboring networking devices are detected
check box if required.
c) (Optional) Make sure the Enable Cisco Non Stop Forwarding Helper mode check box is unchecked to disable the
helper mode on an NSF-aware device.
Step 8 Configure IETF NSF Graceful Restart for OSPFv2, for an NSF-capable or NSF-aware device:
a) Check the Enable IETF Non Stop Forwarding Capability check box.
b) In the Length of graceful restart interval (seconds) field, enter the restart interval in seconds. The default value is
120 seconds. For a restart interval below 30 seconds, graceful restart will be terminated.
c) (Optional) Make sure the Enable IETF nonstop forwarding (NSF) for helper mode check box is unchecked to
disable the IETF NSF helper mode on an NSF-aware device.
d) Enable Strict Link State advertisement checking—When enabled, it indicates that the helper router will terminate
the process of restarting the router if it detects that there is a change to a LSA that would be flooded to the restarting
router, or if there is a changed LSA on the retransmission list of the restarting router when the graceful restart process
is initiated.
e) Enable IETF Non Stop Forwarding—Enables non stop forwarding, which allows for the forwarding of data packets
to continue along known routes while the routing protocol information is being restored following a switchover.
OSPF uses extensions to the OSPF protocol to recover its state from neighboring OSPF devices. For the recovery to
work, the neighbors must support the NSF protocol extensions and be willing to act as "helpers" to the device that is
restarting. The neighbors must also continue forwarding data traffic to the device that is restarting while protocol
state recovery takes place.
Configure OSPFv3
This section describes the tasks involved in configuring an OSPFv3 routing process. For a device using virtual
routing, you can configure OSPFv3 only for its global virtual router and not for its user-defined virtual router.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPFv3.
Step 3 By default Enable Process 1 is selected. You can enable up to two OSPF process instances.
Step 4 Chose the OSPFv3 role from the drop-down list, and enter a description for it. The options are Internal, ABR, ASBR,
and ABR and ASBR. See About OSPF, on page 849 for descriptions of the OSPFv3 roles.
Step 5 Select Area > Add.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 6 Select General, and configure the following options for each OSPF process:
• Area ID—The area for which routes are to be summarized.
• Cost—The metric or cost for the summary route, which is used during OSPF SPF calculations to determine the
shortest paths to the destination. Valid values range from 0 to 16777215.
• Type—Specifies Normal, NSSA, or Stub. If you select Normal, there are no other parameters to configure. If you
select Stub, you can choose to send summary LSAs in the area. If you select NSSA, you can configure the next
three options:
• Allow Sending summary LSA into this area—Allows the sending of summary LSAs into the area.
• Redistribute imports routes to normal and NSSA area—Allows redistribution to import routes to normal
and not to stubby areas.
• Defaults information originate—Generates a default external route into an OSPFv3 routing domain.
• Metric—Metric used for generating the default route. The default value is 10. Valid metric values range from 0
to 16777214.
• Metric Type—The metric type is the external link type that is associated with the default route that is advertised
into the OSPFv3 routing domain. The available options are 1 for a Type 1 external route or 2 for a Type 2 external
route.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete route summaries.
Step 9 Configure the following route summary options for each OSPF process:
• IPv6 Prefix/Length—The IPv6 prefix. To add a new network object, click Add ( ). See Network Objects, on
page 448 for the procedure for adding networks.
• Cost—The metric or cost for the summary route, which is used during OSPF SPF calculations to determine the
shortest paths to the destination. Valid values range from 0 to 16777215.
• Advertise—Advertises the summary route. Uncheck this check box to suppress routes that fall under the summary
address. By default, this check box is checked.
• Peer RouterID—Choose the IP address of the peer router. To add a new network object, click Add ( ). See
Network Objects, on page 448 for the procedure for adding networks.
• TTL Security—Enables TTL security check. The value for the hop-count is a number from 1 to 254. The default
is 1.
OSPF sends outgoing packets with an IP header Time to Live (TTL) value of 255 and discards incoming packets
that have TTL values less than a configurable threshold. Because each device that forwards an IP packet decrements
the TTL, packets received via a direct (one-hop) connection have a value of 255. Packets that cross two hops have
a value of 254, and so on. The receive threshold is configured in terms of the maximum number of hops that a
packet may have traveled.
• Dead Interval—The time in seconds that hello packets are not seen before a neighbor indicates that the router is
down. The default is four times the hello interval, or 40 seconds. Valid values range from 1 to 65535.
The dead interval is an unsigned integer. The value must be the same for all routers and access servers that are
attached to a common network.
• Hello Interval—The time in seconds between the hello packets sent on an interface. Valid values range from 1
to 65535. The default is 10.
The hello interval is an unsigned integer that is to be advertised in the hello packets. The value must be the same
for all routers and access servers on a specific network. The smaller the hello interval, the faster topological changes
are detected, but the more traffic is sent on the interface.
• Retransmit Interval—The time in seconds between LSA retransmissions for adjacencies that belong to the
interface. The retransmit interval is the expected round-trip delay between any two routers on the attached network.
The value must be greater than the expected round-trip delay, and can range from 1 to 65535. The default is 5.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment message. If
the router receives no acknowledgment, it resends the LSA. Be conservative when setting this value, or needless
retransmission can result. The value should be larger for serial lines and virtual links.
• Transmit Delay—The estimated time in seconds that is required to send an LSA packet on the interface. The
integer value must be greater than zero. Valid values range from 1 to 8192. The default is 1.
LSAs in the update packet have their own ages incremented by this amount before transmission. If the delay is
not added before transmission over a link, the time in which the LSA propagates over the link is not considered.
The value assigned should take into account the transmission and propagation delays for the interface. This setting
has more significance on very low-speed links.
What to do next
Continue with Configure OSPFv3 Redistribution.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF.
Step 3 Select Redistribution, and click Add.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 4 Configure the following redistribution options for each OSPF process:
• Source Protocol—The source protocol from which routes are being redistributed. The supported protocols are
connected, OSPF, static, and BGP. If you choose OSPF, you must enter the Process ID in the Process ID field. If
you choose BCP, you must add the AS number in the AS Number field.
• Metric —Metric value for the routes being distributed. The default value is 10. Valid values range from 0 to 16777214.
When redistributing from one OSPF process to another OSPF process on the same device, the metric will be carried
through from one process to the other if no metric value is specified. When redistributing other processes to an OSPF
process, the default metric is 20 when no metric value is specified.
• Metric Type—The metric type is the external link type that is associated with the default route that is advertised
into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2 for a Type 2 external
route.
• Tag —Tag specifies the 32-bit decimal value attached to each external route that is not used by OSPF itself, but
which may be used to communicate information between ASBRs. If none is specified, then the remote autonomous
system number is used for routes from BGP and EGP. For other protocols, zero is used. Valid values are from 0 to
4294967295.
• Route Map—Checks for filtering the importing of routes from the source routing protocol to the current routing
protocol. If this parameter is not specified, all routes are redistributed. If this parameter is specified, but no route
map tags are listed, no routes are imported. Or you can add a new route map by clicking Add ( ). See Route Maps,
on page 511 for the procedure to add a new route map.
• Process ID—The OSPF process ID, either 1 or 2.
Note The Process ID is enabled the OSPFv3 process is redistributing a route learned by another OSPFv3 process.
What to do next
Continue with Configure OSPFv3 Summary Prefixes, on page 868.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPFv3.
Step 3 Select Summary Prefix > Add.
You can click Edit ( ), or use the right-click menu to cut, copy, past, insert, and delete summary prefixes.
Step 4 Configure the following summary prefix options for each OSPF process:
• IPv6 Prefix/Length—The IPv6 prefix and prefix length label. Select one from the list or click Add ( ) to add a
new network object. See Network Objects, on page 448 for the procedure for adding networks.
• Advertise— Advertises routes that match the specified prefix and mask pair. Uncheck this check box to suppress
routes that match the specified prefix and mask pair.
• (Optional) Tag—A value that you can use as a match value for controlling redistribution through route maps.
What to do next
Continue with Configure OSPFv3 Interfaces, Authentication, and Neighbors, on page 869.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPFv3.
Step 3 Select Interface > Add.
You can click Edit to edit, or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 4 Configure the following interface options for each OSPFv3 process:
• Interface—The interface you are configuring.
• Enable OSPFv3—Enables OSPFv3.
• OSPF Process—Choose 1 or 2.
• Area—The area ID for this process.
• Instance —Specifies the area instance ID to be assigned to the interface. An interface can have only one OSPFv3
area. You can use the same area on multiple interfaces, and each interface can use a different area instance ID.
Step 5 Select Properties, and configuring the following options for each OSPFv3 process:
• Filter Outgoing Link Status Advertisements—Filters outgoing LSAs to an OSPFv3 interface. All outgoing
LSAs are flooded to the interface by default.
• Disable MTU mismatch detection—Disables the OSPF MTU mismatch detection when DBD packets are received.
OSPF MTU mismatch detection is enabled by default.
• Flood Reduction—Changes normal LSAs into Do Not Age LSAs, so that they don't get flooded every 3600
seconds across areas.
OSPF LSAs are refreshed every 3600 seconds. In large OSPF networks, this can lead to large amounts of
unnecessary LSA flooding from area to area.
• Point-to-Point Network—Lets you transmit OSPF routes over VPN tunnels. When an interface is configured as
point-to-point, non-broadcast, the following restrictions apply:
• You can define only one neighbor for the interface.
• You need to manually configure the neighbor.
• You need to define a static route pointing to the crypto endpoint.
• If OSPF over a tunnel is running on the interface, regular OSPF with an upstream router cannot be run on
the same interface.
• You should bind the crypto map to the interface before specifying the OSPF neighbor to ensure that the OSPF
updates are passed through the VPN tunnel. If you bind the crypto map to the interface after specifying the
OSPF neighbor, use the clear local-host all command to clear OSPF connections so that the OSPF adjacencies
can be established over the VPN tunnel.
• Broadcast— Specifies that the interface is a broadcast interface. By default, this check box is checked for Ethernet
interfaces. Uncheck this check box to designate the interface as a point-to-point, nonbroadcast interface. Specifying
an interface as point-to-point, nonbroadcast lets you transmit OSPF routes over VPN tunnels.
• Cost—Specifies the cost of sending a packet on the interface. Valid values for this setting range from 0 to 255.
The default value is 1. Entering 0 for this setting makes the router ineligible to become the designated router or
backup designated router. This setting does not apply to interfaces that are configured as point-to-point, nonbroadcast
interfaces.
When two routers connect to a network, both attempt to become the designated router. The device with the higher
router priority becomes the designated router. If there is a tie, the router with the higher router ID becomes the
designated router.
• Priority—Determines the designated router for a network. Valid values range from 0 to 255.
• Dead Interval—Time period in seconds for which hello packets must not be seen before neighbors indicate that
the router is down. The value must be the same for all nodes on the network and can range from 1 to 65535.
• Poll Interval— Time period in seconds between OSPF packets that the router will send before adjacency is
established with a neighbor. Once the routing device detects an active neighbor, the hello packet interval changes
from the time specified in the poll interval to the time specified in the hello interval. Valid values range from 1 to
65535 seconds.
• Retransmit Interval—Time in seconds between LSA retransmissions for adjacencies that belong to the interface.
The time must be greater than the expected round-trip delay between any two routers on the attached network.
Valid values range from 1 to 65535 seconds. The default is 5 seconds.
• Transmit Delay—Estimated time in seconds to send a link-state update packet on the interface. Valid values
range from 1 to 65535 seconds. The default is 1 second.
• Type—Type of authentication. The available options are Area, Interface, and None. The None option indicates
that no authentication is used.
• Security Parameters Index— A number from 256 to 4294967295. Configure this if you chose Interface as the
type.
• Authentication—Type of authentication algorithm. Supported values are SHA-1 and MD5. Configure this if you
chose Interface as the type.
• Authentication Key— When MD5 authentication is used, the key must be 32 hexadecimal digits (16 bytes) long.
When SHA-1 authentication is used, the key must be 40 hexadecimal digits (20 bytes) long.
• Encrypt Authentication Key—Enables encryption of the authentication key.
• Include Encryption— Enables encryption.
• Encryption Algorithm—Type of encryption algorithm. Supported value is DES. The NULL entry indicates no
encryption. Configure this if you chose Include Encryption.
• Encryption Key—Enter the encryption key. Configure this if you chose Include Encryption.
• Encrypt Key—Enables the key to be encrypted.
Configuring the NSF graceful-restart feature involves two steps; configuring capabilities and configuring
a device as NSF-capable or NSF-aware. A NSF-capable device can indicate its own restart activities to
neighbors and a NSF-aware device can help a restarting neighbor.
A device can be configured as NSF-capable or NSF-aware, depending on some conditions:
• A device can be configured as NSF-aware irrespective of the mode in which it is.
• A device has to be in either Failover or Spanned Etherchannel (L2) cluster mode to be configured
as NSF-capable.
• For a device to be either NSF-aware or NSF-capable, it should be configured with the capability of
handling opaque Link State Advertisements (LSAs)/ Link Local Signaling (LLS) block as required.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPFv3 > Advanced.
Step 3 For Router ID, choose Automatic or IP address. If you choose IP address, enter the IP address in the IP Address
field.
Step 4 Check the Ignore LSA MOSPF check box if you want to suppress syslog messages when the route receives unsupported
LSA Type 6 multicast OSPF (MOSPF) packets.
Step 5 Select General, and configure the following:
• Adjacency Changes—Defines the adjacency changes that cause syslog messages to be sent.
By default, a syslog message is generated when an OSPF neighbor goes up or down. You can configure the router
to send a syslog message when an OSPF neighbor goes down and also a syslog for each state.
• Adjacency Changes—Causes the Firepower Threat Defense device to send a syslog message whenever an
OSPF neighbor goes up or down. This setting is checked by default.
• Include Details—Causes the Firepower Threat Defense device to send a syslog message whenever any state
change occurs, not just when a neighbor goes up or down. This setting is unchecked by default.
• Administrative Route Distances—Allows you to modify the settings that were used to configure administrative
route distances for inter-area, intra-area, and external IPv6 routes. The administrative route distance is an integer
from 1 to 254. The default is 110.
• Default Information Originate—Check the Enable check box to generate a default external route into an OSPFv3
routing domain and configure the following options:
• Always Advertise—Will always advertise the default route whether or not one exists.
• Metric—Metric used for generating the default route. Valid metric values range from 0 to 16777214. The
default value is 10.
• Metric Type—The external link type that is associated with the default route that is advertised into the
OSPFv3 routing domain. Valid values are 1 (Type 1 external route) and 2 (Type 2 external route). The default
is Type 2 external route.
• Route Map—Choose the routing process that generates the default route if the route map is satisfied or click
Add ( ) to add a new one. See Route Maps, on page 511 to add a new route map.
Step 7 Select Passive Interface, select the interfaces on which you want to enable passive OSPFv3 routing from the Available
Interfaces list, and click Add to move them to the Selected Interfaces list.
Passive routing assists in controlling the advertisement of OSPFv3 routing information and disables the sending and
receiving of OSPFv3 routing updates on an interface.
• SPF Throttle—Specifies the delay in milliseconds to receive a change to the SPF calculation. The default value
is 5000 milliseconds. The minimum specifies the delay in milliseconds between the first and second SPF calculations.
The default value is 10000 milliseconds. The maximum specifies the maximum wait time in milliseconds for SPF
calculations. The default value is 10000 milliseconds.
Note For SPF throttling, if the minimum or maximum time is less than the first occurrence value, then OSPFv3
automatically corrects to the first occurrence value. Similarly, if the maximum delay specified is less
than the minimum delay, then OSPFv3 automatically corrects to the minimum delay value.
Step 13 Check the Enable graceful-restart (Use when Spanned Cluster or Failover Configured) and enter the graceful-restart
interval in seconds. The range is 1-1800. The default value is 120 seconds. For a restart interval below 30 seconds,
graceful restart will be terminated.
Step 14 Click OK to save the graceful restart configuration.
About BGP
BGP is an inter and intra autonomous system routing protocol. An autonomous system is a network or group
of networks under a common administration and with common routing policies. BGP is used to exchange
routing information for the Internet and is the protocol used between Internet service providers (ISP).
Note AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking
that the AS number of the local system does not appear in the AS path. By default, EBGP advertises the
learned routes to the same peer to prevent additional CPU cycles on the ASA in performing loop checks and
to avoid delays in the existing outgoing update tasks.
Routes learned via BGP have properties that are used to determine the best route to a destination, when multiple
paths exist to a particular destination. These properties are referred to as BGP attributes and are used in the
route selection process:
• Weight—This is a Cisco-defined attribute that is local to a router. The weight attribute is not advertised
to neighboring routers. If the router learns about more than one route to the same destination, the route
with the highest weight is preferred.
• Local preference—The local preference attribute is used to select an exit point from the local AS. Unlike
the weight attribute, the local preference attribute is propagated throughout the local AS. If there are
multiple exit points from the AS, the exit point with the highest local preference attribute is used as an
exit point for a specific route.
• Multi-exit discriminator—The multi-exit discriminator (MED) or metric attribute is used as a suggestion
to an external AS regarding the preferred route into the AS that is advertising the metric. It is referred
to as a suggestion because the external AS that is receiving the MEDs may also be using other BGP
attributes for route selection. The route with the lower MED metric is preferred.
• Origin—The origin attribute indicates how BGP learned about a particular route. The origin attribute
can have one of three possible values and is used in route selection.
• IGP—The route is interior to the originating AS. This value is set when the network router
configuration command is used to inject the route into BGP.
• EGP—The route is learned via the Exterior Border Gateway Protocol (EBGP).
• Incomplete—The origin of the route is unknown or learned in some other way. An origin of
incomplete occurs when a route is redistributed into BGP.
• AS_path—When a route advertisement passes through an autonomous system, the AS number is added
to an ordered list of AS numbers that the route advertisement has traversed. Only the route with the
shortest AS_path list is installed in the IP routing table.
• Next hop—The EBGP next-hop attribute is the IP address that is used to reach the advertising router.
For EBGP peers, the next-hop address is the IP address of the connection between the peers. For IBGP,
the EBGP next-hop address is carried into the local AS.
• Community—The community attribute provides a way of grouping destinations, called communities, to
which routing decisions (such as acceptance, preference, and redistribution) can be applied. Route maps
are used to set the community attribute. The predefined community attributes are as follows:
• no-export—Do not advertise this route to EBGP peers.
• no-advertise—Do not advertise this route to any peer.
• internet—Advertise this route to the Internet community; all routers in the network belong to it.
propagates the path to its neighbors. BGP uses the following criteria, in the order presented, to select a path
for a destination:
• If the path specifies a next hop that is inaccessible, drop the update.
• Prefer the path with the largest weight.
• If the weights are the same, prefer the path with the largest local preference.
• If the local preferences are the same, prefer the path that was originated by BGP running on this router.
• If no route was originated, prefer the route that has the shortest AS_path.
• If all paths have the same AS_path length, prefer the path with the lowest origin type (where IGP is lower
than EGP, and EGP is lower than incomplete).
• If the origin codes are the same, prefer the path with the lowest MED attribute.
• If the paths have the same MED, prefer the external path over the internal path.
• If the paths are still the same, prefer the path through the closest IGP neighbor.
• Determine if multiple paths require installation in the routing table for BGP Multipath, on page 877.
• If both paths are external, prefer the path that was received first (the oldest one).
• Prefer the path with the lowest IP address, as specified by the BGP router ID.
• If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list
length.
• Prefer the path that comes from the lowest neighbor address.
BGP Multipath
BGP Multipath allows installation into the IP routing table of multiple equal-cost BGP paths to the same
destination prefix. Traffic to the destination prefix is then shared across all installed paths.
These paths are installed in the table together with the best path for load-sharing. BGP Multipath does not
affect best-path selection. For example, a router still designates one of the paths as the best path, according
to the algorithm, and advertises this best path to its BGP peers.
In order to be candidates for multipath, paths to the same destination need to have these characteristics equal
to the best-path characteristics:
• Weight
• Local preference
• AS-PATH length
• Origin code
• Multi Exit Discriminator (MED)
• One of these:
• Neighboring AS or sub-AS (before the addition of the BGP Multipaths)
• AS-PATH (after the addition of the BGP Multipaths)
These are the additional requirements for internal BGP (iBGP) multipath candidates:
• The path should be learned from an internal neighbor (iBGP).
• The IGP metric to the BGP next hop should be equal to the best-path IGP metric, unless the router is
configured for unequal-cost iBGP multipath.
BGP inserts up to n most recently received paths from multipath candidates into the IP routing table, where
n is the number of routes to install to the routing table, as specified when you configure BGP Multipath. The
default value, when multipath is disabled, is 1.
For unequal-cost load balancing, you can also use BGP Link Bandwidth.
Note The equivalent next-hop-self is performed on the best path that is selected among eBGP multipaths before it
is forwarded to internal peers.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
IPv6 Guidelines
Supports IPv6. Graceful restart is not supported for IPv6 address family.
Additional Guidelines
ASA does not add route entry for the IP address received over PPPoE in the CP route table. BGP always looks
into CP route table for initiating the TCP session, hence BGP does not form TCP session.
Thus, BGP over PPPoE is not supported.
Configure BGP
To configure BGP, see the following topics:
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing.
Step 3 (For a virtual-router-aware device) Under General Settings, click BGP.
Step 4 Select the Enable BGP check box to enable the BGP routing process.
Step 5 In the AS Number field, enter the autonomous system (AS) number for the BGP process. The AS number internally
includes multiple autonomous numbers. The AS number can be from 1 to4294967295 or from 1.0 to 65535.65535.
The AS number is a uniquely assigned value, that identifies each network on the Internet.
Step 6 (Optional) Edit the various BGP settings, starting with General. The defaults for these settings are appropriate in most
cases, but you can adjust them to fit the needs of your network. Click Edit (pencil) to edit the settings in the group :
a) In the Router ID drop-down list, select Automatic or Manual from the drop-down list. If you choose Automatic,
the highest-level IP address on the Firepower Threat Defense device is used as the router ID. To use a fixed router
ID, choose Manual and enter an IPv4 address in theIP Address field. The default value is Automatic. For a virtual
router-aware device, you can override the router ID settings in the Virtual Routers > BGP page.
b) Enter the Number of AS numbers in AS_PATH attribute. An AS _PATH attribute is a sequence of intermediate
AS numbers between source and destination routers that form a directed route for packets to travel. Valid values
are between 1 and 254. The default value is None.
c) Check the Log Neighbor Changes check box to enable logging of BGP neighbor changes (up or down) and resets.
This helps in troubleshooting network connectivity problems and measuring network stability. This is enabled by
default.
d) Check the Use TCP Path MTU Discovery check box to use the Path MTU determining technique to determine
the maximum transmission unit (MTU) size on the network path between two IP hosts. This avoids IP fragmentation.
This is enabled by default.
e) Check the Reset session upon Failover check box to reset the external BGP session immediately upon link failure.
This is enabled by default.
f) Check the Enforce that the first AS is peer’s AS for EBGP routes check box to discard incoming updates received
from external BGP peers that do not list their AS number as the first segment in the AS_PATH attribute. This
prevents a mis-configured or unauthorized peer from misdirecting traffic by advertising a route as if it was sourced
from another autonomous system. This is enabled by default.
g) Check the Use dot notation for AS number check box to split the full binary 4-byte AS number into two words
of 16 bits each, separated by a dot. AS numbers from 0-65553 are represented as decimal numbers and AS numbers
larger than 65535 are represented using the dot notation. This is disabled by default.
h) Click OK.
Step 7 (Optional) Edit the Best Path Selection section:
a) Enter a value for Default Local Preference between 0 and 4294967295.The default value is 100. Higher values
indicate higher preference. This preference is sent to all routers and access servers in the local autonomous system.
b) Check the Allow comparing MED from different neighbors check box to allow the comparison of Multi Exit
Discriminator (MED) for paths from neighbors in different autonomous systems. This is disabled by default.
c) Check the Compare Router ID for identical EBGP paths check box to compare similar paths received from
external BGP peers during the best path selection process and switch the best path to the route with the lowest
router ID. This is disabled by default.
d) Check the Pick the best MED path among paths advertised from the neighboring AS check box to enable
MED comparison among paths learned from confederation peers. The comparison between MEDs is made only if
no external autonomous systems are there in the path. This is disabled by default.
e) Check the Treat missing MED as the least preferred one check box to consider the missing MED attribute as
having a value of infinity, making the path the least desirable; therefore, a path with a missing MED is least preferred.
This is disabled by default.
f) Click OK.
Step 8 (Optional) Edit the Neighbor Timers section:
a) Enter the time interval for which the BGP neighbor remains active after not sending a keepalive message in the
Keepalive interval field. At the end of this keepalive interval, the BGP peer is declared dead, if no messages are
sent. The default value is 60 seconds.
b) Enter the time interval for which the BGP neighbor remains active while a BGP connection is being initiated and
configured in the Hold time field. The default value is 180 seconds.
c) (Optional) Enter the minimum time interval for which the BGP neighbor remains active while a BGP connection
is being initiated and configured in the Min Hold time field. Specify a value from 0 to 65535.
d) Click OK.
a) Check the Enable Graceful Restartcheckbox to enable FTD peers to avoid a routing flap following a switchover.
b) Specify the time duration that FTD peers will wait to delete stale routes before a BGP open message is received in
the Restart Time field. The default value is 120 seconds. Valid values are between 1 and 3600 seconds.
c) Enter the time duration that the FTD will wait before deleting stale routes after an end of record (EOR) message
is received from the restarting FTD in theStalepath Time field. The default value is 360 seconds. Valid values are
between 1 and 3600 seconds.
d) Click OK.
Step 10 Click Save.
Step 11 To view the BGP basic settings, from the virtual routers drop-down, select the desired router, and then click BGP.
This page displays the basic settings that are configured in the Settings page. You can edit the router ID settings on
this page.
Step 12 To edit the router ID settings, modify the IP address in the IP Address fields. The modified value overrides the router
ID settings that were configured in the BGP page under General Settings.
b) In the Routes and Synchronization section, update the following as required, and click OK :
• (Optional) Generate Default Routes— Select this to configure, a BGP routing process to distribute a default
route (network 0.0.0.0).
• (Optional) Summarize subnet routes into network-level routes— Select this to configure automatic
summarization of subnet routes into network-level routes. This checkbox is applicable only to IPv4 settings.
• (Optional) Advertise inactive routes— Select this to advertise routes that are not installed in the routing
information base (RIB).
• (Optional) Synchronise between BGP and IGP system— Select this to enable synchronization between BGP
and your Interior Gateway Protocol (IGP) system. Usually, a BGP speaker does not advertise a route to an
external neighbor unless that route is local or exists in the IGP. This feature allows routers and access servers
within an autonomous system to have the route before BGP makes it available to other autonomous systems.
• (Optional) Redistribute IBGP into IGP— Select this to configure iBGP redistribution into an interior gateway
protocol (IGP), such as OSPF.
c) In the Administrative Route Distances section, update the following as required, and click OK :
• External — Enter the administrative distance for external BGP routes. Routes are external when learned from
an external autonomous system. The range of values for this argument are from 1 to 255. The default value is
20.
• Internal — Enter administrative distance for internal BGP routes. Routes are internal when learned from peer
in the local autonomous system. The range of values for this argument are from 1 to 255. The default value is
200.
• Local — Enter administrative distance for local BGP routes. Local routes are those networks listed with a
network router show command, often as back doors, for the router or for the networks that is being redistributed
from another process. The range of values for this argument are from 1 to 255. The default value is 200.
d) In the Next Hop section, optionally select the Enable address tracking checkbox to enable BGP next hop address
tracking and enter the Delay Interval between checks on updated next-hop routes installed in the routing table. Click
OK.
Note The Next Hop section is applicable only to IPv4 settings.
e) In the Forward Packets over Multiple Paths section, update the following as required and click OK:
• (Optional) Number of Paths — Specify the maximum number of Border Gateway Protocol routes that can be
installed in a routing table. The range of values are from 1 to 8. The default value is 1.
• (Optional) IBGP Number of Paths — Specify the maximum number of parallel internal Border Gateway
Protocol (iBGP) routes that can be installed in a routing table. The range of values are from 1 to 8. The default
value is 1.
Step 8 Enter the autonomous system to which the BGP neighbor belongs, in the Remote AS field.
Step 9 Select the Enabled address check box to enable communication with this BGP neighbor. Further neighbor settings
will be configured only if the Enabled address check box is selected.
Step 10 (Optional) Select the Shutdown administratively check box to disable a neighbor or peer group.
Step 11 (Optional) Select the Configure graceful restart check box to enable configuration of the BGP graceful restart capability
for this neighbor. After selecting this option, you must use the Graceful Restart (failover / spanned mode) option to
specify whether graceful restart should be enabled or disabled for this neighbor.
Note The graceful restart fields are only applicable to IPv4 settings.
Step 12 (Optional) Select the BFD Fallover check box to enable configuration of the BFD support for BGP. This selection
registers the BGP neighbor to receive forwarding path detection failure messages from BFD.
Step 13 (Optional) Enter a Description for the BGP neighbor.
Step 14 (Optional) In Filtering Routes, use access lists, route maps, prefix lists and AS path filters as required, to distribute
BGP Neighbor information. Update the following sections:
a) Enter or Select the appropriate incoming or outgoing Access List to distribute BGP neighbor information.
Note Access Lists are only applicable to IPv4 settings.
b) Enter or Select the appropriate incoming or outgoing Route Maps to apply a route map to incoming or outgoing
routes.
c) Enter or Select the appropriate incoming or outgoing Prefix List to distribute BGP neighbor information.
d) Enter or Select the appropriate incoming or outgoing AS path filter to distribute BGP neighbor information.
e) Select the Limit the number of prefixes allowed from the neighborto control the number of prefixes that can be
received from a neighbor.
• Enter the maximum number of prefixes allowed from a specific neighbor in the Maximum Prefixes field.
• Enter the percentage (of maximum) at which the router starts to generate a warning message in the Threshold
Level field. Valid values are integers between 1 and 100. The default value is 75.
f) Select theControl prefixes received from the peer check box to specify additional controls for the prefixes received
from a peer. Do one of the following
• Select Terminate peering when prefix limit is exceeded to stop the BGP neighbor when the prefix limit is
reached. Specify the interval after which the BGP neighbor will restart in the Restart interval field.
• Select Give only warning message when prefix limit is exceeded to generate a log message when the
maximum prefix limit is exceeded. Here, the BGP neighbor will not be terminated.
g) Click OK.
Step 15 (Optional) In Routes, specify miscellaneous Neighbor route parameter. Proceed to update the following:
a) Enter the minimum interval (in seconds) between the sending of BGP routing updates in the Advertisment Interval
field. Valid values are between 1 and 600.
b) Select the Remove private AS numbers from outbound routing updates to exclude the private AS numbers
from being advertised on outbound routes.
c) Select the Generate default routes checkbox to allow the local router to send the default route 0.0.0.0 to a neighbor
to use as a default route. Enter or Select the route map that allows the route 0.0.0.0 to be injected conditionally in
the Route map field.
d) To add conditionally advertised routes, click Add Row +. In the Add Advertised Route dialog box, do the following:
1. Add or select a route map in the Advertise Map field, that will be advertised if the conditions of the exist map
or the non-exist map are met.
2. Select Exist Map and choose a route map from the Route Map Object Selector. This route map is compared
with the routes in the BGP table, to determine whether the advertise map route is advertised.
3. Select Non-Exist Map and choose a route map from the Route Map Object Selector. This route map is compared
with the routes in the BGP table, to determine whether the advertise map route is advertised.
4. Click OK.
Step 16 In Timers, select the Set Timers for the BGP Peer check box to set the keepalive frequency, hold time and minimum
hold time
• Keepalive Interval—Enter the frequency (in seconds) with which the FTD device sends keepalive messages to
the neighbor. Valid values are between 0 and 65535. The default value is 60 seconds.
• Hold time—Enter the interval (in seconds) after not receiving a keepalive message that theFTD device declares
a peer dead. Valid values are between 0 and 65535. The default value is 180 seconds.
• Min hold time—(Optional) Enter the minimum interval (in seconds) after not receiving a keepalive message that
the FTD device declares a peer dead. Valid values are between 0 and 65535. The default value is 0 seconds.
b) (Optional) Select the Send Communty attribute to this neighbor check box to specify that communities attributes
should be sent to the BGP neighbor
c) (Optional) Select the Use FTD as next hop for this neighbor check box to configure the router as the next-hop
for a BGP speaking neighbor or peer group.
d) Select the Disable Connection Verification checkbox to disable the connection verification process for eBGP
peering sessions that are reachable by a single hop but are configured on a loopback interface or otherwise configured
with a non-directly connected IP address. When deselected (default), a BGP routing process will verify the connection
of single-hop eBGP peering session (TTL=254) to determine if the eBGP peer is directly connected to the same
network segment by default. If the peer is not directly connected to same network segment, connection verification
will prevent the peering session from being established.
e) Select Allow connections with neighbor that is not directly connected to accept and attempt BGP connections
to external peers residing on networks that are not directly connected. (Optional) Enter the time-to-live in the TTL
hops field. Valid values are between 1 and 255. Alternately, select Limited number of TTL hops to neighbor,
to secure a BGP peering session. Enter the maximum number of hops that separate eBGP peers in the TTL hops
field. Valid values are between 1 and 254.
f) (Optional) Select the Use TCP MTU path discovery check box to enable a TCP transport session for a BGP
session.
g) Choose the TCP connection mode from the TCP Transport Modedrop-down list. Options are Default, Active, or
Passive.
h) (Optional) Enter a Weight for the BGP neighbor connection.
i) Select the BGP Version that the FTD device will accept from the drop-down list. The version can be set to 4-Only
to force the software to use only Version 4 with the specified neighbor. The default is to use Version 4 and
dynamically negotiate down to Version 2 if requested.
Step 18 Update Migration, only if AS migration is considered.
Note The AS migration customization should be removed after transition has been completed.
a) (Optional) Select the Customize the AS number for routes received from the neighbor check box to customize
the AS_PATH attribute for routes received from an eBGP neighbor.
b) Enter the local autonomous system number in the Local AS number field. Valid values are any valid autonomous
system number from 1 to 4294967295 or 1.0 to65535.65535.
c) (Optional) Select the Do not prepend local AS number to routes received from neighbor check box to prevent
the local AS number from being prepended to any routes received from eBGP peer.
d) (Optional) Select the Replace real AS number with local AS number in routes received from neighbor check
box to replace the real autonomous system number with the local autonomous system number in the eBGP updates.
The autonomous system number from the local BGP routing process is not prepended.
e) (Optional) Select the Accept either real AS number or local AS number in routesreceived from neighbor
check box to configure the eBGP neighbor to establish a peering session using the real autonomous system number
(from the local BGP routing process) or by using the local autonomous system number.
Step 19 Click OK.
Step 20 Click Save.
routing (CIDR) principle to combine contiguous networks into one classless set of IP addresses that can be
summarized in routing tables. As a result fewer routes need to be advertised. Use the Add/Edit Aggregate
Address dialog box to define the aggregation of specific routes into one route.
What to do next
• For BGPv4 settings, proceed to Configure BGPv4 Filtering Settings, on page 886
• For BGPv6 settings, proceed to Configure BGP Network Settings, on page 887
b) Process ID— Enter the identifier for the selected source protocol. Applies to the OSPF protocol. For devices using
virtual routing, this drop-down lists the process ID assigned for the virtual router for which you are configuring the
BGP settings.
c) Metric— (Optional) Enter a metric for the redistributed route.
d) Route Map— Enter or select a route map that should be examined to filter the networks to be redistributed. If not
specified, all networks are redistributed.
e) Match— The conditions used for redistributing routes from one routing protocol to another. The routes must match
the selected condition to be redistributed. You can choose one or more of the following match conditions. These
options are enabled only when OSPF is chosen as the Source Protocol.
• Internal
• External 1
• External 2
• NSSA External 1
• NSSA External 2
f) Click OK.
b) Exist Map— Enter or select the route map containing the prefixes that the BGP speaker will track.
c) Injected routes will inherit the attributes of the aggregate route— Select this to configure the injected route to
inherit attributes of the aggregate route.
d) Click OK.
Step 6 Click Save.
About RIP
The Routing Information Protocol, or RIP, as it is more commonly called, is one of the most enduring of all
routing protocols. RIP has four basic components: routing update process, RIP routing metrics, routing stability,
and routing timers. Devices that support RIP send routing-update messages at regular intervals and when the
network topology changes. These RIP packets include information about the networks that the devices can
reach, as well as the number of routers or gateways that a packet must travel through to reach the destination
address. RIP generates more traffic than OSPF, but is easier to configure.
RIP is a distance-vector routing protocol that uses hop count as the metric for path selection. When RIP is
enabled on an interface, the interface exchanges RIP broadcasts with neighboring devices to dynamically
learn about and advertise routes.
The Firepower Threat Defense device supports both RIP Version 1 and RIP Version 2. RIP Version 1 does
not send the subnet mask with the routing update. RIP Version 2 sends the subnet mask with the routing update
and supports variable-length subnet masks. Additionally, RIP Version 2 supports neighbor authentication
when routing updates are exchanged. This authentication ensures that the Firepower Threat Defense device
receives reliable routing information from a trusted source.
RIP has advantages over static routes because the initial configuration is simple, and you do not need to update
the configuration when the topology changes. The disadvantage to RIP is that there is more network and
processing overhead than in static routing.
routers maintain only the best route (the route with the lowest metric value) to a destination. After updating
its routing table, the router immediately begins transmitting routing updates to inform other network routers
of the change. These updates are sent independently of the regularly scheduled updates that RIP routers send.
RIP Timers
RIP uses numerous timers to regulate its performance. These include a routing-update timer, a route-timeout
timer, and a route-flush timer. The routing-update timer clocks the interval between periodic routing updates.
Generally, it is set to 30 seconds, with a small random amount of time added whenever the timer is reset. This
is done to help prevent congestion, which could result from all routers simultaneously attempting to update
their neighbors. Each routing table entry has a route-timeout timer associated with it. When the route-timeout
timer expires, the route is marked invalid but is retained in the table until the route-flush timer expires.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
Additional Guidelines
The following information applies to RIP Version 2 only:
• If using neighbor authentication, the authentication key and key ID must be the same on all neighbor
devices that provide RIP Version 2 updates to the interface.
• With RIP Version 2, the Firepower Threat Defense device transmits and receives default route updates
using the multicast address 224.0.0.9. In passive mode, it receives route updates at that address.
• When RIP Version 2 is configured on an interface, the multicast address 224.0.0.9 is registered on that
interface. When a RIP Version 2 configuration is removed from an interface, that multicast address is
unregistered.
Limitations
• The Firepower Threat Defense device cannot pass RIP updates between interfaces.
• RIP Version 1 does not support variable-length subnet masks.
• RIP has a maximum hop count of 15. A route with a hop count greater than 15 is considered unreachable.
• RIP convergence is relatively slow compared to other routing protocols.
• You can only enable a single RIP process on the Firepower Threat Defense device.
Configure RIP
RIP is a distance-vector routing protocol that uses hop count as the metric for path selection.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing.
Step 3 Select RIP from the table of contents.
Step 4 Select the Enable RIP check box to configure the RIP settings.
Step 5 Select the RIP versions for sending and receiving RIP updates from the RIP Version drop-down list.
Step 6 (Optional) Select the Generate Default Route check box to generate a default route for distribution, based on the route
map that you specify.
a) Specify a route map name to use for generating default routes, in the Route Map field.
The default route 0.0.0.0/0 is generated for distribution over a certain interface , when the route map, specified in
the Route Map field, is present.
Step 7 When Send and Receive Version 2 is the chosen RIP Version, the Enable Auto Summary option is available. When
the Enable Auto Summary checkbox is checked, automatic route summarization is enabled. Disable automatic
summarization if you must perform routing between disconnected subnets. When automatic summarization is disabled,
subnets are advertised.
Note RIP Version 1 always uses automatic summarization—you cannot disable it.
Step 8 Click Networks. Define one or more networks for RIP routing. Enter IP address(es), or enter or select the desired
Network/Hosts objects. There is no limit to the number of networks you can add to the security appliance configuration.
Any interface that belongs to a network defined by this command, will participate in the RIP routing process. The RIP
routing updates will be sent and received only through interfaces on the specified networks. Also, if the network of an
interface is not specified, the interface will not be advertised in any RIP updates.
Note RIP only supports IPv4 objects.
Step 9 (Optional) Click Passive Interface. Use this option to specify passive interfaces on the appliance, and by extension
the active interfaces. The device listens for RIP routing broadcasts on passive interfaces, using that information to
populate its routing tables, but does not broadcast routing updates on passive interfaces. Interfaces that are not designated
as passive, receive and send updates.
Step 10 Click Redistribution to manage redistribution routes. These are the routes that are being redistributed from other
routing processes into the RIP routing process.
a) Click Add to specify redistribution routes.
b) Select the routing protocol to redistribute into the RIP routing process, in the Protocol drop-down list.
Note For the OSPF protocol, specify a process ID. Similarly, specify an AS path for BGP. When you choose
the Connected option in the Protocol drop-down list, you can redistribute, directly connected networks
into the RIP routing process.
c) (Optional) If you are redistributing OSPF routes into the RIP routing process, you can select specific types of OSPF
routes to redistribute in the Match drop-down list . Ctrl-click to select multiple types:
• Internal – Routes internal to the autonomous system (AS) are redistributed.
• External 1 – Type 1 routes external to the AS are redistributed.
• External 2 – Type 2 routes external to the AS are redistributed.
• NSSA External 1 – Type 1 routes external to a not-so-stubby area (NSSA) are redistributed.
• NSSA External 2 – Type 2 routes external to an NSSA are redistributed
d) Select the RIP metric type to apply to the redistributed routes in the Metric drop-down list. The two choices are:
• Transparent – Use the current route metric
• Specified Value – Assign a specific metric value. Enter a specific value from 0-16, in the Metric Value field.
• None – No metric is specified. Do not use any metric value, to apply to redistributed routes.
e) (Optional) Enter the name of a route map that must be satisfied, in the Route Map field before the route can be
redistributed into the RIP routing process. Routes are redistributed only if IP address matches an allow statement
in the route map address list.
f) Click OK.
Step 11 (Optional) Click Filtering to manage filters for the RIP policy. In this section, filters are used to prevent routing updates
through an interface, control the advertising of routes in routing updates, control the processing of routing updates and
filtering sources of routing updates.
a) Click Add to add RIP filters.
b) Select the type of traffic to be filtered - Inbound or Outbound in the Traffic Direction field.
Note If traffic direction is inbound, you can only define an Interface filter.
c) Specify whether the filter is based on an Interface or a Route, by selecting appropriate in the Filter On field. If you
select Interface, enter or Select the name of the interface on which routing updates are to be filtered. If you select
Route, choose the route type:
• Static – Only static routes are filtered.
• Connected – Only connected routes are filtered.
• OSPF – Only OSPFv2 routes discovered by the specified OSPF process are filtered. Enter the Process ID of
the OSPF process to be filtered.
• BGP – Only BGPv4 routes discovered by the specified BGP process are filtered. Enter the AS path of the
BGP process to be filtered.
d) In the Access List field, enter or select the name of one or more access control lists (ACLs) that define the networks
to be allowed or removed from RIP route advertisements.
e) Click OK.
Step 12 (Optional) Click Broadcast to add or edit interface configurations. Using Broadcastf, you can override the global RIP
versions to send or receive per interface. You can also define the authentication parameters per interface if you want
to implement authentication to ensure valid RIP updates.
a) Click Add to add interface configurations.
b) Enter or Select an interface defined on this appliance in the Interface field.
c) In the Send option, select the appropriate boxes to specify sending updates using the RIP Version 1, Version 2,
or both. These options let you override, for the specified interface, the global Send versions specified .
d) In the Receive option, select the appropriate boxes to specify accepting updates using the RIP Version 1, Version
2, or both. These options let you override, for the specified interface, the global Receive versions specified .
e) Select the Authentication used on this interface for RIP broadcasts.
• None – No authentication
• MD5 – Employ MD5
• Clear Text – Employ clear-text authentication
If you choose MD5 or Clear Text, you must also provide the following authentication parameters.
• Key ID – The ID of the authentication key. Valid values are from 0 to 255.
• Key – The key used by the chosen authentication method. Can contain up to 16 characters
• Confirm – Enter the authentication key again, to confirm
f) Click OK.
Note The UDP and non-UDP transports are both supported for multicast routing. However, the non-UDP transport
has no FastPath optimization.
IGMP Protocol
IP hosts use the Internet Group Management Protocol (IGMP) to report their group memberships to
directly-connected multicast routers. IGMP is used to dynamically register individual hosts in a multicast
group on a particular LAN. Hosts identify group memberships by sending IGMP messages to their local
multicast router. Under IGMP, routers listen to IGMP messages and periodically send out queries to discover
which groups are active or inactive on a particular subnet.
IGMP uses group addresses (Class D IP address) as group identifiers. Host group address can be in the range
of 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is never assigned to any group. The address 224.0.0.1
is assigned to all systems on a subnet. The address 224.0.0.2 is assigned to all routers on a subnet.
Note When you enable multicast routing on the Firepower Threat Defense device, IGMP Version 2 is automatically
enabled on all interfaces.
Note If the Firepower Threat Defense device is the PIM RP, use the untranslated outside address of the Firepower
Threat Defense device as the RP address.
send multicast traffic to the RP. If there is only one router per segment that forwards multicast traffic, there
will be no loops. The DF is chosen using the following mechanism:
• The router with the lowest metric to the RP is the DF.
• If the metric is equal, then the router with the highest IP address becomes the DF.
Note The Firepower Threat Defense device does not act as a C-RP, even though the
C-RP is a mandatory requirement for BSR traffic. Only routers can act as a C-RP.
So, for BSR testing functionality, you must add routers to the topology.
• BSR Election Mechanism — Each C-BSR originates Bootstrap messages (BSMs) that contain a BSR
Priority field. Routers within the domain flood the BSMs throughout the domain. A C-BSR that hears
about a higher-priority C-BSR than itself suppresses its sending of further BSMs for some period of time.
The single remaining C-BSR becomes the elected BSR, and its BSMs inform all the other routers in the
domain that it is the elected BSR.
Multicast Addresses
Multicast addresses specify an arbitrary group of IP hosts that have joined the group and want to receive traffic
sent to this group.
Clustering
Multicast routing supports clustering. In Spanned EtherChannel clustering, the control unit sends all multicast
routing packets and data packets until fast-path forwarding is established. After fast-path forwarding is
established, data units may forward multicast data packets. All data flows are full flows. Stub forwarding
flows are also supported. Because only one unit receives multicast packets in Spanned EtherChannel clustering,
redirection to the control unit is common.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
IPv6
Does not support IPv6.
Clustering
In clustering, for IGMP and PIM, this feature is only supported on the primary unit.
Additional Guidelines
• You must configure an access control or prefilter rule on the inbound security zone to allow traffic to
the multicast host, such as 224.1.2.3. However, you cannot specify a destination security zone for the
rule, or it cannot be applied to multicast connections during initial connection validation.
• You cannot disable an interface with PIM configured on it. If you have configured PIM on the interface
(see Configure PIM Protocol, on page 907), disabling the multicast routing and PIM does not remove the
PIM configuration. You must remove (delete) the PIM configuration to disable the interface.
• PIM/IGMP Multicast routing is not supported on interfaces in a traffic zone.
Note Only the UDP transport layer is supported for multicast routing.
The following table lists the maximum number of entries for specific multicast tables based on the amount
of RAM on the Firepower Threat Defense device. Once these limits are reached, any new entries are discarded.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 Check the Enable Multicast Routing check box.
Checking this check box enables IP multicast routing on the Firepower Threat Defense device. Unchecking this check
box disables IP multicast routing. By default, multicast is disabled. Enabling multicast routing enables multicast on all
interfaces.
You can disable multicast on a per-interface basis. This is useful if you know that there are no multicast hosts on a specific
interface and you want to prevent the Firepower Threat Defense device from sending host query messages on that interface.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On Protocol, click Add or Edit.
Use the Add IGMP parameters dialog box to add new IGMP parameters to the Firepower Threat Defense device. Use
the Edit IGMP parameters dialog box to change existing parameters.
• Interface—From the drop-down list, select the interface for which you want to configure IGMP protocol.
• Enable IGMP—Check the check box to enable IGMP.
Note Disabling IGMP on specific interfaces is useful if you know that there are no multicast hosts on a specific
interface and you want to prevent the Firepower Threat Defense device from sending host query messages
on that interface.
• Forward Interface—From the drop-down list, select the specific interface from which you want to forward IGMP
messages.
This configures the Firepower Threat Defense device to act as an IGMP proxy agent and forward IGMP messages
from hosts connected on one interface to an upstream multicast router on another interface.
• Version—Choose IGMP Version 1 or 2.
By default, the Firepower Threat Defense device runs IGMP Version 2, which enables several additional features.
Note All multicast routers on a subnet must support the same version of IGMP. The Firepower Threat Defense
device does not automatically detect Version 1 routers and switch to Version 1. However, you can have
a mix of IGMP Version 1 and 2 hosts on the subnet; the Firepower Threat Defense device running IGMP
Version 2 works correctly when IGMP Version 1 hosts are present.
• Query Interval—The interval in seconds at which the designated router sends IGMP host-query messages. The
range is 1 to 3600. The default is 125.
Note If the Firepower Threat Defense device does not hear a query message on an interface for the specified
timeout value, then the Firepower Threat Defense device becomes the designated router and starts sending
the query messages.
• Response Time—The interval in seconds before the Firepower Threat Defense device deletes the group. The range
is 1 to 25. The default is 10.
If the Firepower Threat Defense device does not receive a response to a host query within this amount of time, it
deletes the group.
• Group Limit—The maximum number of hosts that can join on an interface. The range is 1 to 500. The default is
500.
You can limit the number of IGMP states resulting from IGMP membership reports on a per-interface basis.
Membership reports exceeding the configured limits are not entered in the IGMP cache, and traffic for the excess
membership reports is not forwarded
• Query Timeout—The period of time in seconds before which the Firepower Threat Defense device takes over as
the requester for the interface after the previous requester has stopped. The range is 60 to 300. The default is 255.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On Static Group, click Add or Edit.
Use the Add IGMP Static Group parameters dialog box to statically assign a multicast group to an interface. Use the
Edit IGMP Static Group parameters dialog box to change existing static group assignments.
Note See Configure IGMP Static Groups, on page 905 if you want to forward multicast packets for a specific group
to an interface without the Firepower Threat Defense device accepting those packets as part of the group.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On Join Group, click Add or Edit.
Use the Add IGMP Join Group parameters dialog box to configure the Firepower Threat Defense device to be a
member of a multicast group. Use the Edit IGMP Join Group parameters dialog box to change existing parameters.
Note PIM is not supported with PAT. The PIM protocol does not use ports, and PAT only works with protocols
that use ports.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On Protocol, click Add or Edit.
Use the Add PIM parameters dialog box to add new PIM parameters to the interface. Use the Edit PIM parameters
dialog box to change existing parameters.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On Neighbor Filter, click Add or Edit.
Use the Add PIM Neighbor Filter dialog box to add new PIM neighbor filters to the interface. Use the Edit PIM
Neighbor Filter dialog box to change existing parameters.
• Standard Access List— From the Standard Access List drop-down list, select a standard ACL or click Add ( )
to create a new standard ACL. See Configure Standard ACL Objects, on page 516 for the procedure.
Note Choosing Allow on the Add Standard Access List Entry dialog box lets the multicast group advertisements
pass through the interface. Choosing Block prevents the specified multicast group advertisements from
passing through the interface. When a multicast boundary is configured on an interface, all multicast traffic
is prevented from passing through the interface unless permitted with a neighbor filter entry.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Multicast Routing > PIM.
Step 3 On Bidirectional Neighbor Filter, click Add or Edit.
Use the Add PIM Bidirectional Neighbor Filter dialog box to create ACL entries for the PIM bidirectional neighbor
filter ACL. Use the Edit PIM Bidirectional Neighbor Filter dialog box to change existing parameters.
• From the Interface drop-down list, select the interface to which you want to configure the PIM bidirectional neighbor
filter ACL entry.
• Standard Access List— From the Standard Access List drop-down list, select a standard ACL or click Add ( )
to create a new standard ACL. See Configure Standard ACL Objects, on page 516 for the procedure.
Note Choosing Allow on the Add Standard Access List Entry dialog box lets the specified devices participate
in the DR election process. Choosing Block prevents the specified devices from participating in the DR
election process.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On Rendezvous Points, click Add or Edit.
Use the Add Rendezvous Point dialog box to create a new entry to the Rendezvous Point table. Use the Edit Rendezvous
Point dialog box to change existing parameters.
Note This behavior is known as Shortest Path Switchover (SPT). We recommend that you always use the Shared
Tree option.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On Route Tree, select the path for the route tree:
• Click Shortest Path to use the shortest-path tree for all multicast groups.
• Click Shared Tree to use the shared tree for all multicast groups.
• Click Shared tree for below mentioned group to designate the groups specified in the Multicast Groups table, and
then from the Standard Access List drop-down list, select a standard ACL or click Add ( ) to create a new standard
ACL. See Configure Standard ACL Objects, on page 516 for the procedure.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On Request Filter, define the multicast sources that are allowed to register with the Firepower Threat Defense device
when it acts as an RP:
• From the Filter PIM register messages using: drop-down list select None, Access List, or Route Map.
• If you choose Access List from the drop-down list, select an extended ACL or click Add ( ) to create a new
extended ACL. See Configure Extended ACL Objects, on page 515 for the procedure.
Note In the Add Extended Access List Entry dialog box, select Allow from the drop-down list o create a rule
that allows the specified source of the specified multicast traffic to register with the Firepower Threat
Defense device, or select Block to create a rule that prevents the specified source of the specified multicast
traffic from registering with the Firepower Threat Defense device.
• If you choose Route Map, select a route map from the Route Map drop-down list, or click Add ( ) to create a
new route map. See Creating Network Objects for the procedure.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On Bootstrap Router, check the Configure this FTD as a Candidate Bootstrap Router (C-BSR) check box to perform
the C-BSR setup.
a) From the Interface drop-down list, select the interface on the Firepower Threat Defense device from which the BSR
address is derived to make it a candidate.
This interface must be enabled with PIM.
b) In the Hash mask length field, enter the length of a mask (32 bits maximum) that is to be ANDed with the group
address before the hash function is called. All groups with the same seed hash (correspond) to the same RP. For
example, if this value is 24, only the first 24 bits of the group addresses matter. This fact allows you to get one RP
for multiple groups. The range is 0 to 32.
c) In the Priority field, enter the priority of the candidate BSR. The BSR with the larger priority is preferred. If the
priority values are the same, the router with the larger IP address is the BSR. The range is 0 to 255. The default value
is 0.
Step 4 (Optional) Click Add ( ) to select an interface on which no PIM BSR messages will be sent or received in the Configure
this FTD as a Border Bootstrap Router (BSR) section.
• From the Interface drop-down list, select the interface on which no PIM BSR messages will be sent or received.
RP or BSR advertisements are filtered effectively isolating two domains of RP information exchange.
• Check the Enable Border BSR check box to enable BSR.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > Multicast Routes > Add or Edit.
Use the Add Multicast Route Configuration dialog box to add a new multicast route to the Firepower Threat Defense
device. Use the Edit Multicast Route Configuration dialog box to change an existing multicast route.
Step 3 From the Source Network drop-down box, select an existing network or click Add ( ) to add a new one. See Creating
Network Objects for the procedure.
Step 4 To configure an interface to forward the route, click Interface and configure the following options:
• From the Source Interface drop-down list, select the incoming interface for the multicast route.
• From the Output Interface/Dense drop-down list, select the destination interface that the route is forwarded through.
• In the Distance field, enter the distance of the multicast route. The range is 0 to 255.
Step 5 To configure an RPF address to forward the route, click Address and configure the following options:
• In the RPF Address field, enter the IP address for the multicast route.
• In the Distance field, enter the distance of the multicast route The range is 0 to 255.
A standard ACL defines the range of affected addresses. When a boundary filter is set up, no multicast data
packets are allowed to flow across the boundary from either direction. The boundary filter allows the same
multicast group address to be reused in different administrative domains.
You can configure, examine, and filter Auto-RP discovery and announcement messages at the administratively
scoped boundary. Any Auto-RP group range announcements from the Auto-RP packets that are denied by
the boundary ACL are removed. An Auto-RP group range announcement is permitted and passed by the
boundary filter only if all addresses in the Auto-RP group range are permitted by the boundary ACL. If any
address is not permitted, the entire group range is filtered and removed from the Auto-RP message before the
Auto-RP message is forwarded.
Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > Multicast Boundary Filter, and then click Add or Edit.
Use the Add Multicast Boundary Filter dialog box to add new multicast boundary filters to the Firepower Threat
Defense device. Use the Edit Multicast Boundary Filter dialog box to change existing parameters.
You can configure a multicast boundary for administratively scoped multicast addresses. A multicast boundary restricts
multicast data packet flows and enables reuse of the same multicast group address in different administrative domains.
When a multicast boundary is defined on an interface, only the multicast traffic permitted by the filter ACL passes through
the interface.
Step 3 From the Interface drop-down list, choose the interface for which you are configuring the multicast boundary filter ACL.
Step 4 From the Standard Access List drop-down list, choose the standard ACL you want to use, or click Add ( ) to create
a new standard ACL. See Configure Standard ACL Objects, on page 516 for the procedure.
Step 5 Check the Remove any Auto-RP group range announcement from the Auto-RP packets that are denied by the
boundary check box to filter Auto-RP messages from sources denied by the boundary ACL. If this check box is not
checked, all Auto-RP messages are passed.
Step 6 Click OK to save the multicast boundary filter configuration.
VPN Types
The Firepower Management Center supports the following types of VPN connections:
• Remote Access VPNs on Firepower Threat Defense devices.
Remote access VPNs are secure, encrypted connections, or tunnels, between remote users and your
company’s private network. The connection consists of a VPN endpoint device, which is a workstation
or mobile device with VPN client capabilities, and a VPN headend device, or secure gateway, at the edge
of the corporate private network.
Firepower Threat Defense devices can be configured to support Remote Access VPNs over SSL or IPsec
IKEv2 by the Firepower Management Center. Functioning as secure gateways in this capacity, they
authenticate remote users, authorize access, and encrypt data to provide secure connections to your
network. No other types of appliances, managed by the Firepower Management Center, support Remote
Access VPN connections.
Firepower Threat Defense secure gateways support the AnyConnect Secure Mobility Client full tunnel
client. This client is required to provide secure SSL IPsec IKEv2 connections for remote users. This
client gives remote users the benefits of a client without the need for network administrators to install
and configure clients on remote computers since it can be deployed to the client platform upon connectivity.
It is the only client supported on endpoint devices.
• Site-to-site VPNs on Firepower Threat Defense devices.
A site-to-site VPN connects networks in different geographic locations. You can create site-to-site IPsec
connections between managed devices, and between managed devices and other Cisco or third-party
peers that comply with all relevant standards. These peers can have any mix of inside and outside IPv4
and IPv6 addresses. Site-to-site tunnels are built using the Internet Protocol Security (IPsec) protocol
suite and IKEv1 or IKEv2. After the VPN connection is established, the hosts behind the local gateway
can connect to the hosts behind the remote gateway through the secure VPN tunnel.
VPN Basics
Tunneling makes it possible to use a public TCP/IP network, such as the Internet, to create secure connections
between remote users and private corporate networks. Each secure connection is called a tunnel.
IPsec-based VPN technologies use the Internet Security Association and Key Management Protocol (ISAKMP,
or IKE) and IPsec tunneling standards to build and manage tunnels. ISAKMP and IPsec accomplish the
following:
• Negotiate tunnel parameters.
• Establish tunnels.
• Authenticate users and data.
• Manage security keys.
• Encrypt and decrypt data.
• Manage data transfer across the tunnel.
• Manage data transfer inbound and outbound as a tunnel endpoint or router.
A device in a VPN functions as a bidirectional tunnel endpoint. It can receive plain packets from the private
network, encapsulate them, create a tunnel, and send them to the other end of the tunnel where they are
unencapsulated and sent to their final destination. It can also receive encapsulated packets from the public
network, unencapsulate them, and send them to their final destination on the private network.
After the site-to-site VPN connection is established, the hosts behind the local gateway can connect to the
hosts behind the remote gateway through the secure VPN tunnel. A connection consists of the IP addresses
and hostnames of the two gateways, the subnets behind them, and the method the two gateways use to
authenticate to each other.
and modulus groups from which peers can choose during the Phase 1 negotiation. It is possible to create a
single IKE policy, although you might want different policies to give higher priority to your most desired
options. For site-to-site VPNs, you can create a single IKE policy.
To define an IKE policy, specify:
• A unique priority (1 to 65,543, with 1 the highest priority).
• An encryption method for the IKE negotiation, to protect the data and ensure privacy.
• A Hashed Message Authentication Codes (HMAC) method (called integrity algorithm in IKEv2) to
ensure the identity of the sender, and to ensure that the message has not been modified in transit.
• For IKEv2, a separate pseudorandom function (PRF) used as the algorithm to derive keying material and
hashing operations required for the IKEv2 tunnel encryption. The options are the same as those used for
the hash algorithm.
• A Diffie-Hellman group to determine the strength of the encryption-key-determination algorithm. The
device uses this algorithm to derive the encryption and hash keys.
• An authentication method, to ensure the identity of the peers.
• A limit to the time the device uses an encryption key before replacing it.
When IKE negotiation begins, the peer that starts the negotiation sends all of its policies to the remote peer,
and the remote peer searches for a match with its own policies, in priority order. A match between IKE policies
exists if they have the same encryption, hash (integrity and PRF for IKEv2), authentication, and Diffie-Hellman
values, and an SA lifetime less than or equal to the lifetime in the policy sent. If the lifetimes are not identical,
the shorter lifetime—From the remote peer policy—Applies. By default, the Firepower Management Center
deploys an IKEv1 policy at the lowest priority for all VPN endpoints to ensure a successful negotiation.
IPsec
IPsec is one of the most secure methods for setting up a VPN. IPsec provides data encryption at the IP packet
level, offering a robust security solution that is standards-based. With IPsec, data is transmitted over a public
network through tunnels. A tunnel is a secure, logical communication path between two peers. Traffic that
enters an IPsec tunnel is secured by a combination of security protocols and algorithms.
An IPsec Proposal policy defines the settings required for IPsec tunnels. An IPsec proposal is a collection of
one or more crypto-maps that are applied to the VPN interfaces on the devices. A crypto map combines all
the components required to set up IPsec security associations, including:
• A proposal (or transform set) is a combination of security protocols and algorithms that secure traffic in
an IPsec tunnel. During the IPsec security association (SA) negotiation, peers search for a proposal that
is the same at both peers. When it is found, it is applied to create an SA that protects data flows in the
access list for that crypto map, protecting the traffic in the VPN. There are separate IPsec proposals for
IKEv1 and IKEv2. In IKEv1 proposals (or transform sets), for each parameter, you set one value. For
IKEv2 proposals, you can configure multiple encryption and integration algorithms for a single proposal.
• A crypto map, combines all components required to set up IPsec security associations (SA), including
IPsec rules, proposals, remote peers, and other parameters that are necessary to define an IPsec SA. When
two peers try to establish an SA, they must each have at least one compatible crypto map entry.
Dynamic crypto map policies are used in site-to-site VPNs when an unknown remote peer tries to start
an IPsec security association with the local hub. The hub cannot be the initiator of the security association
negotiation. Dynamic crypto-policies allow remote peers to exchange IPsec traffic with a local hub even
if the hub does not know the remote peer’s identity. A dynamic crypto map policy essentially creates a
crypto map entry without all the parameters configured. The missing parameters are later dynamically
configured (as the result of an IPsec negotiation) to match a remote peer’s requirements.
Dynamic crypto map policies are applicable to both hub-and-spoke and point-to-point VPN topologies.
To apply dynamic crypto map policies, specify a dynamic IP address for one of the peers in the topology
and ensure that the dynamic crypto-map is enabled on this topology. Note that in a full mesh VPN
topology, you can apply only static crypto map policies.
Note Simultaneous IKEv2 dynamic crypto map is not supported for the same interface
for both remote access and site-to-site VPNs on Firepower Threat Defense (FTD).
VPN Licensing
There is no specific licensing for enabling Firepower Threat Defense VPN, it is available by default.
The Firepower Management Center determines whether to allow or block the usage of strong crypto on a
Firepower Threat Defense device based on attributes provided by the smart licensing server.
This is controlled by whether you selected the option to allow export-controlled functionality on the device
when you registered with Cisco Smart License Manager. If you are using the evaluation license, or you did
not enable export-controlled functionality, you cannot use strong encryption.
We cannot provide specific guidance on which options to choose. If you operate within a larger corporation
or other organization, there might already be defined standards that you need to meet. If not, take the time to
research the options.
The following topics explain the available options.
In IPsec proposals, the hash algorithm is used by the Encapsulating Security Protocol (ESP) for authentication.
In IKEv2 IPsec Proposals, this is called the integrity hash. In IKEv1 IPsec proposals, the algorithm name is
prefixed with ESP-, and there is also an -HMAC suffix (which stands for “hash method authentication code”).
For IKEv2, you can configure multiple hash algorithms. The system orders the settings from the most secure
to the least secure and negotiates with the peer using that order. For IKEv1, you can select a single option
only.
You can choose from the following hash algorithms.
• SHA (Secure Hash Algorithm)—Standard SHA (SHA1) produces a 160-bit digest.
The following SHA-2 options, which are even more secure, are available for IKEv2 configurations.
Choose one of these if you want to implement the NSA Suite B cryptography specification.
• SHA256—Specifies the Secure Hash Algorithm SHA 2 with the 256-bit digest.
• SHA384—Specifies the Secure Hash Algorithm SHA 2 with the 384-bit digest.
• SHA512—Specifies the Secure Hash Algorithm SHA 2 with the 512-bit digest.
• Null or None (NULL, ESP-NONE)—(IPsec Proposals only.) A null Hash Algorithm; this is typically
used for testing purposes only. However, you should choose the null integrity algorithm if you select
one of the AES-GCM options as the encryption algorithm. Even if you choose a non-null option, the
integrity hash is ignored for these encryption standards.
Pre-shared Keys
Preshared keys allow for a secret key to be shared between two peers. The key is used by IKE in the
authentication phase. The same shared key must be configured on each peer, or the IKE SA cannot be
established.
To configure the pre-shared keys, choose whether you will use a manual or automatically generated key, and
then speicify the key in the IKEv1/IKEv2 options. Then, when your configuration is deployed, the key is
configured on all devices in the topology.
Digital Certificates
When you use Digital Certificates as the authentication method for VPN connections, peers are configured
to obtain digital certificates from a Certificate Authority (CA). CAs are trusted authorities that “sign” certificates
to verify their authenticity, thereby guaranteeing the identity of the device or user.
CA servers manage public CA certificate requests and issue certificates to participating network devices as
part of a Public Key Infrastructure (PKI), this activity is called Certificate Enrollment. These digital certificates,
also called identity certificates contain:
• The digital identification of the owner for authentication, such as name, serial number, company,
department, or IP address.
• A public key needed to send and receive encrypted data to the certificate owner.
• The secure digital signature of a CA.
Certificates also provide non-repudiation of communication between two peers, meaning that it they prove
that the communication actually took place.
Certificate Enrollment
Using a PKI improves the manageability and scalability of your VPN since you do not have to configure
pre-shared keys between all the encrypting devices. Instead, you individually enroll each participating device
with a CA server, which is explicitly trusted to validate identities and create an identity certificate for the
device. When this has been accomplished, each participating peer sends their identity certificate to the other
peer to validate their identities and establish encrypted sessions with the public keys contained in the certificates.
See Certificate Enrollment Objects, on page 500for details on enrolling FTD devices.
Trustpoints
Once enrollment is complete, a trustpoint is created on the managed device. It is the object representation of
a CA and associated certificates. A trustpoint includes the identity of the CA, CA-specific parameters, and
an association with a single enrolled identity certificate.
PKCS#12 File
A PKCS#12, or PFX, file holds the server certificate, any intermediate certificates, and the private key in one
encrypted file. This type of file may be imported directly into a device to create a trustpoint.
Revocation Checking
A CA may also revoke certificates for peers that no longer participate in you network. Revoked certificates
are either managed by an Online Certificate Status Protocol (OCSP) server or are listed in a certificate revocation
list (CRL) stored on an LDAP server. A peer may check these before accepting a certificate from another
peer.
Define a pre-shared key for VPN authentication manually or automatically, there is no default key. When
choosing automatic, the Firepower Management Center generates a pre-shared key and assigns it to all the
nodes in the topology.
The following diagram displays a typical Hub and Spoke VPN topology.
Implicit Topologies
In addition to the three main VPN topologies, other more complex topologies can be created as combinations
of these topologies. They include:
• Partial mesh—A network in which some devices are organized in a full mesh topology, and other devices
form either a hub-and-spoke or a point-to-point connection to some of the fully meshed devices. A partial
mesh does not provide the level of redundancy of a full mesh topology, but it is less expensive to
implement. Partial mesh topologies are used in peripheral networks that connect to a fully meshed
backbone.
• Tiered hub-and-spoke—A network of hub-and-spoke topologies in which a device can behave as a hub
in one or more topologies and a spoke in other topologies. Traffic is permitted from spoke groups to their
most immediate hub.
• Joined hub-and-spoke—A combination of two topologies (hub-and-spoke, point-to-point, or full mesh)
that connect to form a point-to-point tunnel. For example, a joined hub-and-spoke topology could comprise
two hub-and-spoke topologies, with the hubs acting as peer devices in a point-to-point topology.
VPN Topology
To create a new site-to-site VPN topology you must, at minimum, give it a unique name, specify a topology
type, choose the IKE version that is used for IPsec IKEv1 or IKEv2, or both. Also, determine your authentication
method. Once configured, you deploy the topology to Firepower Threat Defense devices. The Firepower
Management Center configures site-to-site VPNs on FTD devices only.
You can select from three types of topologies, containing one or more VPN tunnels:
• Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints.
• Hub and Spoke deployments establish a group of VPN tunnels connecting a hub endpoint to a group of
spoke nodes.
• Full Mesh deployments establish a group of VPN tunnels among a set of endpoints.
Authentication
For authentication of VPN connections, configure a preshared key in the topology, or a trustpoint on each
device. Preshared keys allow for a secret key, used during the IKE authentication phase, to be shared between
two peers. A trustpoint includes the identity of the CA, CA-specific parameters, and an association with a
single enrolled identity certificate.
Extranet Devices
Each topology type can include Extranet devices, devices that you do not manage in Firepower Management
Center. These include:
• Cisco devices that Firepower Management Center supports, but for which your organization is not
responsible. Such as spokes in networks managed by other organizations within your company, or a
connection to a service provider or partner's network.
• Non-Cisco devices. You cannot use Firepower Management Center to create and deploy configurations
to non-Cisco devices.
Add non-Cisco devices, or Cisco devices not managed by the Firepower Management Center, to a VPN
topology as "Extranet" devices. Also specify the IP address of each remote device.
• Firepower Threat Defense VPNs are only be backed up using the Firepower Management backup.
• The Firepower Threat Defense VPNs do not currently support PDF export and policy comparison.
• There is no per-tunnel or per-device edit option for Firepower Threat Defense VPNs, only the whole
topology can be edited.
• Device interface address verification will not be performed for Transport mode when Crypto ACL is
selected.
• All nodes in a topology must be configured with either Crypto ACL or Protected Network. A topology
may not be configured with Crypto ACL on one node and Protected Network on another.
• There is no support for automatic mirror ACE generation. Mirror ACE generation for the peer is a manual
process on either side.
• While using Crypto ACL, there is no support for tunnel health events for VPN topologies. With Crypto
ACL, there is no support for Hub, Spoke, and Full Mesh topologies; only point to point VPN is supported.
• Whenever IKE ports 500/4500 are in use or when there are some PAT translations that are active, the
Site-to-Site VPN cannot be configured on the same ports as it fails to start the service on those ports.
• Tunnel status is not updated in realtime, but at an interval of 5 minutes in the Firepower Management
Center.
• The character " (double quote) is not supported as part of pre-shared keys. If you have used " in a
pre-shared key, ensure that you change the character after you upgrade to Firepower Threat Defense
6.30.
Supported Domains
Leaf
User Roles
Admin
• Add—To create a new VPN topology, click Add ( ) Add VPN > Firepower Threat Defense Device, and continue
as instructed in Configuring Firepower Threat Defense Site-to-site VPNs, on page 932:
Note VPNs topologies can be created only on leaf domains.
• Edit—To modify the settings of an existing VPN topology, click Edit ( ). Modifying is similar to configuring,
continue as instructed above.
Note You cannot edit the topology type after you initially save it. To change the topology type, delete the
topology and create a new one.
Two users should not edit the same topology simultaneously; however, the web interface does not prevent
simultaneous editing.
Step 5 Required: Add Endpoints for this VPN deployment by clicking Add ( ) for each node in the topology.
Configure each endpoint field as described in FTD VPN Endpoint Options, on page 933.
• For Point to point, configure Node A and Node B.
• For Hub and Spoke, configure a Hub Node and Spoke Nodes
• For Full Mesh, configure multiple Nodes
Step 6 (Optional) Specify non-default IKE options for this deployment as described in FTD VPN IKE Options, on page 935
Step 7 (Optional) Specify non-default IPsec options for this deployment as described in FTD VPN IPsec Options, on page 937
Step 8 (Optional) Specify non-default Advanced options for this deployment as described in FTD Advanced Site-to-site VPN
Deployment Options, on page 939.
Step 9 Click Save.
The endpoints are added to your configuration.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note Some VPN settings are validated only during deployment. Be sure to verify that your deployment was
successful.
If you get an alert that your VPN tunnel is inactive even when the VPN session is up, follow the VPN
troubleshooting instructions to verify and ensure that your VPN is active. For information, see VPN Monitoring
for Firepower Threat Defense, on page 999 and VPN Troubleshooting for Firepower Threat Defense, on page
1003.
Fields
Device
Choose an endpoint node for your deployment:
• A FTD device managed by this Firepower Management Center.
• A FTD high availability container managed by this Firepower Management Center.
• An Extranet device, any device (Cisco or third-party) not managed by this Firepower Management
Center.
Device Name
For Extranet devices only, provide a name for this device. We recommend naming it such that it is
identifiable as an un-manaaged device.
Interface
If you chose a managed device as your endpoint, choose an interface on that managed device.
For 'Point to Point' deployments, you can also configure an endpoint with dynamic interface. Note that
an endpoint with dynamic interface can pair only with an extranet device and cannot pair with an endpoint,
which has a managed device.
You can configure device interfaces at Devices > Device Management > Add/Edit device > Interfaces.
IP Address
• If you choose an extranet device, a device not managed by the Firepower Management Center,
specify an IP address for the endpoint.
For an extranet device, select Static and specify an IP address or select Dynamic to allow dynamic
extranet devices.
If you have chosen point-to-point topology and only IKEv1, you can configure backup peer by
entering the primary IP address and backup peer IP addresses separated by a comma.
• If you chose a managed device as an endpoint, choose a single IPv4 address or multiple IPv6
addresses from the drop-down list (these are the addresses already assigned to this interface on this
managed device).
• All endpoints in a topology must have the same IP addressing scheme. IPv4 tunnels can carry IPv6
traffic and vice-versa. The Protected Networks define which addressing scheme the tunneled traffic
will use.
• If the managed device is a high-availability container, choose from a list of interfaces.
This IP is Private
Check the check box if the endpoint resides behind a firewall with network address translation (NAT).
Public IP address
If you checked the This IP is Private check box, specify a public IP address for the firewall. If the
endpoint is a responder, specify this value.
Connection Type
Specify the allowed negotiation as bidirectional, answer-only, or originate-only. Supported combinations
for the connection type are:
Originate-Only Answer-Only
Bi-Directional Answer-Only
Bi-Directional Bi-Directional
Certificate Map
Choose a pre-configured certificate map object, or click Add ( ) to add a certificate map object that
defines what information is necessary in the received client certificate for it to be valid for VPN
connectivity. See FTD Certificate Map Objects, on page 530 for details.
Protected Networks
Defines the networks that are protected by this VPN Endpoint. The networks may be marked by selecting
the list of Subnet/IP Address that define the networks that are protected by this endpoint. Click Add ( )
to select from available Network Objects or add new Network Objects. See Creating Network Objects,
on page 450. Access Control Lists will be generated from the choices made here.
• Subnet/IP Address (Network)—VPN endpoints cannot have the same IP address and protected
networks in a VPN endpoint pair cannot overlap. If a list of protected networks for an endpoint
contains one or more IPv4 or IPv6 entries, the other endpoint's protected network must have at least
one entry of the same type (that is, IPv4 or IPv6). If it does not, then the other endpoint's IP address
must be of the same type and must not overlap with the entries in the protected network. (Use /32
CIDR address blocks for IPv4 and /128 CIDR address blocks for IPv6.) If both of these checks fail,
the endpoint pair is invalid.
• Access List (Extended)—An extended access lists provide the capability to control the type of
traffic that will be accepted by this endpoint, like GRE or OSPF traffic. Traffic may be restricted
either by address or port. Click Add ( ) to add access control list objects.
Note Access Control List is supported only in the point to point topology.
Note Settings in this dialog apply to the entire topology, all tunnels, and all managed devices.
Navigation Path
Devices > VPN > Site To Site. Then Add VPN > Firepower Threat Defense Device, or edit a listed VPN
Topology. Open the IKE tab.
Fields
Policy
Choose a predefined IKEv1 or IKEv2 policy object or create a new one to use. For details, see FTD IKE
Policies, on page 519
Authentication Type
Site-to-site VPN supports two authentication methods, pre-shared key and certificate. For an explanation
of the two methods, see Deciding Which Authentication Method to Use, on page 923.
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.
• Pre-shared Automatic Key—The Management Center automatically defines the pre-shared key
that is used for this VPN. Specify the Pre-shared Key Length, the number of characters in the key,
1-27.
The character " (double quote) is not supported as part of pre-shared keys. If you have used " in a
pre-shared key, ensure that you change the character after you upgrade to Firepower Threat Defense
6.30 or higher.
• Pre-shared Manual Key—Manually assign the pre-shared key that is used for this VPN. Specify
the Key and then re-enter it in Confirm Key to confirm.
When this option is chosen for IKEv2, the Enforce hex-based pre-shared key only check box
appears, check if desired. If enforced, you must enter a valid hex value for the key, an even number
of 2-256 characters, using numerals 0-9, or A-F.
• 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.
In the Certificate field, select a pre-configured certificate enrollment object. This enrollment object
is used to generate a trustpoint with the same name on the managed device. The certificate enrollment
object should be associated with and installed on the device, post which the enrollment process is
complete, and then a trustpoint is created.
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.
Before you select this option, note the following:
• Ensure you have enrolled a certificate enrollment object on all the endpoints in the topology—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. 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. For instructions on creating a certificate enrollment
object, see Adding Certificate Enrollment Objects, on page 502, and for instructions on enrolling
the object on the endpoints see one of the following as applicable:
• Installing a Certificate Using Self-Signed Enrollment , on page 539
• Installing a Certificate Using SCEP Enrollment, on page 540
• Installing a Certificate Using Manual Enrollment, on page 540
• Installing a Certificate Using a PKCS12 File, on page 541
Note For a site-to-site VPN topology, ensure that the same certificate enrollment object
is enrolled in all the endpoints in the topology. For further details, see the table
below.
• Refer the following table to understand the enrollment requirement for different scenarios.
Some of the scenarios require you to override the certificate enrollment object for specific
devices. See Managing Object Overrides, on page 447 to understand how to override objects.
Certificate Enrollment Device identity certificate for all endpoints is Device identity
Types from the same CA certificate for all
endpoints is from
Device-specific Device-specific different CAs
parameters are NOT parameters are
specified in the specified in the
certificate enrollment certificate enrollment
object object
• Understand the VPN certificate limitations mentioned in Firepower Threat Defense VPN
Certificate Guidelines and Limitations, on page 538.
Note 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 in the Advanced Settings
section on the Key tab in the PKI Certificate Enrollment dialog box for the object
you select. Otherwise, the endpoints cannot complete the site-to-site VPN
connection.
Note Settings in this dialog apply to the entire topology, all tunnels, and all managed devices.
Crypto-Map Type
A crypto map combines all the components required to set up IPsec security associations (SA). When
two peers try to establish an SA, they must each have at least one compatible crypto map entry. The
proposals defined in the crypto map entry are used in the IPsec security negotiation to protect the data
flows specified by that crypto map’s IPsec rules. Choose static or dynamic for this deployment's
crypto-map:
• Static—Use a static crypto map in a point-to-point or full mesh VPN topology.
• Dynamic—Dynamic crypto-maps essentially create a crypto map entry without all the parameters
configured. The missing parameters are later dynamically configured (as the result of an IPsec
negotiation) to match a remote peer’s requirements.
Dynamic crypto map policies are applicable to both hub-and-spoke and point-to-point VPN
topologies. To apply dynamic crypto map policies, specify a dynamic IP address for one of the peers
in the topology and ensure that the dynamic crypto-map is enabled on this topology. Note that in a
full mesh VPN topology, you can apply only static crypto map policies.
IKEv2 Mode
For IPsec IKEv2 only, specify the encapsulation mode for applying ESP encryption and authentication
to the tunnel. This determines what part of the original IP packet has ESP applied.
• Tunnel mode—(default) Encapsulation mode is set to tunnel mode. Tunnel mode applies ESP
encryption and authentication to the entire original IP packet (IP header and data), hiding the ultimate
source and destination addresses and becoming the payload in a new IP packet.
The major advantage of tunnel mode is that the end systems do not need to be modified to receive
the benefits of IPsec. This mode allows a network device, such as a router, to act as an IPsec proxy.
That is, the router performs encryption on behalf of the hosts. The source router encrypts packets
and forwards them along the IPsec tunnel. The destination router decrypts the original IP datagram
and forwards it onto the destination system. Tunnel mode also protects against traffic analysis; with
tunnel mode, an attacker can only determine the tunnel endpoints and not the true source and
destination of the tunneled packets, even if they are the same as the tunnel endpoints.
• Transport preferred— Encapsulation mode is set to transport mode with an option to fallback to
tunnel mode if the peer does not support it. In Transport mode only the IP payload is encrypted,
and the original IP headers are left intact. Therefore, the admin must select a protected network that
matches the VPN interface IP address.
This mode has the advantages of adding only a few bytes to each packet and allowing devices on
the public network to see the final source and destination of the packet. With transport mode, you
can enable special processing (for example, QoS) on the intermediate network based on the
information in the IP header. However, the Layer 4 header is encrypted, which limits examination
of the packet.
• Transport required— Encapsulation mode is set to transport mode only, falling back to tunnel
mode is not allowed. If the endpoints cannot successfully negotiate transport mode, due to one
endpoint not supporting it, the VPN connection is not made.
Proposals
Click Edit ( ) to specify the proposals for your chosen IKEv1 or IKEv2 method. Select from the available
IKEv1 IPsec Proposals or IKEv2 IPsec Proposals objects, or create and then select a new one. See
Configure IKEv1 IPsec Proposal Objects, on page 523 and Configure IKEv2 IPsec Proposal Objects, on
page 523 for details.
Enable Security Association (SA) Strength Enforcement
Enabling this option ensures that the encryption algorithm used by the child IPsec SA is not stronger (in
terms of the number of bits in the key) than the parent IKE SA.
Navigation Path
Devices > VPN > Site To Site, then select Add VPN > Firepower Threat Defense Device, or edit a listed
VPN Topology. Open the Advanced tab, and select Tunnel in the navigation pane.
Tunnel Options
Only available for Hub and Spoke, and Full Mesh topologies. This section will not display for Point to Point
configurations.
• Enable Spoke to Spoke Connectivity through Hub—Disabled by default. Choosing this field enables
the devices on each end of the spokes to extend their connection through the hub node to the other device.
NAT Settings
• Keepalive Messages Traversal —Elect whether to enable NAT keepalive message traversal. NAT
traversal keepalive is used for the transmission of keepalive messages when there is a device (middle
device) located between a VPN-connected hub and spoke, and that device performs NAT on the IPsec
flow.
If you select this option, configure the Interval, in seconds, between the keepalive signals sent between
the spoke and the middle device to indicate that the session is active. The value can be from 5 to 3600
seconds. The default is 20 seconds.
but VPN Filter ACL and authorization ACL downloaded from AAA server are still applied to VPN
traffic.
Enable or disable the option for all your VPN connections. If you disable this option, make sure that the
traffic is allowed by the access control policy or pre-filter policy.
You can use the following examples to allocate limited bandwidth to VPN users and to use VPN identify for
user-id based access control rules:
• How to Limit AnyConnect Bandwidth Per User, on page 993
• How to Use VPN Identity for User-id Based Access Control Rules, on page 995
AAA
• Server authentication using self-signed or CA-signed identity certificates.
• AAA username and password-based remote authentication using RADIUS server or LDAP or AD.
• RADIUS group and user authorization attributes, and RADIUS accounting.
• Double authentication support using an additional AAA server for secondary authentication.
• NGFW Access Control integration using VPN Identity.
VPN Tunneling
• Address assignment
• Split tunneling
• Split DNS
Monitoring
• New VPN Dashboard Widget showing VPN users by various characteristics such as duration and client
application.
• Remote access VPN events including authentication information such as username and OS platform.
• Tunnel statistics available using the FTD Unified CLI.
AnyConnect Components
AnyConnect Secure Mobility Client Deployment
Your remote access VPN Policy can include the AnyConnect Client Image and an AnyConnect Client Profile
for distribution to connecting endpoints. Or, the client software can be distributed using other methods. See
the Deploy AnyConnect chapter in the appropriate version of the Cisco AnyConnect Secure Mobility Client
Administrator Guide.
Without a previously installed client, remote users enter the IP address in their browser of an interface
configured to accept SSL or IPsec-IKEv2 VPN connections. Unless the security appliance is configured to
redirect http:// requests to https://, remote users must enter the URL in the form https://address. After the user
enters the URL, the browser connects to that interface and displays the login screen.
After a user logs in, if the secure gateway identifies the user as requiring the VPN client, it downloads the
client that matches the operating system of the remote computer. After downloading, the client installs and
configures itself, establishes a secure connection, and either remains or uninstalls itself (depending on the
security appliance configuration) when the connection stops. In the case of a previously installed client, after
login, the Firepower Threat Defense security gateway examines the client version and upgrades it as necessary.
You can configure a profile using the AnyConnect Profile Editor. This editor is a convenient GUI-based
configuration tool that is available as part of the AnyConnect software package. It is an independent program
that you run outside of the Firepower Management Center.
Note If you are using client certificates in your deployment, they must be added to your client's platform independent
of the Firepower Threat Defense or Firepower Management Center. Facilities such as SCEP or CA Services
are not provided to populate your clients with certificates.
AAA servers enable managed devices acting as secure gateways to determine who a user is (authentication),
what the user is permitted to do (authorization), and what the user did (accounting). Some examples of the
AAA servers are RADIUS, LDAP/AD, TACACS+, and Kerberos. For Remote Access VPN on Firepower
Threat Defense devices, AD, LDAP, and RADIUS AAA servers are supported for authentication.
Only RADIUS servers can be configured and used for authorization and accounting servers.
Refer to the section Understanding Policy Enforcement of Permissions and Attributes to understand more
about remote access VPN authorization.
Before you add or edit the Remote Access VPN policy, you must configure the Realm and RADIUS server
groups you want to specify. For more information, see Create a Realm, on page 2073 and RADIUS Server
Groups, on page 533.
Without DNS configured, the device cannot resolve AAA server names, named URLs, and CA Servers with
FQDN or Hostnames, it can only resolve IP addresses.
The login information provided by a remote user is validated by an LDAP or AD realm or a RADIUS server
group. These entities are integrated with the Firepower Threat Defense secure gateway.
Note If users authenticate with RA VPN using Active Directory as the authentication source, users must log in
using their username; the format domain\username or username@domain fails. (Active Directory
refers to this username as the logon name or sometimes as sAMAccountName.) For more information, see
User Naming Attributes on MSDN.
If you use RADIUS to authenticate, users can log in with any of the preceding formats.
Once authenticated via a VPN connection, the remote user takes on a VPN Identity. This VPN Identity is used
by identity policies on the Firepower Threat Defense secure gateway to recognize and filter network traffic
belonging to that remote user.
Identity policies are associated with access control policies, which determine who has access to network
resources. It is in this way that the remote user blocked or allowed to access your network resources.
For more information, see the About Identity Policies, on page 2135 and Access Control Policies, on page 1339
sections.
Related Topics
Configure AAA Settings for Remote Access VPN, on page 961
Note The Firepower Threat Defense device does not support inheriting system default attributes from the default
group policy, DfltGrpPolicy. The attributes on the group policy assigned to the connection profile are used
for the user session, if they are not overridden by user attributes or the group policy from the AAA server as
indicated above.
Related Topics
Configure AAA Settings for Remote Access VPN, on page 961
Note If you place a AAA server on a data interface, be sure the management-only
routing policies do not match traffic destined for a data interface. For example,
if you have a default route through the Diagnostic interface, then traffic will never
fall back to the data routing table. Use the show route management-only and
show route commands to verify routing determination.
For both activities on the same AAA servers, in addition to making the servers reachable over the Management
interface for user-identity handling, do one of the following to provide VPN authentication access to the same
AAA servers:
• Enable and configure the Diagnostic interface with an IP address on the same subnet as the Management
interface, and then configure a route to the AAA server through this interface. The Diagnostic interface
access will be used for VPN activity, the Management interface access for identity handling.
Note When configured this way, you cannot also have a data interface on the same
subnet as the Diagnostic and Management interfaces. If you want the Management
interface and a data interface on the same network, for example when using the
device itself as a gateway, you will not be able to use this solution because the
Diagnostic interface must remain disabled.
• Configure a route through a data interface to the AAA server. The data interface access will be used for
VPN activity, the Management interface access for user-identity handling.
For more information about various interfaces, see Regular Firewall Interfaces for Firepower Threat Defense,
on page 633.
After deployment, use the following CLI commands to monitor and troubleshoot AAA server connectivity
from the Firepower Threat Defense device:
• show aaa-server to display AAA server statistics.
• show route management-only to view the management-only routing table entries.
Supported Domains
Any
User Roles
Admin
Note The FTD device denies the VPN connections once the maximum session limit per platform is reached. The
connection is denied with a syslog message. Refer the syslog messages %ASA-4-113029 and %ASA-4-113038
in the syslog messaging guide. For more information, see http://www.cisco.com/c/en/us/td/docs/security/asa/
syslog-guide/syslogs.html
Client Certificates
• If you are using client certificates in your deployment, they must be added to your client's platform
independent of the Firepower Threat Defense or Firepower Management Center. Facilities such as SCEP
or CA Services are not provided to populate your clients with certificates.
• AnyConnect Customization and Localization support. The FTD device does not configure or deploy the
files necessary to configure AnyConnect for these capabilities.
• Custom Attributes for the AnyConnect Client are not supported on the FTD. Hence all features that make
use of Custom Attributes are not supported, such as Deferred Upgrade on desktop clients and Per-App
VPN on mobile clients.
• Local authentication; VPN users cannot be configured on the FTD secure gateway.
Local CA, the secure gateway cannot act as a Certificate Authority.
• Single Sign-on using SAML 2.0.
• TACACS, Kerberos (KCD Authentication and RSA SDI).
• LDAP Authorization (LDAP Attribute Map).
• Browser Proxy.
• VPN load balancing.
Step Review the guidelines and prerequisites. Guidelines and Limitations for Remote Access VPNs,
1 on page 950
Prerequisites for Configuring Remote Access VPN, on
page 953
Step Create a new remote access VPN policy Create a New Remote Access VPN Policy, on page 953
2 using the wizard.
Step Update the access control policy deployed Update the Access Control Policy on the Firepower
3 on the device. Threat Defense Device, on page 955
Step (Optional) Configure a NAT exemption (Optional) Configure NAT Exemption, on page 956
4 rule if NAT is configured on the device.
Step Add an AnyConnect Client Profile. Add an AnyConnect Client Profile XML File, on page
6 957
Step Deploy the remote access VPN policy. Deploy Configuration Changes, on page 385
7
Step (Optional) Verify the remote access VPN Verify the Configuration, on page 958
8 policy configuration.
Step 2 Click (Add ( )) Add to create a new Remote Access VPN Policy using a wizard that walks you through a basic policy
configuration.
You must proceed through the entire wizard to create a new policy; the policy is not saved if you cancel before completing
the wizard.
Step 5 Select the AnyConnect Client Image that the VPN users will use to connect to the remote access VPN.
The Cisco AnyConnect Secure Mobility client provides secure SSL or IPSec (IKEv2) connections to the Firepower Threat
Defense device for remote users with full VPN profiling to corporate resources. After the remote access VPN policy is
deployed on the Firepower Threat Defense device, VPN users can enter the IP address of the configured device interface
in their browser to download and install the AnyConnect client.
Step 7 View the Summary of the Remote Access VPN policy configuration.
The Summary page displays all the remote access VPN settings you have configured so far and provides links to the
additional configurations that need to be performed before deploying the remote access VPN policy on the selected
devices.
Click Back to make changes to the configuration, if required.
Step 8 Click Finish to complete the basic configuration for the remote access VPN policy.
When you have completed the remote access VPN policy using the wizard, it returns to the policy listing page. Set up
DNS configuration, configure access control for VPN users, and enable NAT exemption (if necessary) to complete a
basic RA VPN Policy configuration. Then, deploy the configuration and establish VPN connections.
Update the Access Control Policy on the Firepower Threat Defense Device
Before deploying the remote access VPN policy, you must update the access control policy on the targeted
Firepower Threat Defense device with a rule that allows VPN traffic. The rule must allow all traffic coming
in from the outside interface, with source as the defined VPN pool networks and destination as the corporate
network.
Note If you have selected the Bypass Access Control policy for decrypted traffic (sysopt permit-vpn) option
on the Access Interface tab, you need not update the access control policy for remote access VPN.
Enable or disable the option for all your VPN connections. If you disable this option, make sure that the traffic
is allowed by the access control policy or pre-filter policy.
For more information, see Configure Access Interfaces for Remote Access VPN, on page 967.
Step 1 On your Firepower Management Center web interface, choose Policies > Access Control.
Step 2 Select the access control policy assigned to the target devices where the remote access VPN policy will be deployed and
click Edit.
Step 3 Click Add Rule to add a new rule.
Step 4 Specify the Name for the rule and select Enabled.
Step 5 Select the Action, Allow or Trust.
Step 6 Select the following on the Zones tab:
a) Select the outside zone from Available Zones and click Add to Source.
b) Select the inside zone from Available Zones and click Add to Destination.
Step 7 Select the following on the Networks tab:
a) Select the inside network (inside interface and/or a corporate network) from Available networks and click Add to
Destination.
b) Select the VPN address pool network from Available Networks and click Add to Source Networks.
Step 8 Configure other required access control rule settings and click Add.
Step 9 Save the rule and access control policy.
Step 1 On your Firepower Management Center web interface, click Devices > NAT.
Step 2 Select a NAT policy to update or click New Policy > Threat Defense NAT to create a NAT policy with a NAT rule to
allow connections through all interfaces.
Step 3 Click Add Rule to add a NAT rule.
Step 4 On the Add NAT Rule window, select the following:
a) Select the NAT Rule as Manual NAT Rule.
b) Select the Type as Static.
c) Click Interface Objects and select the Source and destination interface objects.
Note This interface object must be the same as the interface selected in the remote access VPN policy.
For more information, see Configure Access Interfaces for Remote Access VPN, on page 967.
a) Click Translation and select the source and destination networks:
• Original Source and Translated Source
• Original Destination and Translated Destination
Step 5 On the Advanced tab, select Do not proxy ARP on Destination Interface.
Do not proxy ARP on Destination Interface—Disables proxy ARP for incoming packets to the mapped IP addresses.
If you use addresses on the same network as the mapped interface, the system uses proxy ARP to answer any ARP requests
for the mapped addresses, thus intercepting traffic destined for a mapped address. This solution simplifies routing because
the device does not have to be the gateway for any additional networks. You can disable proxy ARP if desired, in which
case you need to be sure to have proper routes on the upstream router.
Configure DNS
Configure DNS on each Firepower Threat Defense device in order to use remote access VPN. Without DNS,
the devices cannot resolve AAA server names, named URLs, and CA Servers with FQDN or Hostnames. It
can only resolve IP addresses.
Step 1 Configure DNS server details and domain-lookup interfaces using the Platform Settings. For more information, see
Configure DNS, on page 1157 and DNS Server Group Objects, on page 508.
Step 2 Configure split-tunnel in group policy to allow DNS traffic through remote access VPN tunnel if the DNS server is
reachable through VNP network. For more information, see Configure Group Policy Objects, on page 524.
c) Click Save.
Related Topics
Access List, on page 514
If AnyConnect is not installed, you will be prompted to download the AnyConnect client.
Step 4 Download AnyConnect if it is not installed already and connect to the VPN.
The AnyConnect client installs itself. On successful authentication, you will be connected to the Firepower Threat Defense
remote access VPN gateway. The applicable identity or QoS policy is enforced according to your remote access VPN
policy configuration.
provides a default connection profile named DefaultWEBVPNGroup. The connection profile that is configured
using the wizard appears in the list.
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Existing remote access policies are listed.
Step 2 Select a remote access VPN policy and click Edit.
Step 3 Click Add and specify the following in the Add Connection Profile window:
a) Connection Profile—Provide a name that the remote users will use for VPN connections. The connection profile
contains a set of parameters that define how the remote users connect to the VPN device.
b) Client Address Assignment— Assign IP Address for the remote clients from the local IP Address pools, DHCP
servers, and AAA servers.
c) AAA— Configure the AAA servers to enable managed devices acting as secure VPN gateways to determine who a
user is (authentication), what the user is permitted to do (authorization), and what the user did (accounting).
d) Aliases—Provide an alternate name or URL for the connection profile. Remote Access VPN administrators can
enable or disable the Alias names and Alias URLs. VPN users can choose an Alias name when they connect to the
Firepower Threat Defense device remote access VPN using the AnyConnect VPN client.
Step 4 Click Save.
Related Topics
Configure Connection Profile Settings, on page 958
Note You can use the IP address from the existing IP pools in Firepower Management Center or create a new pool
using the Add option. Also, you can create an IP pool in Firepower Management Center using the Objects
> Object Management > Address Pools path. For more information, see Address Pools, on page 531.
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Existing remote access policies are listed.
Step 2 Select a remote access VPN policy click Edit.
Step 3 Select the connection profile that you want to update and click Edit > Client Address Assignment.
Step 4 Select the following for Address Pools:
a) Click Add to add IP addresses, and select IPv4 or IPv6 to add the corresponding address pool. Select the IP address
pool from Available Pools and click Add.
Note If you share your remote access VPN policy among multiple Firepower Threat Defense devices, bear in
mind that all devices share the same address pool unless you use device-level object overrides to replace
the global definition with a unique address pool for each device. Unique address pools are required to avoid
overlapping addresses in cases where the devices are not using NAT.
b) Select the Add icon in the Address Pools window to add a new IPv4 or IPv6 address pool. When you choose the
IPv4 pool, provide a starting and ending IP address. When you choose to include a new IPv6 address pool, enter
Number of Addresses in the range 1-16384. Select the Allow Overrides option to avoid conflicts with IP
address when objects are shared across many devices. For more information, see Address Pools, on page 531.
c) Click OK.
Step 5 Select the following for DHCP Servers:
Note The DHCP server address can be configured only with IPv4 address.
a) Specify the name and DHCP (Dynamic Host Configuration Protocol) server address as network objects. Click Add
to choose the server from the object list. Click Delete to delete a DHCP server.
b) Click Add in the New Objects page to add a new network object. Enter the new object name, description, network,
and select the Allow Overrides option as applicable. For more information, see Creating Network Objects, on page
450 and Allowing Object Overrides, on page 447.
c) Click OK.
Step 6 Click Save.
Related Topics
Configure Connection Profile Settings, on page 958
• GN (Given Name)
• I (Initial)
• L (Locality)
• N (Name)
• O (Organisation)
• OU (Organisational Unit)
• SER (Serial Number)
• SN (Surname)
• SP (State Province)
• T (Title)
• UID (User ID)
• UPN (User Principal Name)
• Client Certificate & AAA— Each user is authenticated with both a client certificate and AAA server.
Whichever authentication method you choose, select or deselect Allow connection only if user exists in
authorization database.
• Authentication Server—Authentication is the way a user is identified before being allowed access to the network
and network services. Authentication requires valid user credentials, a certificate, or both. You can use authentication
alone, or with authorization and accounting.
Select an LDAP or AD realm, or a RADIUS server group that has been previously configured to authenticate Remote
Access VPN users.
• Use secondary authentication — Secondary authentication is configured in addition to primary authentication to
provide additional security for VPN sessions. Secondary authentication is applicable only to AAA only and Client
Certificate & AAA authentication methods.
Secondary authentication is an optional feature that requires a VPN user to enter two sets of username and password
on the AnyConnect login screen. You can also configure to pre-fill the secondary username from the authentication
server or client certificate. Remote access VPN authentication is granted only if both primary and secondary
authentications are successful. VPN authentication is denied if any one of the authentication servers is not reachable
or one authentication fails.
You must configure a secondary authentication server group (AAA server) for the second username and password
before configuring secondary authentication. For example, you can set the primary authentication server to an LDAP
or Active Directory realm and the secondary authentication to a RADIUS server.
Note By default, secondary authentication is not required.
Authentication Server— Secondary authentication server to provide secondary username and password for VPN
users.
Select the following under Username for secondary authentication:
• Prompt: Prompts the users to enter the username and password while logging on to VPN gateway.
• Use primary authentication username: The username is taken from the primary authentication server for
both primary and secondary authentication; you must enter two passwords.
• Map username from client certificate: Prefills the secondary username from the client certificate.
• If you select Map specific field option, which includes the username from the client certificate. The
Primary and Secondary fields display default values: CN (Common Name) and OU (Organisational
Unit) respectively. If you select the Use entire DN (Distinguished Name) as username option, the system
automatically retrieves the user identity.
See Authentication Method descriptions for more information about primary and secondary field mapping.
• Prefill username from certificate on user login window: Prefills the secondary username from the client
certificate when the user connects via AnyConnect VPN client.
• Hide username in login window: The secondary username is pre-filled from the client certificate,
but hidden to the user so that the user does not modify the pre-filled username.
• Use secondary username for VPN session: The secondary username is used for reporting user activity during
a VPN session.
Specify the RADIUS Server Group object that will be used to account for the Remote Access VPN session.
Related Topics
Understanding Policy Enforcement of Permissions and Attributes, on page 947
Manage a Realm, on page 2083
Note Firepower Threat Defense devices support attributes with vendor ID 3076.
The following user authorization attributes are sent to the Firepower Threat Defense device from the RADIUS
server.
• RADIUS attributes 146 and 150 are sent from Firepower Threat Defense devices to the RADIUS server
for authentication and authorization requests.
• All three (146, 150, and 151) attributes are sent from Firepower Threat Defense devices to the RADIUS
server for accounting start, interim-update, and stop requests.
Table 83: RADIUS Attributes Sent from Firepower Threat Defense to RADIUS Server
Attribute Single or
Attribute Number Syntax, Type Multi-valued Description or Value
Client Type 150 Integer Single 2 = AnyConnect Client SSL VPN, 6 = AnyConnect
Client IPsec VPN (IKEv2)
Attribute Single or
Attribute Number Syntax, Type Multi-valued Description or Value
Session Type 151 Integer Single 1 = AnyConnect Client SSL VPN, 2 = AnyConnect
Client IPsec VPN (IKEv2)
Attribute Single or
Attribute Number Syntax, Type Multi-valued Description or Value
Access-List-Inbound 86 String Single Both of the Access-List attributes take the name of an
ACL that is configured on the FTD device. Create these
Access-List-Outbound 87 String Single ACLs using the Smart CLI Extended Access List object
type (select Device > Advanced Configuration >
Smart CLI > Objects).
These ACLs control traffic flow in the inbound (traffic
entering the FTD device) or outbound (traffic leaving
the FTD device) direction.
Address-Pools 217 String Single The name of a network object defined on the FTD device
that identifies a subnet, which will be used as the address
pool for clients connecting to the RA VPN. Define the
network object on the Objects page.
Banner1 15 String Single The banner to display when the user logs in.
Banner2 36 String Single The second part of the banner to display when the user
logs in. Banner2 is appended to Banner1.
Filter ACLs 86, 87 String Single Filter ACLs are referred to by ACL name in the
RADIUS server. It requires the ACL configuration to
be already present on the Firepower Threat Defense
device, so that it can be used during RADIUS
authorization.
86=Access-List-Inbound
87=Access-List-Outbound
Group-Policy 25 String Single The group policy to use in the connection. You must
create the group policy on the RA VPN Group Policy
page. You can use one of the following formats:
• group policy name
• OU=group policy name
• OU=group policy name;
Attribute Single or
Attribute Number Syntax, Type Multi-valued Description or Value
VLAN 140 Integer Single The VLAN on which to confine the user's connection,
0 - 4094. You must also configure this VLAN on a
subinterface on the FTD device.
Related Topics
Configure Connection Profile Settings, on page 958
• DTLS Port Number—The UDP port to use for DTLS connections. The default port is 443.
• SSL Global Identity Certificate— The selected SSL Global Identity Certificate will be used for all the associated
interfaces if the Interface Specific Identity Certificate is not provided.
Step 7 For IPsec-IKEv2 Settings, select the IKEv2 Identity Certificate from the list or add an identity certificate.
Step 8 Under the Access Control for VPN Traffic section, select the following option if you want to bypass access control
policy:
• Bypass Access Control policy for decrypted traffic (sysopt permit-vpn) — Decrypted traffic is subjected to
Access Control Policy inspection by default. Enabling the Bypass Access Control policy for decrypted traffic option
bypasses the ACL inspection, but VPN Filter ACL and authorization ACL downloaded from AAA server are still
applied to VPN traffic.
Note If you select this option, you need not update the access control policy for remote access VPN as specified
in Update the Access Control Policy on the Firepower Threat Defense Device, on page 955.
Related Topics
Interface Objects: Interface Groups and Security Zones, on page 456
Adding a Cisco AnyConnect Mobility Client Image to the Firepower Management Center
You can upload the Cisco AnyConnect Mobility client image to the Firepower Management Center by using
the AnyConnect File object. For more information, see FTD File Objects, on page 530. For more information
about the client image, see Cisco AnyConnect Secure Mobility Client Image, on page 968.
Click Show re-order link to view a specific client image.
Note To delete an already installed Cisco AnyConnect client image, click Delete in that row.
Step 1 On the Firepower Management Center web interface, choose Devices > VPN > Remote Access, choose and edit a listed
RA VPN policy, then choose the Advanced tab.
Step 2 Click Add in the Available AnyConnect Images portion of the AnyConnect Images dialog.
Step 3 Enter the Name, File Name, and Description for the available AnyConnect Image.
Step 4 Click Browse to navigate to the location for selecting the client image to be uploaded.
Step 5 Click Save to upload the image in the Firepower Management Center.
Once you upload the client image to the Firepower Management Center, the operating system displays platform information
for the image that you uploaded to the Firepower Management Center.
Related Topics
Cisco AnyConnect Secure Mobility Client Image, on page 968
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click Edit.
Step 3 Click Advanced > AnyConnect Client Image> Add.
Step 4 Select a client image file from Available AnyConnect Images and click Add.
If the required AnyConnect client image is not listed, click Add to browse and upload an image.
Related Topics
Remote Access VPN Connection Profile Options
• Reuse an IP address so many minutes after it is released—Delays the reuse of an IP address after its
return to the address pool. Adding a delay helps to prevent problems firewalls can experience when an
IP address is reassigned quickly. By default, the delay is set to zero, meaning the Firepower Threat
Defense device does not impose a delay in reusing the IP address. If you want to extend the delay, enter
the number of minutes in the range 0 - 480 to delay the IP address reassignment. This configurable
element is available for IPv4 assignment policies.
Related Topics
Configure Connection Profile Settings, on page 958
Remote Access VPN Authentication, on page 946
Note Configuring a certificate mapping implies certificate-based authentication. The remote user will be prompted
for a client certificate regardless of the configured Authentication Method.
Step 5 Under the Certificate to Connection Profile Mapping section, click Add Mapping to create certificate to connection
profile mapping for this policy.
a) Choose or create a Certificate Map object.
b) Select the Connection Profile that should be used if the rules in the certificate map object are satisfied.
c) Click OK to create the mapping.
Step 6 Click Save.
Note There is no group policy attribute inheritance on the FTD. 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.
Step 4 Select one or more group policies to associate with this remote access VPN policy. These are above and beyond the
default group policy assigned during the remote access VPN policy creation. Click Add.
Use the Refresh and Search utilities to locate the group policy. Add a new group policy object if necessary.
Step 5 Select group policies from the available group policy and click Add to select them.
Step 6 Click OK to complete the group policy selection.
Related Topics
Configure Group Policy Objects, on page 524
Step 4 Use the navigation pane to edit the following IPsec options:
a) Crypto Maps—The Crypto Maps page lists the interface groups on which IKEv2 protocol is enabled. Crypto Maps
are auto generated for the interfaces on which IKEv2 protocol is enabled. To edit a Crypto Map, see Configure Remote
Access VPN Crypto Maps, on page 972. You can add or remove interface groups to the selected VPN policy in Access
Interface. See Configure Access Interfaces for Remote Access VPN, on page 967 for more information.
b) IKE Policy—The IKE Policy page lists all the IKE policy objects applicable for the selected VPN policy when
AnyConnect endpoints connect using the IPsec protocol. See IKE Policies in Remote Access VPNs, on page 974 for
more information. To add a new IKE policy, see Configure IKEv2 Policy Objects , on page 521. FTD supports only
AnyConnect IKEv2 clients. Third-party standard IKEv2 clients are not supported.
c) IPsec/IKEv2 Parameters—The IPsec/IKEv2 Parameters page enables you to modify the IKEv2 session settings,
IKEv2 Security Association settings, IPsec settings, and NAT Transparency settings. See Configure Remote Access
VPN IPsec/IKEv2 Parameters, on page 975 for more information.
Step 5 Click Save.
Step 4 Select IKEv2 IPsec Proposals and select the transform sets to specify which authentication and encryption algorithms
will be used to secure the traffic in the tunnel.
Step 5 Select Enable Reverse Route Injection to enable static routes to be automatically inserted into the routing process for
those networks and hosts protected by a remote tunnel endpoint.
Step 6 Select Enable Client Services and specify the port number.
The Client Services Server provides HTTPS (SSL) access to allow the AnyConnect Downloader to receive software
upgrades, profiles, localization and customization files, CSD, SCEP, and other file downloads required by the AnyConnect
client. If you select this option, specify the client services port number. If you do not enable the Client Services Server,
users will not be able to download any of these files that the AnyConnect client might need.
Note You can use the same port that you use for SSL VPN running on the same device. Even if you have an SSL
VPN configured, you must select this option to enable file downloads over SSL for IPsec-IKEv2 clients.
Step 7 Select Enable Perfect Forward Secrecy and select the Modulus group.
Use Perfect Forward Secrecy (PFS) to generate and use a unique session key for each encrypted exchange. The unique
session key protects the exchange from subsequent decryption, even if the entire exchange was recorded and the attacker
has obtained the preshared or private keys used by the endpoint devices. If you select this option, also select the
Diffie-Hellman key derivation algorithm to use when generating the PFS session key in the Modulus Group list.
Modulus group is the Diffie-Hellman group to use for deriving a shared secret between the two IPsec peers without
transmitting it to each other. A larger modulus provides higher security but requires more processing time. The two
peers must have a matching modulus group. Select the modulus group that you want to allow in the remote access VPN
configuration:
• 1—Diffie-Hellman Group 1 (768-bit modulus).
• 2—Diffie-Hellman Group 2 (1024-bit modulus).
• 5—Diffie-Hellman Group 5 (1536-bit modulus, considered good protection for 128-bit keys, but group 14 is
better). If you are using AES encryption, use this group (or higher).
• 14—Diffie-Hellman Group 14 (2048-bit modulus, considered good protection for 128-bit keys).
• 19—Diffie-Hellman Group 19 (256-bit elliptical curve field size).
• 20—Diffie-Hellman Group 20 (384-bit elliptical curve field size).
• 21—Diffie-Hellman Group 21 (521-bit elliptical curve field size).
• 24—Diffie-Hellman Group 24 (2048-bit modulus and 256-bit prime order subgroup).
You can specify a value from 10 to 2147483647 kbytes. The default is 4,608,000 kilobytes. No specification allows
infinite data.
• Select Enable Traffic Flow Confidentiality (TFC) Packets— Enable dummy TFC packets that mask the traffic
profile which traverses the tunnel. Use the Burst, Payload Size, and Timeout parameters to generate random
length packets at random intervals across the specified SA.
• Burst—Specify a value from 1 to 16 bytes.
• Payload Size—Specify a value from 64 to 1024 bytes.
• Timeout—Specify a value from 10 to 60 seconds.
Related Topics
Interface Objects: Interface Groups and Security Zones, on page 456
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 remote access IPsec VPN.
Related Topics
Remote Access VPN Access Interface Options
• Hostname—Uses the fully qualified domain name (FQDN) of the hosts exchanging ISAKMP identity
information. This name comprises the hostname and the domain name.
• Enable Notification on Tunnel Disconnect—Allows an administrator to enable or disable the sending of an IKE
notification to the peer when an inbound packet that is received on an SA does not match the traffic selectors for
that SA. Sending this notification is disabled by default.
• Do not allow device reboot until all sessions are terminated—Check to enable waiting for all active sessions to
voluntarily terminate before the system reboots. This is disabled by default.
Step 5 Select the following for IKEv2 Security Association (SA) Settings:
• Cookie Challenge—Whether to send cookie challenges to peer devices in response to SA initiated packets, which
can help thwart denial of service (DoS) attacks. The default is to use cookie challenges when 50% of the available
SAs are in negotiation. Select one of these options:
• Custom—Specify Threshold to Challenge Incoming Cookies, the percentage of the total allowed SAs that
are in-negotiation. This triggers cookie challenges for any future SA negotiations. The range is zero to 100%.
The default is 50%.
• Always— Select to send cookie challenges to peer devices always.
• Never— Select to never send cookie challenges to peer devices.
•
• Number of SAs Allowed in Negotiation—Limits the maximum number of SAs that can be in negotiation at any
time. If used with Cookie Challenge, configure the cookie challenge threshold lower than this limit for an effective
cross-check. The default is 100 %.
• Maximum number of SAs Allowed—Limits the number of allowed IKEv2 connections.
Step Configure a RADIUS server object with RADIUS Server Group Options, on page 533
2 dynamic authorization.
Step Configure a route to ISE server through an RADIUS Server Group Options, on page 533
3 interface enabled for change of
Configure ISE/ISE-PIC for User Control, on page 2100
authorization (CoA) to establish
connectivity from Firepower Threat
Defense to RADIUS server through routing
or a specific interface.
Step Configure a remote access VPN policy and Create a New Remote Access VPN Policy, on page 953
4 select the RADIUS server group object that
you have created with dynamic
authorization.
Step Configure the DNS server details and Configure DNS, on page 956
5 domain-lookup interfaces using the
DNS Server Group Objects, on page 508
Platform Settings.
Step Configure a split-tunnel in group policy to Configure Group Policy Objects, on page 524
6 allow DNS traffic through Remote Access
VPN tunnel if the DNS server is reachable
through VNP network.
Step Deploy the configuration changes. Deploy Configuration Changes, on page 385
7
Two-Factor Authentication
You can configure two-factor authentication for the remote access VPN. With two-factor authentication, the
user must supply a username and static password, plus an additional item such as an RSA token or a passcode.
Two-factor authentication differs from using a second authentication source in that two-factor is configured
on a single authentication source, with the relationship to the RSA server tied to the primary authentication
source.
Firepower Threat Defense supports RSA tokens and Duo Push authentication requests to Duo Mobile for the
second factor in conjunction with any RADIUS or AD server as the first factor in the two-factor authentication
process.
Figure 37: Two-Factory Authentication
Step Create a RADIUS server group. RADIUS Server Group Options, on page 533
2
Step Create a RADIUS Server object within the RADIUS Server Options, on page 534
3 new RADIUS server group, with RADIUS
Note The RADIUS or AD server must be the same
or AD server as the host and with a timeout
server that is configured as the authentication
of 60 seconds or more.
agent in RSA server.
For two-factor authentication, make sure that
the timeout is updated to 60 seconds or more
in the AnyConnect client profile XML file as
well.
Step Configure a new remote access VPN policy Create a New Remote Access VPN Policy, on page 953
4 using the wizard or edit an existing remote
access VPN policy.
Step Select RADIUS as the authentication server Configure AAA Settings for Remote Access VPN, on
5 and then select the newly-created RADIUS page 961
server group as the authentication server.
Step Deploy the configuration changes. Deploy Configuration Changes, on page 385
7
• Windows: https://dl.duosecurity.com/duoauthproxy-latest.exe
• Linux: https://dl.duosecurity.com/duoauthproxy-latest-src.tgz
• Verify the checksum at https://duo.com/docs/checksums#duo-authentication-proxy.
Step Create a RADIUS server group. RADIUS Server Group Options, on page 533
2
Step Create a RADIUS Server object within the RADIUS Server Options, on page 534
3 new RADIUS server group with Duo proxy
Note For two-factor authentication, make sure that
server as the host with a timeout of 60
the timeout is updated to 60 seconds or more
seconds or more.
in the AnyConnect client profile XML file as
well.
Step Configure a new remote access VPN policy Create a New Remote Access VPN Policy, on page 953
4 using the wizard or edit an existing remote
access VPN policy.
Step Select RADIUS as the authentication server Configure AAA Settings for Remote Access VPN, on
5 and then select the RADIUS server group page 961
created with the Duo proxy server as the
authentication server.
Step Deploy the configuration changes. Deploy Configuration Changes, on page 385
7
Secondary Authentication
Secondary authentication or double authentication in Firepower Threat Defense adds an additional layer of
security to remote access VPN connections by using two different authentication servers. With secondary
authentication enabled, an AnyConnect VPN user must provide two sets of credentials to login to the VPN
gateway.
Firepower Threat Defense remote access VPN supports secondary authentication in AAA Only and Client
Certificate & AAA authentication methods.
Figure 38: Remote Access VPN Secondary or Double Authentication
Related Topics
Configure Remote Access VPN Secondary Authentication, on page 982
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a remote access policy and click Edit; or click Add to create a new remote access VPN policy.
Step 3 For a new remote access VPN policy, configure the authentication while selecting connection profile settings. For an
existing configuration, select the connection profile that includes the client profile, and click Edit.
Step 4 Click AAA > Authentication Method, AAA or Client Certificate & AAA.
• When you select the Authentication Method as:
Client Certificate & AAA—Authentication is done using both client certificate and AAA server.
• AAA—If you select the Authentication Server as RADIUS, by default, the Authorization Server has the same
value. Select the Accounting Server from the drop-down list. Whenever you select AD and LDAP from the
Authentication Server drop-down list, you must manually select the Authorization Server and Accounting
Server respectively.
• Whichever authentication method you choose, select or deselect Allow connection only if user exists in
authorization database.
Authentication Server— Secondary authentication server to provide secondary username and password for VPN
users.
Select the following under Username for secondary authentication:
• Prompt: Prompts the users to enter the username and password while logging on to VPN gateway.
• Use primary authentication username: The username is taken from the primary authentication server for
both primary and secondary authentication; you must enter two passwords.
• Map username from client certificate: Prefills the secondary username from the client certificate.
• If you select Map specific field option, which includes the username from the client certificate. The
Primary and Secondary fields display default values: CN (Common Name) and OU (Organisational
Unit) respectively. If you select the Use entire DN (Distinguished Name) as username option, the system
automatically retrieves the user identity.
See Authentication Method descriptions for more information about primary and secondary field mapping.
• Prefill username from certificate on user login window: Prefills the secondary username from the client
certificate when the user connects via AnyConnect VPN client.
• Hide username in login window: The secondary username is pre-filled from the client certificate,
but hidden to the user so that the user does not modify the pre-filled username.
• Use secondary username for VPN session: The secondary username is used for reporting user activity during
a VPN session.
For more information, see Configure AAA Settings for Remote Access VPN, on page 961.
Related Topics
Configure Connection Profile Settings, on page 958
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a remote access policy and click Edit; or click Add to create a new remote access VPN policy.
Step 3 For a new remote access VPN policy, configure the authentication while selecting connection profile settings. For an
existing configuration, select the connection profile that includes the client profile, and click Edit.
Step 4 Click AAA > Authentication Method > Client Certificate Only.
With this authentication method, the user is authenticated using a client certificate. You must configure the client certificate
on VPN client endpoints. By default, the user name is derived from client certificate fields CN and OU respectively. If
the user name is specified in other fields in the client certificate, use 'Primary' and 'Secondary' field to map appropriate
fields.
If you select Map specific field option, which includes the username from the client certificate. The Primary and
Secondary fields display the following default values, respectively: CN (Common Name) and OU (Organisational
Unit) respectively. If you select the Use entire DN as username option, the system automatically retrieves the user
identity. A distinguished name (DN) is a unique identification, made up of individual fields, that can be used as the
identifier when matching users to a connection profile. DN rules are used for enhanced certificate authentication.
• Primary and Secondary fields pertaining to the Map specific field option contains these common values:
• C (Country)
• CN (Common Name)
• DNQ (DN Qualifier
• EA (Email Address)
• GENQ (Generational Qualifier)
• GN (Given Name)
• I (Initial)
• L (Locality)
• N (Name)
• O (Organisation)
• OU (Organisational Unit)
• SER (Serial Number)
• SN (Surname)
• SP (State Province)
• T (Title)
• UID (User ID)
• UPN (User Principal Name)
• Whichever authentication method you choose, select or deselect Allow connection only if user exists in authorization
database.
For more information, see Configure AAA Settings for Remote Access VPN, on page 961.
Related Topics
Configure Connection Profile Settings, on page 958
Adding Certificate Enrollment Objects, on page 502
Configure Remote Access VPN Login via Client Certificate and AAA Server
When remote access VPN authentication is configured to use both client certificate and authentication server,
VPN client authentication is done using both the client certificate validation and AAA server.
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a existing remote access policy and click Edit; or click Add to create a new remote access VPN policy.
Step 3 For a new remote access VPN policy, configure the authentication while selecting connection profile settings. For an
existing configuration, select the connection profile that includes the client profile, and click Edit.
Step 4 Click AAA > Authentication Method, Client Certificate & AAA.
• Whichever authentication method you choose, select or deselect Allow connection only if user exists in
authorization database.
For more information, see Configure AAA Settings for Remote Access VPN, on page 961.
Related Topics
Configure Connection Profile Settings, on page 958
Adding Certificate Enrollment Objects, on page 502
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a remote access policy and click Edit.
Step 3 Select the connection profile that includes AAA settings and click Edit.
Step 4 Select AAA > Advanced Settings > Password Management.
Step 5 Select Enable Password Management and select one of the following:
• Notify User - Notify user ahead of password expiry; specify the number of days in the box.
• Notify user on the day of password expiration - Notify user on the day their passwords expire.
Related Topics
Configure Connection Profile Settings, on page 958
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Create a remote access VPN policy with LDAP or AD realm object as the authentication server. Or edit an existing remote
access VPN configuration and select LDAP or AD realm as the authentication server.
Step 3 Choose Objects > Object Management > FlexConfig > FlexConfig Object.
Step 4 Create a FlexConfig policy and create and assign the following two FlexConfig objects in the append section:
See Configure the FlexConfig Policy, on page 1060.
a) Create the FlexConfig Object for LDAP Attribute Map with Deployment type: Once and Type: Append.
Enter the following in the object body:
lda attribute-map <LDAP_Map_for_VPN_Access>
map-name memberOf Group-Policy
map-value memberOf CN=APP-SSL-VPN Managers,CN=Users,OU=stbu,DC=cisco,DC=com
LabAdminAccessGroupPolicy
map-value memberOf CN=cisco-Eng,CN=Users,OU=stbu,DC=cisco,DC=com VPNAccessGroupPolicy
b) Create a FlexConfig Object associating the LDAP attribute map to the LDAP AAA-server, with Deployment type:
Everytime and Type: Append.
Note This mapping is required to reinstate the LDAP-attribute-map association because it is negated by Firepower
Management Center.
Use the same aaa-server same as the LDAP realm name used in the AAA server settings of the connection profile
that you have added to the remote access VPN policy configuration.
For more information, see Configure FlexConfig Text Objects, on page 1059.
a) Click Save.
Make sure the order of the FlexConfig objects in the FlexConfig Policy is the LDAP Attribute Map FlexConfig object
followed by the AAA-server object.
This will configure the LDAP attribute map and associate it with the LDAP server configuration on the Firepower Threat
Defense device.
Related Topics
Configure FlexConfig Objects, on page 1055
Note You can use the same RADIUS server or separate RADIUS servers for authentication, authorization, and
accounting in remote access VPN AAA settings.
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a remote access policy and click Edit, or create a new remote access VPN policy.
Step 3 Select the connection profile that includes AAA settings and click Edit > AAA.
Step 4 Select a RADIUS server as the Accounting Server.
Step 5 Click Save.
Related Topics
Configure Connection Profile Settings, on page 958
Configure AAA Settings for Remote Access VPN, on page 961
Figure 39: Remote Access VPN Group Policy Selection by AAA Server
Related Topics
Configure Group Policy Objects, on page 524
Configure Connection Profile Settings, on page 958
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a remote access policy and click Edit.
Step 3 Select RADIUS or ISE as the authorization server if not configured already.
Step 4 Select Advanced > Group Policies and add the required group policy. For detailed information about a group policy
object, see Configure Group Policy Objects, on page 524.
You can map only one group policy to a connection profile; but you can create multiple group policies in a remote access
VPN policy. These group policies can be referenced in ISE or the RADIUS server and configured to override the group
policy configured in the connection profile by assigning the authorization attributes in the authorization server.
Step 5 Deploy the configuration on the target Firepower Threat Defense device.
Step 6 On the authorization server, create an Authorization Profile with RADIUS attributes for IP address and downloadable
ACLs.
When the group policy is configured in the authorization server selected for remote access VPN, the group policy overrides
the group policy configured in the connection profile for the remote access VPN user after the user is authenticated.
Related Topics
Configure Group Policy Objects, on page 524
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a remote access policy and click Edit.
Step 3 Select Advanced > Group Policies.
Step 4 Select a group policy and click Edit or add a new group policy.
Step 5 Select Advanced > Session Settings and set Simultaneous Login Per User to 0 (zero).
This stops the user or user group from connecting to the VPN even once.
Step 6 Click Save to save the group policy and then save the remote access VPN configuration.
Step 7 Configure ISE or the RADIUS server to set the Authorization Profile for that user/user-group to send IETF RADIUS
Attribute 25 and map to the corresponding group policy name.
Step 8 Configure the ISE or RADIUS server as the authorization server in the remote access VPN policy.
Step 9 Save and deploy the remote access VPN policy.
Related Topics
Configure Connection Profile Settings, on page 958
The AnyConnect client, by default, shows a list of the connection profiles ( by connection profile name, alias,
or alias URL) configured in Firepower Management Center and deployed on Firepower Threat Defense. If
custom connection profiles are not configured, AnyConnect shows the DefaultWEBVPNGroup connection
profile. Use the following procedure to enforce a single connection profile for a user group.
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a remote access policy and click Edit.
Step 3 Select Access Interfaces and disable Allow users to select connection profile while logging in.
Step 4 Click Advanced > Certificate Maps.
Step 5 Select Use the configured rules to match a certificate to a Connection Profile.
Step 6 Select the Certificate Map Name or click the Add icon to add a certificate rule.
Step 7 Select the Connection Profile, and click Ok.
With this configuration, when a user connects from the AnyConnect client, the user will have the mapped connection
profile and will be authenticated to use the VPN.
Related Topics
Configure Group Policy Objects, on page 524
Configure Connection Profile Settings, on page 958
Update the AnyConnect Client Profile for Remote Access VPN Clients
AnyConnect Client Profile is an XML file that contains an administrator-defined end user requirements and
authentication policies to be deployed on a VPN client system as part of AnyConnect. It makes the preconfigured
network profiles available to end users.
You can use the GUI-based AnyConnect Profile Editor, an independent configuration tool, to create an
AnyConnect Client Profile. The standalone profile editor can be used to create a new or modify existing
AnyConnect profile. You can download the profile editor from Cisco Software Download Center.
See the AnyConnect Profile Editor chapter in the appropriate release of the Cisco AnyConnect Secure Mobility
Client Administrator Guide for details.
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select a remote access VPN policy and click Edit.
Step 3 Select the connection profile that includes the client profile to be edited, and click Edit.
Step 4 Click Edit Group Policy > AnyConnect > Profiles.
Step 5 Select the client profile XML file from the list or click Add to add a new client profile.
Step 6 Save the group policy, connection profile, and then the remote access VPN policy.
Step 7 Deploy the changes.
Changes to the client profile will be updated on the VPN clients when they connect to the remote access VPN gateway.
Related Topics
Configure Group Policy Objects, on page 524
Step Create and set up a realm. Create and Set up an Active Directory Realm, on page
1 993.
Step Create a QoS policy and QoS rule for the Create a QoS Policy and Rule, on page 994
2 user or group available in the newly created
realm.
Step Configure a remote access VPN policy and Create or Update a Remote Access VPN Policy, on page
3 select the newly-created realm for user 995
authentication.
Step Deploy the remote access VPN policy. Deploy Configuration Changes, on page 385
4
Step 1 On your Firepower Management Center web interface, choose System > Integration > Realms.
Step 2 Click New realm, specify the realm details, and click OK.
Step 3 Enter the required details on the following tabs and then click Save:
• Directory—You can specify more than one directory for a realm, in which case each domain controller is queried
in the order listed on the realm's Directory page to match user and group credentials for user control.
See Configure a Realm Directory, on page 2080.
• Realm Configuration—You can update the realm settings entered while creating the realm.
• User Download—You can include or exclude users and groups from being downloaded to Firepower Management
Center.
Step 4 Slide State to the right to enable a realm to be able to use it for user control. See Manage a Realm, on page 2083.
Step 5 Click download to download users and user groups to Firepower Management Center. See Download Users and Groups,
on page 2082.
Step 6 Click Save.
Related Topics
Create a Realm, on page 2073
Step 1 On your Firepower Management Center web interface, choose Devices > QoS > New Policy.
Step 2 Enter a Name and, optionally, a Description.
Step 3 Choose the Available Devices where you want to deploy the QoS policy, then click Add to Policy, or drag and drop to
the Selected Devices.
Note Select the same device where you want to deploy the remote access VPN policy. You must assign devices
before you deploy the policy.
Related Topics
Creating a QoS Policy, on page 707
Rate Limiting with QoS Policies, on page 706
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Create a new remote access VPN policy using the wizard. And select the newly-created realm as the Authentication
Server or edit an existing remote access VPN policy and performing the following:
a) Select the connection profile that you want to assign for your VPN users and click Edit.
b) Select AAA > Authentication Method > AAA or Certificate & AAA.
c) Select the required realm as the Authentication Server.
d) Update other connection profile options, if required, and save the connection profile.
Step 3 Complete the required configurations for remote access VPN policy and click Save.
Related Topics
Configuring a New Remote Access VPN Connection, on page 952
Configure Connection Profile Settings, on page 958
How to Use VPN Identity for User-id Based Access Control Rules
Do This More Info
Step Create and set up a realm. Create and Set up an Active Directory Realm, on page
1 993.
Step Create an identity policy and add an Create an Identity Policy and an Identity Rule, on page
2 identity rule. 996.
Step Associate the identity policy with an access Associate an Identity Policy with an Access Control
3 control policy. Policy, on page 997
Step Configure a remote access VPN policy and Create or Update a Remote Access VPN Policy, on page
4 select the newly-created realm for user 995
authentication.
Step Deploy the remote access VPN policy. Deploy Configuration Changes, on page 385
5
Step 1 On your Firepower Management Center web interface, choose System > Integration > Realms.
Step 2 Click New realm, specify the realm details, and click OK.
Step 3 Enter the required details on the following tabs and then click Save:
• Directory—You can specify more than one directory for a realm, in which case each domain controller is queried
in the order listed on the realm's Directory page to match user and group credentials for user control.
See Configure a Realm Directory, on page 2080.
• Realm Configuration—You can update the realm settings entered while creating the realm.
• User Download—You can include or exclude users and groups from being downloaded to Firepower Management
Center.
Step 4 Slide State to the right to enable a realm to be able to use it for user control. See Manage a Realm, on page 2083.
Step 5 Click download to download users and user groups to Firepower Management Center. See Download Users and Groups,
on page 2082.
Step 6 Click Save.
Related Topics
Create a Realm, on page 2073
Step 1 On your Firepower Management Center web interface, choose Policies > Access Control > Identity and lick New
Policy.
Step 2 Enter a Name and Description, and then click Save.
Step 3 To add a rule to the policy, click Add Rule, and enter a Name.
Step 4 Specify whether the rule is Enabled.
Step 5 To add the rule to an existing category, indicate where you want to Insert the rule. To add a new category, click Add
Category.
Step 6 Choose a rule Action from the list and select the interface configured in remote access VPN as the source interface.
Step 7 Click Realms & Settings, choose the new realm created for the identity rule from the Realms list. Make sure that you
select the same realm selected for user authentication in remote access VPN policy.
Step 8 Configure your preferred settings for the users in the selected realm and select other required rule options.
Step 9 Click Add to save the rule and then save the identity policy.
Related Topics
Create and Manage Identity Policies, on page 2135
Step 1 On your Firepower Management Center web interface, choose Policies > Access Control > Access Control.
Step 2 Select the required access control policy and click Edit.
Step 3 In the access control policy editor, click Advanced.
Step 4 Click Edit ( ) in the Identity Policy Settings area.
If View ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify
the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Related Topics
Create and Manage Identity Policies, on page 2135
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Create a new remote access VPN policy using the wizard. And select the newly-created realm as the Authentication
Server or edit an existing remote access VPN policy and performing the following:
a) Select the connection profile that you want to assign for your VPN users and click Edit.
b) Select AAA > Authentication Method > AAA or Certificate & AAA.
c) Select the required realm as the Authentication Server.
d) Update other connection profile options, if required, and save the connection profile.
Step 3 Complete the required configurations for remote access VPN policy and click Save.
Related Topics
Configuring a New Remote Access VPN Connection, on page 952
Configure Connection Profile Settings, on page 958
Support for Datagram Transport 6.6 DTLS 1.2 is now part of the default
Layer Security (DTLS) 1.2 SSL cipher group and it can be
configured along with TLS 1.2.
Step 1 Choose Overview > Dashboards > Access Controlled User Statistics > VPN.
Step 2 View the Remote Access VPN information widgets:
• Current VPN Users by Duration.
• Current VPN Users by Client Application.
• Current VPN Users by Device.
• VPN Users by Data Transferred.
• VPN Users by Duration.
• VPN Users by Client Application.
• VPN Users by Client Country.
What to do next
The VPN dashboard is a complex, highly customizable monitoring feature that provides exhaustive data.
• For complete information on how to use dashboards in the Firepower System, see Dashboards, on page
287.
• For information on how to modify the VPN dashboard widgets, see Configuring Widget Preferences, on
page 302.
Note If you have configured your VPN in a high-availability deployment, the device name displayed against active
VPN sessions can be the primary or secondary device that identified the user session.
• To learn more about active sessions; see Viewing Active Session Data, on page 2628.
• To learn more about the contents of the columns in the active sessions table; see Active Sessions, Users,
and User Activity Data, on page 2621.
See Health Monitoring, on page 307 for more details on how you can use the health monitor to check the status
of critical functionality across your Firepower System deployment.
System Messages
The Message Center is the place to start your troubleshooting. This feature allows you to view messages that
are continually generated about system activities and status. To open the Message Center, click System Status,
located to the immediate right of the Deploy button in the main menu. See System Messages, on page 351 for
details on using the Message Center.
Note VPN syslogs are automatically enabled to be sent to the Firepower Management Center by default whenever
a device is configured with site-to-site or remote access VPNs.
Debug Commands
This section explains how you use debug commands to help you diagnose and resolve VPN-related problems.
Not all available debug commands are described in this section. Commands are included here based on the
their usefulness in assisting you to diagnose VPN-related problems.
Usage Guidelines Because debugging output is assigned high priority in the CPU process, it can render the system unusable.
For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions
with the Cisco Technical Assistance Center (TAC). Moreover, it is best to use debug commands during
periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood
that increased debug command processing overhead will affect system use.
You can view debug output in a CLI session only. Output is directly available when connected to the Console
port, or when in the diagnostic CLI (enter system support diagnostic-cli). You can also view output from
the regular Firepower Threat Defense CLI using the show console-output command.
To show debugging messages for a given feature, use the debug command. To disable the display of debug
messages, use the no form of this command. Use no debug all to turn off all debugging commands.
Syntax Description feature Specifies the feature for which you want to enable debugging. To see available
features, use the debug ? command for CLI help.
subfeature (Optional) Depending on the feature, you can enable debug messages for one or
more subfeatures. Use ? to see the available subfeatures.
level (Optional) Specifies the debugging level. The level might not be available for all
features. Use ? to see the available levels.
Example
With multiple sessions running on a remote access VPN, troubleshooting can be difficult given the
size of the logs. You can use the debug webvpn condition command to set up filters to target your
debug process more precisely.
debug webvpn condition {group name | p-ipaddress ip_address [{subnet subnet_mask | prefix
length}] | reset | user name}
Where:
• group name filters on a group policy (not a tunnel group or connection profile).
• p-ipaddress ip_address [{subnet subnet_mask | prefix length}] filters on the public IP address
of the client. The subnet mask (for IPv4) or prefix (for IPv6) is optional.
• reset resets all filters. You can use the no debug webvpn condition command to turn off a
specific filter.
• user name filters by username.
If you configure more than one condition, the conditions are conjoined (ANDed), so that debugs are
shown only if all conditions are met.
After setting up the condition filter, use the base debug webvpn command to turn on the debug.
Simply setting the conditions does not enable the debug. Use the show debug and show webvpn
debug-condition commands to view the current state of debugging.
The following shows an example of enabling a conditional debug on the user jdoe.
undebug Disables debugging for a feature. This command is a synonym for no debug.
debug aaa
See the following commands for debugging configurations or settings associated with authentication,
authorization, and accounting (AAA, pronounced “triple A”).
Syntax Description aaa Enables debugging for AAA. Use ? to see the available subfeatures.
common (Optional) Specifies the AAA common debug level. Use ? to see the available
levels.
shim (Optional) Specifies the AAA shim debug level. Use ? to see the available levels.
show debug aaa Shows the currently active debug settings for AAA.
undebug aaa Disables debugging for AAA. This command is a synonym for no debug aaa.
debug crypto
See the following commands for debugging configurations or settings associated with crypto.
debug crypto [ca | condition | engine | ike-common | ikev1 | ikev2 | ipsec | ss-apic]
Syntax Description crypto Enables debugging for crypto. Use ? to see the available subfeatures.
ca (Optional) Specifies the PKI debug levels. Use ? to see the available subfeatures.
condition (Optional) Specifies the IPsec/ISAKMP debug filters. Use ? to see the available
filters.
engine (Optional) Specifies the crypto engine debug levels. Use ? to see the available
levels.
ike-common (Optional) Specifies the IKE common debug levels. Use ? to see the available
levels.
ikev1 (Optional) Specifies the IKE version 1 debug levels. Use ? to see the available
levels.
ikev2 (Optional) Specifies the IKE version 2 debug levels. Use ? to see the available
levels.
ipsec (Optional) Specifies the IPsec debug levels. Use ? to see the available levels.
condition (Optional) Specifies the Crypto Secure Socket API debug levels. Use ? to see the
available levels.
vpnclient (Optional) Specifies the EasyVPN client debug levels. Use ? to see the available
levels.
show debug crypto Shows the currently active debug settings for crypto.
undebug crypto Disables debugging for crypto. This command is a synonym for no debug crypto.
debug crypto ca
See the following commands for debugging configurations or settings associated with crypto ca.
Syntax Description crypto ca Enables debugging for crypto ca. Use ? to see the available subfeatures.
cluster (Optional) Specifies the PKI cluster debug level. Use ? to see the available levels.
cmp (Optional) Specifies the CMP transactions debug level. Use ? to see the available
levels.
messages (Optional) Specifies the PKI Input/Output message debug level. Use ? to see the
available levels.
periodic-authentication (Optional) Specifies the PKI periodic-authentication debug level. Use ? to see
the available levels.
scep-proxy (Optional) Specifies the SCEP proxy debug level. Use ? to see the available
levels.
server (Optional) Specifies the local CA server debug level. Use ? to see the available
levels.
transactions (Optional) Specifies the PKI transaction debug level. Use ? to see the available
levels.
trustpool (Optional) Specifies the trustpool debug level. Use ? to see the available levels.
show debug crypto ca Shows the currently active debug settings for crypto ca.
undebug Disables debugging for crypto ca. This command is a synonym for no debug
crypto ca.
Syntax Description ikev1 Enables debugging for ikev1. Use ? to see the available subfeatures.
show debug crypto ikev1 Shows the currently active debug settings for IKEv1.
undebug crypto ikev1 Disables debugging for IKEv1. This command is a synonym for no debug crypto
ikev1.
Syntax Description ikev2 Enables debugging ikev2. Use ? to see the available subfeatures.
ha (Optional) Specifies the IKEv2 HA debug level. Use ? to see the available levels.
platform (Optional) Specifies the IKEv2 platform debug level. Use ? to see the available
levels.
protocol (Optional) Specifies the IKEv2 protocol debug level. Use ? to see the available
levels.
show debug crypto ikev2 Shows the currently active debug settings for IKEv2.
undebugcrypto ikev2 Disables debugging for IKEv2. This command is a synonym for no debug crypto
ikev2.
Syntax Description ipsec Enables debugging for ipsec. Use ? to see the available subfeatures.
show debug crypto ipsec Shows the currently active debug settings for IPsec.
undebugcrypto ipsec Disables debugging for IPsec. This command is a synonym for no debug crypto
ipsec.
debug ldap
See the following commands for debugging configurations or settings associated with LDAP (Lightweight
Directory Access Protocol).
Syntax Description ldap Enables debugging for LDAP. Use ? to see the available subfeatures.
show debug ldap Shows the currently active debug settings for LDAP.
undebugldap Disables debugging for LDAP. This command is a synonym for no debug ldap.
debug ssl
See the following commands for debugging configurations or settings associated with SSL sessions.
Syntax Description ssl Enables debugging for SSL. Use ? to see the available subfeatures.
cipher (Optional) Specifies the SSL cipher debug level. Use ? to see the available levels.
device (Optional) Specifies the SSL device debug level. Use ? to see the available levels.
show debug ssl Shows the currently active debug settings for SSL.
undebug ssl Disables debugging for SSL. This command is a synonym for no debug ssl.
debug webvpn
See the following commands for debugging configurations or settings associated with WebVPN.
Syntax Description webvpn Enables debugging for WebVPN. Use ? to see the available subfeatures.
anyconnect (Optional) Specifies the WebVPN AnyConnect debug level. Use ? to see the
available levels.
chunk (Optional) Specifies the WebVPN chunk debug level. Use ? to see the available
levels.
cifs (Optional) Specifies the WebVPN CIFS debug level. Use ? to see the available
levels.
citrix (Optional) Specifies the WebVPN Citrix debug level. Use ? to see the available
levels.
compression (Optional) Specifies the WebVPN compression debug level. Use ? to see the
available levels.
condition (Optional) Specifies the WebVPN filter conditions debug level. Use ? to see the
available levels.
cstp-auth (Optional) Specifies the WebVPN CSTP authentication debug level. Use ? to see
the available levels.
customization (Optional) Specifies the WebVPN customization debug level. Use ? to see the
available levels.
failover (Optional) Specifies the WebVPN failover debug level. Use ? to see the available
levels.
html (Optional) Specifies the WebVPN HTML debug level. Use ? to see the available
levels.
javascript (Optional) Specifies the WebVPN Javascript debug level. Use ? to see the
available levels.
kcd (Optional) Specifies the WebVPN KCD debug level. Use ? to see the available
levels.
listener (Optional) Specifies the WebVPN listener debug level. Use ? to see the available
levels.
mus (Optional) Specifies the WebVPN MUS debug level. Use ? to see the available
levels.
nfs (Optional) Specifies the WebVPN NFS debug level. Use ? to see the available
levels.
request (Optional) Specifies the WebVPN request debug level. Use ? to see the available
levels.
response (Optional) Specifies the WebVPN response debug level. Use ? to see the available
levels.
saml (Optional) Specifies the WebVPN SAML debug level. Use ? to see the available
levels.
session (Optional) Specifies the WebVPN session debug level. Use ? to see the available
levels.
task (Optional) Specifies the WebVPN task debug level. Use ? to see the available
levels.
transformation (Optional) Specifies the WebVPN transformation debug level. Use ? to see the
available levels.
url (Optional) Specifies the WebVPN URL debug level. Use ? to see the available
levels.
util (Optional) Specifies the WebVPN utility debug level. Use ? to see the available
levels.
xml (Optional) Specifies the WebVPN XML debug level. Use ? to see the available
levels.
show debug webvpn Shows the currently active debug settings for WebVPN.
undebug webvpn Disables debugging for WebVPN. This command is a synonym for no debug
webvpn.
A given connection can match only one traffic class, either interface-based or global, for a given feature.
There should be at most one rule for a given interface object/traffic flow combination.
Service policy rules are applied after access control rules. These services are configured only for connections
you are allowing.
Note Traffic classes that are created from the Firepower Threat Defense Service Policy are named
class_map_ACLname, where ACLname is the name of the extended ACL object used in the service policy
rule.
using service policy rules to protect servers from denial of service (DoS) attacks. Particularly, you can
set limits on embryonic connections (those that have not finished the TCP handshake), which protects
against SYN flooding attacks. When embryonic limits are exceeded, the TCP Intercept component gets
involved to proxy connections and ensure that attacks are throttled.
• Dead Connection Detection (DCD)—If you have persistent connections that are valid but often idle,
so that they get closed because they exceed idle timeout settings, you can enable Dead Connection
Detection to identify idle but valid connections and keep them alive (by resetting their idle timers).
Whenever idle times are exceeded, DCD probes both sides of the connection to see if both sides agree
the connection is valid. The show service-policy command output includes counters to show the amount
of activity from DCD. You can use the show conn detail command to get information about the initiator
and responder and how often each has sent probes.
• TCP sequence randomization—Each TCP connection has two initial sequence numbers (ISN): one
generated by the client and one generated by the server. By default, the Firepower Threat Defense device
randomizes the ISN of the TCP SYN passing in both the inbound and outbound directions. Randomization
prevents an attacker from predicting the next ISN for a new connection and potentially hijacking the new
session. You can disable randomization per traffic class if desired.
• TCP Normalization—The TCP Normalizer protects against abnormal packets. You can configure how
some types of packet abnormalities are handled by traffic class. You can configure TCP Normalization
using the FlexConfig policy.
• TCP State Bypass—You can bypass TCP state checking if you use asymmetrical routing in your network.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
and interface group, be aware that the actual limitation is based on the interfaces, and not the zone/group.
Thus, you might be prevented from having 25 rules per zone/group based on the membership of your
zones/groups.
• You can have at most one rule for a given interface object/traffic flow combination.
• When you make service policy changes to the configuration, all new connections use the new service
policy. Existing connections continue to use the policy that was configured at the time of the connection
establishment. If you want all connections to immediately use the new policy, you need to disconnect
the current connections so they can reconnect using the new policy. From an SSH or Console CLI session,
enter the clear conn or clear local-host commands.
Step 1 Choose Policies > Access Control > Access Control, and click Edit ( ) for the access control policy whose Firepower
Threat Defense Service Policy you want to edit.
Step 2 Click Advanced.
Step 3 Click Edit ( ) in the Threat Defense Service Policy group.
A dialog box opens that shows the existing policy. The policy consists of an ordered list of rules, separated between
global rules (which apply to all interfaces) and interface-based rules. The table shows the interface object and extended
access control list name (which combined defines the traffic class for the rule), and the services applied.
• Click Edit ( ) to edit an existing rule. See Configure a Service Policy Rule, on page 1018.
Step 1 If you are not already in the Firepower Threat Defense Service Policy dialog box, choose Policies > Access Control >
Access Control, edit the access control policy, click Advanced, then edit the Threat Defense Service Policy.
Step 2 Do any of the following:
• Click Add Rule to create a new rule.
The service policy rule wizard opens to step you through the process of configuring the rule.
Step 3 In the Interface Object step, select the option that defines the interfaces that will use the policy.
• Apply Globally—Select this option to create a global rule, which applies to all interfaces.
• Select Interface Objects—Select this option to create an interface-based rule. Then, select the security zones or
interface objects that contain the desired interfaces, and click > to move them to the Nextselected list. The service
policy rule will be configured on each interface contained in the selected objects; it is not configured on the zone/group
itself.
Step 4 In the Traffic Flow step, select the extended ACL object that defines the connections to which the rule applies, then click
Next.
Step 5 In the Connection Setting step, configure the services to apply to this traffic class.
• Enable TCP State Bypass (TCP connections only)—Implement TCP State Bypass. Connections subject to TCP
State Bypass are not inspected by any inspection engines, and they bypass all TCP state checking and TCP
normalization. For detailed information, see Bypass TCP State Checks for Asynchronous Routing (TCP State
Bypass), on page 1021.
Note Use TCP State Bypass for troubleshooting purposes or when asymmetric routing cannot be resolved. This
feature disables multiple security features, which can cause a high number of connections if you do not
implement it properly with a narrowly-defined traffic class.
• Randomize TCP Sequence Number (TCP connections only)—Whether to enable or disable TCP sequence number
randomization. Randomization is enabled by default. For more information, see Disable TCP Sequence Randomization,
on page 1024.
• Enable Decrement TTL (TCP connections only)—Decrement the time-to-live (TTL) on packets that match the
class. If you decrement time to live, packets with a TTL of 1 will be dropped, but a connection will be opened for
the session on the assumption that the connection might contain packets with a greater TTL. Note that some packets,
such as OSPF hello packets, are sent with TTL = 1, so decrementing time to live can have unexpected consequences.
Note If you want the Firepower Threat Defense device to appear on traceroutes, you must configure the decrement
TTL option and also set the ICMP unreachable rate limit in the platform settings policy. See Make the
Firepower Threat Defense Device Appear on Traceroutes, on page 1028.
• Connections—Limits for the number of connections allowed for the entire class. You can configure these options:
• Maximum TCP and UDP (TCP/UDP connections only)—The maximum number of simultaneous connections
that are allowed, between 0 and 2000000, for the entire class. For TCP, this count applies to established
connections only. The default is 0, which allows unlimited connections. Because the limit is applied to a class,
one attacking host can consume all the connections and leave none for the rest of the hosts that are matched to
the class. Set the per-client limit to ameliorate this problem.
• Maximum Embryonic (TCP connections only)—The maximum number of simultaneous embryonic TCP
connections (those that have not finished the TCP handshake) allowed, between 0 and 2000000. The default is
0, which allows unlimited connections. By setting a non-zero limit, you enable TCP Intercept, which protects
inside systems from a DoS attack perpetrated by flooding an interface with TCP SYN packets. Also set the
per-client options to protect against SYN flooding. For more information, see Protect Servers from a SYN
Flood DoS Attack (TCP Intercept), on page 1026.
• Connections Per Client—Limits for the number of connections allowed for a given client (source IP address). You
can configure these options:
• Maximum TCP and UDP (TCP/UDP connections only)—The maximum number of simultaneous connections
allowed per client, between 0 and 2000000. For TCP, this includes established, half-open (embryonic), and
half-closed connections. The default is 0, which allows unlimited connections. This option restricts the maximum
number of simultaneous connections that are allowed for each host that is matched to the class.
• Maximum Embryonic (TCP connections only)—The maximum number of simultaneous embryonic TCP
connections allowed per client, between 0 and 2000000. The default is 0, which allows unlimited connections.
For more information, see Protect Servers from a SYN Flood DoS Attack (TCP Intercept), on page 1026.
• Connections Timeout—The timeout settings to apply to the traffic class. These timeouts override the global timeouts
defined in the platform settings policy. You can configure the following:
• Embryonic (TCP connections only)—The timeout period until a TCP embryonic (half-open) connection is
closed, between 0:0:5 and 1193:00:00. The default is 0:0:30.
• Half Closed (TCP connections only)—The idle timeout period until a half-closed connection is closed, between
0:0:30 and 1193:0:0. The default is 0:10:0. Half-closed connections are not affected by Dead Connection
Detection (DCD). Also, the system does not send a reset when taking down half-closed connections.
• Idle (TCP, UDP, ICMP, IP connections)—The idle timeout period after which an established connection of
any protocol closes, between 0:0:1 and 1193:0:0. The default is 1:0:0, unless you select the TCP State Bypass
option, where the default is 0:2:0.
• Reset Connection Upon Timeout (TCP connections only)—Whether to send a TCP RST packet to both end
systems after idle connections are removed.
• Detect Dead Connections (TCP connections only)—Whether to enable Dead Connection Detection (DCD). Before
expiring an idle connection, the system probes the end hosts to determine if the connection is valid. If both hosts
respond, the connection is preserved, otherwise the connection is freed. When operating in transparent firewall mode,
you must configure static routes for the endpoints. You cannot configure DCD on connections that are also offloaded,
so do not configure DCD on connections you are fast-pathing in the prefilter policy.Use the show conn detail
command in the FTD CLI to track how many DCD probes have been sent by the initiator and responder.
Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass)
If you have an asynchronous routing environment in your network, where the outbound and inbound flow for
a given connection can go through two different Firepower Threat Defense devices, you need to implement
TCP State Bypass on the affected traffic.
However, TCP State Bypass weakens the security of your network, so you should apply bypass on very
specific, limited traffic classes.
The following topics explain the problem and solution in more detail.
If you have asymmetric routing configured on upstream routers, and traffic alternates between two Firepower
Threat Defense devices, then you can configure TCP state bypass for specific traffic. TCP state bypass alters
the way sessions are established in the fast path and disables the fast path checks. This feature treats TCP
traffic much as it treats a UDP connection: when a non-SYN packet matching the specified networks enters
the Firepower Threat Defense device, and there is not a fast path entry, then the packet goes through the
session management path to establish the connection in the fast path. Once in the fast path, the traffic bypasses
the fast path checks.
Step 1 Create the extended ACL that defines the traffic class.
For example, to define a traffic class for TCP traffic from 10.1.1.1 to 10.2.2.2, do the following:
a) Choose Objects > Object Management.
b) Choose Access List > Extended from the table of contents.
c) Click Add Extended Access List.
d) Enter a Name for the object, for example, bypass.
e) Click Add to add a rule.
f) Keep Allow for the action.
g) Enter 10.1.1.1 beneath the Source list and click Add, and 10.2.2.2 beneath the Destination list, and click Add.
h) Click Port, select TCP (6) beneath the Selected Source Ports list, and click Add. Do not enter a port number, simply
add TCP as the protocol, which will cover all ports.
i) Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
j) Click Save on the Extended Access List Object dialog box to save the ACL object.
Step 2 Configure the TCP state bypass service policy rule.
For example, to configure TCP state bypass for this traffic class globally, do the following:
a) Choose Policies > Access Control > Access Control, and edit the policy assigned to the devices that require this
service.
b) Click Advanced, and click Edit ( ) for the Threat Defense Service Policy.
c) Click Add Rule.
d) Select Apply Globally > Next.
e) Select the extended ACL object you created for this rule and click Next.
f) Select Enable TCP State Bypass.
g) (Optional.) Adjust the Idle timeout for bypassed connections. The default is 2 minutes.
h) Click Finish to add the rule. If necessary, drag and drop the rule to the desired position in the service policy.
i) Click OK to save the changes to the service policy.
j) Click Save on Advanced to save the changes to the access control policy.
Step 3 Configure a prefilter fastpath rule for the traffic class.
You cannot use the ACL object in the prefilter rule, so you need to recreate the traffic class either directly in the prefilter
rule, or by first creating network objects that define the class.
The following procedure assumes that you already have a prefilter policy attached to the access control policy. If you
have not created a prefilter policy yet, go to Policies > Access Control > Prefilter and first create the policy. You can
then follow this procedure to attach it to the access control policy and create the rule.
Keeping with our example, this procedure creates a fastpath rule for TCP traffic from 10.1.1.1 to 10.2.2.2.
a) Choose Policies > Access Control > Access Control, and edit the policy that has the TCP bypass service policy
rule.
b) Click the link for the Prefilter Policy, which is to the left immediately under the policy description.
c) In the Prefilter Policy dialog box, select the policy to assign to the device if the correct one is not already selected.
Do not click OK yet.
Because you cannot add rules to the default prefilter policy, you must choose a custom policy.
d) In the Prefilter Policy dialog box, click the Edit ( ). This action opens a new browser window where you can edit
the policy.
e) Click Add Prefilter Rule and configure a rule with the following properties.
• Name—Any name that you fined meaningful will do, such as TCPBypass.
• Action—Select Fastpath.
• Interface Objects—If you configured TCP state bypass as a global rule, leave the default, any, for both source
and destination. If you created an interface-based rule, select the same interface objects you used for rule in the
Source Interface Objects list, and keep any as the destination.
• Networks—Add 10.1.1.1 to the Source Networks list, and 10.2.2.2 to the Destination Networks list. You can
either use network objects or manually add the addresses.
• Ports—Under Selected Source Ports, select TCP(6), do not enter a port, and click Add. This will apply the
rule to all (and only) TCP traffic, regardless of TCP port number.
• If another in-line firewall is also randomizing the initial sequence numbers, there is no need for both
firewalls to be performing this action, even though this action does not affect the traffic.
• If you use eBGP multi-hop through the device, and the eBGP peers are using MD5. Randomization
breaks the MD5 checksum.
• If you use a WAAS device that requires the Firepower Threat Defense device not to randomize the
sequence numbers of connections.
• If you enable hardware bypass for the ISA 3000, and TCP connections are dropped when the ISA 3000
is no longer part of the data path.
Step 1 Create the extended ACL that defines the traffic class.
For example, to define a traffic class for TCP traffic from any host to 10.2.2.2, do the following:
a) Choose Objects > Object Management.
b) Choose Access List > Extended from the table of contents.
c) Click Add Extended Access List.
d) Enter a Name for the object, for example, preserve-sq-no.
e) Click Add to add a rule.
f) Keep Allow for the action.
g) Leave the Source list empty, enter 10.2.2.2 beneath the Destination list, and click Add.
h) Click Port, select TCP (6) beneath the Selected Source Ports list, and click Add. Do not enter a port number, simply
add TCP as the protocol, which will cover all ports.
i) Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
j) Click Save on the Extended Access List Object dialog box to save the ACL object.
Step 2 Configure the service policy rule that disables TCP sequence number randomization.
For example, to disable randomization for this traffic class globally, do the following:
a) Choose Policies > Access Control > Access Control, and edit the policy assigned to the devices that require this
service.
b) Click Advanced, and click the Edit ( ) for the Threat Defense Service Policy.
c) Click Add Rule.
d) Select Apply Globally > Next.
e) Select the extended ACL object you created for this rule and click Next.
f) Deselect Randomize TCP Sequence Number.
g) (Optional.) Adjust the other connection options as needed.
h) Click Finish to add the rule. If necessary, drag and drop the rule to the desired position in the service policy.
i) Click OK to save the changes to the service policy.
j) Click Save on Advanced to save the changes to the access control policy.
You can now deploy the changes to the affected devices.
Step 1 Create the extended ACL that defines the traffic class, which is the list of servers you want to protect.
For example, to define a traffic class to protect the web servers with the IP addresses 10.1.1.5 and 10.1.1.6:
a) Choose Objects > Object Management.
b) Choose Access List > Extended from the table of contents.
c) Click Add Extended Access List.
d) Enter a Name for the object, for example, protected-servers.
e) Click Add to add a rule.
f) Keep Allow for the action.
g) Leave the Source list empty, enter 10.1.1.5 beneath the Destination list, and click Add.
h) Also enter 10.1.1.6 beneath the Destination list and click Add.
i) Click Port, select HTTP in the available ports list, and click Add to Destination. If your server also support HTTPS
connections, also add that port.
j) Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
k) Click Save on the Extended Access List Object dialog box to save the ACL object.
Step 2 Configure the service policy rule that sets embryonic connection limits.
For example, to set the total concurrent embryonic limit to 1000 connections, and the per-client limit to 50 connections,
do the following:
a) Choose Policies > Access Control > Access Control, and edit the policy assigned to the devices that require this
service.
b) Click Advanced, and click Edit ( ) for the Threat Defense Service Policy.
c) Click Add Rule.
d) Select Apply Globally > Next.
e) Select the extended ACL object you created for this rule and click Next.
f) Enter 1000 for Connections > Maximum Embryonic.
g) Enter 50 for Connections Per Client > Maximum Embryonic.
h) (Optional.) Adjust the other connection options as needed.
i) Click Finish to add the rule. If necessary, drag and drop the rule to the desired position in the service policy.
j) Click OK to save the changes to the service policy.
k) Click Save on Advanced to save the changes to the access control policy.
Step 3 (Optional.) Configure the rates for TCP Intercept statistics.
TCP Intercept uses the following options to determine the rate for collecting statistics. All options have default values,
so if these rates suit your needs, you can skip this step.
• Rate Interval—The size of the history monitoring window, between 1 and 1440 minutes. The default is 30 minutes.
During this interval, the system samples the number of attacks 30 times.
• Burst Rate—The threshold for syslog message generation, between 25 and 2147483647. The default is 400 per
second. When the burst rate is exceeded, the device generates syslog message 733104.
• Average Rate—The average rate threshold for syslog message generation, between 25 and 2147483647. The default
is 200 per second. When the average rate is exceeded, the device generates syslog message 733105.
c) Select the Threat_Detection_Configure object in the Available FlexConfig list and click >>. The object is added
to the Selected Append FlexConfigs list.
d) Click Save.
e) (Optional.) You can verify that you have the right settings by clicking Preview Config and selecting one of the
devices.
The system generates the CLI commands that will be written to the device during the next deployment. These
commands will include those needed for the service policy as well as those needed for threat detection statistics.
Scroll to the bottom of the preview to see the appended CLI. The TCP Intercept statistics command should look
something like the following, if you use the default values (line break added for clarity):
Step 5 You can now deploy the changes to the affected devices.
Step 6 Monitor the TCP Intercept statistics from the device CLI using the following commands:
• show threat-detection statistics top tcp-intercept [all | detail]—View the top 10 protected servers under attack.
The all keyword shows the history data of all the traced servers. The detail keyword shows history sampling data.
The system samples the number of attacks 30 times during the rate interval, so for the default 30 minute period,
statistics are collected every 60 seconds.
Note You can use the shun command to block attacking host IP addresses. To remove the block, use the no
shun command.
Example:
Note If you decrement time to live, packets with a TTL of 1 will be dropped, but a connection will be opened for
the session on the assumption that the connection might contain packets with a greater TTL. Note that some
packets, such as OSPF hello packets, are sent with TTL = 1, so decrementing time to live can have unexpected
consequences. Keep these considerations in mind when defining your traffic class.
Step 1 Create the extended ACL that defines the traffic class for which to enable traceroute reporting.
For example, to define a traffic class for all addresses, but excluding OSPF traffic, do the following:
a) Choose Objects > Object Management.
b) Choose Access List > Extended from the table of contents.
c) Click Add Extended Access List.
d) Enter a Name for the object, for example, traceroute-enabled.
e) Click Add to add a rule to exclude OSPF.
f) Change the action to Block, click Port, select OSPFIGP (89) as the protocol beneath the Destination Ports list, and
click Add to add the protocol to the selected list.
g) Click Add on the Extended Access List Entry dialog box to add the OSPF rule to the ACL.
h) Click Add to add a rule to include all other connections.
i) Keep Allow for the action, and leave both the Source and Destination lists empty.
j) Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
Ensure that the OSPF deny rule is above the Allow Any rule. Drag and drop to move the rules if necessary.
k) Click Save on the Extended Access List Object dialog box to save the ACL object.
Step 2 Configure the service policy rule that decrements the time-to-live value.
For example, to decrement time-to-live globally, do the following:
a) Choose Policies > Access Control > Access Control, and edit the policy assigned to the devices that require this
service.
b) Click Advanced, and click Edit ( ) for the Threat Defense Service Policy.
c) Click Add Rule.
d) Select Apply Globally and click Next.
e) Select the extended ACL object you created for this rule and click Next.
f) Select Enable Decrement TTL.
g) (Optional.) Adjust the other connection options as needed.
h) Click Finish to add the rule. If necessary, drag and drop the rule to the desired position in the service policy.
i) Click OK to save the changes to the service policy.
j) Click Save on Advanced to save the changes to the access control policy.
You can now deploy the changes to the affected devices.
d) Increase the Rate Limit, for example, to 50. You can ignore the Burst Size, it is not used.
You can leave the ICMP rules table empty, it is not related to this task.
e) Click Save.
Step 4 You can now deploy the changes to the affected devices.
• show service-policy
Shows service policy statistics, including Dead Connection Detection (DCD) statistics.
• show threat-detection statistics top tcp-intercept [all | detail]
View the top 10 protected servers under attack. The all keyword shows the history data of all the traced
servers. The detail keyword shows history sampling data. The system samples the number of attacks 30
times during the rate interval, so for the default 30 minute period, statistics are collected every 60 seconds.
Firepower Threat Defense Service 6.3 You can now configure a Firepower Threat Defense Service Policy as
Policy. part of your access control policy advanced options. You can use
Firepower Threat Defense Service Policies to apply services to specific
traffic classes. Features supported include TCP State Bypass,
randomizing TCP sequence numbers, decrementing the time-to-live
(TTL) value on packets, Dead Connection Detection, setting a limit
on the maximum number of connections and embryonic connections
per traffic class and per client, and timeouts for embryonic, half closed,
and idle connections.
New screen: Policies > Access Control > Access Control, Advanced
tab, Threat Defense Service Policy.
Supported platforms: Firepower Threat Defense
Initiator and responder information for 6.5 If you enable Dead Connection Detection (DCD), you can use the show
Dead Connection Detection (DCD), and conn detail command to get information about the initiator and
DCD support in a cluster. responder. Dead Connection Detection allows you to maintain an
inactive connection, and the show conn output tells you how often the
endpoints have been probed. In addition, DCD is now supported in a
cluster.
New/Modified commands: show conn (output only).
Supported platforms: Firepower Threat Defense
Caution Cisco strongly recommends using FlexConfig policies only if you are an advanced user with a strong ASA
background and at your own risk. You may configure any commands that are not prohibited. Enabling features
through FlexConfig policies may cause unintended results with other configured features.
You may contact the Cisco Technical Assistance Center for support concerning FlexConfig policies that you
have configured. The Cisco Technical Assistance Center does not design or write custom configurations on
any customer's behalf. Cisco expresses no guarantees for correct operation or interoperability with other
Firepower System features. FlexConfig features may become deprecated at any time. For fully guaranteed
feature support, you must wait for Firepower Management Center support. When in doubt, do not use
FlexConfig policies.
The system includes a set of predefined FlexConfig objects that represent tested configurations. If the feature
you need is not represented by these objects, first determine if you can configure an equivalent feature in
standard policies. For example, the access control policy includes intrusion detection and prevention, HTTP
and other types of protocol inspection, URL filtering, application filtering, and access control, which the ASA
implements using separate features. Because many features are not configured using CLI commands, you will
not see every policy represented within the output of show running-config.
Note At all times, keep in mind that there is not a one-to-one overlap between ASA and FTD. Do not attempt to
completely recreate an ASA configuration on a FTD device. You must carefully test any feature that you
configure using FlexConfig.
You can also issue these commands from within Firepower Management Center using the following procedure.
Access-list Advanced ACL, Extended ACL, and Standard ACL are blocked.
Ethertype ACL is allowed.
You can use standard and extended ACL objects defined in the object
manager inside the template as variables.
Network Object/Object-group Network object creation in the FlexConfig object is blocked, but you
can use network objects and groups defined in the object manager inside
the template as variables.
Reload You cannot schedule reloads. The system does not use the reload
command to restart the system, it uses the reboot command.
Route-Map Object Route-map object creation in the FlexConfig object is blocked, but you
can use route map objects defined in the object manager inside the
template as variables.
Service Object/Object-group Service object creation in the FlexConfig object is blocked, but you can
use port objects defined in the object manager inside the template as
variables.
Template Scripts
You can use scripting language to control processing within a FlexConfig object. Scripting language instructions
are a subset of commands supported in the Apache Velocity 1.3.1 template engine, a Java-based scripting
language that supports looping, if/else statements, and variables.
To learn how to use the scripting language, see the Velocity Developer Guide at http://velocity.apache.org/
engine/devel/developer-guide.html.
FlexConfig Variables
You can use variables in a FlexConfig object in cases where part of a command or processing instruction
depends on runtime information rather than static information. During deployment, the variables are replaced
with strings obtained from other configurations for the device based on the type of variable:
• Policy object variables are replaced with strings obtained from objects defined in Firepower Management
Center.
• System variables are replaced with information obtained from the device itself or from policies configured
for it.
• Processing variables are loaded with the contents of policy object or system variables as scripting
commands are processed. For example, in a loop, you iteratively load one value from a policy object or
system variable into a processing variable, then use the processing variable to form a command string
or perform some other action. These processing variables do not show up in the Variables list within a
FlexConfig object. Also, you do not add them using the Insert menu in the FlexConfig object editor.
• Secret key variables are replaced with the single string defined for the variable within the FlexConfig
object.
Variables start with the $ character, except for secret keys, which start with the @ character. For example,
$ifname is a policy object variable in the following command, whereas @keyname is a secret key.
interface $ifname
key @keyname
Note The first time you insert a policy object or system variable, you must do so through the Insert menu in the
FlexConfig object editor. This action adds the variable to the Variables list at the bottom of the FlexConfig
object editor. But you must type in the variable string on subsequent uses, even when using system variables.
If you are adding a processing variable, which does not have an object or system variable assignment, do not
use the Insert menu. If you are adding a secret key, always use the Insert menu. Secret key variables do not
show up in the Variables list.
Whether a variable is resolved as a single string, a list of strings, or a table of values depends on the type of
policy object or system variable you assign to the variable. (Secret keys always resolve to a single string.)
You must understand what will be returned in order to process the variables correctly.
The following topics explain the various types of variable and how to process them.
#if($tcpMssMinimum == "true")
sysopt connection tcpmss minimum $tcpMssBytes
#else
sysopt connection tcpmss $tcpMssBytes
#end
In this example, you would use the Insert menu in the FlexConfig object editor to add the first use of
$tcpMssBytes, but you would type in the variable directly on the #else line.
Secret key variables are a special type of single value variable. For secret keys, you always use the Insert
menu to add the variable, even for second and subsequent uses. These variables do not show up in the Variables
list within the FlexConfig object. For example, if you wanted to hide the keys for EIGRP configuration, you
could copy the Eigrp_Interface_Configure FlexConfig, and replace the $eigrpAuthKey and $eigrpAuthKeyId
variables with secret keys, @SecretEigrpAuthKey and @SecretEigrpAuthKeyId.
Note Policy object variables for network objects also equate to a single IP address specification, either a host address,
network address, or address range. However, in this case, you must know what type of address to expect,
because the ASA commands require specific address types. For example, if a command requires a host address,
using a network object variable that points to an object that contains a network address will result in an error
during deployment.
policy-map global_policy
class inspection_default
#foreach ( $protocol in $enableInspectProtocolList)
inspect $protocol
#end
In this example, the script assigns each value in turn to the $protocol variable, which is then used in an ASA
inspect command to enable the inspection engine for that protocol. In this case, you simply type in $protocol
as a variable name. You do not use the Insert menu to add it, because you are not assigning an object or
system value to the variable. However, you must use the Insert menu to add $enableInspectProtocolList.
The system loops through the code between #foreach and #end until there are no values remaining in
$enableInspectProtocolList.
In this example, you would use the Insert menu in the FlexConfig object editor to add the first use of
$netflow_Destination, and then add .get(0). But you would type in the variable directly for the
$netflow_Destination.get(1) and $netflow_Destination.get(2) specifications.
[{intf_hardwarare_id=GigabitEthernet0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.10.1, intf_ipv6_link_local_address=,
intf_logical_name=outside},
{intf_hardwarare_id=GigabitEthernet0/1, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.11.1, intf_ipv6_link_local_address=,
intf_logical_name=inside},
{intf_hardwarare_id=GigabitEthernet0/2, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=},
{intf_hardwarare_id=Management0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=diagnostic}]
In the above example, information is returned for 4 interfaces. Each interface includes a table of named values.
For example, intf_hardwarare_id is the name of the interface hardware name property, and returns strings
such as GigabitEthernet0/0.
This type of variable is typically of indeterminate length, so you need to use looping to process the values.
But you also need to add the property name to the variable name to indicate which value to retrieve.
For example, IS-IS configuration requires that you add the ASA isis command to an interface that has a logical
name in interface configuration mode. However, you enter that mode using the interface’s hardware name.
Thus, you need to identify which interfaces have logical names, then configure just those interfaces using
their hardware names. The ISIS_Interface_Configuration predefined FlexConfig does this using an if/then
structure nested in a loop. In the following code, you can see that the #foreach scripting command loads each
interface map into the $intf variable, then the #if statement keys off the intf_logical_name value in the map
($intf.intf_logical_name), and if the value is in the list defined in the isisIntfList predefined text variable,
enters the interface command using the intf_hardwarare_id value ($intf.intf_hardwarare_id). You would need
to edit the isisIntfList variable to add the names of the interfaces on which to configure IS-IS.
Note Do not deploy this FlexConfig to the device, however, because it will not contain any valid configuration
commands. You would get deployment errors. After obtaining the preview, delete the FlexConfig object from
the FlexConfig policy and save the policy.
$IPv4_Private_addresses
$SYS_FW_MANAGEMENT_IP
$SYS_FW_ENABLED_INSPECT_PROTOCOL_LIST
$SYS_FTD_ROUTED_INTF_MAP_LIST
$SYS_FW_INTERFACE_NAME_LIST
The preview of this object might look like the following (line returns added for clarity):
192.168.0.171
[dns, ftp, h323 h225, h323 ras, rsh, rtsp, sqlnet, skinny, sunrpc,
xdmcp, sip, netbios, tftp, icmp, icmp error, ip-options]
[{intf_hardwarare_id=GigabitEthernet0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.10.1, intf_ipv6_link_local_address=,
intf_logical_name=outside},
{intf_hardwarare_id=GigabitEthernet0/1, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.11.1, intf_ipv6_link_local_address=,
intf_logical_name=inside},
{intf_hardwarare_id=GigabitEthernet0/2, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=},
{intf_hardwarare_id=Management0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=diagnostic}]
are highly flexible and built specifically for use within FlexConfig objects. For detailed information, see
Configure FlexConfig Text Objects, on page 1059.
• Network—For IP addresses. You can use network objects or groups. Select Network from the table of
contents, then select Add Network > Add Object or Add Group. If you use a group object, the variable
returns a list of each IP address specification within the group. Addresses can be host, network, or address
ranges, depending on the object contents. See Network Objects, on page 448.
• Security Zones—For interfaces within a security zone or interface group. Select Interface from the
table of contents, then select Add > Security Zone or Interface Group. A security zone variable returns
a list of the interfaces within that zone or group for the device being configured. See Interface Objects:
Interface Groups and Security Zones, on page 456.
• Standard ACL Object—For standard access control lists. A standard ACL variable returns the name
of the standard ACL object. Select Access List > Standard from the table of contents, then click Add
Standard Access List Object. See Access List, on page 514.
• Extended ACL Object—For extended access control lists. An extended ACL variable returns the name
of the extended ACL object. Select Access List > Extended from the table of contents, then click Add
Extended Access List Object. See Access List, on page 514.
• Route Map—For route map objects. A route map variable returns the name of the route map object.
Select Route Map from the table of contents, then click Add Route Map. See Route Maps, on page
511.
Name Description
SYS_FW_OS_MODE The operating system mode of the device. Possible values are ROUTED or
TRANSPARENT.
SYS_FW_OS_MULTIPLICITY Whether the device is running in single or multiple context mode. Possible
values are SINGLE, MULTI, or NOT_APPLICABLE.
SYS_FTD_INTF_POLICY_MAP A map with interface name as key and policy-map as value. This variable
returns nothing if there are no interface-based service policies defined on
the device.
Name Description
SYS_FTD_ROUTED_INTF_MAP_LIST A list of routed interface maps on the device. Each map includes a set of
named values related to routed interface configuration.
SYS_FTD_SWITCHED_INTF_MAP_LIST A list of switched interface maps on the device. Each map includes a set of
named values related to switched interface configuration.
SYS_FTD_INLINE_INTF_MAP_LIST A list of inline interface maps on the device. Each map includes a set of
named values related to inline set interface configuration.
SYS_FTD_PASSIVE_INTF_MAP_LIST A list of passive interface maps on the device. Each map includes a set of
named values related to passive interface configuration.
SYS_FTD_INTF_BVI_MAP_LIST A list of Bridge Virtual Interface maps on the device. Each map includes
a set of named values related to BVI configuration.
SYS_FW_INTERFACE_HARDWARE_ID_LIST A list of the hardware names for interfaces on the device, such as
GigabitEthernet0/0.
SYS_FW_INTERFACE_NAME_LIST A list of logical names for interfaces on the device, such as inside.
SYS_FW_NON_INLINE_INTERFACE_NAME_LIST A list of logical names for interfaces that are not part of inline sets, such as
all routed interfaces.
PrefixDelegationInside Configures the inside interface for DHCPv6 None, but could be used with a copy of
prefix delegation. The object includes DHCPv6_Prefix_Delegation_Configure.
multiple entries, in order, interface name,
IPv6 suffix with prefix length, and prefix
pool name.
PrefixDelegationOutside Configure the outside DHCPv6 prefix None, but could be used with a copy of
delegation client. The object includes DHCPv6_Prefix_Delegation_Configure.
multiple entries, in order, interface name
and IPv6 prefix length
Supported Domains
Any
User Roles
Admin
Note The system also configures zone name passive commands to configure passive
zones if you define some interfaces as passive. This is handled automatically
based on your interface configuration. Do not use FlexConfig to create passive
traffic zones.
Step 1 Determine the CLI command sequence that you want to configure.
If you have a functioning configuration on an ASA device, use show running-config to get the sequence of commands
that you need. Make adjustments to items such as interface names and IP addresses as needed.
If this is for a new feature, it is best to try to implement it on an ASA device in a lab setting to verify that you have the
correct command sequence.
For more information, see the following topics:
• Recommended Usage for FlexConfig Policies, on page 1034
• CLI Commands in FlexConfig Objects, on page 1034
Step 2 Select Objects > Object Management, then select FlexConfig > FlexConfig Objects from the table of contents.
Examine the predefined FlexConfig objects to determine if any will be able to generate the commands you need. Click
View ( ) to see the object contents. If an existing object is close to what you want, start by making a copy of the
object, and then edit the copy. See Predefined FlexConfig Objects, on page 1044.
Examining the objects will also give you an idea of the structure, command syntax, and expected sequencing for a
FlexConfig object.
Note If you find any objects that you will use, either directly or as copies, examine the Variables list at the bottom
of the object. Make note of the variable names, except those in all capitals that start with SYS, which are
system variables. These variables are text objects that you will probably need to edit and define overrides
for, especially if the default value column shows the object has no value.
Step 3 If you need to create your own FlexConfig objects, determine what variables you will need and create the associated
objects.
The CLI you need to deploy might contain IP addresses, interface names, port numbers, and other parameters that you
might want to adjust over time. These are best isolated into variables, which point to objects that contain the necessary
values. You might also need variables for strings that are part of the configuration but which might change over time.
Also, determine if you need different values for each device to which you will assign the policy. For example, you
might want to configure the feature on three devices, but you might need to specify a different interface name or IP
address on a given command for each of these devices. If you need to customize the object for each device, ensure that
you enable overrides when creating the object, and then define the override values per device.
See the following topics for an explanation of the various types of variables and how to configure the related objects
when necessary.
• FlexConfig Variables, on page 1037
• FlexConfig Policy Object Variables, on page 1042
• FlexConfig System Variables, on page 1043
• Configure FlexConfig Text Objects, on page 1059
Step 4 If you are using the predefined FlexConfig objects, edit the text objects used as variables.
See Configure FlexConfig Text Objects, on page 1059.
You need to create objects only if the predefined objects cannot do the job.
• If there is more than one set of commands for an interface, only the last set of commands is deployed.
Therefore, we recommend you not use beginning and ending commands to configure interfaces. For an
example of configuring interfaces, see the ISIS_Interface_Configuration predefined FlexConfig object.
• If you want to edit a predefined object, click Copy ( ) to create a new object with the same contents.
You can use variables to supply information that can be known only at runtime, or which can differ from device to device.
You simply type in processing variables, but you must use the Insert menu to add variables that are associated with
policy objects or system variables, or which are secret keys. For a complete discussion of variables, see FlexConfig
Variables, on page 1037.
• To insert system variables, choose Insert > Insert System Variable > Variable Name. For a detailed explanation
of these variables, see FlexConfig System Variables, on page 1043.
• To insert policy object variables, choose Insert > Insert Policy Object > Object Type, selecting the appropriate
type of object. Then, give the variable a name (which can be the same name as the associated policy object), select
the object to associate with the variable, and click Save. For a detailed explanation of these types, see FlexConfig
Policy Object Variables, on page 1042. For more detail on the procedure, see Add a Policy Object Variable to a
FlexConfig Object, on page 1058.
• To insert secret key variables, choose Insert > Secret Key and define the variable name and value. For more detail
on the procedure, see Configure Secret Keys, on page 1058.
Note You must use the Insert menu to create a new policy object or system variable. However, for subsequent uses
of that variable, you must type it in, $ included. This is also true for system variables: the first time you use it,
add it from the Insert menu. Then, type it out for subsequent uses. If you use the Insert menu more than once
for a system variable, the system variable is added to the Variables list multiple times, and the FlexConfig will
not validate, meaning you cannot save your changes. For processing variables (those not associated with a
policy object or system variable), simply type in the variable. If you are adding a secret key, always use the
Insert menu. Secret key variables do not show up in the Variables list.
Step 7 (Optional.) Click Validate above the object body to check the integrity of the script.
The object is always validated when you click Save. You cannot save an invalid object.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
Step 1 Choose Insert > Insert Policy Object > Object Type, selecting the appropriate type of object.
Step 2 Enter a name for the variable, and optionally, a description.
The name must be unique within the context of the FlexConfig object. It cannot include spaces. You are allowed to use
the exact same name as the object associated with the variable.
Step 3 Select the object to associate with the variable and click Add to move it to the Selected Object list.
You can associate a variable with a single object only.
Note For text objects, you can select any of the predefined objects as needed. However, many of these objects have
no default values. You must update the objects to add the required values either directly or as overrides for the
device to which you will deploy the FlexConfig object. Trying to deploy a FlexConfig without updating these
objects typically results in deployment errors.
Note Any data defined in a secret key variable is masked from users except when previewing a FlexConfig policy.
In addition, if you export a FlexConfig policy, the content of any secret key variable is erased. When you
import the policy, you will need to manually edit each secret key variable to enter the data.
Step 1 While editing a FlexConfig Policy Object, choose Insert > Secret Key.
Step 2 In the Insert Secret Key dialog box, do any of the following:
• To create a new key, click Add Secret Key, then fill in the following information and click Add.
• Secret Key Name—The name of the variable. This name appears in the FlexConfig object prefixed with @.
• Password, Confirm Password—The secret string, which is masked with asterisks as you type.
• To insert a secret key variable in the FlexConfig object, select the check box for the variable.
• To edit the value of a secret key variable, click Edit ( ) for the variable. Make your changes and click Add.
• Click Edit ( ) to edit an existing object. You are allowed to edit the predefined text objects, which is required if
you intended to use the predefined FlexConfig objects.
Step 6 If the variable type is Multiple, use the up and down arrows to specify a Count.
Rows are added or removed from the object as you change the number.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 385.
• Click Edit ( ) to edit an existing Policy. You can change the name or description by clicking them in edit mode.
• Click Copy ( ) to create a new policy with the same contents. You are prompted for a name. Device assignments
are not retained for the copy.
Step 3 Select the FlexConfig objects required for the policy from the Available FlexConfig list and click > to add them to the
policy.
Objects are automatically added to the prepended or appended list based on the deployment type specified in the FlexConfig
object.
Step 4 For each selected object, click View ( ) next to the object to identify the variables used in the object.
Except for system variables, which start with SYS, you need to ensure that the objects associated with the variables are
not empty. A blank or brackets with nothing between them, [ ], indicate an empty object. You will need to edit these
objects before deploying the policy.
Note If you use object overrides, those values will not show up in this view. Thus, an empty default value does not
necessarily mean that you have not updated the object with the required values. Previewing the configuration
will show whether the variables resolve correctly for a given device. See Preview the FlexConfig Policy, on
page 1062.
What to do next
• Set target devices for the policy; see Set Target Devices for a FlexConfig Policy, on page 1061.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note Normally, when you unassign a policy from a device, the system automatically removes the associated
configuration upon the next deployment. However, because FlexConfig objects are scripts for deploying
customized commands, simply unassigning a FlexConfig policy from a device does not remove the commands
that were configuring by the FlexConfig objects. If your intention is to remove FlexConfig-generated commands
from a device's configuration, see Remove Features Configured Using FlexConfig, on page 1064.
• Delete—Click Delete ( ) next to a single device, or select multiple devices, right-click, then choose Delete Selection.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
For example, the following sequence shows that Firepower Management Center (FMC) sent commands to configure
GigabitEthernet0/0 with the logical name outside. The device responded that it automatically set the security level
to 0. FTD does not use the security level for anything. Messages relevant to FlexConfig are in the CLI Apply section
of the transcript.
Step 2 Verify that the deployed configuration includes the expected commands.
You can do this by making an SSH connection to the device's management IP address. Use the show running-config
command to view the configuration.
Alternatively, use the CLI tool within Firepower Management Center.
a) Choose System > Health > Monitor and click the name of the device.
You might need to click the open/close arrow in the Count column in the Status table to see any devices.
2. Remove the object from the FlexConfig policy, save the change, then preview the configuration again. If
the ###CLI generated from managed features ### section still does not include the required clear or
negate commands, you must follow this procedure to manually remove the configuration.
Step 1 Choose Objects > Object Management and create the FlexConfig Objects to clear or negate the configuration commands.
If a feature has a clear command that can remove all configuration settings, then use that command. For example, the
predefined Eigrp_Unconfigure_All object contains a single command that removes all EIGRP-related configuration
commands:
If there is not a clear command for the feature, you need to use the no form of each command you want to remove. For
example, the predefined Sysopt_basic_negate object removes the commands configured through the predefined Sysopt_basic
object.
You would typically configure a FlexConfig object that removes configurations as a prepended, deploy once object.
Step 2 Choose Devices > FlexConfig and create a new FlexConfig policy or edit the existing policy.
If you want to preserve the FlexConfig policy that deploys the configuration commands, create a new policy specifically
for negating the commands, and assign the devices to the policy. Then, add the new FlexConfig objects to the policy.
If you want to completely remove the FlexConfig configuration objects from all devices, you can simply delete those
commands from the existing FlexConfig policy and replace them with the objects that negate the configuration.
Step 7 While editing the FlexConfig policy, click Policy Assignments and remove the device. Optionally, remove the FlexConfig
Objects from the policy.
Assuming that the FlexConfig policy simply removes the unwanted configuration commands, there is no need to keep
the policy assigned to the device after the removal is complete.
However, if the FlexConfig policy retains options that you still want configured on the device, remove the negation
objects from the policy. They are no longer needed.
Step 1 (Routed mode only.) Enable Multicast routing, and configure the IGMP group for the interfaces.
In Routed mode, you must enable Multicast routing. In addition, for stand-alone physical interfaces, that is, those that
are not bridge group members, you must also configure the interface to join the 224.0.1.129 IGMP group. You cannot
configure bridge group members to join an IGMP group, but PTP configuration on bridge group members will work
without the IGMP join.
Perform this procedure for each device on which you will configure PTP.
Note Write down the hardware names of each PTP-clock-facing interface on each device, for example,
GigabitEthernet1/1.
Repeat this step for each PTP-clock-facing stand-alone interface on the device.
g) Click Save on the Routing page.
Step 2 Create the FlexConfig object to enable PTP globally and on the interface.
The following procedure assumes that the PTP-clock-facing interface is the same on every device you are configuring.
If you have used different interfaces on different devices, you need to create separate objects for each distinct combination.
For example, if you use GigabitEthernet1/1 on devices A and B, GigabitEthernet1/2 on devices C and D, and both
GigabitEthernet1/1 and 1/2 on devices E and F, you need 3 separate FlexConfig objects, and subsequently, 3 separate
FlexConfig policies (explained in the next step).
a) Choose Objects > Object Management.
b) Choose FlexConfig > FlexConfig Object from the table of contents.
c) Click Add FlexConfig Object, configure the following properties, and click Save.
• Name—The object name. For example, Enable_PTP.
• Deployment—Select Everytime. You want this configuration to be sent in every deployment to ensure it remains
configured.
• Type—Keep the default, Append. The commands are sent to the device after the commands for directly-supported
features. This ensures that any other changes you make to interface configuration are configured before these
commands.
• Object body—In the object body, type the commands needed to configure PTP globally and on each
PTP-clock-facing interface. For example, the commands needed for the global configuration for PTP domain
10 and the interface configuration on GigabitEthernet1/1 are:
interface gigabitethernet1/1
ptp enable
d) Click Save.
e) If you have not yet assigned all the targeted devices to the policy, click the Policy Assignments link below Save and
make the assignments now.
f) Click Preview Config, and in the Preview dialog box, select one of the assigned devices.
The system generates a preview of the configuration CLI that will be sent to the device. Verify that the commands
generated from the PTP FlexConfig object look correct. These will be shown at the end of the preview. Note that you
will also see commands generated from other changes you have made to managed features. For the PTP commands,
you should see something similar to the following:
After the deployment completes, you can check the deployment history and view the transcript for the deployment. This
is especially valuable if the deployment fails. See Verify the Deployed Configuration, on page 1063.
• GigabitEthernet0/1.
• Interface name: outside-1
• IP address: 192.168.6.5/24
• GigabitEthernet0/2.
• Interface name: outside-2
• IP address: 172.16.7.6/24
Step 1 Create the extended ACL objects to match traffic from the 10.1.0.0/16 and 10.2.0.0/16 address spaces. You must create
separate ACLs, because you will apply different actions to the traffic in the route map.
a) Choose Objects > Object Management.
b) Select Access List > Extended from the table of contents. You must configure an extended access list to specify the
traffic source addresses.
c) Click the Add Extended Access List button.
d) Enter a name for the access list, such as high-priority.
e) Click the Add button, and create the rule for the high-priority address space. The key characteristics are:
• Action—Allow.
• Source Networks—Enter 10.1.0.0/16 in the edit box below the list and click Add. Alternatively, you can define
a network object for this network address.
f) Click Add at the bottom of the dialog box. This adds the rule to the access list.
g) Click Save.
h) Repeat the process to create a second access list with the following attributes:
• Name—low-priority.
• Action—Allow.
• Source Networks—Enter 10.2.0.0/16 in the edit box below the list and click Add. Alternatively, you can define a
network object for this network address.
Step 2 Create the route map that defines the next hop addresses for these address spaces.
a) While still on the objects page, click Route Map in the table of contents.
b) Click the Add Route Map button.
c) Enter a name for the object, such as load-balance.
d) Click Add and create a rule for high-priority traffic with the following attributes:
• Sequence No.—10.
• Redistribution—Allow.
• Match Clauses > IPv4 > Address—Select the Access List radio button, then Available Access Lists > Extended,
and move the high-priority ACL to the selected list.
• Set Clauses > BGP Clauses > Others—In IPv4 Settings > Next Hop, select Specific IP, then enter the gateway
for ISP-A, 192.168.6.6 into the Specific IP edit box.
h) Click Save.
Step 3 Create the FlexConfig object that enables PBR on the inside interface using the route map.
a) While still on the objects page, click FlexConfig > FlexConfig Object in the table of contents.
b) Find the Policy_Based_Routing object, then click the Copy ( ).
This is a system-defined object, but it is not usable until you edit it. It does not point to a text object that you can
simply update with the name of your route map. You must always create a custom object for this system-defined
object.
c) When you click the copy icon, the system opens a dialog box with the new object, with the default name
Policy_Based_Routing_Copy. Make these basic changes:
• Name—Enter a meaningful name. For example, if you are configuring PBR for device FTD1, perhaps
PBR_FTD1.
• Description—Delete the description or make it meaningful for your purposes.
• Deployment—Keep Once.
• Type—Keep Append.
interface GigabitEthernet0/0
policy-route route-map $r-map-object
Note that the “interface GigabitEthernet0/0” line already is set to configure the correct interface for this example. If
you were to apply PBR to a different interface, you would need to correct the interface hardware name.
The $r-map-object string actually is not a real variable, and it points to nothing. You need to replace this string.
e) Delete the $r-map-object string, and leave your cursor on the “policy-route route-map” line, one space after route-map.
f) Select Insert > Insert Policy Object > Route Map.
g) In the Route Map Variable dialog box, configure the following:
• Variable Name—Any name will do, such as pbr-route-map.
• Selected Object—Move the load-balance route map object from the available list to the selected list.
i) Click Save.
Step 4 Add the FlexConfig object to the FlexConfig policy that is assigned to the device.
a) Choose Devices > FlexConfig.
b) Assuming you do not already have a FlexConfig policy assigned to this device, click New Policy, give the policy a
name and select the FTD1 device to assign the policy to it, then click Save.
c) Find the object under the User Defined folder in the available objects list, then click > to add it to the selected objects
list.
What to do next
You can now deploy the configuration to the device.
FlexConfig. 6.2 The FlexConfig feature allows you use the Firepower Management
Center to deploy ASA CLI template-based functionality to Firepower
Threat Defense devices. This feature allows you to enable some of the
most valuable ASA functions that are not currently available on
Firepower Threat Defense devices. This functionality is structured as
templates and objects that work together in a policy. The default
templates are officially supported by Cisco TAC.
New screen: Devices > FlexConfig. Also, under Objects > Object
Management, FlexConfig > FlexConfig Objects and FlexConfig >
Text Object.
Supported platforms: Firepower Threat Defense
FlexConfig Updates 6.2(1) As per the Government Certification requirements, all sensitive
information like password, shared keys in system-provided or
6.2(2)
user-defined FlexConfig object should be masked using secret key
variables. After you update the Firepower Management Center to these
releases, all sensitive information in FlexConfig Objects are converted
to secret key variable format.
In addition, the following new FlexConfig templates are added:
• Default_DNS_Configure template allows you to the default DNS
group, which is used to resolve hostnames for commands or
features that resolve names through the data interfaces.
• TCP Embryonic connection limit and timeout configuration
template allows you to configure embryonic connection
limits/timeout CLIs to protect from SYN Flood DoSAttack.
• Turn on threat detection configure and clear templates allow
you to configure threat detection statistics for attacks intercepted
by TCP Intercept.
• IPV6 router header inspection template allows you to configure
of IPV6 inspection header for selectively allow/block certain
headers with different types (e.g. allowing RH Type 2,mobile).
• DHCPv6 prefix delegation template allows you to configure one
outside (PD client) and one inside interface (recipient of delegated
prefix) for IPv6 prefix delegation.
Deprecated FlexConfig objects. 6.3 Several features that in previous releases you configured using
FlexConfig are now directly supported in Firepower Management
Center. You need to remove these FlexConfig objects if you are using
them, and convert your configuration to use the new objects. Following
are the deprecated FlexConfig objects and text objects.
• Default_DNS_Configure, including the
defaultDNSNameServerList and defaultDNSParameters text
objects. Now, please configure DNS for the data interfaces using
the Platform Settings policy.
• TCP_Embryonic_Conn_Limit, and the tcp_conn_misc and
tcp_conn_limit text objects. Configure these features in the
Firepower Threat Defense Service Policy, which you can find on
the Advanced tab of the access control policy assigned to the
device.
• TCP_Embryonic_Conn_Timeout, and the tcp_conn_misc and
tcp_conn_timeout text objects. Configure these features in the
Firepower Threat Defense Service Policy.
Precision Time Protocol (PTP) 6.5 You can use FlexConfig to configure the Precision Time Protocol
configuration for ISA 3000 devices. (PTP) on ISA 3000 devices. PTP is a time-synchronization protocol
developed to synchronize the clocks of various devices in a
packet-based network. The protocol is designed specifically for
industrial, networked measurement and control systems.
We now allow you to include the ptp (interface mode) command, and
the global commands ptp mode e2etransparent and ptp domain, in
FlexConfig objects.
New/Modified commands: show ptp.
Supported platforms: Firepower Threat Defense
Supported Domains
Global
User Roles
Admin
Setting Description
Access Control Configure the system to prompt users for a comment when they add or modify an access control policy;
Preferences see Policy Change Comments, on page 1111.
Access List Control which computers can access the system on specific ports; see Access List, on page 1111.
Audit Log Configure the system to send an audit log to an external host; see Audit Logs, on page 1112.
Audit Log Certificate Configure the system to secure the channel when streaming the audit log to an external host; see Audit
Log Certificate, on page 1115 .
Change Reconciliation Configure the system to send a detailed report of changes to the system over the last 24 hours; see Change
Reconciliation, on page 1109.
Console Configuration Configure console access via VGA or serial port, or via Lights-Out Management (LOM); see Remote
Console Access Management, on page 1132.
Dashboard Enable Custom Analysis widgets on the dashboard; see Dashboard Settings, on page 1119.
Database Specify the maximum number of each type of event that the Firepower Management Center can store;
see Database Event Limits, on page 1095.
DNS Cache Configure the system to resolve IP addresses automatically on event view pages; see DNS Cache, on
page 1120.
Email Notification Configure a mail host, select an encryption method, and supply authentication credentials for email-based
notifications and reporting; see Email Notifications, on page 1120.
External Database Access Enable external read-only access to the database, and provide a client driver to download; see External
Database Access Settings, on page 1094.
HTTPS Certificate Request an HTTPS server certificate, if needed, from a trusted authority and upload certificates to the
system; see HTTPS Certificates, on page 1087.
Information View current information about the appliance and edit the display name; see Appliance Information, on
page 1086.
Intrusion Policy Configure the system to prompt users for a comment when they modify an intrusion policy; see Policy
Preferences Change Comments, on page 1111.
Language Specify a different language for the web interface; see Language Selection, on page 1122.
Login Banner Create a custom login banner that appears when users log in; see Login Banners, on page 1122.
Management Interfaces Change options such as the IP address, hostname, and proxy settings of the appliance; see Management
Interfaces, on page 1097.
Network Analysis Policy Configure the system to prompt users for a comment when they modify a network analysis policy; see
Preferences Policy Change Comments, on page 1111.
Process Shut down, reboot, or restart Firepower processes; see Shut Down or Restart, on page 1105.
Remote Storage Device Configure remote storage for backups and reports; see Remote Storage Management, on page 1106.
Setting Description
REST API Preferences Enable or disable access to the Firepower Management Center via the Firepower REST API; see REST
API Preferences, on page 1138.
Shell Timeout Configure the amount of idle time, in minutes, before a user’s login session times out due to inactivity;
see Session Timeouts, on page 1131.
SNMP Enable Simple Network Management Protocol (SNMP) polling; see SNMP Polling, on page 1123.
Time View and change the current time setting; see Time and Time Synchronization, on page 1124.
Time Synchronization Manage time synchronization on the system; see Time and Time Synchronization, on page 1124.
UCAPL/CC Compliance Enable compliance with specific requirements set out by the United States Department of Defense; see
Enable Security Certifications Compliance, on page 1202.
User Configuration Configure the Firepower Management Center to track successful login history and password history for
all users, or enforce temporary lockouts on users who enter invalid login credentials; see Global User
Configuration Settings, on page 1128
VMware Tools Enable and use VMware Tools on a Firepower Management Center Virtual; see VMware Tools and
Virtual Systems, on page 1138.
Vulnerability Mapping Map vulnerabilities to a host IP address for any application protocol traffic received or sent from that
address; see Vulnerability Mapping, on page 1132.
Web Analytics Enable and disable collection of non-personally-identifiable information from your system. See (Optional)
Opt Out of Web Analytics Tracking, on page 1139.
Related Topics
About Platform Settings for Classic Devices, on page 1147
Appliance Information
The System > Configuration page of the web interface includes the information listed in the table below.
Unless otherwise noted, all fields are read-only.
Note See also the Help > About page, which includes similar but slightly different information.
Field Description
Field Description
Operating System Version The version of the operating system currently running
on the appliance.
HTTPS Certificates
Secure Sockets Layer (SSL)/TLS certificates enable Firepower Management Centers to establish an encrypted
channel between the system and a web browser. A default certificate is included with all Firepower devices,
but it is not generated by a certificate authority (CA) trusted by any globally known CA. For this reason,
consider replacing it with a custom certificate signed by a globally known or internally trusted CA.
Caution The FMC supports 4096-bit HTTPS certificates. If the certificate used by the FMC was generated using a
public server key larger than 4096 bits, you will not be able to log in to the FMC web interface. If this happens,
contact Cisco TAC.
The lifetime of the default server certificate depends on when the certificate was generated. To view your
default server certificate expiration date, choose System > Configuration > HTTPS Certificate.
Note that some Firepower software upgrades can automatically renew the certificate. For more information,
see the appropriate version of the Cisco Firepower Release Notes.
On the Firepower Management Center, you can renew the default certificate on the System > Configuration
> HTTPS Certificate page.
Subject Public Key Info Public key and an identifier for its algorithm. See RFC
5280, section 4.1.2.7.
Extended Key Usage extension Indicates one or more purposes for which the certified
public key may be used, in addition to or in place of
the basic purposes indicated in the Key Usage
extension. See RFC 5280, section 4.2.1.12. Be certain
you import certificates that can be used as server
certificates.
• The user selects a certificate in the browser that is not generated by the certificate authority that signed
the server certificate.
• The user selects a certificate in the browser that is not generated by a certificate authority in the certificate
chain on the device.
To verify client browser certificates, configure the system to use the online certificate status protocol (OCSP)
or load one or more certificate revocation lists (CRLs). Using the OCSP, when the web server receives a
connection request it communicates with the certificate authority to confirm the client certificate's validity
before establishing the connection. If you configure the server to load one or more CRLs, the web server
compares the client certificate against those listed in the CRLs. If a user selects a certificate that is listed in a
CRL as a revoked certificate, the browser cannot load the web interface.
Note If you choose to verify certificates using CRLs, the system uses the same CRLs to validate both client browser
certificates and audit log server certificates.
Step 10 To request a certificate that secures multiple domain names or IP addresses, enter the folowing information in the
Subject Alternative Name section:
a) Domain Names: Enter the fully qualified domains and subdomains (if any) secured by the Subject Alternative
Name.
b) IP Addresses: Enter the IP addresses secured by the Subject Alternative Name.
Step 11 Click Generate.
Step 12 Open a text editor.
Step 13 Copy the entire block of text in the certificate request, including the BEGIN CERTIFICATE REQUEST and END CERTIFICATE
REQUEST lines, and paste it into a blank text file.
Step 14 Save the file as servername.csr, where servername is the name of the server where you plan to use the certificate.
Step 15 Click Close.
What to do next
• Submit the certificate request to the certificate authority.
• When you receive the signed certificate, import it to the Firepower Management Center; see Importing
HTTPS Server Certificates, on page 1092.
Caution The Firepower Management Center supports 4096-bit HTTPS certificates. If the certificate used by the
Firepower Management Center was generated using a public server key larger than 4096 bits, you will not
be able to log in to the FMC web interface. For more information about updating HTTPS Certificates to
Version 6.0.0, see "Update Management Center HTTPS Certificates to Version 6.0" in Firepower System
Release Notes, Version 6.0. If you generate or import an HTTPS Certificate and cannot log in to the FMC
web interface, contact Support.
Step 6 Open any required intermediate certificates, copy the entire block of text for each, and paste it into the Certificate Chain
field.
Step 7 Click Save.
Note To access the web interface after enabling client certificates, you must have a valid client certificate present
in your browser (or a CAC inserted in your reader).
Step 5 Enter a valid URL to an existing CRL file and click Add CRL. Repeat to add up to 25 CRLs.
Step 6 Click Refresh CRL to load the current CRL or CRLs from the specified URL or URLs.
Note Enabling fetching of the CRL creates a scheduled task to regularly update the CRL or CRLs. Edit the task to
set the frequency of the update.
Step 7 Verify that the client certificate is signed by the certificate authority loaded onto the appliance and the server certificate
is signed by a certificate authority loaded in the browser certificate store. (These should be the same certificate authority.)
Caution Saving a configuration with enabled client certificates, with no valid client certificate in your browser certificate
store, disables all web server access to the appliance. Make sure that you have a valid client certificate installed
before saving settings.
Related Topics
Configuring Certificate Revocation List Downloads, on page 211
Step 3 Click Renew HTTPS Certificate. (This option appears on the display below the certificate information only if your
system is configured to used the default HTTPS server certificate.)
Step 4 (Optional) In the Renew HTTPS Certificate dialog box, select Generate New Key to generate a new key for the
certificate.
Step 5 In the Renew HTTPS Certificate dialog box, click Save.
What to do next
You can confirm that the certificate has been renewed by checking that that certificate validity dates displayed
on the HTTPS Certificate page have updated.
Use the Firepower Management Center's system configuration to enable database access and create an access
list that allows selected hosts to query the database. Note that this access list does not also control appliance
access.
You can also download a package that contains the following:
• RunQuery, the Cisco-provided database query tool
• InstallCert, a tool you can use to retrieve and accept the SSL certificate from the Firepower Management
Center you want to access
• the JDBC driver you must use to connect to the database
See the Firepower System Database Access Guide for information on using the tools in the package you
downloaded to configure database access.
Related Topics
Firepower System IP Address Conventions, on page 17
Step 3 For each of the databases, enter the number of records you want to store.
For information on how many records each database can maintain, see Database Event Limits, on page 1096.
Step 4 Optionally, in the Data Pruning Notification Address field, enter the email address where you want to receive pruning
notifications.
Step 5 Click Save.
White list violation history a 30-day history of violations One day’s history
Management Interfaces
After setup, you can change the management network settings, including adding more management interfaces,
hostname, search domains, DNS servers, and HTTP proxy on the FMC.
For device management, the management interface carries two separate traffic channels: the management
traffic channel carries all internal traffic (such as inter-device traffic specific to managing the device), and
the event traffic channel carries all event traffic (such as web events). You can optionally configure a separate
event-only interface on the FMC to handle event traffic; you can configure only one event interface. Event
traffic can use a large amount of bandwidth, so separating event traffic from management traffic can improve
the performance of the FMC. For example, you can assign a 10 GigabitEthernet interface to be the event
interface, if available, while using 1 GigabitEthernet interfaces for management. You might want to configure
an event-only interface on a completely secure, private network while using the regular management interface
on a network that includes Internet access, for example. You can also use both management and event interfaces
on the same network if the goal is only to take advantage of increased throughput. If you configure an event-only
interface on the FMC, you can support devices with separate management and event-only interfaces, but also
devices that do not have separate interfaces. For devices with a single combined management/event interface,
all traffic goes to the FMC management interface.
Note All management interfaces support HTTP administrator access as controlled by your Access List configuration
(Configure an Access List, on page 1112). Conversely, you cannot restrict an interface to only HTTP access;
management interfaces always support device management (management traffic, event traffic, or both).
Note Only the eth0 interface supports DHCP IP addressing. Other management interfaces only support static IP
addresses.
NAT Environments
Network address translation (NAT) is a method of transmitting and receiving network traffic through a router
that involves reassigning the source or destination IP address. The most common use for NAT is to allow
private networks to communicate with the internet. Static NAT performs a 1:1 translation, which does not
pose a problem for FMC communication with devices, but port address translation (PAT) is more common.
PAT lets you use a single public IP address and unique ports to access the public network; these ports are
dynamically assigned as needed, so you cannot initiate a connection to a device behind a PAT router.
Normally, you need both IP addresses (along with a registration key) for both routing purposes and for
authentication: the FMC specifies the device IP address when you add a device, and the device specifies the
FMC IP address. However, if you only know one of the IP addresses, which is the minimum requirement for
routing purposes, then you must also specify a unique NAT ID on both sides of the connection to establish
trust for the initial communication and to look up the correct registration key. The FMC and device use the
registration key and NAT ID (instead of IP addresses) to authenticate and authorize for initial registration.
For example, you add a device to the FMC, and you do not know the device IP address (for example, the
device is behind a PAT router), so you specify only the NAT ID and the registration key on the FMC; leave
the IP address blank. On the device, you specify the FMC IP address, the same NAT ID, and the same
registration key. The device registers to the FMC's IP address. At this point, the FMC uses the NAT ID instead
of IP address to authenticate the device.
Although the use of a NAT ID is most common for NAT environments, you might choose to use the NAT
ID to simplify adding many devices to the FMC. On the FMC, specify a unique NAT ID for each device you
want to add while leaving the IP address blank, and then on each device, specify both the FMC IP address
and the NAT ID. Note: The NAT ID must be unique per device.
The following example shows three devices behind a PAT IP address. In this case, specify a unique NAT ID
per device on both the FMC and the devices, and specify the FMC IP address on the devices.
Figure 41: NAT ID for Managed Devices Behind PAT
The following example shows the FMC behind a PAT IP address. In this case, specify a unique NAT ID per
device on both the FMC and the devices, and specify the device IP addresses on the FMC.
Figure 42: NAT ID for FMC Behind PAT
The following example shows the Firepower Management Center using separate management interfaces for
devices; and each managed device using 1 management interface.
Figure 44: Mutliple Management Interfaces on the Firepower Management Center
The following example shows the Firepower Management Center and managed devices using a separate event
interface.
Figure 45: Separate Event Interface on the Firepower Management Center and Managed Devices
The following example shows a mix of multiple management interfaces and a separate event interface on the
Firepower Management Center and a mix of managed devices using a separate event interface, or using a
single management interface.
Caution Be careful when making changes to the management interface to which you are connected; if you cannot
re-connect because of a configuration error, you need to access the FMC console port to re-configure the
network settings in the Linux shell. You must contact Cisco TAC to guide you in this operation.
Note If you change the FMC IP address, then see the following tasks to ensure device management connectivity
depending on how you added the device to the FMC:
• IP address—No action. If you added the device to the FMC using a reachable device IP address, then
the management connection will be reestablished automatically after several minutes even though the
IP address identified on the FTD is the old IP address. Note: If you specified a device IP address that is
unreachable, then you must contact Cisco TAC, who can advise you how to restore connectivity for your
devices.
• NAT ID only—Contact Cisco TAC. If you added the device using only the NAT ID, then the connection
cannot be reestablished. In this case, you must contact Cisco TAC, who can advise you how to restore
connectivity for your devices.
Note In a high availability configuration, when you modify the management IP address of a registered Firepower
device from the device CLI or from Firepower Management Center, the secondary Firepower Management
Center does not reflect the changes even after an HA synchronization. To ensure that the secondary Firepower
Management Center is also updated, switch roles between the two Firepower Management Centers, making
the secondary Firepower Management Center as the active unit. Modify the management IP address of the
registered Firepower device on the device management page of the now active Firepower Management Center.
Step 1 Choose System > Configuration, and then choose Management Interfaces.
Step 2 In the Interfaces area, click Edit next to the interface that you want to configure.
All available interfaces are listed in this section. You cannot add more interfaces.
You can configure the following options on each management interface:
• Enabled—Enable the management interface. Do not disable the default eth0 management interface. Some processes
require the eth0 interface.
• Channels—Configure an event-only interface; you can configure only one event interface on the FMC. To do so,
uncheck the Management Traffic check box, and leave the Event Traffic check box checked. You can optionally
disable Event Traffic for the management interface(s). In either case, the device will try to send events to the
event-only interface, and if that interface is down, it will send events on the management interface even if you disable
the event channel. You cannot disable both event and management channels on an interface.
• Mode—Specify a link mode. Note that any changes you make to auto-negotiation are ignored for GigabitEthernet
interfaces.
• MDI/MDIX—Set the Auto-MDIX setting.
• MTU—Set the maximum transmission unit (MTU). The default is 1500. The range within which you can set the
MTU can vary depending on the model and interface type.
Because the system automatically trims 18 bytes from the configured MTU value, any value below 1298 does not
comply with the minimum IPv6 MTU setting of 1280, and any value below 594 does not comply with the minimum
IPv4 MTU setting of 576. For example, the system automatically trims a configured value of 576 to 558.
• IPv4 Configuration—Set the IPv4 IP address. Choose:
• Static—Manually enter the IPv4 Management IP address and IPv4 Netmask.
• DHCP—Set the interface to use DHCP (eth0 only).
• Disabled—Disable IPv4. Do not disable both IPv4 and IPv6.
Step 3 In the Routes area, edit a static route by clicking Edit ( ), or add a route by clicking Add ( ).
View the route table by clicking .
You need a static route for each additional interface to reach remote networks. For more information about when new
routes are needed, see Network Routes on FMC Management Interfaces, on page 1099.
Note For the default route, you can change only the gateway IP address.The egress interface is chosen automatically
by matching the specified gateway to the interface's network.
Step 4 In the Shared Settings area, set network parameters shared by all interfaces.
Note If you selected DHCP for the eth0 interface, you cannot manually specify some shared settings derived from
the DHCP server.
Caution Do not shut off Firepower appliances using the power button; it may cause a loss
of data. Using the web interface (or CLI) prepares the system to be safely powered
off and restarted without losing configuration data.
Tip For virtual devices, refer to the documentation for your virtual platform. For VMware in particular, custom
power options are part of VMware Tools.
Restart the console Click Run Command next to Restart Management Center Console.
Note Restarting may cause deleted hosts to reappear in the network map.
Related Topics
Snort® Restart Scenarios, on page 388
You cannot send backups to one remote system and reports to another, but you can choose to send either to
a remote system and store the other on the Firepower Management Center.
Tip After configuring and selecting remote storage, you can switch back to local storage only if you have not
increased the connection database limit.
Step 5 Optionally, check the Use Advanced Options check box and enter any required command line options; see Remote
Storage Management Advanced Options, on page 1109.
Step 6 Under System Usage:
• Choose Use for Backups to store backups on the designated host.
• Choose Use for Reports to store reports on the designated host.
• Enter Disk Space Threshold for backup to remote storage. Default is 90%.
Step 5 Optionally, check the Use Advanced Options check box and enter any required command line options; see Remote
Storage Management Advanced Options, on page 1109.
Step 6 Under System Usage:
• Choose Use for Backups to store backups on the designated host.
• Choose Use for Reports to store reports on the designated host.
Step 5 Optionally, check the Use Advanced Options check box and enter any required command line options; see Remote
Storage Management Advanced Options, on page 1109.
Step 6 Under System Usage:
Step 7 If you want to test the settings, you must click Test.
Step 8 Click Save.
sec=mode
where mode is the security mode you want to use for remote storage.
Mode Description
Change Reconciliation
To monitor the changes that users make and ensure that they follow your organization’s preferred standard,
you can configure the system to send, via email, a detailed report of changes made over the past 24 hours.
Whenever a user saves changes to the system configuration, a snapshot is taken of the changes. The change
reconciliation report combines information from these snapshots to present a clear summary of recent system
changes.
The following sample graphic displays a User section of an example change reconciliation report and lists
both the previous value for each configuration and the value after changes. When users make multiple changes
to the same configuration, the report lists summaries of each distinct change in chronological order, beginning
with the most recent.
You can view changes made during the previous 24 hours.
Step 6 If you want to include policy changes, check the Include Policy Configuration check box.
Step 7 If you want to include all changes over the past 24 hours, check the Show Full Change History check box.
Step 8 Click Save.
Related Topics
Using the Audit Log to Examine Changes, on page 346
Note The change reconciliation report does not include changes to Firepower Threat Defense interfaces and routing
settings.
Step 2 Configure the policy comment preferences for any of the following:
• Click Access Control Preferences for comment preferences for access control policies.
• Click Intrusion Policy Preferences for comment preferences for intrusion policies.
• Click Network Analysis Policy Preferences for comment preferences for network analysis policies.
Step 3 You have the following choices for each policy type:
• Disabled—Disables change comments.
• Optional—Gives users the option to describe their changes in a comment.
• Required—Requires users to describe their changes in a comment before saving.
Access List
You can limit access to the FMC by IP address and port. By default, the following ports are enabled for any
IP address:
• 443 (HTTPS) for web interface access.
• 22 (SSH) for CLI access.
You can also add access to poll for SNMP information over port 161. Because SNMP is disabled by default,
you must first enable SNMP before you can add SNMP access rules. For more information, see Configure
SNMP Polling, on page 1123.
Caution By default, access is not restricted. To operate in a more secure environment, consider adding access for
specific IP addresses and then deleting the default any option.
Caution If you delete access for the IP address that you are currently using to connect to the FMC, and there is no
entry for “IP=any port=443”, you will lose access when you save.
To configure access lists for Classic devices, use device platform settings. See Configure Access Lists for
Classic Devices, on page 1149.
Related Topics
Firepower System IP Address Conventions, on page 17
Audit Logs
The Firepower Management Center records user activity in read-only audit logs. You can review audit log
data in several ways:
• Use the web interface: Auditing the System, on page 341.
Audit logs are presented in a standard event view where you can view, sort, and filter audit log messages
based on any item in the audit view. You can easily delete and report on audit information and you can
view detailed reports of the changes that users make.
• Stream audit log messages to the syslog: Stream Audit Logs to Syslog, on page 1113..
• Stream audit log messages to an HTTP server: Stream Audit Logs to an HTTP Server, on page 1114.
Streaming audit log data to an external server allows you to conserve space on the FMC. Note that sending
audit information to an external URL may affect system performance.
Optionally, you can secure the channel for audit log streaming, enable TLS and mutual authentication using
TLS certificates; see Audit Log Certificate, on page 1115.
Classic devices also maintain audit logs. To stream audit logs from a Classic devices, see Stream Audit Logs
from Classic Devices, on page 1149.
Where the local date, time, and originating hostname precede the bracketed optional tag, and the sending
device name precedes the audit log message.
For example, if you specify a tag of FMC-AUDIT-LOG for audit log messages from your management center, a
sample audit log message from your FMC could appear as follows:
Mar 01 14:45:24 localhost [FMC-AUDIT-LOG] Dev-MC7000: [email protected], Operations > Monitoring,
Page View
If you specify a severity and facility, these values do not appear in syslog messages; instead, they tell the
system that receives the syslog messages how to categorize them.
To stream audit logs from Classic devices, use device platform settings: Stream Audit Logs from Classic
Devices, on page 1149.
Option Description
Host The IP address or the fully qualified name of the syslog server to which you will send audit logs.
Option Description
Step 5 (Optional) To test whether the IP address of the syslog server is valid, click Test Syslog Server.
The system displays the result for the server.
Step 6 Click Save.
Where the local date, time, and originating hostname precede the bracketed optional tag, and the sending
appliance or device name precedes the audit log message.
For example, if you specify a tag of FROMMC, a sample audit log message could appear as follows:
Mar 01 14:45:24 localhost [FROMMC] Dev-MC7000: [email protected], Operations > Monitoring,
Page View
To stream audit logs from Classic devices, use device platform settings: Stream Audit Logs from Classic
Devices, on page 1149.
• subsystem
• actor
• event_type
• message
• action_source_ip
• action_destination_ip
• result
• time
• tag (if defined; see Step 3)
Caution To allow encrypted posts, use an HTTPS URL. Sending audit information to an external URL may affect system
performance.
• For the FMC, use the local system configuration: Require Valid Audit Log Server Certificates, on page
1118.
• For Classic devices, use device platform settings: Require Valid Audit Log Server Certificates for Classic
Devices, on page 1151.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
The system generates certificate request keys in Base-64 encoded PEM format.
What to do next
• Submit the certificate signing request to the certificate authority that you selected using the guidelines
in the "Before You Begin" section of this procedure.
• When you receive the signed certificate, import it to the appliance; see Import an Audit Log Client
Certificate into the FMC, on page 1117.
• Make sure you are importing the signed certificate for the correct appliance. Each certificate is unique
to a specific appliance or device.
• If the signing authority that generated the certificate requires you to trust an intermediate CA, be prepared
to provide the necessary certificate chain (or certificate path). The CA that signed the client certificate
must be the same CA that signed any intermediate certificates in the certificate chain.
Note If you choose to verify certificates using CRLs, the system uses the same CRLs to validate both audit log
server certificates and certificates used to secure the HTTP connection between an appliance and a web
browser.
Important You cannot perform this procedure on the standby Firepower Management Center in a high availablity pair.
Step 4 If you want to accept server certificates without verification (not recommended):
a) Deselect Enable Mutual Authentication.
b) Click Save and skip the remainder of this procedure.
Step 5 To verify the certificate of the audit log server, choose Enable Mutual Authentication.
Step 6 (If you enabled mutual authentication) To automatically recognize certificates that are no longer valid:
a) Select Enable Fetching of CRL.
Note Enabling fetching of the CRL creates a scheduled task to regularly update the CRL or CRLs.
b) Enter a valid URL to an existing CRL file and click Add CRL.
Repeat to add up to 25 CRLs.
c) Click Refresh CRL to load the current CRL or CRLs from the specified URL or URLs.
Step 7 Verify that you have a valid server certificate generated by the same certificate authority that created the client certificate.
Step 8 Click Save.
What to do next
(Optional) Set the frequency of CRL updates. See Configuring Certificate Revocation List Downloads, on
page 211.
Dashboard Settings
Dashboards provide you with at-a-glance views of current system status through the use of widgets: small,
self-contained components that provide insight into different aspects of the Firepower System. The Firepower
System is delivered with several predefined dashboard widgets.
You can configure the Firepower Management Center so that Custom Analysis widgets are enabled on the
dashboard.
Related Topics
About Dashboards, on page 287
DNS Cache
You can configure the system to resolve IP addresses automatically on the event view pages. You can also
configure basic properties for DNS caching performed by the appliance. Configuring DNS caching allows
you to identify IP addresses you previously resolved without performing additional lookups. This can reduce
the amount of traffic on your network and speed the display of event pages when IP address resolution is
enabled.
Step 4 In the DNS Cache Timeout (in minutes) field, enter the number of minutes a DNS entry remains cached in memory
before it is removed for inactivity.
The default setting is 300 minutes (five hours).
Related Topics
Configuring Event View Settings, on page 35
Email Notifications
Configure a mail host if you plan to:
• Email event-based reports
When you configure email notification, you can select an encryption method for the communication between
the system and mail relay host, and can supply authentication credentials for the mail server if needed. After
configuring, you can test the connection.
Step 6 In the From Address field, enter the valid email address you want to use as the source email address for messages sent
by the appliance.
Step 7 Optionally, to supply a user name and password when connecting to the mail server, choose Use Authentication. Enter
a user name in the Username field. Enter a password in the Password field.
Step 8 To send a test email using the configured mail server, click Test Mail Server Settings.
A message appears next to the button indicating the success or failure of the test.
Language Selection
You can use the Language page to specify a different language for the web interface.
Login Banners
You can use the Login Banner page to specify session, login, or custom message banners for a security
appliance or shared policy.
You can use ASCII characters and carriage returns to create a custom login banner. The system does not
preserve tab spacing. If your login banner is too large or causes errors, Telnet or SSH sessions can fail when
the system attempts to display the banner.
SNMP Polling
You can enable Simple Network Management Protocol (SNMP) polling. This feature supports use of versions
1, 2, and 3 of the SNMP protocol. This feature allows access to the standard management information base
(MIB), which includes system details such as contact, administrative, location, service information, IP
addressing and routing information, and transmission protocol usage statistics.
Note When selecting SNMP versions for the SNMP protocol, note that SNMPv2 only supports read-only communities
and SNMPv3 only supports read-only users. SNMPv3 also supports encryption with AES128.
Enabling SNMP polling does not cause the system to send SNMP traps; it only makes the information in the
MIBs available for polling by your network management system.
Note The SNMP MIB contains information that could be used to attack your deployment. We recommend that you
restrict your access list for SNMP access to the specific hosts that will be used to poll for the MIB. We also
recommend you use SNMPv3 and use strong passwords for network management access.
• Version 3: Click Add User to display the user definition page. SNMPv3 only supports read-only users and
encryption with AES128.
Step 8 Choose the privacy protocol you want to use from the Privacy Protocol list, or choose None to not use a privacy
protocol.
Step 9 Enter the SNMP privacy key required by the SNMP server in the Privacy Password field.
Step 10 Re-enter the privacy password in the Verify Password field.
Step 11 Click Add.
Step 12 Click Save.
Note If you specified an NTP server for the FMC during initial configuration, the connection with that NTP server
is not secured. You must edit the configuration for that connection to specify MD5 or SHA1 keys.
Caution Unintended consequences can occur when time is not synchronized between the FMC and managed devices.
Caution If the Firepower Management Center is rebooted and your DHCP server sets an NTP server record different
than the one you specify here, the DHCP-provided NTP server will be used instead. To avoid this situation,
configure your DHCP server to use the same NTP server.
What to do next
Set managed devices to synchronize with the same NTP server or servers:
• Configure device platform settings: Configure NTP Time Synchronization for Threat Defense, on page
1192 and Synchronize Time on Classic Devices with an NTP Server, on page 1152.
Note that even if you force the FMC to make a secure connection with an NTP server (Use the
authenticated NTP server only), device connections to that server do not use authentication.
Important • Do not use this procedure unless you have no other NTP server. Instead, use the procedure in Synchronize
Time on the FMC with an NTP Server, on page 1124.
• Do not use a virtual Firepower Management Center as an NTP server.
Step 1 Manually set the system time on the Firepower Management Center:
a) Choose System > Configuration.
b) Click Time Synchronization.
c) If Serve Time via NTP is Enabled, choose Disabled.
d) Click Save.
e) For Set My Clock, choose Manually in Local Configuration.
f) Click Save.
g) In the navigation panel at the left side of the screen, click Time.
h) Use the Set Time drop-down lists to set the time.
i) If the time zone displayed is not UTC, click it and set the time zone to UTC.
j) Click Save.
k) Click Done.
l) Click Apply.
Step 2 Set the Firepower Management Center to serve as an NTP server:
a) In the navigation panel at the left side of the screen, click Time Synchronization.
b) For Serve Time via NTP, choose Enabled.
c) Click Save.
Step 3 Set managed devices to synchronize with the Firepower Management Center NTP server:
a) In the Time Synchronization settings for the platform settings policy assigned to your managed devices, set the clock
to synchronize Via NTP from Management Center.
b) Deploy the change to managed devices.
For instructions:
• For Firepower Threat Defense devices, see Configure NTP Time Synchronization for Threat Defense, on page 1192
• For all other devices, see Synchronize Time on Classic Devices with an NTP Server, on page 1152
View Current System Time, Source, and NTP Server Connection Status
Time settings are displayed on most pages in local time using the time zone you set on the Time Zone page
in User Preferences (the default is America/New York), but are stored on the appliance using UTC time.
Restriction The Time Zone function (in User Preferences) assumes that the default system clock is set to UTC time. DO
NOT ATTEMPT TO CHANGE THE SYSTEM TIME. Be advised that changing the system time from UTC
is NOT supported, and doing so will require you to reimage the device to recover from an unsupported state.
Column Description
Column Description
Authentication The authentication status for communication between the FMC and the NTP server:
• none indicates no authentication is configured.
• bad indicates authentication is configured but has failed.
• ok indicates authentication is successful.
If authentication has been configured, the system displays the key number and key
type (SHA1 or MD5) following the status value. For example: bad, key 2, SHA1.
Offset The number of milliseconds of difference between the time on the appliance and the
configured NTP server. Negative values indicate that the appliance is behind the NTP
server, and positive values indicate that it is ahead.
Last Update The number of seconds that have elapsed since the time was last synchronized with
the NTP server. The NTP daemon automatically adjusts the synchronization times
based on a number of conditions. For example, if you see larger update times such as
300 seconds, that indicates that the time is relatively stable and the NTP daemon has
determined that it does not need to use a lower update increment.
to zero (the default), the system does not track or report successful login activity. See Track Successful
Logins, on page 1130.
• Max Number of Login Failures: The number of times in a row that users can enter incorrect web
interface login credentials before the system temporarily blocks the account from access for a configurable
time period. If a user continues login attempts while the temporary lockout is in force:
• The system refuses access for that account (even with a valid password) without informing the user
that a temporary lockout is in force.
• The system continues to increment the failed login count for that account with each login attempt.
• If the user exceeds the Maximum Number of Failed Logins configured for that account on the
individual User Configuration page, the account is locked out until an admin user reactivates it.
• Set Time in Minutes to Temporarily Lockout Users: The duration in minutes for a temporary web
interface user lockout if Max Number of Failed Logins is non-zero.
• Max Concurrent Sessions Allowed: The number of sessions of a particular type (read-only or read/write)
that can be open at the same time. The type of session is determined by the roles assigned to a user. If a
user is assigned only read-only roles, that user's session is counted toward the (Read Only) session limit.
If a user has any roles with write privileges, the session is counted toward the Read/Write session limit.
For example, if a user is assigned the Admin role and the Maximum sessions for users with Read/Write
privileges/CLI users is set to 5, the user will not be allowed to log in if there are already five other users
logged in that have read/write privileges.
Note Predefined user roles and custom user roles that the system considers read-only
for the purposes of concurrent session limits, are labeled with (Read Only) in
the role name on the System > Users > Users and the System > Users > User
Roles. If a user role does not contain (Read Only) in the role name, the system
considers the role to be read/write. The system automatically applies (Read Only)
to roles that meet the required criteria. You cannot make a role read-only by
adding that text string manually to the role name.
For each type of session, you can set a maximum limit ranging from 1 to 1024. When Max Concurrent
Sessions Allowed is set to zero (the default), the number of concurrent sessions is unlimited.
If you change the concurrent session limit to a value more restrictive, the system will not close any
currently open sessions; it will, however, prevent new sessions beyond the number specified from being
opened.
Note If you lower the number of days, the system deletes records of older logins. If you then increase the limit, the
system does not restore the count from those days. In that case, the reported number of successful logins may
be temporarily lower than the actual number.
Step 4 Set the Time in Minutes to Temporarily Lockout Users to the number of minutes to lock out users who have triggered
a temporary lockout.
When this value is zero, users do not have to wait to retry to log in, even if the Max Number of Login Failures is
non-zero.
Session Timeouts
Unattended login sessions may be security risks. You can configure the amount of idle time before a user’s
login session times out due to inactivity.
Note that you can exempt specific web interface users from timeout, for scenarios where you plan to passively,
securely monitor the system for long periods of time. Users with the Administrator role, whose complete
access to menu options poses an extra risk if compromised, cannot be made exempt from session timeouts.
Vulnerability Mapping
The Firepower System automatically maps vulnerabilities to a host IP address for any application protocol
traffic received or sent from that address, when the server has an application ID in the discovery event database
and the packet header for the traffic includes a vendor and version.
For any servers which do not include vendor or version information in their packets, you can configure whether
the system associates vulnerabilities with server traffic for these vendor and versionless servers.
For example, a host serves SMTP traffic that does not have a vendor or version in the header. If you enable
the SMTP server on the Vulnerability Mapping page of a system configuration, then save that configuration
to the Firepower Management Center managing the device that detects the traffic, all vulnerabilities associated
with SMTP servers are added to the host profile for the host.
Although detectors collect server information and add it to host profiles, the application protocol detectors
will not be used for vulnerability mapping, because you cannot specify a vendor or version for a custom
application protocol detector and cannot select the server for vulnerability mapping.
tasks, such as viewing the chassis serial number or monitoring such conditions as fan speed and temperature,
using a command line interface on an out-of-band management connection.
You must enable LOM for both the system and the user you want to manage the system. After you enable the
system and the user, you use a third-party Intelligent Platform Management Interface (IPMI) utility to access
and manage your system.
Step 4 To configure LOM via SOL, enter the necessary IPv4 settings:
• Choose the address Configuration for the system (DHCP or Manual)
• Enter the IP Address to be used for LOM.
Note The LOM IP address must be different from the management interface IP address of the system.
What to do next
• If you configured Lights-Out Management, enable a Lights-Out Management user; see Lights-Out
Management User Access Configuration, on page 1133.
• The username may have up to 16 alphanumeric characters. Hyphens and longer user names are not
supported for LOM users.
• The password may have up to 20 alphanumeric characters. A user’s LOM password is the same as that
user’s system password. Cisco recommends that you use a complex, non-dictionary-based password of
the maximum supported length for your appliance and change it every three months.
• Physical Firepower Management Centers can have up to 13 LOM users.
Note that if you deactivate, then reactivate, a role with LOM while a user with that role is logged in, or restore
a user or user role from a backup during that user’s login session, that user must log back into the web interface
to regain access to IPMItool commands.
• To grant LOM user access to an existing user, click Edit ( ) next to a user name in the list.
• To grant LOM user access to a new user, click Create User.
Linux
IPMItool is standard with many distributions and is ready to use.
Mac
You must install IPMItool on a Mac. First, confirm that your Mac has Apple's XCode Developer tools installed,
making sure that the optional components for command line development are installed (UNIX Development
and System Tools in newer versions, or Command Line Support in older versions). Then you can install
macports and the IPMItool. Use your favorite search engine for more information or try these sites:
https://developer.apple.com/technologies/tools/
http://www.macports.org/
Windows
You must compile IPMIutil on Windows. If you do not have access to a compiler, you can use IPMIutil itself
to compile. Use your favorite search engine for more information or try this site:
http://ipmiutil.sourceforge.net/
where:
• ipmitool invokes the utility
• -I lanplus enables encryption for the session
• -H IP_address indicates the IP address of the appliance you want to access
• -U user_name is the name of an authorized user
• - command is the name of the command you want to give
This command connects you to the command line on the appliance where you can log in as if you were
physically present at the appliance. You may be prompted to enter a password.
Caution In rare cases, if your computer is on a different subnet than the system's management interface and the system
is configured for DHCP, attempting to access LOM features can fail. If this occurs, you can either disable and
then re-enable LOM on the system, or use a computer on the same subnet as the system to ping its management
interface. You should then be able to use LOM.
Caution Cisco is aware of a vulnerability inherent in the Intelligent Platform Management Interface (IPMI) standard
(CVE-2013-4786). Enabling Lights-Out Management (LOM) on an system exposes this vulnerability. To
mitigate this vulnerability, deploy your systems on a secure management network accessible only to trusted
users and use a complex, non-dictionary-based password of the maximum supported length for your system
and change it every three months. To prevent exposure to this vulnerability, do not enable LOM.
If all attempts to access your system have failed, you can use LOM to restart your system remotely. Note that
if a system is restarted while the SOL connection is active, the LOM session may disconnect or time out.
Caution Do not restart your system unless it does not respond to any other attempts to restart. Remotely restarting
does not gracefully reboot the system and you may lose data.
For example, to display a list of appliance information, the IPMItool command is:
Note In deployments using Firepower Management Center high availability, this feature is available only in the
active Firepower Management Center.
You can also enable VMware Tools on all supported versions of ESXi. For a list of supported versions, see
the Cisco Firepower NGIPSv Quick Start Guide for VMware. For information on the full functionality of
VMware Tools, see the VMware website (http://www.vmware.com/).
Because NGIPSv does not have a web interface, you must use the CLI to enable VMware Tools on that
platform; see the Cisco Firepower NGIPSv Quick Start Guide for VMware.
What to do next
(Optional) Determine whether to share data via the Cisco Success Network, on page 142.
Subject Alternative Name 6.6 When creating an HTTPS certificate for the FMC, you can specify SAN fields. We recommend
(SAN) you use SAN if the certificate secures multiple domain names or IP addresses. For more
information about SAN, see RFC 5280, section 4.2.1.6.
New/modified screens:
System > Configuration > HTTPS Certificate
Supported platforms: FMC
HTTPS Certificates 6.6 The default HTTPS server certificate provided with the system now expires in 800 days. If your
appliance uses a default certificate that was generated before you upgraded to Version 6.6, the
certificate lifetime varies depending on the Firepower version being used when the certificate
was generated. See Default HTTPS Server Certificates, on page 1087 for more information.
New/modified screens: None.
Supported platforms: Physical FMCs.
Secure NTP 6.5 The FMC supports secure communications with NTP servers using SHA1 or MD5 symmetric
key authentication.
New/modified screens:
System > Configuration > Time Synchronization
Supported platforms: FMC
Web analytics 6.5 Web analytics data collection begins after you accept the EULA.
As previously, you can opt not to continue to share data. See (Optional) Opt Out of Web Analytics
Tracking, on page 1139
Automatic CLI access for 6.5 When you use SSH to log into the FMC, you automatically access the CLI. Although strongly
the FMC discouraged, you can then use the CLI expert command to access the Linux shell.
Note This feature deprecates the Version 6.3 ability to enable and disable CLI access for
the FMC. As a consequence of deprecating this option, the virtual FMC no longer
displays the System > Configuration > Console Configuration page, which still
appears on physical FMCs.
Configurable session 6.5 Added the Max Concurrent Sessions Allowed setting. This setting allows the administrator to
limits for read-only and specify the maximum number of sessions of a particular type (read-only or read/write) that can
read/write access be open at the same time.
Note Predefined user roles and custom user roles that the system considers read- only for
the purposes of concurrent session limits, are labeled with (Read Only) in the role
name on the System > Users > Users and the System > Users > User Roles. If a user
role does not contain (Read Only) in the role name, the system considers the role to
be read/write.
New/modified screens:
System > Configuration > User Configuration
System > Users > User Roles
Supported Platforms: FMC
Ability to disable 6.4 When you enable IPv6, you can disable DAD. You might want to disable DAD because the use
Duplicate Address of DAD opens up the possibility of denial of service attacks. If you disable this setting, you need
Detection (DAD) on check manually that this interface is not using an already-assigned address.
management interfaces
New/modified screens:
System > Configuration > Management Interfaces > Interfaces > Edit Interface dialog
box > IPv6 DAD check box
Supported Platforms: FMC
Ability to disable 6.4 When you enable IPv6, you can now disable ICMPv6 Echo Reply and Destination Unreachable
ICMPv6 Echo Reply and messages. You might want to disable these packets to guard against potential denial of service
Destination Unreachable attacks. Disabling Echo Reply packets means you cannot use IPv6 ping to the device management
messages on management interfaces for testing purposes.
interfaces
New/modified screens:
System > Configuration > Management Interfaces > ICMPv6
New/modified commands: configure network ipv6 destination-unreachable, configure
network ipv6 echo-reply
Supported Platforms: FMC (web interface only), FTD (CLI only), ASA FirePOWER module
(CLI only), NGIPSv (CLI only)
Global User 6.3 Added the Track Successful Logins setting. The system can track the number of successful
Configuration Settings logins each FMC account has performed within a selected number of days. When this feature is
enabled, on log in users see a message reporting how many times they have successfully logged
in to the system in the past configured number of days. (Applies to web interface as well as
shell/CLI access.)
Added the Password Reuse Limit setting. The system can track the password history for each
account for a configurable number of previous passwords. The system prevents all users from
re-using passwords that appear in that history. (Applies to web interface as well as shell/CLI
access.)
Added the Max Number of Login Failures and Set Time in Minutes to Temporarily Lockout
Users settings. These allow the administrator to limit the number of times in a row a user can
enter incorrect web interface login credentials before the system temporarily blocks the account
for a configurable period of time.
New screen: System > Configuration > User Configuration
Supported Platforms: FMC
HTTPS Certificates 6.3 The default HTTPS server certificate provided with the system now expires in three years. If
your appliance uses a default server certificate that was generated before you upgraded to Version
6.3, the server certificate will expire 20 years from when it was first generated. If you are using
the default HTTPS server certificate the system now provides the ability to renew it.
New/modified screens:
System > Configuration > HTTPS Certificate page > Renew HTTPS Certificate.
Supported platforms: FMC
Previous to Version 6.3, there was only one setting on the Console Configuration page, and it
applied to physical devices only. So the Console Configuration page was not available on virtual
FMCs. With the addition of this new option, the Console Configuration page now appears on
virtual FMCs as well as physical. However, for virtual FMCs, this check box is the only thing
that appears on the page.
Supported platforms: FMC
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
• Edit — To modify the settings in an existing platform settings policy, click Edit ( ).
• Delete — To delete a policy that is not in use, click Delete ( ), then confirm your choice.
Caution You should not delete a policy that is the last deployed policy on any of its target devices, even if it is out
of date. Before you delete the policy completely, it is good practice to deploy a different policy to those
targets.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 4 Enter a Name for the new policy and optionally, a Description.
Step 5 Optionally, choose the Available Devices where you want to apply the policy and click Add to Policy (or drag and drop)
to add the selected devices. You can enter a search string in the Search field to narrow the list of devices.
Step 6 Click Save.
The system creates the policy and opens it for editing.
Step 7 Configure the platform settings based on the device platform type:
• For Firepower Settings, see Platform Settings for Classic Devices, on page 1147.
• For Threat Defense Settings, see Platform Settings for Firepower Threat Defense, on page 1155.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note that for the FMC, many of these settings are handled in the system configuration; see System
Configuration, on page 1083.
Access List Control which computers can access the system on Configure Access Lists
specific ports. for Classic Devices, on
page 1149
Audit Log Configure the system to send an audit log to an Stream Audit Logs from
external host. Classic Devices, on page
1149
Audit Log Certificate As part of audit log secure streaming, require mutual Require Valid Audit Log
authentication between Classic devices and the audit Server Certificates for
log server. Classic Devices, on page
1151
Login Banner Create a custom login banner that appears when users Customize the Login
log in. Banner for Classic
Devices , on page 1152
Shell Timeout Configure the amount of idle time, in minutes, before Configure Session
a user’s login session times out due to inactivity. Timeouts for Classic
Devices, on page 1153
UCAPL/CC Compliance Enable compliance with specific requirements set out Enable Security
by the United States Department of Defense. Certifications
Compliance, on page 1202
Model Requirements
You can apply a Firepower platform settings policy to any Classic device.
Domain Requirements
None.
You can apply a Firepower platform setting policy at any Domain level.
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
See About Platform Settings for Classic Devices, on page 1147 and Create a Platform Settings Policy, on page 1145.
Step 2 Choose the Available Devices where you want to deploy the policy by clicking Policy Assignment.
Step 3 Click Add to Policy (or drag and drop) to add the selected devices.
Step 4 Click Save.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 2 Click Access List.
Step 3 To add access for one or more IP addresses, click Add Rules.
Step 4 In the IP Address field, enter an IP address or address range, or any.
Step 5 Choose SSH, HTTPS, SNMP, or a combination of these options to specify which ports you want to enable for these IP
addresses.
Step 6 Click Add.
Step 7 Click Save.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
For example:
Note that the tag is optional and user-configurable. Syslog events also have an optional facility and severity..
Step 1 (Optional) Set up secure communications with the audit log server.
For ASA FirePOWER and NGIPSv, you can generate a CSR with a tool like OpenSSL, then use the CLI to import the
signed certificate: configure audit_cert import.
To verify that the certificate imported correctly, use show audit_cert.
Step 2 On the FMC, choose Devices > Platform Settings and create or edit a Firepower policy.
Step 3 Click Audit Log to configure audit log streaming.
Syslog streaming:
a) Set Send Audit Log to Syslog to Enabled.
b) Provide Host information for the syslog server: IP address or fully qualified name.
c) Choose a Facility (Syslog Alert Facilities, on page 2275) and Severity (Syslog Severity Levels, on page 2276).
Attention When you enable Send Audit Log to Syslog and provide Host information, syslog messages are also sent to
the configured host in addition to the audit logs; see Filter Syslogs from Audit Logs, on page 1151.
HTTP streaming:
a) Set Send Audit Log to HTTP Server to Enabled.
b) Provide a URL to Post Audit where you want to send audit logs. HTTPS is supported.
The URL must correspond to a Listener program that expects the following HTTP POST variables: subsystem, actor,
event_type, message, action_source_ip, action_destination_ip, result, time, tag (if provided).
Step 4 (Optional) Enter a Tag in include in each message. For example, you might want to tag Firepower audit logs with
FIREPOWER.
Step 5 Click Save.
If you configured syslog streaming, the system verifies that the syslog server is reachable.
What to do next
• (Optional) If you configured secure communications, we recommend you also require mutual
authentication between the device and the audit log server: Require Valid Audit Log Server Certificates
for Classic Devices, on page 1151.
• (Optional) If you enabled streaming the audit logs to a syslog server and want to filter the syslog messages
from the audit logs: Filter Syslogs from Audit Logs, on page 1151.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 2 Click Audit Log Certificate.
Step 3 Select Enable TLS, then Enable Mutual Authentication.
We recommend you enable mutual authentication. If you do not, the device will accept server certificates without
verification.
Step 4 Select Enable Fetching of CRL, provide the URL to a CRL file, and click Add CRL.
You can add up to 25 CRLs. When you deploy, the system will schedule CRL updates. To set the update frequency, see
Configuring Certificate Revocation List Downloads, on page 211.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Caution Make sure that only authorized personnel have access to the appliance and to its admin account.
Step 1 In the /etc/syslog-ng.conf file, comment out the @include "/etc/syslog-ng.d/*.conf" line.
Example:
#@include "/etc/syslog-ng.d/*.conf"
Step 2 Reload the syslog configuration file. Use the syslog-ng-ctl reload command to reload the configuration file without
having to restart the application.
Example:
syslog-ng-ctl reload
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 2 Choose Login Banner.
Step 3 In the Custom Login Banner field, enter the login banner text you want to use.
The system will not preserve tab spacing.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Caution Unintended consequences can occur when time is not synchronized between the FMC and managed devices.
After you deploy, it may take a few minutes for managed devices to synchronize with the configured NTP
servers.
Note that even if you configure secure communications between the FMC and an NTP server (Use the
authenticated NTP server only), device connections to that server do not use authentication.
If you choose this option, the device gets its time directly from the configured NTP server. If the device's
configured NTP servers are not reachable for any reason, it synchronizes its time with the FMC.
• If your device cannot reach an NTP server or your organization does not have one, you must use the Via
NTP from Management Center option discussed in the following proecedure.
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 2 Click Time Synchronization.
Step 3 Specify how time is synchronized:
• Via NTP from: If your Firepower Management Center is using NTP servers on the network, select this option and
enter the fully-qualified DNS name (such as ntp.example.com), or IP address, of the same NTP servers you specified
in System > Configuration > Time Synchronization. If the NTP servers are not reachable, the Firepower
Management Center acts as an NTP server.
• Via NTP from Management Center: (Default). The managed device gets time from the NTP servers you configured
for the Firepower Management Center (except for authenticated NTP servers) and synchronizes time with those
servers directly. However, if any of the following are true, the managed device synchronizes time from the Firepower
Management Center:
• The Firepower Management Center’s NTP servers are not reachable by the device.
• The Firepower Management Center has no unauthenticated servers.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 2 Click Shell Timeout.
Step 3 Enter a Shell Timeout (Minutes).
Step 4 Click Save.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note The SNMP MIB contains information that could be used to attack your deployment. We recommend that you
restrict your access list for SNMP access to the specific hosts that will be used to poll for the MIB. We also
recommend you use SNMPv3 and use strong passwords for network management access.
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 2 Click SNMP.
Step 3 From the SNMP Version drop-down list, choose the SNMP version you want to use:
• Version 1 or Version 2: Enter a read-only SNMP community name in the Community String field, then skip to
the end of the procedure.
Note Do not include special characters (< > / % # & ? ', etc.) in the SNMP community string name.
• Version 3: Click Add User to display the user definition page. SNMPv3 only supports read-only users and
encryption with AES128.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
When you enable ARP inspection, the Firepower Threat Defense device compares the MAC address, IP
address, and source interface in all ARP packets to static entries in the ARP table, and takes the following
actions:
• If the IP address, MAC address, and source interface match an ARP entry, the packet is passed through.
• If there is a mismatch between the MAC address, the IP address, or the interface, then the Firepower
Threat Defense device drops the packet.
• If the ARP packet does not match any entries in the static ARP table, then you can set the Firepower
Threat Defense device to either forward the packet out all interfaces (flood), or to drop the packet.
Note The dedicated Diagnostic interface never floods packets even if this parameter
is set to flood.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select ARP Inspection.
Step 3 Add entries to the ARP inspection table.
a) Click Add to create a new entry, or click Edit if the entry already exists.
b) Select the desired options.
• Inspect Enabled—To perform ARP inspection on the selected interfaces and zones.
• Flood Enabled—Whether to flood ARP requests that do not match static ARP entries out all interfaces other
than the originating interface or the dedicated management interface. This is the default behavior.
If you do not elect to flood ARP requests, then only those requests that exactly match static ARP entries are
allowed.
• Security Zones—Add the zones that contain the interfaces on which to perform the selected actions. The zones
must be switched zones. For interfaces not in a zone, you can type the interface name into the field below the
Selected Security Zone list and click Add. These rules will be applied to a device only if the device includes
the selected interfaces or zones.
c) Click OK.
Step 4 Add static ARP entries according to Add a Static ARP Entry, on page 675.
Step 5 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Configure Banners
You can configure messages to show users when they connect to the device command line interface (CLI).
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Banner.
Step 3 Configure the banner.
Following are some tips and requirements for banners.
• Only ASCII characters are allowed. You can use line returns (press Enter), but you cannot use tabs.
• You can dynamically add the hostname or domain name of the device by including the variables $(hostname) or
$(domain).
• Although there is no absolute length restriction on banners, Telnet or SSH sessions will close if there is not enough
system memory available to process the banner messages.
• From a security perspective, it is important that your banner discourage unauthorized access. Do not use the words
"welcome" or "please," as they appear to invite intruders in. The following banner sets the correct tone for unauthorized
access:
Configure DNS
The DNS resolution settings allows you to configure DNS for the data interfaces and the diagnostic interface.
It also allows you to set variables to connect to the DNS server.
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Click DNS.
Step 3 Select the Enable DNS name resolution by device check box.
Step 4 Select the DNS Server Group that you have already created.
Step 5 (Optional) Enter the Expiry Entry Timer and Poll Timer values in minutes.
• Expiry entry timer specifies the time limit to remove the IP address of a resolved FQDN from the DNS lookup table
after its time-to-live (TTL) expires. Removing an entry requires the table to be recompiled, so frequent removals
can increase the processing load on the device. This setting virtually extends the TTL.
• Poll timer specifies the time limit after which the device queries the DNS server to resolve the FQDN that was
defined in a network object group. An FQDN is resolved periodically either when the poll timer has expired, or
when the TTL of the resolved IP entry has expired, whichever occurs first.
Note The first instance of the FQDN resolution occurs when the FQDN object is deployed in an access control policy.
Step 6 (Optional) Select the required interface objects from the available list and Add them to the Selected Interface Objects
list.
If you do not specify any interfaces—and do not enable DNS lookup on the diagnostic interface (see the next step)—then
the FTD uses the data routing table to determine the interface, and if there is no match, uses the management routing
table.
Step 7 (Optional) Select Enable DNS Lookup via diagnostic interface also check box.
If enabled, Firepower Threat Defense uses both the selected data interfaces and the diagnostic interface for DNS resolutions.
Be sure to configure an IP address for the diagnostic interface on the Devices > Device Management > edit device >
Interfaces page.
What to do next
To use FQDN objects for access control rules, create an FQDN network object which can then be assigned
to an access control rule. For instructions see, Creating Network Objects, on page 450.
When you enable external authentication for management users, the FTD verifies the user credentials with
an LDAP or RADIUS server as specified in an external authentication object.
devices, you must enable the external authentication object in the platform settings that you deploy to the
devices, and you can only activate one external authentication object per policy. An LDAP object with CAC
authentication enabled cannot also be used for CLI access.
FTD Supported Fields
Only a subset of fields in the external authentication object are used for FTD SSH access. If you fill in additional
fields, they are ignored. If you also use this object for the FMC, those fields will be used. This procedure only
covers the supported fields for the FTD. For other fields, see Configure External Authentication.
Usernames
Usernames must be Linux-valid usernames and be lower-case only, using alphanumeric characters plus period
(.) or hyphen (-). Other special characters such as at sign (@) and slash (/) are not supported. You cannot add
the admin user for external authentication. You can only add external users (as part of the External
Authentication object) in the FMC; you cannot add them at the CLI. Note that internal users can only be added
at the CLI, not in the FMC.
If you previously configured the same username for an internal user using the configure user add command,
the FTD first checks the password against the internal user, and if that fails, it checks the AAA server. Note
that you cannot later add an internal user with the same name as an external user; only pre-existing internal
users are supported. For users defined on the RADIUS server, be sure to set the privilege level to be the same
as any internal users; otherwise you cannot log in using the external user password.
Privilege Level
LDAP users always have Config privileges. RADIUS users can be defined as either Config or Basic users.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Click External Authentication.
Step 3 Click the Manage External Authentication Server link.
You can also open the External Authentication screen by clicking System > Users > External Authentication.
• SSL Certificate Upload Path—For SSL or TLS encryption, you must choose a certificate by clicking
Choose File.
• (Not Used) User Name Template—Not used by the FTD.
• Timeout—Enter the number of seconds before rolling over to the backup connection. The default is 30.
i) (Optional) Set the Shell Access Attribute if you want to use a shell access attribute other than the user distinguished
type. For example, on a Microsoft Active Directory Server, use the sAMAccountName shell access attribute to retrieve
shell access users by typing sAMAccountName in the Shell Access Attribute field.
j) Set the Shell Access Filter.
Choose one of the following methods:
• To use the same filter you specified when configuring authentication settings, choose Same as Base Filter.
• To retrieve administrative user entries based on attribute value, enter the attribute name, a comparison operator,
and the attribute value you want to use as a filter, enclosed in parentheses. For example, if all network
administrators have a manager attribute which has an attribute value of shell, you can set a base filter of
(manager=shell).
k) Click Save.
Step 5 For LDAP, if you later add or delete users on the LDAP server, you must refresh the user list and redeploy the Platform
Settings.
a) Choose System > Users > External Authentication.
b) Click Refresh ( ) next to the LDAP server.
If the user list changed, you will see a message advising you to deploy configuration changes for your device. The
Firepower Theat Defense Platform Setttings will also show that it is "Out-of-Date on x targeted devices."
c) Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 6 Configure a RADIUS Authentication Object.
a) Define users on the RADIUS server using the Service-Type attribute.
The following are supported values for the Service-Type attribute:
• Administrator (6)—Provides Config access authorization to the CLI. These users can use all commands in the
CLI.
• NAS Prompt (7) or any level other than 6—Provides Basic access authorization to the CLI. These users can
use read-only commands, such as show commands, for monitoring and troubleshooting purposes.
Alternatively, you can predefine users in the external authentication object (see Step 6.j, on page 1162). To use the
same RADIUS server for the FTD and FMC while using the Service-Type attribute method for the FTD, create
two external authentication objects that identify the same RADIUS server: one object includes the predefined Shell
Access Filter users (for use with the FMC), and the other object leaves the Shell Access Filter empty (for use with
FTDs).
b) In FMC, click Add External Authentication Object.
c) Set the Authentication Method to RADIUS.
d) Enter a Name and optional Description.
e) For the Primary Server, enter a Host Name/IP Address.
Note If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the
host name used in this field. In addition, IPv6 addresses are not supported for encrypted connections.
• Timeout (Seconds)—Enter the number of seconds before rolling over to the backup connection. The default
is 30.
• Retries—Enter the number of times the primary server connection should be tried before rolling over to the
backup connection. The default is 3.
j) (Optional) Instead of using RADIUS-defined users, under Shell Access Filter, enter a comma-separated list of
usernames in the Administrator Shell Access User List field. For example, enter jchrichton, aerynsun,
rygel.
You may want to use the Shell Access Filter method for FTD so you can use the same external authentication
object with FTD and other platform types. Note that if you want to use RADIUS-defined users, you must leave the
Shell Access Filter empty.
Make sure that these usernames match usernames on the RADIUS server. The names must be Linux-valid usernames:
• Maximum 32 alphanumeric characters, plus hyphen (-) and underscore (_)
• All lowercase
• Cannot start with hyphen (-); cannot be all numbers; cannot include a period (.), at sign (@), or slash (/)
Note If you want to only define users on the RADIUS server, you must leave this section empty.
k) Click Save.
Step 7 Return to Devices > > Platform Settings > External Authentication.
Step 9 Click Slider enabled ( ) next to the External Authentication object you want to use. You can only enable one object.
Step 10 Click Save.
Step 11 Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note These settings establish the defaults for devices assigned this policy. You can override these settings for
specific interfaces on a device by selecting Override Default Fragment Setting in the interface configuration.
When you edit an interface, you can find the option on Advanced > Security Configuration. Select Devices >
Device Management, edit a FTD device, and select Interfaces to edit interface properties..
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Fragment Settings.
Step 3 Configure the following options. Click Reset to Defaults if you want to use the default settings.
• Size (Block)—The maximum number of packet fragments from all connections collectively that can be waiting for
reassembly. The default is 200 fragments.
• Chain (Fragment)—The maximum number of packets into which a full IP packet can be fragmented. The default
is 24 packets. Set this option to 1 to disallow fragments.
• Timeout (Sec)—The maximum number of seconds to wait for an entire fragmented packet to arrive. The default is
5 seconds. If all fragments are not received within this time, all fragments are discarded.
Configure HTTP
If you want to allow HTTPS connections to one or more interfaces on the FTD device, configure HTTPS
settings. You can use HTTPS to download packet captures for troubleshooting.
• You need network objects that define the hosts or networks you will allow to make HTTPS connections
to the device. You can add objects as part of the procedure, but if you want to use object groups to identify
a group of IP addresses, ensure that the groups needed in the rules already exist. Select Objects > Object
Management to configure objects.
Note You cannot use the system-provided any network object group. Instead, use
any-ipv4 or any-ipv6.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select HTTP.
Step 3 Enable the HTTPS server by clicking Enable HTTP server.
Step 4 (Optional) Change the HTTPS port. The default is 443.
Step 5 Identify the interfaces and IP addresses that allow HTTPS connections.
Use this table to limit which interfaces will accept HTTPS connections, and the IP addresses of the clients who are allowed
to make those connections. You can use network addresses rather than individual IP addresses.
a) Click Add to add a new rule, or click Edit to edit an existing rule.
b) Configure the rule properties:
• IP Address—The network object that identifies the hosts or networks you are allowing to make HTTPS
connections. Choose an object from the drop-down menu, or add a new network object by clicking +.
• Security Zones—Add the zones that contain the interfaces to which you will allow HTTPS connections. For
interfaces not in a zone, you can type the interface name into the field below the Selected Security Zone list and
click Add. These rules will be applied to a device only if the device includes the selected interfaces or zones.
c) Click OK.
Step 6 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
To protect the device from attacks, you can use ICMP rules to limit ICMP access to interfaces to particular
hosts, networks, or ICMP types. ICMP rules function like access rules, where the rules are ordered, and the
first rule that matches a packet defines the action.
If you configure any ICMP rule for an interface, an implicit deny ICMP rule is added to the end of the ICMP
rule list, changing the default behavior. Thus, if you want to simply deny a few message types, you must
include a permit any rule at the end of the ICMP rule list to allow the remaining message types.
We recommend that you always grant permission for the ICMP unreachable message type (type 3). Denying
ICMP unreachable messages disables ICMP path MTU discovery, which can halt IPsec and PPTP traffic.
Additionally ICMP packets in IPv6 are used in the IPv6 neighbor discovery process.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select ICMP.
Step 3 Configure ICMP rules.
a) Click Add to add a new rule, or click Edit to edit an existing rule.
b) Configure the rule properties:
• Action—Whether to permit (allow) or deny (drop) matching traffic.
• ICMP Service—The port object that identifies the ICMP message type.
• Network—The network object or group that identifies the hosts or networks whose access you are controlling.
• Security Zones—Add the zones that contain the interfaces that you are protecting. For interfaces not in a zone,
you can type the interface name into the field below the Selected Security Zone list and click Add. These rules
will be applied to a device only if the device includes the selected interfaces or zones.
c) Click OK.
Step 4 (Optional.) Set rate limits on ICMPv4 Unreachable messages.
• Rate Limit—Sets the rate limit of unreachable messages, between 1 and 100 messages per second. The default is
1 message per second.
• Burst Size—Sets the burst rate, between 1 and 10. This value is not currently used by the system.
Note You must have administrator privileges and be in a leaf domain to perform this task.
You must make sure that you are running a fully licensed version of the Firepower Management Center. The
SSL Settings will be disabled if you are running Firepower Management Center in evaluation mode.
Additionally, the SSL Settings will be disabled when the licensed Firepower Management Center version
does not meet the export-compliance criteria. If you are using Remote Access VPN with SSL, your Smart
Account must have the strong-crypto features enabled. For more information, see FTD License Types and
Restrictions, on page 96.
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Select SSL.
Step 3 Add entries to the Add SSL Configuration table.
a) Click Add to create a new entry, or click Edit if the entry already exists.
b) Select the required security configurations from the drop-down list .
• Protocol Version—Specifies the TLS protocols to be used while establishing remote access VPN sessions.
• Security Level—Indicates the kind of security positioning you would like to set up for the SSL.
Step 4 Select the Available Algorithms based on the protocol version that you select and click Add to include them for the
selected protocol. For more information, seeAbout SSL Settings, on page 1166
The algorithms are listed based on the protocol version that you select. Each security protocol identifies unique algorithm
for setting up the security level.
What to do next
Select Deploy > Deployment and click Deploy to deploy the policy to the assigned devices.
Fields
Minimum SSL Version as Server—Specify the minimum SSL/TLS protocol version that the Firepower
Threat Defense device uses when acting as a server. For example, when it functions as a Remote Access VPN
Gateway.
TLS Version—Select one of the following TLS versions from the drop-down list:
DTLS Version—Select the DTLS versions from the drop-down list, based on the selected TLS version. By
default, DTLSv1 is configured on FTD device, you can choose the DTLS version as per your requirement.
Note Ensure that the TLS protocol version is higher than or equal to the DTLS protocol version selected. TLS
protocol versions support the following DTLS versions:
TLS V1 DTLSv1
TLSV1.1 DTLSv1
Diffie-Hellman Group—Choose a group from the drop-down list. Available options are Group1 - 768-bit
modulus, Group2 - 1024-bit modulus, Group5 - 1536-bit modulus, Group14 - 2048-bit modulus, 224-bit prime
order, and Group24 - 2048-bit modulus, 256-bit prime order. The default is Group1.
Elliptical Curve Diffie-Hellman Group—Choose a group from the drop-down list. Available options are
Group19 - 256-bit EC, Group20 - 384-bit EC, and Group21 - 521-bit EC. The default value is Group19.
TLSv1.2 adds support for the following ciphers:
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-GCM-SHA384
• AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-GCM-SHA256
• RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
The SSL configuration table can be used to specify the protocol version, security level, and Cipher algorithms
that you want to support on the Firepower Threat Defense devices.
Protocol Version—Lists the protocol version that the Firepower Threat Defense device supports and uses
for SSL connections. Available protocol versions are:
• Default
• TLSV1
• TLSV1.1
• TLSV1.2
• DTLSv1
• DTLSv1.2
Security Level—Lists the cipher security levels that Firepower Threat Defense device supports and uses for
SSL connections.
If you have Firepower Threat Defense devices with evaluation license, the security level is Low by default.
With Firepower Threat Defense smart license, the default security level is High. You can choose one of the
following options to configure the required security level:
• All includes all ciphers, including NULL-SHA.
• Low includes all ciphers, except NULL-SHA.
• Medium includes all ciphers, except NULL-SHA, DES-CBC-SHA, RC4-SHA, and RC4-MD5 (this is
the default).
• Fips includes all FIPS-compliant ciphers, except NULL-SHA, DES-CBC-SHA, RC4-MD5, RC4-SHA,
and DES-CBC3-SHA.
• High includes only AES-256 with SHA-2 ciphers and applies to TLS version 1.2 and the default version.
• Custom includes one or more ciphers that you specify in the Cipher algorithms/custom string box. This
option provides you with full control of the cipher suite using OpenSSL cipher definition strings.
Cipher Algorithms/Custom String—Lists the cipher algorithms that Firepower Threat Defense device
supports and uses for SSL connections. For more information about ciphers using OpenSSL, see
https://www.openssl.org/docs/apps/ciphers.html
The Firepower Threat Defense device specifies the order of priority for supported ciphers as:
Ciphers supported by TLSv1.2 only
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-SHA256
AES256-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA256
AES128-SHA256
RC4-SHA
RC4-MD5
DES-CBC-SHA
NULL-SHA
For the Management interface, to configure an SSH access list, see the configure ssh-access-list command
in the Firepower Threat Defense Command Reference. To configure a static route, see the configure network
static-routes command. By default, you configure the default route through the Management interface at
initial setup.
To use SSH, you do not also need an access rule allowing the host IP address. You only need to configure
SSH access according to this section.
You can only SSH to a reachable interface; if your SSH host is located on the outside interface, you can only
initiate a management connection directly to the outside interface.
The device allows a maximum of 5 concurrent SSH connections.
Note On all appliances, after a user makes three consecutive failed attempts to log into the CLI via SSH, the system
terminates the SSH connection.
Note You cannot use the system-provided any network object. Instead, use any-ipv4
or any-ipv6.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Secure Shell.
Step 3 Identify the interfaces and IP addresses that allow SSH connections.
Use this table to limit which interfaces will accept SSH connections, and the IP addresses of the clients who are allowed
to make those connections. You can use network addresses rather than individual IP addresses.
a) Click Add to add a new rule, or click Edit to edit an existing rule.
b) Configure the rule properties:
• IP Address—The network object that identifies the hosts or networks you are allowing to make SSH connections.
Choose an object from the drop-down menu, or add a new network object by clicking +.
• Security Zones—Add the zones that contain the interfaces to which you will allow SSH connections. For
interfaces not in a zone, you can type the interface name into the field below the Selected Security Zone list and
click Add. These rules will be applied to a device only if the device includes the selected interfaces or zones.
c) Click OK.
Step 4 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Configure SMTP
You must identity an SMTP server if you configure email alerts in the Syslog settings. The source email
address you configure for Syslog must be a valid account on the SMTP servers.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Click SMTP Server.
Step 3 Select the network objects that identify the Primary Server IP Address and optionally, the Secondary Server IP
Address.
Step 4 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Note To create an alert to an external SNMP server, access Policies > Action > Alerts
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select SNMP.
Step 3 Enable SNMP and configure basic options.
• Enable SNMP Servers—Whether to provide SNMP information to the configured SNMP hosts. You can deselect
this option to disable SNMP monitoring while retaining the configuration information.
• Read Community String, Confirm—Enter the password used by a SNMP management station when sending
requests to the FTD device. The SNMP community string is a shared secret among the SNMP management stations
and the network nodes being managed. The security device uses the password to determine if the incoming SNMP
request is valid. The password is a case-sensitive alphanumeric string of up to 32 characters; spaces and special
characters are not permitted.
• System Administrator Name—Enter the name of the device administrator or other contact person. This string is
case-sensitive and can be up to 127 characters. Spaces are accepted, but multiple spaces are shortened to a single
space.
• Location—Enter the location of this security device (for example, Building 42,Sector 54). This string is case-sensitive
and can be up to 127 characters. Spaces are accepted, but multiple spaces are shortened to a single space.
• Port—Enter the UDP port on which incoming requests will be accepted. The default is 161.
Note You create users for SNMPv3 only. These steps are not applicable for SNMPv1 or SNMPv2c.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Click SNMP > Users.
Step 3 Click Add.
Step 4 Select the security level for the user from the Security Level drop-down list.
• Auth—Authentication but No Privacy, which means that messages are authenticated.
• No Auth—No Authentication and No Privacy, which means that no security is applied to messages.
• Priv—Authentication and Privacy, which means that messages are authenticated and encrypted.
Step 5 Enter the name of the SNMP user in the Username field. Usernames must be 32 characters or less.
Step 6 Select the type of password, you want to use in the Encryption Password Type drop-down list.
• Clear text—The FTD device will still encrypt the password when deploying to the device.
• Encrypted—The FTD device will directly deploy the encrypted password.
Step 7 Select the type of authentication you want to use: MD5 or SHA, in the Auth Algorithm Type drop-down list.
Step 8 In the Authentication Password field, enter the password to use for authentication. If you selected Encrypted as the
Encrypt Password Type, the password must be formatted as xx:xx:xx..., where xx are hexadecimal values.
Note The length of the password will depend on the authentication algorithm selected. For all passwords, the length
must be 256 characters or less.
If you selected Clear Text as the Encrypt Password Type, repeat the password in the Confirm field.
Step 9 In the Encryption Type drop-down list, select the type of encryption you want to use: AES128, AES192,AES256,
3DES, DES.
Note To use AES or 3DES encryption, you must have the appropriate license installed on the device.
Step 10 Enter the password to use for encryption in theEncryption Password field. If you selected Encrypted as the Encrypt
Password Type, the password must be formatted as xx:xx:xx..., where xx are hexadecimal values. For encrypted
passwords, the length of the password depends on the encryption type selected. The password sizes are as follows
(where each xx is one octal):
• AES 128 requires 16 octals
• AES 192 requires 24 octals
• AES 256 requires 32 octals
• 3DES requires 32 octals
• DES can be any size
Note For all passwords, the length must be 256 characters or less.
If you selected Clear Text as the Encrypt Password Type, repeat the password in the Confirm field.
You can add up to 4000 hosts. However, only 128 of this number can be for traps.
Note The supported network objects include IPv6 hosts, IPv4 hosts, IPv4 range and IPv4 subnet addresses.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Click SNMP > Hosts.
Step 3 Click Add.
Step 4 In the IP Address field, either enter a valid IPv6 or IPv4 host or select the network object that defines the SNMP
management station's host address.
The IP address can be an IPv6 host, IPv4 host, IPv4 range or IPv4 subnet.
Step 5 Select the appropriate SNMP version from the SNMP version drop-down list.
Step 6 (SNMPv3 only.) Select the username of the SNMP user that you configured from the User Name drop-down list.
Note You can associate up to 23 SNMP users per SNMP host.
Step 7 (SNMPv1, 2c only.) In the Read Community String field, enter the community string that you have already configured,
for read access to the device. Re-enter the string to confirm it.
Note This string is required, only if the string used with this SNMP station is different from the one already defined
in the Enable SNMP Server section.
Step 8 Select the type of communication between the device and the SNMP management station. You can select both types.
• Poll—The management station periodically requests information from the device.
• Trap—The device sends trap events to the management station as they occur.
Note When the SNMP host IP address is either an IPv4 range or an IPv4 subnet, you can configure either Poll or
Trap, not both.
Step 9 In the Port field, enter a UDP port number for the SNMP host. The default value is 162. The valid range is 1 to 65535.
Step 10 Select the interface type for communication between the device and the SNMP management station under the Reachable
By options. You can select either the device's Management interface or an available security zone/named interface.
• Device Management Interface—Communication between the device and the SNMP management station occurs
over the Management interface.
• Security Zones or Named Interface—Communication between the device and the SNMP management station
occurs over a security zone or interface.
• Search for zones in the Available Zones field.
• Add the zones that contain the interfaces through which the device communicates with the management
station to the Selected Zone/Interface field. For interfaces not in a zone, you can type the interface name
into the field below the Selected 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 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Click SNMP > SNMP Traps to configure SNMP traps (event notifications) for the FTD device.
Step 3 Select the appropriate Enable Traps options. You can select either or both options.
a) Check Enable All SNMP Traps to quickly select all traps in the subsequent four sections.
b) Check Enable All Syslog Traps to enable transmission of trap-related syslog messages.
Note SNMP traps are of higher priority than other notification messages from the FTD as they are expected to be
near real-time. When you enable all SNMP or syslog traps, it is possible for the SNMP process to consume
excess resources in the agent and in the network, causing the system to hang. If you notice system delays,
unfinished requests, or timeouts, you can selectively enable SNMP and syslog traps. You can also limit the
rate at which syslog messages are generated by severity level or message ID. For example, all syslog message
IDs that begin with the digits 212 are associated with the SNMP class; see Limit the Rate of Syslog Message
Generation, on page 1187.
Step 4 The event-notification traps in the Standard section are enabled by default for an existing policy:
• Authentication – Unauthorized SNMP access. This authentication failure occurs for packets with an incorrect
community string
• Link Up – One of the device’s communication links has become available (it has “come up”), as indicated in the
notification
• Link Down – One of the device’s communication links has failed, as indicated in the notification
• Cold Start – The device is reinitializing itself such that its configuration or the protocol entity implementation may
be altered
• Warm Start – The device is reinitializing itself such that its configuration and the protocol entity implementation
is unaltered
Step 5 Select the desired event-notification traps in the Entity MIB section:
• Field Replaceable Unit Insert – A Field Replaceable Unit (FRU) has been inserted, as indicated. (FRUs include
assemblies such as power supplies, fans, processor modules, interface modules, etc.)
• Field Replaceable Unit Delete – A Field Replaceable Unit (FRU) has been removed, as indicated in the notification
• Configuration Change – There has been a hardware change, as indicated in the notification
About Syslog
System logging is a method of collecting messages from devices to a server running a syslog daemon. Logging
to a central syslog server helps in aggregation of logs and alerts. Cisco devices can send their log messages
to a UNIX-style syslog service. A syslog service accepts messages and stores them in files, or prints them
according to a simple configuration file. This form of logging provides protected long-term storage for logs.
Logs are useful both in routine troubleshooting and in incident handling.
Device and This syslog configuration generates messages for features running on Platform
system health, the data plane, that is, features that are defined in the CLI configuration Settings
network that you can view with the show running-config command. This
configuration includes features such as routing, VPN, data interfaces, DHCP server,
NAT, and so forth. Data plane syslog messages are numbered, and they
are the same as those generated by devices running ASA software.
However, Firepower Threat Defense does not necessarily generate every
message type that is available for ASA Software. For information on
these messages, see Cisco Firepower Threat Defense Syslog Messages
at https://www.cisco.com/c/en/us/td/docs/security/firepower/Syslogs/
b_fptd_syslog_guide.html. This configuration is explained in the
following topics.
(Devices This syslog configuration generates alerts for file and malware, Platform
running versions connection, Security Intelligence, and intrusion events. For details, see Settings and the
6.3 and later) About Sending Syslog Messages for Security Events, on page 2337 and Logging in an
subtopics. access control
Security events
policy
(All devices) This syslog configuration generates alerts for access control rules, Alert Responses
intrusion rules, and other advanced services as described in and the Logging
Policies, rules,
Configurations Supporting Alert Responses, on page 2272. These messages in an access
and events
are not numbered. For information on configuring this type of syslog, control policy
see Creating a Syslog Alert Response, on page 2274.
You can configure more than one syslog server, and control the messages and events sent to each server. You
can also configure different destinations, such as console, email, internal buffer, and so forth.
Severity Levels
The following table lists the syslog message severity levels.
Note Firepower Threat Defense does not generate syslog messages with a severity level of zero (emergencies).
You customize these criteria by creating a message list that you can specify when you set the output destination.
Alternatively, you can configure the Firepower Threat Defense device to send a particular message class to
each type of output destination independently of the message list.
(Message lists do not apply to syslog messages for security events such as connection and intrusion events.)
Note This topic does not apply to messages for security events (connection, intrusion, etc.)
The syslog message class provides a method of categorizing syslog messages by type, equivalent to a feature
or function of the device. For example, the rip class denotes RIP routing.
All syslog messages in a particular class share the same initial three digits in their syslog message ID numbers.
For example, all syslog message IDs that begin with the digits 611 are associated with the vpnc (VPN client)
class. Syslog messages associated with the VPN client feature range from 611101 to 611323.
In addition, most of the ISAKMP syslog messages have a common set of prepended objects to help identify
the tunnel. These objects precede the descriptive text of a syslog message when available. If the object is not
known at the time that the syslog message is generated, the specific heading = value combination does not
appear.
The objects are prefixed as follows:
Group = groupname, Username = user, IP = IP_address
Where the group is the tunnel-group, the username is the username from the local database or AAA server,
and the IP address is the public IP address of the remote access client or Layer 2 peer.
The following table lists the message classes and the range of message IDs in each class.
— Clustering 747
eap, eapoudp EAP or EAPoUDP for Network Admission Control 333, 334
— IPv6 325
— Licensing 444
— NP SSL 725
session User Session 106, 108, 201, 202, 204, 302, 303, 304,
305, 314, 405, 406, 407, 500, 502, 607,
608, 609, 616, 620, 703, 710
— ScanSafe 775
sys System 199, 211, 214, 216, 306, 307, 315, 414,
604, 605, 606, 610, 612, 614, 615,701,
711, 741
— UC-IME 339
vpn IKE and IPsec 316, 320, 402, 404, 501, 602, 702, 713,
714, 715
— VXLAN 778
IPv6 Guidelines
• IPv6 is supported. Syslogs can be sent using TCP or UDP.
• Ensure that the interface configured for sending syslogs is enabled, IPv6 capable, and the syslog server
is reachable through the designated interface.
• Secure logging over IPv6 is not supported.
Additional Guidelines
• The syslog server must run a server program called syslogd. Windows provides a syslog server as part
of its operating system.
• To view logs generated by the Firepower Threat Defense device, you must specify a logging output
destination. If you enable logging without specifying a logging output destination, the Firepower Threat
Defense device generates messages but does not save them to a location from which you can view them.
You must specify each different logging output destination separately.
• It is not possible to have two different lists or classes being assigned to different syslog servers or same
locations.
This is the expected behavior. Note that the global UDP connection idle timeout applies to these sessions,
and the default is 2 minutes. You can adjust that setting if you want to close these session more quickly,
but the timeout applies to all UDP connections, not just syslog.
• When the Firepower Threat Defense device sends syslogs via TCP, the connection takes about one minute
to initiate after the syslogd service restarts.
Tip If you are configuring devices to send syslog messages about security events (such as connection and intrusion
events), most FTD platform settings do not apply to these messages. See FTD Platform Settings That Apply
to Security Event Syslog Messages, on page 1183.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Click Syslog from the table of contents.
Step 3 Click Logging Setup to enable logging, specify FTP Server settings, and specify Flash usage. For more information, see
Enable Logging and Configure Basic Settings, on page 1183
Step 4 Click Logging Destinations to enable logging to specific destinations and to specify filtering on message severity level,
event class, or on a custom event list. For more information, see Enable Logging Destinations, on page 1185
You must enable a logging destination to see messages at that destination.
Step 5 Click E-mail Setup to specify the e-mail address that is used as the source address for syslog messages that are sent as
e-mail messages. For more information, see Send Syslog Messages to an E-mail Address, on page 1185
Step 6 Click Events List to define a custom event list that includes an event class, a severity level, and an event ID. For more
information, see Create a Custom Event List, on page 1186
Step 7 Click Rate Limit to specify the volume of messages being sent to all configured destinations and define the message
severity level to which you want to assign rate limits. For more information, see Limit the Rate of Syslog Message
Generation, on page 1187
Step 8 Click Syslog Settings to specify the logging facility, enable the inclusion of a time stamp, and enable other settings to
set up a server as a syslog destination. For more information, see Configure Syslog Settings, on page 1188
Step 9 Click Syslog Servers to specify the IP address, protocol used, format, and security zone for the syslog server that is
designated as a logging destination. For more information, see Configure a Syslog Server, on page 1189
See also Best Practices for Configuring Security Event Syslog Messaging, on page 2337.
Tip If you are configuring devices to send syslog messages about security events (such as connection and intrusion
events), most FTD platform settings do not apply to these messages. See FTD Platform Settings That Apply
to Security Event Syslog Messages, on page 1183.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Syslog > Logging Setup.
Step 3 Enable logging and configure basic logging settings.
• Enable Logging—Turns on data plane system logging for the Firepower Threat Defense device.
• Enable Logging on the Failover Standby Unit—Turns on logging for the standby for the Firepower Threat Defense
device, if available.
• Send syslogs in EMBLEM format—Enables EMBLEM format logging for every logging destination. If you enable
EMBLEM, you must use the UDP protocol to publish syslog messages; EMBLEM is not compatible with TCP.
Note Syslog messages in RFC5424 format, typically displays the priority value (PRI). However, in FMC, if
you want to display the PRI value in the syslog messages of the managed FTD, ensure to enable the
EMBLEM format. For more information on PRI, see RFC5424.
• Send debug messages as syslogs—Redirects all the debug trace output to the syslog. The syslog message does not
appear in the console if this option is enabled. Therefore, to see debug messages, you must enable logging at the
console and configure it as the destination for the debug syslog message number and logging level. The syslog
message number used is 711011. Default logging level for this syslog is debug.
• Memory Size of Internal Buffer—Specify the size of the internal buffer to which syslog messages are saved if the
logging buffer is enabled. When the buffer fills up, it is overwritten. The default is 4096 bytes. The range is 4096
to 52428800.
Step 4 (Optional) Enable VPN logging by checking the Enable Logging to FMC check box. Choose the syslog severity level
for VPN messages from the Logging Level drop-down list.
For information on the levels, see Severity Levels, on page 1177.
Step 5 (Optional) Configure an FTP server if you want to save log buffer contents to the server before the buffer is overwritten.
Specify the FTP Server information.
• FTP Server Buffer Wrap— To save the buffer contents to the FTP server before it is overwritten, check this box
and enter the necessary destination information in the following fields. To remove the FTP configuration, deselect
this option.
• IP Address—Select the host network object that contains the IP address of the FTP server.
• User Name—Enter the user name to use when connecting to the FTP server.
• Path—Enter the path, relative to the FTP root, where the buffer contents should be saved.
• Password/ Confirm—Enter and confirm the password used to authenticate the user name to the FTP server.
Step 6 (Optional) Specify Flash size if you want to save log buffer contents to flash before the buffer is overwritten.
• Flash—To save the buffer contents to the flash memory before it is overwritten, check this box.
• Maximum flash to be used by logging (KB)—Specify the maximum space to be used in the flash memory for
logging(in KB). The range is 4-8044176 bytes.
• Minimum free space to be preserved (KB)—Specifies the minimum free space to be preserved in flash memory
(in KB). The range is 0-8044176 bytes.
Tip If you are configuring devices to send syslog messages about security events (such as connection and intrusion
events), most FTD platform settings do not apply to these messages. See FTD Platform Settings That Apply
to Security Event Syslog Messages, on page 1183.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Syslog > Logging Destinations.
Step 3 Click Add to enable a destination and apply a logging filter, or edit an existing destination.
Step 4 In the Logging Destinations dialog box, select a destination and configure the filter to use for a destination:
a) Choose the destination you are enabling in the Logging Destination drop-down list. You can create one filter per
destination: Console, E-Mail, Internal buffer, SNMP trap, SSH Sessions, and Syslog servers.
Note Console and SSH session logging works in the diagnostic CLI only. Enter system support diagnostic-cli.
b) In Event Class, choose the filter that will apply to all classes not listed in the table.
You can configure these filters:
• Filter on severity —Select the severity level. Messages at this level or higher are sent to the destination
• Use Event List —Select the event list that defines the filter. You create these lists on the Event Lists page.
• Disable Logging —Prevents messages from being sent to this destination.
c) If you want to create filters per event class, click Add to create a new filter, or edit an existing filter, and select the
event class and severity level to limit messages in that class. Click OK to save the filter.
For an explanation of the event classes, see Syslog Message Classes, on page 1178.
d) Click OK .
Step 5 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
Tip If you are configuring devices to send syslog messages about security events (such as connection and intrusion
events), most FTD platform settings do not apply to these messages. See FTD Platform Settings That Apply
to Security Event Syslog Messages, on page 1183.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Syslog > Email Setup.
Step 3 Specify the e-mail address that is used as the source address for syslog messages that are sent as e-mail messages.
Step 4 Click Add to enter a new e-mail address recipient of the specified syslog messages.
Step 5 Choose the severity level of the syslog messages that are sent to the recipient from the drop-down list.
The syslog message severity filter used for the destination e-mail address causes messages of the specified severity level
and higher to be sent. For information on the levels, see Severity Levels, on page 1177.
Tip If you are configuring devices to send syslog messages about security events (such as connection and intrusion
events), most FTD platform settings do not apply to these messages. See FTD Platform Settings That Apply
to Security Event Syslog Messages, on page 1183.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Syslog > Events List.
Step 3 Configure an event list.
a) Click Add to add a new list, or edit an existing list.
b) Enter a name for the event list in the Name field. Spaces are not allowed.
c) To identify messages based on severity or event class, select the Severity/Event Class tab and add or edit entries.
For information on the available classes see Syslog Message Classes, on page 1178.
For information on the levels, see Severity Levels, on page 1177.
Certain event classes are not applicable for the device in transparent mode. If such options are configured then they
will be bypassed and not deployed.
d) To identify messages specifically by message ID, select the Message ID and add or edit the IDs.
You can enter a range of IDs using a hyphen, for example, 100000-200000. IDs are six digits. For information on
how the initial three digits map to features, see Syslog Message Classes, on page 1178.
For specific message numbers, see Cisco ASA Series Syslog Messages.
e) Click OK to save the event list.
Step 4 Click Logging Destinations and add or edit the destination that should use the filter.
See Enable Logging Destinations, on page 1185.
Tip If you are configuring devices to send syslog messages about security events (such as connection and intrusion
events), most FTD platform settings do not apply to these messages. See FTD Platform Settings That Apply
to Security Event Syslog Messages, on page 1183.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Syslog > Rate Limit.
Step 3 To limit message generation by severity level, click Logging Level > Add and configure the following options:
• Logging Level—The severity level you are rate limiting. For information on the levels, see Severity Levels, on page
1177.
• Number of messages—The maximum number of messages of the specified type allowed in the specified time
period.
• Interval—The number of seconds before the rate limit counter resets.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Syslog > Syslog Settings.
Step 3 Select a system log facility for syslog servers to use as a basis to file messages in the Facility drop-down list.
The default is LOCAL4(20), which is what most UNIX systems expect. However, because your network devices share
available facilities, you might need to change this value for system logs.
Facility values are not typically relevant for security events. If you need to include Facility values in messages, see Facility
in Security Event Syslog Messages, on page 2348.
Step 4 Select the Enable timestamp on each syslog message check box to include the date and time a message was generated
in the syslog message.
Step 5 Select the Timestamp Format for the syslog message:
• The Legacy (MMM dd yyyy HH:mm:ss) format is the default format for syslog messages.
When this timestamp format is selected, the messages do not indicate the time zone, which is always UTC.
• RFC 5424 (yyyy-MM-ddTHH:mm:ssZ) uses the ISO 8601 timestamp format as specified in the RFC 5424 syslog
format.
If you select the RFC 5424 format, a “Z” is appended to the end of each timestamp to indicate that the timestamp
uses the UTC time zone.
Step 6 If you want to add a device identifier to syslog messages (which is placed at the beginning of the message), check the
Enable Syslog Device ID check box and then select the type of ID.
• Interface—To use the IP address of the selected interface, regardless of the interface through which the appliance
sends the message. Select the security zone that identifies the interface. The zone must map to a single interface.
• User Defined ID—To use a text string (up to 16 characters) of your choice.
• Host Name—To use the hostname of the device.
Step 7 Use the Syslog Message table to alter the default settings for specific syslog messages. You need to configure rules in
this table only if you want to change the default settings. You can change the severity assigned to a message, or you can
disable the generation of a message.
By default, Netflow is enabled and the entries are shown in the table.
a) To suppress syslog messages that are redundant because of Netflow, select Netflow Equivalent Syslogs.
This adds the messages to the table as suppressed messages.
Note If any of these syslog equivalents are already in the table, your existing rules are not overwritten.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
FTD Platform Settings That Apply to Security Event Syslog Messages, on page 1183
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Syslog > Syslog Server.
Step 3 Check the Allow user traffic to pass when TCP syslog server is down check box, to allow traffic if any syslog server
that is using the TCP protocol is down.
Step 4 Enter a size of the queue for storing syslog messages on the security appliance when syslog server is busy in the Message
queue size (messages) field. The minimum is 1 message. The default is 512. Specify 0 to allow an unlimited number of
messages to be queued (subject to available block memory).
Step 5 Click Add to add a new syslog server.
a) In the IP Address drop-down list, select a network host object that contains the IP address of the syslog server.
b) Choose the protocol (either TCP or UDP) and enter the port number for communications between the Firepower
Threat Defense device and the syslog server.
UDP is faster and uses less resources on the device than TCP.
The default ports are 514 for UDP, 1470 for TCP. Valid non-default port values for either protocol are 1025 through
65535.
c) Check the Log messages in Cisco EMBLEM format (UDP only) check box to specify whether to log messages in
Cisco EMBLEM format (available only if UDP is selected as the protocol).
Note Syslog messages in RFC5424 format, typically displays the priority value (PRI). However, in FMC, only
when you enable logging in Cisco EMBLEM format, the PRI value in the syslog messages of the managed
FTD is displayed. For more information on PRI, see RFC5424.
d) Check the Enable Secure Syslog check box to encrypt the connection between the device and server using SSL/TLS
over TCP.
Note You must select TCP as the protocol to use this option. You must also upload the certificate required to
communicate with the syslog server on the Devices > Certificates page. Finally, upload the certificate
from the Firepower Threat Defense device to the syslog server to complete the secure relationship and
allow it to decrypt the traffic. The Enable Secure Syslog option is not supported on the device management
interface.
e) Select Device Management Interface or Security Zones or Named Interfaces to communicate with the syslog
server.
• Device Management Interface: This option is applicable only to Firepower Threat Defense devices 6.3 and
later versions. If the syslog server is reachable over a device management interface, use this option over data
port. We recommend that you use this option when configuring syslog on Snort events.
Note The Device Management Interface option does not support the Enable Secure Syslog option.
• Security Zones or Named Interfaces: Select the interfaces from the list of Available Zones and click Add.
You must also configure this name (if not already configured), and an IP address, for the Diagnostic interface
(edit the device settings from the Device Management page and select the Interfaces tab). For more information
about the management/diagnostic interface, see Diagnostic Interface, on page 625.
Note If the syslog server is on the network attached to the physical Management interface, enter the name
of that interface in the Interface Name field below the Selected Security Zones list and click Add.
You must also configure this name (if not already configured), and an IP address, for the Diagnostic
interface (edit the device settings from the Device Management page and select the Interfaces tab).
For more information about the management/diagnostic interface, see Diagnostic Interface, on page
625.
f) Click OK.
Step 6 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not active until
you deploy them.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Timeouts.
Step 3 Configure the timeouts you want to change.
For any given setting, select Custom to define your own value, Default to return to the system default value. In most
cases, the maximum timeout is 1193 hours.
You can disable some timeouts by selecting Disable.
• Console Timeout—The idle time until a connection to the console is closed, range is 0 or 5 to 1440 minutes. The
default is 0, which means the session does not time out. If you change the value, existing console sessions use the
old timeout value. The new value applies to new connections only.
• Translation Slot (xlate)—The idle time until a NAT translation slot is freed. This duration must be at least 1 minute.
The default is 3 hours.
• Connection (Conn)—The idle time until a connection slot is freed. This duration must be at least 5 minutes. The
default is 1 hour.
• Half-Closed—The idle time until a TCP half-closed connection closes. The minimum is 30 seconds. The default is
10 minutes.
• UDP—The idle time until a UDP connection closes. This duration must be at least 1 minute. The default is 2 minutes.
• ICMP—The idle time after which general ICMP states are closed. The default (and minimum) is 2 seconds.
• RPC/Sun RPC—The idle time until a SunRPC slot is freed. This duration must be at least 1 minute. The default is
10 minutes.
In a Sun RPC-based connection, when the parent connection is deleted or timed-out, a new child connection may
not be considered as a part of the parent-child connection, and thereby the new connection could be evaluated as
per the policy or rules set in the system. After the parent connection has timed-out the existing child connections
are valid only until the timeout value set is reached.
• H.225—The idle time until an H.225 signaling connection closes. The default is 1 hour. To close a connection
immediately after all calls are cleared, a timeout of 1 second (0:0:1) is recommended.
• H.323—The idle time after which H.245 (TCP) and H.323 (UDP) media connections close. The default (and
minimum) is 5 minutes. Because the same connection flag is set on both H.245 and H.323 media connections, the
H.245 (TCP) connection shares the idle timeout with the H.323 (RTP and RTCP) media connection.
• SIP—The idle time until a SIP signaling port connection closes. This duration must be at least 5 minutes. The default
is 30 minutes.
• SIP Media—The idle time until a SIP media port connection closes. This duration must be at least 1 minute. The
default is 2 minutes. The SIP media timer is used for SIP RTP/RTCP with SIP UDP media packets, instead of the
UDP inactivity timeout.
• SIP Disconnect—The idle time after which SIP session is deleted if the 200 OK is not received for a CANCEL or
a BYE message, between 0:0:1 and 0:10:0. The default is 2 minutes (0:2:0).
• SIP Invite—The idle time after which pinholes for PROVISIONAL responses and media xlates will be closed,
between 0:1:0 and 00:30:0. The default is 3 minutes (0:3:0).
• SIP Provisional Media—The timeout value for SIP provisional media connections, between 1 and 30 minutes. The
default is 2 minutes.
• Floating Connection—When multiple routes exist to a network with different metrics, the ASA uses the one with
the best metric at the time of connection creation. If a better route becomes available, then this timeout lets connections
be closed so a connection can be reestablished to use the better route. The default is 0 (the connection never times
out). To make it possible to use better routes, set the timeout to a value between 0:0:30 and 1193:0:0.
• Xlate PAT—The idle time until a PAT translation slot is freed, between 0:0:30 and 0:5:0. The default is 30 seconds.
You may want to increase the timeout if upstream routers reject new connections using a freed PAT port because
the previous connection might still be open on the upstream device.
• TCP Proxy Reassembly—The idle timeout after which buffered packets waiting for reassembly are dropped,
between 0:0:10 and 1193:0:0. The default is 1 minute (0:1:0).
• ARP Timeout—(Transparent mode only.) The number of seconds between ARP table rebuilds, from 60 to 4294967.
The default is 14,400 seconds (4 hours).
Note If you are deploying FTD on the Firepower 4100/9300 chassis, you must configure NTP on the Firepower
4100/9300 chassis so that Smart Licensing will work properly and to ensure proper timestamps on device
registrations. You should use the same NTP server for the Firepower 4100/9300 chassis and the Firepower
Management Center.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
Step 2 Select Time Synchronization.
Step 3 Configure one of the following clock options:
• Via NTP from Defense Center—(Default). The managed device gets time from the NTP servers you configured
for the Firepower Management Center (except for authenticated NTP servers) and synchronizes time with those
servers directly. However, if any of the following are true, the managed device synchronizes time from the Firepower
Management Center:
• The Firepower Management Center’s NTP servers are not reachable by the device.
• The Firepower Management Center has no unauthenticated servers.
• Via NTP from—If your Firepower Management Center is using NTP servers on the network, select this option and
enter the fully-qualified DNS name (such as ntp.example.com), or IP address, of the same NTP servers you specified
in System > Configuration > Time Synchronization. If the NTP servers are not reachable, the Firepower
Management Center acts as an NTP server.
What to do next
• Make sure the policy is assigned to your devices. See Setting Target Devices for a Platform Settings
Policy, on page 1145.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• If your Firepower system includes Classic devices, set up time synchronization for those devices. See
Synchronize Time on Classic Devices with an NTP Server, on page 1152.
The time zone you specify will be used only for time-based policy application in policies that support this
functionality.
Step 1 Select Devices > Platform Settings and create or edit an FTD policy.
You can also create time zone objects from the Objects > Object Management > Time Zone page.
What to do next
• Make sure the policy is assigned to your devices. See Setting Target Devices for a Platform Settings
Policy, on page 1145.
• Create time range objects, select applicable time ranges in access control and prefilter rules, and assign
the parent policies to devices associated with the correct time zone.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Specify time zone for device 6.6 Specify a local time zone for a managed
device, for use in time-based policy
application.
New screen:
Devices > Platform Settings > Time Zone
Supported platforms: Firepower Threat
Defense
Specify the Management interface for 6.6 You can now select the Management
SNMP communication interface for communication between the
device and the SNMP management station.
New/Modified screen:
Devices > Platform Settings > SNMP >
Hosts
Supported platforms: Firepower Threat
Defense
Limit number of SSH login failures 6.3 When a user accesses any device via SSH
and fails three successive login attempts,
the device terminates the SSH session.
External Authentication added for SSH 6.2.3 You can now configure external
authentication for SSH access to the
Firepower Threat Defense using LDAP or
RADIUS.
New/Modified screen:
Devices > Platform Settings > External
Authentication
Supported platforms: Firepower Threat
Defense
Support for UC/APPL compliance mode 6.2.1 You can enable security certifications
compliance in CC mode or UCAPL mode.
Enabling security certifications compliance
does not guarantee strict compliance with
all requirements of the security mode
selected. For more information on
hardening procedures, refer to the
guidelines for this product provided by the
certifying entity.
New/Modified screen:
Devices > Platform Settings > UC/APPL
Compliance
Supported platforms: Any device
SSL settings for remote access VPN 6.2.1 The Firepower Threat Defense device uses
the Secure Sockets Layer (SSL) protocol
and Transport Layer Security (TLS) to
support secure message transmission for
Remote Access VPN connection from
remote clients. You can configure SSL
versions and encryption algorithms that will
be negotiated and used for message
transmission during remote VPN access
over SSL.
New/Modified screen:
Devices > Platform Settings > SSL
Supported platforms: Firepower Threat
Defense
External Authentication for SSH and 6.1.0 Due to changes to support converged
HTML removed management access, only local users are
supported for SSH and HTML to data
interfaces. Also, you can no longer SSH to
the logical Diagnostic interface; instead you
can SSH to the logical Management
interface (which shares the same physical
port). Previously, only external
authentication was supported for SSH and
HTML access to Diagnostic and data
interfaces, while only local users were
supported to the Management interface.
New/Modified screen:
Devices > Platform Settings > External
Authentication
Supported platforms: Firepower Threat
Defense
Note The U.S. Government has changed the name of the Unified Capabilities Approved
Products List (UCAPL) to the Department of Defense Information Network
Approved Products List (DODIN APL). References to UCAPL in this
documentation and the Firepower Management Center web interface can be
interpreted as references to DODIN APL.
• Federal Information Processing Standards (FIPS) 140: a requirements specification for encryption modules
You can enable security certifications compliance in CC mode or UCAPL mode. Enabling security certifications
compliance does not guarantee strict compliance with all requirements of the security mode selected. For
more information on hardening procedures, refer to the guidelines for this product provided by the certifying
entity.
Caution After you enable this setting, you cannot disable it. If you need to take an appliance out of CC or UCAPL
mode, you must reimage.
The system does not allow remote storage for Yes Yes — — — —
backups or reports.
The minimum required password length for the local No No No No Yes Yes
admin user can be configured using the local device
CLI.
The system locks out users other than admin after No Yes No Yes No No
three failed login attempts in a row. In this case, the
password must be reset by an administrator.
The admin user can be locked out after a maximum Yes Yes Yes Yes — —
number of failed login attempts configurable through
the web interface.
The admin user can be locked out after a maximum No No Yes, Yes, Yes Yes
number of failed login attempts configurable through regardless regardless
the local appliance CLI. of security of security
certifications certifications
compliance compliance
enablement. enablement.
The system automtically rekeys an SSH session with Yes Yes Yes Yes Yes Yes
an appliance:
• After a key has been in use for one hour of
session activity
• After a key has been used to transmit 1 GB of
data over the connection
The system performs a file system integrity check Yes Yes Yes Yes Yes Yes
(FSIC) at boot-time. If the FSIC fails, Firepower
software does not start, remote SSH access is
disabled, and you can access the appliance only via
local console. If this happens, contact Cisco TAC.
Caution The Firepower Management Center will not receive event data from a managed
device unless both are operating in the same security certifications compliance
mode.
• For all users, enable password strength checking and set the minimum password length to the value
required by the certifying agency.
• If you are using Firepower Management Centers in a high-availability configuration, configure them
both to use the same security certifications compliance mode.
• When you configure Firepower Threat Defense on a Firepower 4100/9300 Chassis to operate in CC or
UCAPL mode, you should also configure the Firepower 4100/9300 Chassis to operate in CC mode. For
more information, see the Cisco FXOS Firepower Chassis Manager Configuration Guide.
• Do not enable external authentication using LDAP or RADIUS in deployments using CC mode.
• Do not enable CACs in deployments using CC mode.
• Disable access to the Firepower Management Center and managed devices via the Firepower REST API
in deployments using CC or UCAPL mode.
• Enable CACs in deployments using UCAPL mode.
• Do not configure Firepower Threat Defense devices into a high availability pair unless they are both
using the same security certifications compliance mode.
Note The Firepower System does not support CC or UCAPL mode for:
• Firepower Threat Defense devices in clusters
• Firepower Threat Defense container instances on the Firepower 4100/9300
Appliance Hardening
For information about features you can use to further harden your Firepower system, see the latest versions
of the Cisco Firepower Mangement Center Hardening Guide and the Cisco Firepower Threat Defense
Hardening Guide, as well as the following topics within this document:
• Licensing the Firepower System, on page 89
• User Accounts for FMC, on page 41
• Logging into the Firepower System, on page 21
• Audit Logs, on page 1112
• Audit Log Certificate, on page 1115
• Time and Time Synchronization, on page 1124
• Configure NTP Time Synchronization for Threat Defense, on page 1192
• Creating an Email Alert Response, on page 2276
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Caution After you enable this setting, you cannot disable it. If you need to take the appliance out of CC or UCAPL
mode, you must reimage.
Step 3 To permanently enable security certifications compliance on the appliance, you have two choices:
• To enable security certifications compliance in Common Criteria mode, choose CC from the drop-down list.
• To enable security certifications compliance in Unified Capabilities Approved Products List mode, choose UCAPL
from the drop-down list.
What to do next
• If you have not already, apply Control and Protection licenses to all Classic devices in your deployment.
• Establish additional configuration changes as described in the guidelines for this product provided by
the certifying entity.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
Administrators in ancestor domains can target NAT policies to devices in descendant domains, which descendant
domains can use or replace with customized local policies. If a NAT policy targets devices in different
descendant domains, administrators in the descendant domains can view information about target devices
belonging to their domain only.
• Copy — Click Copy ( ) next to the policy you want to copy; see Copying NAT Policies, on page 1211.
• Create — Click New Policy; see Creating NAT Policies, on page 1208.
• Delete — Click Delete ( ) next to the policy you want to delete, then click OK. When prompted whether to
continue, you are also informed if another user has unsaved changes in the policy.
Caution After you have deployed a NAT policy to a managed device, you cannot delete the policy from the device.
Instead, you must deploy a NAT policy with no rules to remove the NAT rules already present on the
managed device. You also cannot delete a policy that is the last deployed policy on any of its target devices,
even if it is out of date. Before you can delete the policy completely, you must deploy a different policy
to those targets.
• Deploy—Choose Deploy > Deployment; see Deploy Configuration Changes, on page 385.
In a multidomain deployment, policy names must be unique within the domain hierarchy. The system may identify a
conflict with the name of a policy you cannot view in your current domain.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
• To enable or disable an existing rule, right-click a rule, choose State, and choose Disable or Enable.
• To view any warnings or errors in the policy, click Show Warnings, then choose a Device. Warnings and errors
mark configurations that could adversely affect traffic flow or prevent the policy from deploying.
• To change the number of rules displayed on the page, use the Rows Per Page drop-down list.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 2 Click Copy ( ) next to the NAT policy you want to copy.
Step 3 Enter a unique Name for the policy.
In a multidomain deployment, policy names must be unique within the domain hierarchy. The system may identify a
conflict with the name of a policy you cannot view in your current domain.
One of the main functions of NAT is to enable private IP networks to connect to the Internet. NAT replaces
a private IP address with a public IP address, translating the private addresses in the internal private network
into legal, routable addresses that can be used on the public Internet. In this way, NAT conserves public
addresses because it can be configured to advertise at a minimum only one public address for the entire network
to the outside world.
Other functions of NAT include:
• Security—Keeping internal IP addresses hidden discourages direct attacks.
• IP routing solutions—Overlapping IP addresses are not a problem when you use NAT.
• Flexibility—You can change internal IP addressing schemes without affecting the public addresses
available externally; for example, for a server accessible to the Internet, you can maintain a fixed IP
address for Internet use, but internally, you can change the server address.
• Translating between IPv4 and IPv6 (Routed mode only) —If you want to connect an IPv6 network to
an IPv4 network, NAT lets you translate between the two types of addresses.
Note NAT is not required. If you do not configure NAT for a given set of traffic, that traffic will not be translated,
but will have all of the security policies applied as normal.
NAT Basics
The following topics explain some of the basics of NAT.
NAT Terminology
This document uses the following terminology:
• Real address/host/network/interface—The real address is the address that is defined on the host, before
it is translated. In a typical NAT scenario where you want to translate the inside network when it accesses
the outside, the inside network would be the “real” network. Note that you can translate any network
connected to the device, not just an inside network. Therefore if you configure NAT to translate outside
addresses, “real” can refer to the outside network when it accesses the inside network.
• Mapped address/host/network/interface—The mapped address is the address that the real address is
translated to. In a typical NAT scenario where you want to translate the inside network when it accesses
the outside, the outside network would be the “mapped” network.
Note During address translation, IP addresses configured for the device interfaces are
not translated.
NAT Types
You can implement NAT using the following methods:
• Dynamic NAT—A group of real IP addresses are mapped to a (usually smaller) group of mapped IP
addresses, on a first come, first served basis. Only the real host can initiate traffic. See Dynamic NAT,
on page 1230.
• Dynamic Port Address Translation (PAT)—A group of real IP addresses are mapped to a single IP address
using a unique source port of that IP address. See Dynamic PAT, on page 1235.
• Static NAT—A consistent mapping between a real and mapped IP address. Allows bidirectional traffic
initiation. See Static NAT, on page 1244.
• Identity NAT—A real address is statically translated to itself, essentially bypassing NAT. You might
want to configure NAT this way when you want to translate a large group of addresses, but then want
to exempt a smaller subset of addresses. See Identity NAT, on page 1253.
1. When the inside host at 10.1.2.27 sends a packet to a web server, the real source address of the packet,
10.1.2.27, is translated to a mapped address, 209.165.201.10.
2. When the server responds, it sends the response to the mapped address, 209.165.201.10, and the Firepower
Threat Defense device receives the packet because the Firepower Threat Defense device performs proxy
ARP to claim the packet.
3. The Firepower Threat Defense device then changes the translation of the mapped address, 209.165.201.10,
back to the real address, 10.1.2.27, before sending it to the host.
The following figure shows a typical NAT scenario in transparent mode, with the same network on the inside
and outside interfaces. The transparent firewall in this scenario is performing the NAT service so that the
upstream router does not have to perform NAT.
Figure 48: NAT Example: Transparent Mode
1. When the inside host at 10.1.1.75 sends a packet to a web server, the real source address of the packet,
10.1.1.75, is changed to a mapped address, 209.165.201.15.
2. When the server responds, it sends the response to the mapped address, 209.165.201.15, and the Firepower
Threat Defense device receives the packet because the upstream router includes this mapped network in
a static route directed to the Firepower Threat Defense device management IP address.
3. The Firepower Threat Defense device then undoes the translation of the mapped address, 209.165.201.15,
back to the real address, 10.1.1.1.75. Because the real address is directly-connected, the Firepower Threat
Defense device sends it directly to the host.
4. For host 192.168.1.2, the same process occurs, except for returning traffic, the Firepower Threat Defense
device looks up the route in its routing table and sends the packet to the downstream router at 10.1.1.3
based on the Firepower Threat Defense device static route for 192.168.1.0/24.
Auto NAT
All NAT rules that are configured as a parameter of a network object are considered to be auto NAT rules.
This is a quick and easy way to configure NAT for a network object. You cannot create these rules for a group
object, however.
Although these rules are configured as part of the object itself, you cannot see the NAT configuration in the
object definition through the object manager.
When a packet enters an interface, both the source and destination IP addresses are checked against the auto
NAT rules. The source and destination address in the packet can be translated by separate rules if separate
matches are made. These rules are not tied to each other; different combinations of rules can be used depending
on the traffic.
Because the rules are never paired, you cannot specify that sourceA/destinationA should have a different
translation than sourceA/destinationB. Use manual NAT for that kind of functionality, where you can identify
the source and destination address in a single rule.
Manual NAT
Manual NAT lets you identify both the source and destination address in a single rule. Specifying both the
source and destination addresses lets you specify that sourceA/destinationA can have a different translation
than sourceA/destinationB.
Note For static NAT, the rule is bidirectional, so be aware that “source” and “destination” are used in commands
and descriptions throughout this guide even though a given connection might originate at the “destination”
address. For example, if you configure static NAT with port address translation, and specify the source address
as a Telnet server, and you want all traffic going to that Telnet server to have the port translated from 2323
to 23, then you must specify the source ports to be translated (real: 23, mapped: 2323). You specify the source
ports because you specified the Telnet server address as the source address.
The destination address is optional. If you specify the destination address, you can either map it to itself
(identity NAT), or you can map it to a different address. The destination mapping is always a static mapping.
Section 1 Manual NAT Applied on a first match basis, in the order they appear in the
configuration. Because the first match is applied, you must ensure
that specific rules come before more general rules, or the specific
rules might not be applied as desired. By default, manual NAT
rules are added to section 1.
By "specific rules first," we mean:
• Static rules should come before dynamic rules.
• Rules that include destination translation should come before
rules with source translation only.
Section 2 Auto NAT If a match in section 1 is not found, section 2 rules are applied in
the following order:
1. Static rules.
2. Dynamic rules.
Section 3 Manual NAT If a match is still not found, section 3 rules are applied on a first
match basis, in the order they appear in the configuration. This
section should contain your most general rules. You must also
ensure that any specific rules in this section come before general
rules that would otherwise apply.
For section 2 rules, for example, you have the following IP addresses defined within network objects:
• 192.168.1.0/24 (static)
• 192.168.1.0/24 (dynamic)
• 10.1.1.0/24 (static)
• 192.168.1.1/32 (static)
• 172.16.1.0/24 (dynamic) (object def)
• 172.16.1.0/24 (dynamic) (object abc)
NAT Interfaces
Except for bridge group member interfaces, you can configure a NAT rule to apply to any interface (in other
words, all interfaces), or you can identify specific real and mapped interfaces. You can also specify any
interface for the real address, and a specific interface for the mapped address, or vice versa.
For example, you might want to specify any interface for the real address and specify the outside interface
for the mapped address if you use the same private addresses on multiple interfaces, and you want to translate
them all to the same global pool when accessing the outside.
Figure 49: Specifying Any Interface
However, the concept of “any” interface does not apply to bridge group member interfaces. When you specify
“any” interface, all bridge group member interfaces are excluded. Thus, to apply NAT to bridge group members,
you must specify the member interface. This could result in many similar rules where only one interface is
different. You cannot configure NAT for the Bridge Virtual Interface (BVI) itself, you can configure NAT
for member interfaces only.
Note You cannot configure NAT for interfaces operating in inline, inline tap, or passive modes. When specifying
interfaces, you do so indirectly by selecting the interface object that contains the interface.
Note If you configure the mapped interface to be any interface, and you specify a mapped address on the same
network as one of the mapped interfaces, then if an ARP request for that mapped address comes in on a
different interface, then you need to manually configure an ARP entry for that network on the ingress interface,
specifying its MAC address. Typically, if you specify any interface for the mapped interface, then you use a
unique network for the mapped addresses, so this situation would not occur. Configure the ARP table in the
ingress interface's Advanced settings.
Normally for identity NAT, proxy ARP is not required, and in some cases can cause connectivity issues. For
example, if you configure a broad identity NAT rule for “any” IP address, then leaving proxy ARP enabled
can cause problems for hosts on the network directly connected to the mapped interface. In this case, when a
host on the mapped network wants to communicate with another host on the same network, then the address
in the ARP request matches the NAT rule (which matches “any” address). The Firepower Threat Defense
device will then proxy ARP for the address, even though the packet is not actually destined for the Firepower
Threat Defense device. (Note that this problem occurs even if you have a manual NAT rule; although the
NAT rule must match both the source and destination addresses, the proxy ARP decision is made only on the
“source” address). If the Firepower Threat Defense device ARP response is received before the actual host
ARP response, then traffic will be mistakenly sent to the Firepower Threat Defense device.
Note You cannot configure NAT for interfaces operating in inline, inline tap, or passive modes.
• You cannot use dynamic PAT for IPv6 (NAT66) when translating between interfaces in the same bridge
group. This restriction does not apply when the interfaces are members of different bridge groups, or
between a bridge group member and a standard routed interface.
• For static NAT, you can specify an IPv6 subnet up to /64. Larger subnets are not supported.
• When using FTP with NAT46, when an IPv4 FTP client connects to an IPv6 FTP server, the client must
use either the extended passive mode (EPSV) or extended port mode (EPRT); PASV and PORT commands
are not supported with IPv6.
The following table lists the inspected protocols that apply NAT rewrite and their NAT limitations. Keep
these limitations in mind when writing NAT rules that include these protocols. Inspected protocols not listed
here do not apply NAT rewrite. These inspections include GTP, HTTP, IMAP, POP, SMTP, SSH, and SSL.
Note NAT rewrite is supported on the listed ports only. For some of these protocols, you can extend inspection to
other ports using Network Analysis Policies, but NAT rewrite is not extended to those ports. This includes
DCERPC, DNS, FTP, and Sun RPC inspection. If you use these protocols on non-standard ports, do not use
NAT on the connections.
DNS over UDP UDP/53 No NAT support is available for name resolution No
through WINS.
Note If you remove a dynamic NAT or PAT rule, and then add a new rule with mapped
addresses that overlap the addresses in the removed rule, then the new rule will
not be used until all connections associated with the removed rule time out or are
cleared using the clear xlate command. This safeguard ensures that the same
address is not assigned to multiple hosts.
• You cannot use an object group with both IPv4 and IPv6 addresses; the object group must include only
one type of address.
• A network object used in NAT cannot include more than 131,838 IP addresses, either explicitly or implied
in a range of addresses or a subnet. Break up the address space into smaller ranges and write separate
rules for the smaller objects.
• (Manual NAT only.) When using any as the source address in a NAT rule, the definition of “any” traffic
(IPv4 vs. IPv6) depends on the rule. Before the Firepower Threat Defense device performs NAT on a
packet, the packet must be IPv6-to-IPv6 or IPv4-to-IPv4; with this prerequisite, the Firepower Threat
Defense device can determine the value of any in a NAT rule. For example, if you configure a rule from
“any” to an IPv6 server, and that server was mapped from an IPv4 address, then any means “any IPv6
traffic.” If you configure a rule from “any” to “any,” and you map the source to the interface IPv4 address,
then any means “any IPv4 traffic” because the mapped interface address implies that the destination is
also IPv4.
• You can use the same mapped object or group in multiple NAT rules.
• The mapped IP address pool cannot include:
• The mapped interface IP address. If you specify “any” interface for the rule, then all interface IP
addresses are disallowed. For interface PAT (routed mode only), specify the interface name instead
of the interface address.
• The failover interface IP address.
• (Transparent mode.) The management IP address.
• (Dynamic NAT.) The standby interface IP address when VPN is enabled.
• Avoid using overlapping addresses in static and dynamic NAT policies. For example, with overlapping
addresses, a PPTP connection can fail to get established if the secondary connection for PPTP hits the
static instead of dynamic xlate.
• You cannot use overlapping addresses in the source address of a NAT rule and a remote access VPN
address pool.
• If you specify a destination interface in a rule, then that interface is used as the egress interface rather
than looking up the route in the routing table. However, for identity NAT, you have the option to use a
route lookup instead.
• If you use PAT on Sun RPC traffic, which is used to connect to NFS servers, be aware that the NFS
server might reject connections if the PAT'ed port is above 1024. The default configuration of NFS
servers is to reject connections from ports higher than 1024. The error is typically "Permission Denied."
Mapping ports above 1024 might happen if you use the "flat range" option to use the higher port numbers
if a port in the lower range is not available, especially if you do not select the option to include the lower
range in the flat range. You can avoid this problem by changing the NFS server configuration to allow
all port numbers.
• NAT applies to through traffic only. Traffic generated by the system is not subject to NAT.
• Click Edit ( ) to edit an existing Threat Defense NAT policy. Note that the page also shows Firepower NAT
policies, which are not used by FTD devices.
To accomplish the above, you would do the following. Although this example rule is for dynamic auto NAT,
you can generalize the technique for any type of NAT rule.
Step 1 Create the security zones for the inside and outside interfaces.
a) Choose Objects > Object Management.
b) Select Interface Objects from the table of contents and click Add > Security Zone. (You can use interface groups
instead of zones.)
c) Configure the inside zone properties.
• Name—Enter a name, for example, inside-zone.
• Type—Select Routed for routed-mode devices, Switched for transparent mode.
• Selected Interfaces—Add the FTD-A/inside and FTD-B/inside interfaces to the selected list.
d) Click Save.
e) Click Add > Security Zone and define the outside zone properties.
• Name—Enter a name, for example, outside-zone.
• Interface Type—Select Routed for routed-mode devices, Switched for transparent mode.
• Selected Interfaces—Add the FTD-A/outside and FTD-B/outside interfaces to the selected list.
f) Click Save.
Step 2 Create the network object for the original inside network on the Object Management page.
a) Select Network from the table of contents and click Add Network > Add Object.
b) Configure the inside network properties.
• Name—Enter a name, for example, inside-network.
• Network—Enter the network address, for example, 192.168.1.0/24.
c) Click Save.
Step 3 Create the network object for the translated NAT pool and define overrides.
a) Click Add Network > Add Object.
b) Configure the NAT pool properties for FTD-A.
• Name—Enter a name, for example, NAT-pool.
• Network—Enter the range of addresses to include in the pool for FTD-A, for example,
10.100.10.10-10.100.10.200.
Note The interface objects control on which devices the rule is configured. Because in this example the zones
contain interfaces for FTD-A and FTD-B only, even if the NAT policy were assigned to additional devices,
the rule would be deployed to those 2 devices only.
f) Click Save.
You now have a single rule that will be interpreted differently for FTD-A and FTD-B, providing unique translations
for the inside networks protected by each firewall.
Dynamic NAT
The following topics explain dynamic NAT and how to configure it.
Note For the duration of the translation, a remote host can initiate a connection to the translated host if an access
rule allows it. Because the address is unpredictable, a connection to the host is unlikely. Nevertheless, in this
case you can rely on the security of the access rule.
The following figure shows a typical dynamic NAT scenario. Only real hosts can create a NAT session, and
responding traffic is allowed back.
Figure 50: Dynamic NAT
The following figure shows a remote host attempting to initiate a connection to a mapped address. This address
is not currently in the translation table; therefore, the packet is dropped.
Figure 51: Remote Host Attempts to Initiate a Connection to a Mapped Address
The advantage of dynamic NAT is that some protocols cannot use PAT. PAT does not work with the following:
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click Edit ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
interface, the record is rewritten from the real value to the mapped value. This option is used in specific circumstances,
and is sometimes needed for NAT64/46 translation, where the rewrite also converts between A and AAAA records.
For more information, see Rewriting DNS Queries and Responses Using NAT, on page 1305.
• Fallthrough to Interface PAT (Destination Interface)—Whether to use the IP address of the destination interface
as a backup method when the other mapped addresses are already allocated (interface PAT fallback). This option is
available only if you select a destination interface that is not a member of a bridge group. To use the IPv6 address
of the interface, also check the IPv6 option.
• IPv6—Whether to use the IPv6 address of the destination interface for interface PAT.
You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule.
For dynamic NAT, you can also perform port translation on the destination. In the Object Manager, ensure
that there are port objects you can use for the Original Destination Port and Translated Destination Port.
If you specify the source port, it will be ignored.
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click Edit ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
• Enable—Whether you want the rule to be active. You can later activate or deactivate the rule using the right-click
menu on the rules page.
• Insert—Where you want to add the rule. You can insert it in a category (before or after auto NAT rules), or above
or below the rule number you specify.
Step 5 (On the Translation page.) Identify the original packet addresses, either IPv4 or IPv6; namely, the packet addresses
as they appear in the original packet.
See the following figure for an example of the original packet vs. the translated packet.
• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations. If you leave
this blank, the source address translation applies regardless of destination. If you do specify the destination address,
you can configure a static translation for that address or just use identity NAT for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot be Any).
If you select this option, you must also select a translated destination object. To implement a static interface NAT
with port translation for the destination addresses, select this option and also select the appropriate port objects
for the destination ports.
Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on the
destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—The network object or group that contains the mapped addresses.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses used
in the translated packet. If you selected an object for Original Destination, you can set up identity NAT (that is,
no translation) by selecting the same object.
Step 7 (Optional.) Identify the destination service ports for service translation: Original Destination Port, Translated
Destination Port.
Dynamic NAT does not support port translation, so leave the Original Source Port and Translated Source Port fields
empty. However, because the destination translation is always static, you can perform port translation for the destination
port.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service objects
are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both the real and
mapped ports.
Dynamic PAT
The following topics describe dynamic PAT.
For the duration of the translation, a remote host on the destination network can initiate a connection to the
translated host if an access rule allows it. Because the port address (both real and mapped) is unpredictable,
a connection to the host is unlikely. Nevertheless, in this case you can rely on the security of the access rule.
After the connection expires, the port translation also expires.
Note We recommend that you use different PAT pools for each interface. If you use the same pool for multiple
interfaces, especially if you use it for "any" interface, the pool can be quickly exhausted, with no ports available
for new translations.
• If you enable extended PAT for a dynamic PAT rule, then you cannot also use an address in the PAT
pool as the PAT address in a separate static NAT with port translation rule. For example, if the PAT pool
includes 10.1.1.1, then you cannot create a static NAT-with-port-translation rule using 10.1.1.1 as the
PAT address.
• If you use a PAT pool and specify an interface for fallback, you cannot specify extended PAT.
• For VoIP deployments that use ICE or TURN, do not use extended PAT. ICE and TURN rely on the
PAT binding to be the same for all destinations.
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
Step 6 If you are using a PAT pool, select the PAT Pool page and do the following:
a) Select Enable PAT pool.
b) Select the network object group that contains the addresses for the pool in the PAT > Address field.
You can alternatively select Destination Interface IP, which is another way to implement interface PAT.
c) (Optional) Select the following options as needed:
• Use Round Robin Allocation—To assign addresses/ports in a round-robin fashion. By default without round
robin, all ports for a PAT address will be allocated before the next PAT address is used. The round-robin method
assigns one address/port from each PAT address in the pool before returning to use the first address again, and
then the second address, and so on.
• Extended PAT Table—To use extended PAT. Extended PAT uses 65535 ports per service, as opposed to per
IP address, by including the destination address and port in the translation information. Normally, the destination
port and address are not considered when creating PAT translations, so you are limited to 65535 ports per PAT
address. For example, with extended PAT, you can create a translation of 10.1.1.1:1027 when going to
192.168.1.7:23 as well as a translation of 10.1.1.1:1027 when going to 192.168.1.7:80. You cannot use this
option with interface PAT or interface PAT fallback.
• Flat Port Range, Include Reserved Ports—To use the 1024 to 65535 port range as a single flat range when
allocating TCP/UDP ports. When choosing the mapped port number for a translation, PAT uses the real source
port number if it is available. However, without this option, if the real port is not available, by default the mapped
ports are chosen from the same range of ports as the real port number: 1 to 511, 512 to 1023, and 1024 to 65535.
To avoid running out of ports at the low ranges, configure this setting. To use the entire range of 1 to 65535,
also check the Include Reserved Ports option.
• Block Allocation—To enable port block allocation. For carrier-grade or large-scale PAT, you can allocate a
block of ports for each host, rather than have NAT allocate one port translation at a time. If you allocate a block
of ports, subsequent connections from the host use new randomly selected ports within the block. If necessary,
additional blocks are allocated if the host has active connections for all ports in the original block. Port blocks
are allocated in the 1024-65535 range only. Port block allocation is compatible with round robin, but you cannot
use it with the extended PAT or flat port range options. You also cannot use interface PAT fallback.
You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule.
For dynamic NAT, you can also perform port translation on the destination. In the Object Manager, ensure
that there are port objects you can use for the Original Destination Port and Translated Destination Port.
If you specify the source port, it will be ignored.
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click Edit ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Step 5 (On the Translation page.) Identify the original packet addresses, either IPv4 or IPv6; namely, the packet addresses
as they appear in the original packet.
See the following figure for an example of the original packet vs. the translated packet.
• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations. If you leave
this blank, the source address translation applies regardless of destination. If you do specify the destination address,
you can configure a static translation for that address or just use identity NAT for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot be Any).
If you select this option, you must also select a translated destination object. To implement a static interface NAT
with port translation for the destination addresses, select this option and also select the appropriate port objects
for the destination ports.
Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on the
destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—One of the following:
• (Interface PAT.) To use the address of the destination interface, select Destination Interface IP. You must
also select a specific destination interface object. To use the IPv6 address of the interface, you must also
select the IPv6 option on Advanced. Skip the step for configuring a PAT pool.
• To use a single address other than the destination interface address, select the host network object you created
for this purpose. Skip the step for configuring a PAT pool.
• To use a PAT pool, leave Translated Source empty.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses used
in the translated packet. If you selected an object for Original Destination, you can set up identity NAT (that is,
no translation) by selecting the same object.
Step 7 (Optional.) Identify the destination service ports for service translation: Original Destination Port, Translated
Destination Port.
Dynamic NAT does not support port translation, so leave the Original Source Port and Translated Source Port fields
empty. However, because the destination translation is always static, you can perform port translation for the destination
port.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service objects
are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both the real and
mapped ports.
Step 8 If you are using a PAT pool, select the PAT Pool page and do the following:
a) Select Enable PAT pool.
b) Select the network object group that contains the addresses for the pool in the PAT > Address field.
You can alternatively select Destination Interface IP, which is another way to implement interface PAT.
c) (Optional) Select the following options as needed:
• Use Round Robin Allocation—To assign addresses/ports in a round-robin fashion. By default without round
robin, all ports for a PAT address will be allocated before the next PAT address is used. The round-robin
method assigns one address/port from each PAT address in the pool before returning to use the first address
again, and then the second address, and so on.
• Extended PAT Table—To use extended PAT. Extended PAT uses 65535 ports per service, as opposed to
per IP address, by including the destination address and port in the translation information. Normally, the
destination port and address are not considered when creating PAT translations, so you are limited to 65535
ports per PAT address. For example, with extended PAT, you can create a translation of 10.1.1.1:1027 when
going to 192.168.1.7:23 as well as a translation of 10.1.1.1:1027 when going to 192.168.1.7:80. You cannot
use this option with interface PAT or interface PAT fallback.
• Flat Port Range, Include Reserved Ports—To use the 1024 to 65535 port range as a single flat range when
allocating TCP/UDP ports. When choosing the mapped port number for a translation, PAT uses the real source
port number if it is available. However, without this option, if the real port is not available, by default the
mapped ports are chosen from the same range of ports as the real port number: 1 to 511, 512 to 1023, and
1024 to 65535. To avoid running out of ports at the low ranges, configure this setting. To use the entire range
of 1 to 65535, also check the Include Reserved Ports option.
• Block Allocation—To enable port block allocation. For carrier-grade or large-scale PAT, you can allocate a
block of ports for each host, rather than have NAT allocate one port translation at a time. If you allocate a
block of ports, subsequent connections from the host use new randomly selected ports within the block. If
necessary, additional blocks are allocated if the host has active connections for all ports in the original block.
Port blocks are allocated in the 1024-65535 range only. Port block allocation is compatible with round robin,
but you cannot use it with the extended PAT or flat port range options. You also cannot use interface PAT
fallback.
• For a given PAT pool, you must specify (or not specify) block allocation for all rules that use the pool.
You cannot allocate blocks in one rule and not in another. PAT pools that overlap also cannot mix block
allocation settings. You also cannot overlap static NAT with port translation rules with the pool.
i) Click Save.
You can click Preview Config, select one of the target devices, and verify that the xlate commands appear correctly.
Step 2 Add NAT rules that use PAT pool port block allocation.
a) Select Devices > NAT and add or edit the Threat Defense NAT policy.
b) Add or edit a NAT rule and configure at least the following options.
• Type = Dynamic
• In Translation > Original Source, select the object that defines the source address.
• On PAT Pool, configure the following options:
• Select Enable PAT Pool
• In PAT > Address, select a network object that defines the pat pool.
• Select the Block Allocation option.
Static NAT
The following topics explain static NAT and how to implement it.
Static NAT-with-port-translation rules limit access to the destination IP address for the specified port only.
If you try to access the destination IP address on a different port not covered by a NAT rule, then the connection
is blocked. In addition, for manual NAT, traffic that does not match the source IP address of the NAT rule
will be dropped if it matches the destination IP address, regardless of the destination port. Therefore, you
must add additional rules for all other traffic allowed to the destination IP address. For example, you can
configure a static NAT rule for the IP address, without port specification, and place it after the port translation
rule.
Note For applications that require application inspection for secondary channels (for example, FTP and VoIP),
NAT automatically translates the secondary ports.
Following are some other uses of static NAT with port translation.
Static NAT with Identity Port Translation
You can simplify external access to internal resources. For example, if you have three separate servers
that provide services on different ports (such as FTP, HTTP, and SMTP), you can give external users a
single IP address to access those services. You can then configure static NAT with identity port translation
to map the single external IP address to the correct IP addresses of the real servers based on the port they
are trying to access. You do not need to change the port, because the servers are using the standard ones
(21, 80, and 25 respectively).
Static NAT with Port Translation for Non-Standard Ports
You can also use static NAT with port translation to translate a well-known port to a non-standard port
or vice versa. For example, if inside web servers use port 8080, you can allow outside users to connect
to port 80, and then undo translation to the original port 8080. Similarly, to provide extra security, you
can tell web users to connect to non-standard port 6785, and then undo translation to port 80.
For example, you have a load balancer at 10.1.2.27. Depending on the URL requested, it redirects traffic to
the correct web server.
For a many-to-few or many-to-one configuration, where you have more real addresses than mapped addresses,
you run out of mapped addresses before you run out of real addresses. Only the mappings between the lowest
real IP addresses and the mapped pool result in bidirectional initiation. The remaining higher real addresses
can initiate traffic, but traffic cannot be initiated to them (returning traffic for a connection is directed to the
correct real address because of the unique 5-tuple (source IP, destination IP, source port, destination port,
protocol) for the connection).
Note Many-to-few or many-to-one NAT is not PAT. If two real hosts use the same source port number and go to
the same outside server and the same TCP destination port, and both hosts are translated to the same IP address,
then both connections will be reset because of an address conflict (the 5-tuple is not unique).
Instead of using a static rule this way, we suggest that you create a one-to-one rule for the traffic that needs
bidirectional initiation, and then create a dynamic rule for the rest of your addresses.
• Translated Source—You have the following options to specify the translated address:
• Destination Interface—To use the destination interface address, you do not need a network object.
This configures static interface NAT with port translation: the source address/port is translated to
the interface's address and the same port number.
• Address—Create a network object or group containing hosts, ranges, or subnets. A group cannot
contain both IPv4 and IPv6 addresses; it must contain one type only. Typically, you configure the
same number of mapped addresses as real addresses for a one-to-one mapping. You can, however,
have a mismatched number of addresses.
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click Edit ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
• (Optional.) Original Port, Translated Port—If you need to translate a TCP or UDP port, select the protocol in
Original Port, and type the original and translated port numbers. For example, you can translate TCP/80 to 8080
if necessary.
from the mapped value to the real value. Conversely, for DNS replies traversing from a real interface to a mapped
interface, the record is rewritten from the real value to the mapped value. This option is used in specific circumstances,
and is sometimes needed for NAT64/46 translation, where the rewrite also converts between A and AAAA records.
For more information, see Rewriting DNS Queries and Responses Using NAT, on page 1305. This option is not
available if you are doing port translation.
• IPv6—Whether to use the IPv6 address of the destination interface for interface PAT.
• Net to Net Mapping—For NAT 46, select this option to translate the first IPv4 address to the first IPv6 address,
the second to the second, and so on. Without this option, the IPv4-embedded method is used. For a one-to-one
translation, you must use this option.
• Do not proxy ARP on Destination Interface—Disables proxy ARP for incoming packets to the mapped IP addresses.
If you use addresses on the same network as the mapped interface, the system uses proxy ARP to answer any ARP
requests for the mapped addresses, thus intercepting traffic destined for a mapped address. This solution simplifies
routing because the device does not have to be the gateway for any additional networks. You can disable proxy ARP
if desired, in which case you need to be sure to have proper routes on the upstream router. Normally for identity
NAT, proxy ARP is not required, and in some cases can cause connectivity issues.
You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule. If you want to configure destination static
interface NAT with port translation only, you can skip adding an object for the destination mapped addresses
and specify the interface in the rule.
You can also perform port translation on the source, destination, or both. In the Object Manager, ensure that
there are port objects you can use for the original and translated ports.
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click Edit ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Step 5 (On the Translation page.) Identify the original packet addresses, either IPv4 or IPv6; namely, the packet addresses
as they appear in the original packet.
See the following figure for an example of the original packet vs. the translated packet.
• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations. If you leave
this blank, the source address translation applies regardless of destination. If you do specify the destination address,
you can configure a static translation for that address or just use identity NAT for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot be Any).
If you select this option, you must also select a translated destination object. To implement a static interface NAT
with port translation for the destination addresses, select this option and also select the appropriate port objects
for the destination ports.
Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on the
destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—One of the following:
• To use a set group of addresses, select Address and the network object or group that contains the mapped
addresses. Typically, you configure the same number of mapped addresses as real addresses for a one-to-one
mapping. You can, however, have a mismatched number of addresses.
• (Static interface NAT with port translation.) To use the address of the destination interface, select Destination
Interface IP. You must also select a specific destination interface object. To use the IPv6 address of the
interface, you must also select the IPv6 option on Advanced. This configures static interface NAT with port
translation: the source address/port is translated to the interface's address and the same port number.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses used
in the translated packet. If you selected an object for Original Destination, you can set up identity NAT (that is,
no translation) by selecting the same object.
Step 7 (Optional.) Identify the source or destination service ports for service translation.
If you are configuring static NAT with port translation, you can translate ports for the source, destination, or both. For
example, you can translate between TCP/80 and TCP/8080.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service objects
are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both the real and
mapped ports.
• Original Source Port, Translated Source Port—Defines a port translation for the source address.
• Original Destination Port, Translated Destination Port—Defines a port translation for the destination address.
Identity NAT
You might have a NAT configuration in which you need to translate an IP address to itself. For example, if
you create a broad rule that applies NAT to every network, but want to exclude one network from NAT, you
can create a static NAT rule to translate an address to itself.
The following figure shows a typical identity NAT scenario.
Figure 59: Identity NAT
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click Edit ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
is the object containing the real interface, the one through which the traffic enters the device. Destination is the
object containing the mapped interface, the one through which traffic exits the device. By default, the rule applies
to all interfaces (Any) except for bridge group member interfaces.
You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule. If you want to configure destination static
interface NAT with port translation only, you can skip adding an object for the destination mapped addresses
and specify the interface in the rule.
You can also perform port translation on the source, destination, or both. In the Object Manager, ensure that
there are port objects you can use for the original and translated ports. You can use the same object for identity
NAT.
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click Edit ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Step 5 Identify the original packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear in the original
packet.
See the following figure for an example of the original packet vs. the translated packet where you perform identity
NAT on the inside host but translate the outside host.
• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations. If you leave
this blank, the source address translation applies regardless of destination. If you do specify the destination address,
you can configure a static translation for that address or just use identity NAT for it.
You can select Interface Object to base the original destination on the source interface (which cannot be Any).
If you select this option, you must also select a translated destination object. To implement a static interface NAT
with port translation for the destination addresses, select this option and also select the appropriate port objects
for the destination ports.
Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on the
destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—The same object as the original source. Optionally, you can select a different object that has
the exact same contents.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses used
in the translated packet. If you selected an object for Original Destination, you can set up identity NAT (that is,
no translation) by selecting the same object.
Step 7 (Optional.) Identify the source or destination service ports for service translation.
If you are configuring static NAT with port translation, you can translate ports for the source, destination, or both. For
example, you can translate between TCP/80 and TCP/8080.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service objects
are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both the real and
mapped ports.
• Original Source Port, Translated Source Port—Defines a port translation for the source address.
• Original Destination Port, Translated Destination Port—Defines a port translation for the destination address.
NAT rules include the following basic properties. The properties are the same for auto NAT and manual NAT
rules except where indicated.
NAT Type
Whether you want to configure a Manual NAT Rule or an Auto NAT Rule. Auto NAT translates the
source address only, and you cannot make different translations based on the destination address. Because
auto NAT is more simple to configure, use it unless you need the added features of manual NAT. For
more information on the differences, see Auto NAT and Manual NAT, on page 1217.
Type
Whether the translation rule is Dynamic or Static. Dynamic translation automatically chooses the mapped
address from a pool of addresses, or an address/port combination when implementing PAT. Use static
translation if you want to precisely define the mapped address/port.
Enable (Manual NAT only.)
Whether you want the rule to be active. You can later activate or deactivate the rule using the right-click
menu on the rules page. You cannot disable auto NAT rules.
Insert (Manual NAT only.)
Where you want to add the rule. You can insert it in a category (before or after auto NAT rules), or above
or below the rule number you specify.
Description (Optional. Manual NAT only.)
A description of the purpose of the rule.
The following topics describe the tabs for the NAT rules properties.
Note The concept of “any” interface does not apply to bridge group member interfaces. When you specify “any”
interface, all bridge group member interfaces are excluded. Thus, to apply NAT to bridge group members,
you must specify the member interface. You cannot configure NAT for the Bridge Virtual Interface (BVI)
itself, you can configure NAT for member interfaces only.
If you select interface objects, a NAT rule will be configured on an assigned device only if the device has
interfaces included in all selected objects. For example, if you select both source and destination security
zones, both zones must contain one or more interface for a given device.
Source Interface Objects, Destination Interface Objects
(Required for bridge group member interfaces.) The interface objects (security zones or interface groups)
that identify the interfaces where this NAT rule applies. Source is the object containing the real interface,
the one through which the traffic enters the device. Destination is the object containing the mapped
interface, the one through which traffic exits the device. By default, the rule applies to all interfaces
(Any) except for bridge group member interfaces.
• Identity NAT—The same object as the original source. Optionally, you can select a different object
that has the exact same contents.
• Identity NAT—The same object as the original source. Optionally, you can select a different object
that has the exact same contents.
Original Destination
The network object that contains the addresses of the destinations. If you leave this blank, the source
address translation applies regardless of destination. If you do specify the destination address, you can
configure a static translation for that address or just use identity NAT for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a
static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.
Translated Destination
The network object or group that contains the destination addresses used in the translated packet. If you
selected an object for Original Destination, you can set up identity NAT (that is, no translation) by
selecting the same object.
Original Source Port, Translated Source Port, Original Destination Port, Translated Destination Port
The port objects that define the source and destination services for the original and translated packets.
You can translate the ports, or select the same object to make the rule sensitive to the service without
translating the ports. Keep the following rules in mind when configuring services:
• (Dynamic NAT or PAT.) You cannot do translation on the Original Source Port and Translated
Source Port. You can do translation on the destination port only.
• NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and
mapped service objects are identical (both TCP or both UDP). For identity NAT, you can use the
same service object for both the real and mapped ports.
Round Robin
To assign addresses/ports in a round-robin fashion. By default without round robin, all ports for a PAT
address will be allocated before the next PAT address is used. The round-robin method assigns one
address/port from each PAT address in the pool before returning to use the first address again, and then
the second address, and so on.
Extended PAT Table
To use extended PAT. Extended PAT uses 65535 ports per service, as opposed to per IP address, by
including the destination address and port in the translation information. Normally, the destination port
and address are not considered when creating PAT translations, so you are limited to 65535 ports per
PAT address. For example, with extended PAT, you can create a translation of 10.1.1.1:1027 when going
to 192.168.1.7:23 as well as a translation of 10.1.1.1:1027 when going to 192.168.1.7:80. You cannot
use this option with interface PAT or interface PAT fallback.
desired, in which case you need to be sure to have proper routes on the upstream router. Normally for
identity NAT, proxy ARP is not required, and in some cases can cause connectivity issues.
Perform Route Lookup for Destination Interface (Static Identity NAT only. Routed mode only.)
If you select source and destination interfaces when selecting the same object for original and translated
source address, you can select this option to have the system determine the destination interface based
on the routing table rather than using the destination interface configured in the NAT rule.
Unidirectional (Manual NAT only, static NAT only.)
Select this option to prevent the destination addresses from initiating traffic to the source addresses.
• NAT66—Translates IPv6 packets to a different IPv6 address. We recommend using static NAT. Although
you can use dynamic NAT or PAT, IPv6 addresses are in such large supply, you do not have to use
dynamic NAT.
Note NAT64 and NAT 46 are possible on standard routed interfaces only. NAT66 is possible on both routed and
bridge group member interfaces.
• The IPv6 address pool for the NAT46 rule can be equal to or larger than the number of IPv4 addresses
to be mapped. This allows each IPv4 address to be mapped to a different IPv6 address. NAT46 supports
static mappings only, so you cannot use dynamic PAT.
You need to define two policies, one for the source IPv6 network, and one for the destination IPv4 network.
Although you can accomplish this with a single manual NAT rule, if the DNS server is on the external network,
you probably need to rewrite the DNS response. Because you cannot enable DNS rewrite on a manual NAT
rule when you specify a destination, creating two auto NAT rules is the better solution.
In this example, you translate the inside IPv6 network to IPv4 using dynamic interface PAT with the IP address
of the outside interface. Outside IPv4 traffic is statically translated to addresses on the 2001:db8::/96 network,
allowing transmission on the inside network.
Step 1 Create the network object that defines the inside IPv6 network.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8::/96.
d) Click Save.
Step 2 Create the manual NAT rule to translate the IPv6 network to IPv4 and back again.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
f) Click OK.
With this rule, any traffic from the 2001:db8::/96 subnet on the inside interface going to the outside interface gets a
NAT64 PAT translation using the IPv4 address of the outside interface. Conversely, any IPv4 address on the outside
network coming to the inside interface is translated to an address on the 2001:db8::/96 network using the embedded
IPv4 address method.
g) Click Save on the NAT rules page.
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet and DNS Translation
Following is a typical example where you have an inside IPv6-only network, but there are some IPv4-only
services on the outside Internet that internal users need.
In this example, you translate the inside IPv6 network to IPv4 using dynamic interface PAT with the IP address
of the outside interface. Outside IPv4 traffic is statically translated to addresses on the 2001:db8::/96 network,
allowing transmission on the inside network. You enable DNS rewrite on the NAT46 rule, so that replies from
the external DNS server can be converted from A (IPv4) to AAAA (IPv6) records, and the addresses converted
from IPv4 to IPv6.
Following is a typical sequence for a web request where a client at 2001:DB8::100 on the internal IPv6 network
tries to open www.example.com.
1. The client’s computer sends a DNS request to the DNS server at 2001:DB8::D1A5:CA81. The NAT rules
make the following translations to the source and destination in the DNS request:
• 2001:DB8::100 to a unique port on 209.165.201.1 (The NAT64 interface PAT rule.)
• 2001:DB8::D1A5:CA81 to 209.165.202.129 (The NAT46 rule. D1A5:CA81 is the IPv6 equivalent
of 209.165.202.129.)
2. The DNS server responds with an A record indicating that www.example.com is at 209.165.200.225. The
NAT46 rule, with DNS rewrite enabled, converts the A record to the IPv6-equivalent AAAA record, and
translates 209.165.200.225 to 2001:db8:D1A5:C8E1in the AAAA record. In addition, the source and
destination addresses in the DNS response are untranslated:
• 209.165.202.129 to 2001:DB8::D1A5:CA81
• 209.165.201.1 to 2001:db8::100
3. The IPv6 client now has the IP address of the web server, and makes an HTTP request to www.example.com
at 2001:db8:D1A5:C8E1. (D1A5:C8E1 is the IPv6 equivalent of 209.165.200.225.) The source and
destination of the HTTP request are translated:
• 2001:DB8::100 to a unique port on 209.156.101.54 (The NAT64 interface PAT rule.)
• 2001:db8:D1A5:C8E1 to 209.165.200.225 (The NAT46 rule.)
Step 1 Create the network objects that define the inside IPv6 and outside IPv4 networks.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8::/96.
d) Click Save.
e) Click Add Network > Add Object and define the outside IPv4 network.
Name the network object (for example, outside_v4_any) and enter the network address 0.0.0.0/0.
f) Click Save.
Step 2 Configure the NAT64 dynamic PAT rule for the inside IPv6 network.
Step 3 Configure the static NAT46 rule for the outside IPv4 network.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click OK.
With this rule, any IPv4 address on the outside network coming to the inside interface is translated to an address on
the 2001:db8::/96 network using the embedded IPv4 address method. In addition, DNS responses are converted from
A (IPv4) to AAAA (IPv6) records, and the addresses converted from IPv4 to IPv6.
Step 1 Create the network objects that define the inside IPv6 and outside IPv6 NAT networks.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8:122:2091::/96.
d) Click Save.
e) Click Add Network > Add Object and define the outside IPv6 NAT network.
Name the network object (for example, outside_nat_v6) and enter the network address 2001:db8:122:2999::/96.
f) Click Save.
Step 2 Configure the static NAT rule for the inside IPv6 network.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click OK.
With this rule, any traffic from the 2001:db8:122:2091::/96 subnet on the inside interface going to the outside interface
gets a static NAT66 translation to an address on the 2001:db8:122:2999::/96 network.
Step 1 Create the network object that defines the inside IPv6 network.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8:122:2091::/96.
d) Click Save.
Step 2 Configure the dynamic PAT rule for the inside IPv6 network.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.
f) On tAdvanced, select IPv6, which indicates that the IPv6 address of the destination interface should be used.
g) Click OK.
With this rule, any traffic from the 2001:db8:122:2091::/96 subnet on the inside interface going to the outside interface
gets a NAT66 PAT translation to one of the IPv6 global addresses configured for the outside interface.
Monitoring NAT
To monitor and troubleshoot NAT connections, log into the device CLI and use the following commands.
• show nat displays the NAT rules and per-rule hit counts. There are additional keywords to show other
aspects of NAT.
• show xlate displays the actual NAT translations that are currently active.
• clear xlate lets you remove an active NAT translation. You might need to remove active translations if
you alter NAT rules, because existing connections continue to use the old translation slot until the
connection ends. Clearing a translation allows the system to build a new translation for a client on the
client's next connection attempt based on your new rules.
Step 1 Create the network objects that define the server’s private and public host addresses.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the web server’s private address.
Name the network object (for example, WebServerPrivate) and enter the real host IP address, 10.1.2.27.
d) Click Save.
e) Click Add Network > Add Object and define the public address.
Name the network object (for example, WebServerPublic) and enter the host address 209.165.201.10.
f) Click Save.
Step 2 Configure static NAT for the object.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click Save.
Step 3 Click Save on the NAT rule page.
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server
The following example configures dynamic NAT for inside users on a private network when they access the
outside. Also, when inside users connect to an outside web server, that web server address is translated to an
address that appears to be on the inside network.
Figure 61: Dynamic NAT for Inside, Static NAT for Outside Web Server
Step 1 Create a network object for the dynamic NAT pool to which you want to translate the inside addresses.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the dynamic NAT pool.
Name the network object (for example, myNATpool) and enter the network range 209.165.201.20-209.165.201.30.
d) Click Save.
c) Click Save.
Step 3 Create a network object for the outside web server.
a) Click Add Network > Add Object.
b) Name the network object (for example, MyWebServer) and enter the host address 209.165.201.12.
c) Click Save.
Step 4 Create a network object for the translated web server address.
a) Click Add Network > Add Object.
b) Name the network object (for example, TransWebServer) and enter the host address 10.1.2.20.
c) Click Save.
Step 5 Configure dynamic NAT for the inside network using the dynamic NAT pool object.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.
f) Click Save.
Step 6 Configure static NAT for the web server.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) Click Save.
Step 7 Click Save on the NAT rule page.
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT,
One-to-Many)
The following example shows an inside load balancer that is translated to multiple IP addresses. When an
outside host accesses one of the mapped IP addresses, it is untranslated to the single load balancer address.
Depending on the URL requested, it redirects traffic to the correct web server.
Figure 62: Static NAT with One-to-Many for an Inside Load Balancer
Step 1 Create a network object for the addresses to which you want to map the load balancer.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the addresses.
Name the network object (for example, myPublicIPs) and enter the network range 209.165.201.3-209.165.201.5.
d) Click Save.
Step 2 Create a network object for the load balancer.
a) Click Add Network > Add Object.
b) Name the network object (for example, myLBHost), enter the host address 10.1.2.27.
c) Click Save.
Step 3 Configure static NAT for the load balancer.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click Save.
Step 4 Click Save on the NAT rule page.
d) Click Save.
Step 2 Create a network object for the HTTP server.
c) Click Save.
Step 3 Create a network object for the SMTP server.
a) Click Add Network > Add Object.
b) Name the network object (for example, SMTPserver), enter the host address 10.1.2.29.
c) Click Save.
Step 4 Create a network object for the public IP address used for the three servers.
a) Click Add Network > Add Object.
b) Name the network object (for example, ServerPublicIP) and enter the host address 209.165.201.3.
c) Click Save.
Step 5 Configure static NAT with port translation for the FTP server, mapping the FTP port to itself.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click Save.
Step 6 Configure static NAT with port translation for the HTTP server, mapping the HTTP port to itself.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) Click Save.
Step 7 Configure static NAT with port translation for the SMTP server, mapping the SMTP port to itself.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) Click Save.
Step 8 Click Save on the NAT rule page.
d) Click Save.
Step 2 Create a network object for the DMZ network 1.
a) Click Add Network > Add Object.
b) Name the network object (for example, DMZnetwork1) and enter the network address 209.165.201.0/27 (subnet
mask of 255.255.255.224).
c) Click Save.
Step 3 Create a network object for the PAT address for DMZ network 1.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress1) and enter the host address 209.165.202.129.
c) Click Save.
Step 4 Create a network object for the DMZ network 2.
a) Click Add Network > Add Object.
b) Name the network object (for example, DMZnetwork2) and enter the network address 209.165.200.224/27 (subnet
mask of 255.255.255.224).
c) Click Save.
Step 5 Create a network object for the PAT address for DMZ network 2.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress2) and enter the host address 209.165.202.130.
c) Click Save.
Step 6 Configure dynamic manual PAT for DMZ network 1.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
f) Click Save.
Step 7 Configure dynamic manual PAT for DMZ network 2.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
e) Click Save.
Step 8 Click Save on the NAT rule page.
d) Click Save.
Step 2 Create a network object for the Telnet/Web server.
a) Click Add Network > Add Object.
b) Name the network object (for example, TelnetWebServer) and enter the host address 209.165.201.11.
c) Click Save.
Step 3 Create a network object for the PAT address when using Telnet.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress1) and enter the host address 209.165.202.129.
c) Click Save.
Step 4 Create a network object for the PAT address when using HTTP.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress2) and enter the host address 209.165.202.130.
c) Click Save.
Step 5 Configure dynamic manual PAT for Telnet access.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
f) Click Save.
Step 6 Configure dynamic manual PAT for web access.
a) Click Add Rule.
b) Configure the following properties:
e) Click Save.
Step 7 Click Save on the NAT rule page.
d) Click Save.
e) Click Add Network > Add Object and define the inside San Jose network.
Name the network object (for example, sanjose-network) and enter the network address 10.2.2.0/24.
f) Click Save.
Step 2 Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1 (Boulder).
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Static.
g) Click Save.
Step 3 Configure manual dynamic interface PAT when going to the Internet for the inside Boulder network on Firewall1
(Boulder).
e) Click Save.
Step 4 If you are also managing Firewall2 (San Jose), you can configure similar rules for that device.
• The manual identity NAT rule would be for sanjose-network when the destination is boulder-network. Create new
interface objects for the Firewall2 inside and outside networks.
• The manual dynamic interface PAT rule would be for sanjose-network when the destination is "any."
Following are the main circumstances when you would need to configure DNS rewrite on a NAT rule.
• The rule is NAT64 or NAT46, and the DNS server is on the outside network. You need DNS rewrite to
convert between DNS A records (for IPv4) and AAAA records (for IPv6).
• The DNS server is on the outside, clients are on the inside, and some of the fully-qualified domain names
that the clients use resolve to other inside hosts.
• The DNS server is on the inside and responds with private IP addresses, clients are on the outside, and
the clients access fully-qualified domain names that point to servers that are hosted on the inside.
Step 1 Create the network objects for the FTP server, DNS server, inside network, and PAT pool.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the real FTP server address.
Name the network object (for example, ftp_server) and enter the host address, 209.165.200.225.
d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated IPv6 address.
Name the network object (for example, ftp_server_v6) and enter the host address, 2001:DB8::D1A5:C8E1.
f) Click Save.
g) Click Add Network > Add Object and define the DNS server's real address.
Name the network object (for example, dns_server) and enter the host address, 209.165.201.15.
h) Click Save.
i) Click Add Network > Add Object and define the DNS server's translated IPv6 address.
Name the network object (for example, dns_server_v6) and enter the host address, 2001:DB8::D1A5:C90F (where
D1A5:C90F is the IPv6 equivalent of 209.165.201.15).
j) Click Save.
k) Click Add Network > Add Object and define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:DB8::/96.
l) Click Save.
m) Click Add Network > Add Object and define the IPv4 PAT pool for the inside IPv6 network.
Name the network object (for example, ipv4_pool) and enter the range 209.165.200.230-209.165.200.235.
n) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
g) Click OK.
Step 3 Configure the static NAT rule for the DNS server.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) On Advanced, select Net to Net Mapping, because this is a one-to-one NAT46 translation.
f) Click OK.
Step 4 Configure the dynamic NAT with a PAT pool rule for the inside IPv6 network.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.
f) Click OK.
In this case, you want to enable DNS reply modification on this static rule so that inside users who have access
to ftp.cisco.com using the real address receive the real address from the DNS server, and not the mapped
address.
When an inside host sends a DNS request for the address of ftp.cisco.com, the DNS server replies with the
mapped address (209.165.201.10). The system refers to the static rule for the inside server and translates the
address inside the DNS reply to 10.1.3.14. If you do not enable DNS reply modification, then the inside host
attempts to send traffic to 209.165.201.10 instead of accessing ftp.cisco.com directly.
d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated address.
Name the network object (for example, ftp_server_outside) and enter the host address, 209.165.201.10.
f) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
g) Click OK.
d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated address.
Name the network object (for example, ftp_server_translated) and enter the host address, 10.1.2.56.
f) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit an FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
g) Click OK.
Network Address Translation (NAT) 6.0.1 The NAT policy for Firepower Threat Defense was added.
for Firepower Threat Defense.
New/modified screens: Threat Defense was added as a type of NAT policy
to the Devices > NAT page.
Supported platforms: Firepower Threat Defense
Support for network range objects in 6.1.0 You can now use network range objects in Firepower Threat Defense NAT
NAT for Firepower Threat Defense. rules where appropriate.
Carrier Grade NAT enhancements. 6.5 For carrier-grade or large-scale PAT, you can allocate a block of ports for
each host, rather than have NAT allocate one port translation at a time (see
RFC 6888).
New/Modified screens: We added the Block Allocation option to the NAT
PAT Pool tab for Firepower Threat Defense NAT rules.
Supported platforms: Firepower Threat Defense
Each type of traffic inspection and control occurs where it makes the most sense for maximum flexibility and
performance. For example, reputation-based blocking uses simple source and destination data, so it can block
prohibited traffic early in the process. In contrast, detecting and blocking intrusions and exploits is a last-line
defense.
In a simple access control policy, the default action specifies how target devices handle all traffic. In a more
complex policy, the default action handles traffic that:
• is not trusted by Intelligent Application Bypass
• is not on a Security Intelligence Block list
• is not blocked by SSL inspection (encrypted traffic only)
• matches none of the rules in the policy (except Monitor rules, which match and log—but do not handle
or inspect—traffic)
The access control policy default action can block or trust traffic without further inspection, or inspect traffic
for intrusions and discovery data.
Note You cannot perform file or malware inspection on traffic handled by the default action. Logging for connections
handled by the default action is initially disabled, though you can enable it.
If you are using policy inheritance, the default action for the lowest-level descendant determines final traffic
handling. Although an access control policy can inherit its default action from its base policy, you cannot
enforce this inheritance.
The following table describes the types of inspection you can perform on traffic handled by each default
action.
Access Control: Block All Traffic block without further inspection none
Access Control: Trust All Traffic trust (allow to its final destination none
without further inspection)
Intrusion Prevention allow, as long as it is passed by the intrusion, using the specified
intrusion policy you specify intrusion policy and associated
variable set, and
discovery, using the network
discovery policy
Inherit from base policy defined in base policy defined in base policy
The following diagrams illustrate the Block All Traffic and Trust All Traffic default actions.
The following diagrams illustrate the Intrusion Prevention and Network Discovery Only default actions.
Tip The purpose of Network Discovery Only is to improve performance in a discovery-only deployment. Different
configurations can disable discovery if you are only interested in intrusion detection and prevention.
Related Topics
Performance Considerations for Limited Deployments, on page 396
Logging Connections with a Policy Default Action, on page 2443
For complete information, see Intrusion Detection and Prevention, on page 1627.
• File policies govern the system’s file control and AMP for Networks capabilities.
For complete information, see File Policies and Malware Protection, on page 1537.
Access control occurs before deep inspection; access control rules and the access control default action
determine which traffic is inspected by intrusion and file policies.
By associating an intrusion or file policy with an access control rule, you are telling the system that before it
passes traffic that matches the access control rule’s conditions, you first want to inspect the traffic with an
intrusion policy, a file policy, or both.
In an access control policy, you can associate one intrusion policy with each Allow and Interactive Block
rule, as well as with the default action. Every unique pair of intrusion policy and variable set counts as one
policy.
To associate intrusion and file policies with an access control rule, see:
• Access Control Rule Configuration to Perform Intrusion Prevention, on page 1664
• Configuring an Access Control Rule to Perform Malware Protection, on page 1542
Note By default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false
positives and improve performance when an encrypted connection matches an access control rule that has
intrusion and file inspection configured.
Related Topics
How Policies Examine Traffic For Intrusions, on page 1630
File Policies, on page 1537
In the scenario above, the first three access control rules in the policy—Monitor, Trust, and Block—cannot
inspect matching traffic. Monitor rules track and log but do not inspect network traffic, so the system continues
to match traffic against additional rules to determine whether to permit or deny it. (However, see an important
exception and caveat at Access Control Rule Monitor Action, on page 1363.) Trust and Block rules handle
matching traffic without further inspection of any kind, while traffic that does not match continues to the next
access control rule.
The fourth and final rule in the policy, an Allow rule, invokes various other policies to inspect and handle
matching traffic, in the following order:
• Discovery: Network Discovery Policy—First, the network discovery policy inspects traffic for discovery
data. Discovery is passive analysis and does not affect the flow of traffic. Although you do not explicitly
enable discovery, you can enhance or disable it. However, allowing traffic does not automatically guarantee
discovery data collection. The system performs discovery only for connections involving IP addresses
that are explicitly monitored by your network discovery policy.
• AMP for Networks and File Control: File Policy—After traffic is inspected by discovery, the system
can inspect it for prohibited files and malware. AMP for Networks detects and optionally blocks malware
in many types of files, including PDFs, Microsoft Office documents, and others. If your organization
wants to block not only the transmission of malware files, but all files of a specific type (regardless of
whether the files contain malware), file control allows you to monitor network traffic for transmissions
of specific file types, then either block or allow the file.
• Intrusion Prevention: Intrusion Policy—After file inspection, the system can inspect traffic for intrusions
and exploits. An intrusion policy examines decoded packets for attacks based on patterns, and can block
or alter malicious traffic. Intrusion policies are paired with variable sets, which allow you to use named
values to accurately reflect your network environment.
• Destination—Traffic that passes all the checks described above passes to its destination.
An Interactive Block rule (not shown in the diagram) has the same inspection options as an Allow rule. This
is so you can inspect traffic for malicious content when a user bypasses a blocked website by clicking through
a warning page.
Traffic that does not match any access control rules in the policy with an action other than Monitor is handled
by the default action. In this scenario, the default action is an Intrusion Prevention action, which allows traffic
to its final destination as long as it is passed by the intrusion policy you specify. In a different deployment,
you might have a default action that trusts or blocks all traffic without further inspection. Note that the system
can inspect traffic allowed by the default action for discovery data and intrusions, but not prohibited files or
malware. You cannot associate a file policy with the access control default action.
Note Sometimes, when a connection is analyzed by an access control policy, the system must process the first few
packets in that connection, allowing them to pass, before it can decide which access control rule (if any) will
handle the traffic. However, so these packets do not reach their destination uninspected, you can specify an
intrusion policy (in the Advanced settings for the access control policy) to inspect these packets and generate
intrusion events.
Note Traffic allowed by an Intrusion Prevention or Network Discovery Only default action can be inspected for
discovery data and intrusions, but cannot be inspected for prohibited files or malware. You cannot associate
a file policy with the access control default action.
You do not have to perform both file and intrusion inspection in the same rule. For a connection matching an
Allow or Interactive Block rule:
• without a file policy, traffic flow is determined by the intrusion policy
• without an intrusion policy, traffic flow is determined by the file policy
• without either, allowed traffic is inspected by network discovery only
Tip The system does not perform any kind of inspection on trusted traffic. Although configuring an Allow rule
with neither an intrusion nor file policy passes traffic like a Trust rule, Allow rules let you perform discovery
on matching traffic.
The diagram below illustrates the types of inspection you can perform on traffic that meets the conditions of
either an Allow or user-bypassed Interactive Block access control rule. For simplicity, the diagram displays
traffic flow for situations where both (or neither) an intrusion and a file policy are associated with a single
access control rule.
For any single connection handled by an access control rule, file inspection occurs before intrusion inspection.
That is, the system does not inspect files blocked by a file policy for intrusions. Within file inspection, simple
blocking by type takes precedence over malware inspection and blocking.
For example, consider a scenario where you normally want to allow certain network traffic as defined in an
access control rule. However, as a precaution, you want to block the download of executable files, examine
downloaded PDFs for malware and block any instances you find, and perform intrusion inspection on the
traffic.
You create an access control policy with a rule that matches the characteristics of the traffic you want to
provisionally allow, and associate it with both an intrusion policy and a file policy. The file policy blocks the
download of all executables, and also inspects and blocks PDFs containing malware:
• First, the system blocks the download of all executables, based on simple type matching specified in the
file policy. Because they are immediately blocked, these files are subject to neither malware nor intrusion
inspection.
• Next, the system performs malware cloud lookups for PDFs downloaded to a host on your network. Any
PDFs with a malware disposition are blocked, and are not subject to intrusion inspection.
• Finally, the system uses the intrusion policy associated with the access control rule to inspect any remaining
traffic, including files not blocked by the file policy.
Note Until a file is detected and blocked in a session, packets from the session may be subject to intrusion inspection.
When using policy inheritance, the default action for the lowest-level descendant determines final traffic
handling. Although an access control policy can inherit its default action from an ancestor policy, you cannot
enforce this inheritance.
For example, as a Global domain administrator for your organization, you can create an access control policy
at the Global level. You can then require that all your devices, which are divided into subdomain by function,
use that Global-level policy as a base policy.
When subdomain administrators log into the Firepower Management Center to configure access control, they
can deploy the Global-level policy as-is. Or, they can create and deploy a descendant access control policy
within the boundaries of the Global-level policy.
Note Although the most useful implementation of access control inheritance and enforcement complements
multitenancy, you can create a hierarchy of access control policies within a single domain. You can also assign
and deploy access control policies at any level.
Related Topics
Managing Access Control Policy Inheritance, on page 1345
Security Intelligence Block Listing, on page 1393
HTTP Response Pages and Interactive Blocking, on page 1389
Access Control Policy Advanced Settings, on page 1349
Logging Settings for Access Control Policies, on page 1348
Note When you deploy configuration changes, the system evaluates all rules together and creates an expanded set
of criteria that target devices use to evaluate network traffic. If these criteria exceed the resources (physical
memory, processors, and so on) of a target device, you cannot deploy to that device.
Related Topics
Best Practices for Application Control, on page 421
Best Practices for URL Filtering, on page 1371
Exceptions and additions to the above guidelines are noted in the sections below.
Rule Preemption
Rule preemption occurs when a rule will never match traffic because a rule earlier in the evaluation order
matches the traffic first. A rule's conditions govern whether it preempts other rules. In the following example,
the second rule cannot block Admin traffic because the first rule allows it:
Note Certain managed devices support encrypting and decrypting TLS/SSL traffic in hardware, which significantly
improves performance. For more information, see TLS Crypto Acceleration, on page 1454.
1. Monitor—Rules that log matching connections, but take no other action on traffic.
2. Block, Block with reset—Rules that block traffic without further inspection.
3. Do not decrypt—Rules that do not decrypt encrypted traffic, passing the encrypted session to access
control rules. The payloads of these sessions are not subject to deep inspection.
4. Decrypt - Known Key—Rules that decrypt incoming traffic with a known private key.
5. Decrypt - Resign—Rules that decrypt outgoing traffic by re-signing the server certificate.
Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before
rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect
(OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data
link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session,
presentation, and application) should be ordered later in your access control rules. For more information about
the OSI model, see this Wikipedia article.
For more information and an example, see Best Practices for Configuring Application Control, on page 423
and Best Practices for Application Control, on page 421.
To allow this traffic, configure an SSL rule with the Do Not Decrypt action to match the server certificate
common name or distinguished name. In the SSL policy, order this rule before all Decrypt - Resign rules
that also match the traffic. You can retrieve the pinned certificate from the client's browser after a successful
connection to the website. You can also view the certificate from the logged connection event, regardless of
whether the connection succeeded or failed.
VLAN tags, ports, users, applications, URL categories), you can preempt ClientHello modification and increase
the number of undecrypted sessions.
If you configure exceptions to a rule, put the exception above the other rule.
• Access control rules that invoke deep inspection—Intrusion, file, and malware inspection requires
resources, especially if you use multiple custom intrusion policies and variable sets. Make sure you only
invoke deep inspection where required.
For maximum performance benefit, constrain rules by interface. If a rule excludes all of a device’s interfaces,
that rule does not affect that device's performance.
Usually, the system handles network traffic according to the first access control rule where all the rule’s
conditions match the traffic. Conditions can be simple or complex, and their use often depends on certain
licenses.
Default Action
The default action determines how the system handles and logs traffic that is not handled by any other
access control configuration. The default action can block or trust all traffic without further inspection,
or inspect traffic for intrusions and discovery data.
Although an access control policy can inherit its default action from an ancestor policy, you cannot
enforce this inheritance.
Security Intelligence
Security Intelligence is a first line of defense against malicious internet content. This feature allows you
to block connections based on the latest IP address, URL, and domain name reputation intelligence. To
ensure continual access to vital resources, you can override Block list entries with custom Allow list
entries.
HTTP Responses
When the system blocks a user’s website request, you can either display a generic system-provided
response page, or a custom page. You can also display a page that warns users, but also allows them to
continue to the originally requested site.
Logging
Settings for access control policy logging allow you to configure default syslog destinations for the
current access control policy. The settings are applicable to the access control policy and all the included
SSL, prefilter, and intrusion policies unless the syslog destination settings are explicitly overridden with
custom settings in included rules and policies.
Advanced Access Control Options
Advanced access control policy settings typically require little or no modification. Often, the default
settings are appropriate. Advanced settings you can modify include traffic preprocessing, SSL inspection,
identity, and various performance options.
Related Topics
Rule Management: Common Characteristics, on page 403
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
• Delete—Click Delete ( ).
• Deploy—Choose Deploy > Deployment; see Deploy Configuration Changes, on page 385.
Related Topics
Out-of-Date Policies, on page 395
Step 6 Optionally, choose the Available Devices where you want to deploy the policy, then click Add to Policy (or drag and
drop) to add the selected devices. To narrow the devices that appear, type a search string in the Search field.
If you want to deploy this policy immediately, you must perform this step.
What to do next
• Optionally, further configure the new policy as described in Editing an Access Control Policy, on page
1344.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Access Control Policy Default Action, on page 1323
Setting Target Devices for an Access Control Policy, on page 1348
Note You can only edit access control policies that were created in the current domain. Also, you cannot edit settings
that are locked by an ancestor access control policy.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
Settings:
• Name and Description—Click either field and enter new information.
• Default Action—Choose a value from the Default Action drop-down list.
• Default Action Variable Set—To change the variable set associated with an Intrusion Prevention default action,
click Variables ( ). In the popup window that appears, select a new variable set and click OK. You can also
click Edit ( ) to edit the selected variable set in a new window. For more information, see Managing Variables,
on page 471.
• Default Action Logging—To configure logging for connections handled by the default action, click Logging ( );
see Logging Connections with a Policy Default Action, on page 2443.
• HTTP Responses—To specify what the user sees in a browser when the system blocks a website request, click
HTTP Responses; see Choosing HTTP Response Pages, on page 1391.
• Inheritance: Change Base Policy—To change the base access control policy for this policy, click Inheritance
Settings; see Choosing a Base Access Control Policy, on page 1346.
• Inheritance: Lock Settings in Descendants—To enforce this policy's settings in its descendant policies, click
Inheritance Settings; see Locking Settings in Descendant Access Control Policies, on page 1347.
• Policy Assignment: Targets—To identify the managed devices targeted by this policy, click Policy Assignment;
see Setting Target Devices for an Access Control Policy, on page 1348.
• Policy Assignment: Required in Domains—To enforce this policy in a subdomain, click Policy Assignment; see
Requiring an Access Control Policy in a Domain, on page 1347.
• Rules—To manage access control rules, and to inspect and block malicious traffic using intrusion and file policies,
click Rules; see Create and Edit Access Control Rules, on page 1361.
• Rule Conflicts—To show rule conflict warnings, enable Show rule conflicts. Rule conflicts occur when a rule will
never match traffic because an earlier rule always matches the traffic first. Because determining rule conflicts is
resource intensive, displaying them may take some time. For more information, see Best Practices for Ordering
Rules, on page 1332.
• Security Intelligence—To immediately block connections based on the latest reputation intelligence using a Block
list, click Security Intelligence; see Configure Security Intelligence, on page 1396.
• Advanced Options—To set preprocessing, SSL inspection, identity, performance, and other advanced options, click
Advanced; see Access Control Policy Advanced Settings, on page 1349.
• Warnings—To view a list of warnings or errors in your access control policy (and its descendant and associated
policies), click Show Warnings. Warnings and errors mark configurations that could adversely affect traffic analysis
and flow or prevent the policy from deploying. If there are no warnings, show warnings does not appear. To view
rule conflict warnings, first enable Show rule conflicts.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Rule and Other Policy Warnings, on page 436
Deep Inspection Using File and Intrusion Policies, on page 1325
Step 1 Edit the access control policy whose inheritance settings you want to change; see Editing an Access Control Policy, on
page 1344.
Step 2 Manage policy inheritance:
• Change Base Policy — To change the base access control policy for this policy, click Inheritance Settings and
proceed as described in Choosing a Base Access Control Policy, on page 1346.
• Lock Settings in Descendants — To enforce this policy's settings in its descendant policies, click Inheritance
Settings and proceed as described in Locking Settings in Descendant Access Control Policies, on page 1347 .
• Required in Domains — To enforce this policy in a subdomain, click Policy Assignment and proceed as described
in Requiring an Access Control Policy in a Domain, on page 1347.
• Inherit Settings from Base Policy — To inherit settings from a base access control policy, click Security Intelligence,
HTTP Responses, or Advanced and proceed as directed in Inheriting Access Control Policy Settings from the Base
Policy, on page 1346.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
You can use one access control policy as the base (parent) for another. By default, a child policy inherits its
settings from its base policy, though you can change unlocked settings.
When you change the base policy for the current access control policy, the system updates the current policy
with any locked settings from the new base policy.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the access control policy editor, click Security Intelligence, HTTP Responses, or Advanced.
Step 2 Check the Inherit from base policy check box for each setting you want to inherit.
If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to modify the
configuration.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• Delete — Click Delete ( ) next to a leaf domain, or right-click an ancestor domain and choose Delete Selected.
• Search — Type a search string in the search field. Click Clear ( ) to clear the search.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 3 Optionally, click Required on Domains to require that all the devices in the subdomains you choose use the same base
policy. See Requiring an Access Control Policy in a Domain, on page 1347.
Step 4 Click OK to save your targeted device settings.
Step 5 Click Save to save the access control policy.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
SSL, prefilter, and intrusion policies unless the syslog destination settings are explicitly overridden with
custom settings in included rules and policies.
Logging for connections handled by the default action is initially disabled.
Note Behavior of the options is altered when both the options are selected. The dynamic Summary section shows
the results of your selections.
File and Malware Settings are effective only after you have selected an option at the top of the page for
sending syslog messages generally.
If View ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Caution See Configurations that Restart the Snort Process When Deployed or Activated, on page 391 for a list of
advanced setting modifications that restart the Snort process, temporarily interrupting traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on how the target
device handles traffic. See Snort® Restart Traffic Behavior, on page 390 for more information.
General Settings
Option Description
Maximum URL characters to store in To customize the number of characters you store for each
connection events URL requested by your users, see Limiting Logging of Long
URLs, on page 2444.
To customize the length of time before you re-block a
website after a user bypasses an initial block, see Setting the
User Bypass Timeout for a Blocked Website, on page 1392.
Allow an Interactive Block to bypass See Setting the User Bypass Timeout for a Blocked Website,
blocking for (seconds) on page 1392.
Retry URL cache miss lookup Disable this option to allow the system to immediately pass
traffic to a URL without a cloud lookup when the category
is not cached. The system treats URLs that require a cloud
lookup as Uncategorized until the cloud lookup completes
with a different category. In passive deployments, the system
does not retry the lookup, as it cannot hold packets.
Enable Threat Intelligence Director Disable this option to stop publishing TID data to your
configured devices. For more information about TID, see
Cisco Threat Intelligence Director (TID), on page 1583.
Inspect traffic during policy apply To inspect traffic when you deploy configuration changes
unless specific configurations require restarting the Snort
process, ensure that Inspect traffic during policy apply is
set to its default value (enabled).
When this option is enabled, resource demands could result
in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the
Snort process, which interrupts traffic inspection. Whether
traffic drops during this interruption or passes without further
inspection depends on how the target device handles traffic.
See Snort® Restart Scenarios, on page 388 for more
information.
Associated Policies
Use advanced settings to associate subpolicies (SSL, identity, prefilter) with access control; see Associating
Other Policies with Access Control, on page 1352.
• Use custom network analysis rules and network analysis policies to tailor preprocessing options to specific
security zones, networks, and VLANs.
For more information, see Advanced Access Control Settings for Network Analysis and Intrusion Policies,
on page 1847.
Caution Adding or removing an SSL policy restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic
drops during this interruption or passes without further inspection depends on
how the target device handles traffic. See Snort® Restart Traffic Behavior, on
page 390 for more information.
• Identity policy—Performs user authentication based on the realm and authentication method associated
with the traffic.
• Prefilter policy—Performs early traffic handling using limited network (layer 4) outer-header criteria.
If View ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify
the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Snort® Restart Scenarios, on page 388
Note • If the Firepower Threat Defense device is rebooted, all the hit count information is reset.
• You will not be able to derive the hit count information from a device when deployment or a task is in
progress on the device.
Step 5 Click Fetch Current Hit Count to get the hit count data.
If it is not your first attempt in accessing the hit count information for the selected device, you see Refresh instead of
Fetch Current Hit Count. Click Refresh to get the latest hit count information.
Step 6 (Optional) Customize the table and the listings within the table by using the Filter Rules/Policy box, or the Filter by
and In Last drop-down boxes, along with Cog ( ).
Step 7 (Optional) Click on a rule name to edit it, or click View ( ) in the last column to view the rule details.
Clicking on the rule name highlights it in the policy page where you can edit it.
Note If you have accessed the Hit Count page from the Access Control Policy page, you will not be able to view
or edit prefilter rules and vice-versa.
Step 8 (Optional) Clear the hit count information for a rule by right-clicking the rule and selecting Clear Hit Count.
For clearing hit count information of multiple rules, you can select rules by using Ctrl and selecting Clear Hit Count
after right-clicking on one of the selected rules.
Note Clearing hit count information will irreversibly set the hit count to zero.
Step 9 (Optional) Generate a CSV report of the details on the page by clicking Generate CSV on the bottom-left of the page.
Step 10 Click Close to return to the policy page.
Note Security Intelligence filtering, SSL inspection, user identification, and some decoding and preprocessing occur
before access control rules evaluate network traffic.
The system matches traffic to access control rules in the order you specify. In most cases, the system handles
network traffic according to the first access control rule where all the rule’s conditions match the traffic.
Each rule also has an action, which determines whether you monitor, trust, block, or allow matching traffic.
When you allow traffic, you can specify that the system first inspect it with intrusion or file policies to block
any exploits, malware, or prohibited files before they reach your assets or exit your network.
The following scenario summarizes the ways that traffic can be evaluated by access control rules in an inline,
intrusion prevention deployment.
Traffic you allow, whether with an access control rule or the default action, is automatically eligible for
inspection for host, application, and user data by the network discovery policy. You do not explicitly enable
discovery, although you can enhance or disable it. However, allowing traffic does not automatically guarantee
discovery data collection. The system performs discovery only for connections involving IP addresses that
are explicitly monitored by your network discovery policy; additionally, application discovery is limited for
encrypted sessions.
Note that access control rules handle encrypted traffic when your SSL inspection configuration allows it to
pass, or if you do not configure SSL inspection. However, some access control rule conditions require
unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the system disables intrusion
and file inspection of encrypted payloads. This helps reduce false positives and improve performance when
an encrypted connection matches an access control rule that has intrusion and file inspection configured.
• Intrusion policy ( )
• File policy ( )
• Safe search ( )
• YouTube EDU ( )
• Logging ( )
• Original Client option
• Comment ( )
• Warning ( )
• Errors ( )
• important Information ( )
Disabled rules are dimmed and marked (disabled) beneath the rule name.
To create or edit a rule, use the access control rule editor. You can:
• Configure basic properties such as the rule’s name, state, position, and action in the upper portion of the
editor.
• Add conditions using the tabs on the left side of the lower portion of the editor.
• Use the tabs on the right side of the lower portion to configure inspection and logging options, and also
to add comments to the rule. For your convenience, the editor lists the rule’s inspection and logging
options regardless of which tab you are viewing.
Note Properly creating and ordering access control rules is a complex task, but one that is essential to building an
effective deployment. If you do not plan your policy carefully, rules can preempt other rules, require additional
licenses, or contain invalid configurations. To help ensure that the system handles traffic as you expect, the
access control policy interface has a robust warning and error feedback system for rules.
Related Topics
Access Control Rule Components, on page 1358
Create Custom User Roles, on page 62
Best Practices for Access Control Rules, on page 1332
State
By default, rules are enabled. If you disable a rule, the system does not use it and stops generating warnings
and errors for that rule.
Position
Rules in an access control policy are numbered, starting at 1. If you are using policy inheritance, rule 1 is the
first rule in the outermost policy. The system matches traffic to rules in top-down order by ascending rule
number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that
traffic.
Rules can also belong to a section and a category, which are organizational only and do not affect rule position.
Rule position goes across sections and categories.
Conditions
Conditions specify the specific traffic the rule handles. Conditions can be simple or complex; their use often
depends on license.
Applicable Time
You can specify days and times during which a rule is applicable.
Action
A rule’s action determines how the system handles matching traffic. You can monitor, trust, block, or allow
(with or without further inspection) matching traffic. The system does not perform deep inspection on trusted,
blocked, or encrypted traffic.
Inspection
Deep inspection options govern how the system inspects and blocks malicious traffic you would otherwise
allow. When you allow traffic with a rule, you can specify that the system first inspect it with intrusion or file
policies to block any exploits, malware, or prohibited files before they reach your assets or exit your network.
Logging
A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record
of traffic that matches a rule. In general, you can log sessions at the beginning or end of a connection, or both.
You can log connections to the database, as well as to the system log (syslog) or to an SNMP trap server.
Comments
Each time you save changes to an access control rule, you can add comments.
Related Topics
Best Practices for Access Control Rules, on page 1332
Access Control Rule Management, on page 1357
Create and Edit Access Control Rules, on page 1361
Rule Condition Types, on page 405
Access Control Rule Actions, on page 1363
Deep Inspection Using File and Intrusion Policies, on page 1325
Best Practices for Connection Logging, on page 2438
Access Control Rule Comments, on page 1366
Tip Proper access control rule order reduces the resources required to process network traffic, and prevents rule
preemption. Although the rules you create are unique to every organization and deployment, there are a few
general guidelines to follow when ordering rules that can optimize performance while still addressing your
needs.
Related Topics
Best Practices for Ordering Rules, on page 1332
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the access control policy editor, you have the following options:
• To add a new rule, click Add Rule.
If View ( ) appears next to a rule instead, the rule belongs to an ancestor policy, or you do not have permission to
modify the rule.
• Time Range—(Supported on FTD devices only) Add or choose the days and times when the rule is applicable. For
details, see Creating Time Range Objects, on page 457.
• Conditions—Click the corresponding condition you want to add. See Rule Condition Types, on page 405 for more
information.
• Deep Inspection—For Allow and Interactive Block rules, click Intrusion policy ( ) or File policy ( ) to configure
the rule’s Inspection options. If the option is dimmed, no policy of that type is selected for the rule. See Understanding
Access Control, on page 1323 for more information.
• Content Restriction—Click Safe search ( ) or YouTube EDU ( ) to configure content restriction settings on
Applications of the rule editor. If the option are dimmed, content restriction is disabled for the rule. See About
Content Restriction, on page 1441 for more information.
• Logging—Click Logging ( ) to specify Logging options. If the option is dimmed, connection logging is disabled
for the rule. See Best Practices for Connection Logging, on page 2438 for more information.
• Comments—Click the number in the comment column to add Comments. The number indicates how many comments
the rule already contains. See Access Control Rule Comments, on page 1366 for more information.
What to do next
If you will deploy time-based rules, specify the time zone of the device to which the policy is assigned. See
Configure Device Time Zone for Policy Application, on page 1193.
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Best Practices for Access Control Rules, on page 1332
Tip You can also enable or disable an access control rule using the rule editor.
Step 1 In the access control policy editor, right-click the rule and choose a rule state.
If View ( ) appears next to a rule instead, the rule belongs to an ancestor policy, or you do not have permission to
modify the rule.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Access Control Rule Components, on page 1358
Tip You can move multiple rules at once by selecting the rules then cutting and pasting using the right-click menu.
Step 1 In the access control rule editor, you have the following options:
• If you are adding a new rule, use the Insert drop-down list.
• If you are editing an existing rule, click Move.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Caution As a best practice, avoid placing layer 7 conditions on broadly-defined monitor rules high in your rule priority
order, to prevent inadvertently allowing traffic into your network. Also, if locally bound traffic matches a
Monitor rule in a Layer 3 deployment, that traffic may bypass inspection. To ensure inspection of the traffic,
enable Inspect Local Router Traffic in the advanced device settings for the managed device routing the
traffic.
Related Topics
Logging for Monitored Connections, on page 2432
Related Topics
Logging for Trusted Connections, on page 2432
Block with reset rules reset the connection, with the exception of web requests met with an HTTP response
page. This is because the response page, which you configure to appear when the system blocks web requests,
cannot display if the connection is immediately reset. For more information, see HTTP Response Pages and
Interactive Blocking, on page 1389.
Related Topics
Logging for Blocked Connections, on page 2433
About HTTP Response Pages, on page 1389
If a user bypasses the block, the rule mimics an allow rule. Therefore, you can associate interactive block
rules with file and intrusion policies, and matching traffic is also eligible for network discovery.
If a user does not (or cannot) bypass the block, the rule mimics a block rule. Matching traffic is denied without
further inspection.
Note that if you enable interactive blocking, you cannot reset all blocked connections. This is because the
response page cannot display if the connection is immediately reset. Use the Interactive Block with reset
action to (non-interactively) block-with-reset all non-web traffic, while still enabling interactive blocking for
web requests.
For more information, see HTTP Response Pages and Interactive Blocking, on page 1389.
Related Topics
Logging for Allowed Connections, on page 2434
TLS/SSL Rule Blocking Actions, on page 1500
• You can perform file control using a file policy. File control allows you to detect and block your users
from uploading (sending) or downloading (receiving) files of specific types over specific application
protocols.
• You can perform network-based advanced malware protection (AMP), also using a file policy. AMP for
Networks can inspect files for malware, and block detected malware depending on the configuration.
The following diagram illustrates the types of inspection performed on traffic that meets the conditions of an
Allow rule (or a user-bypassed Interactive Block rule. Notice that file inspection occurs before intrusion
inspection; blocked files are not inspected for intrusion-related exploits.
For simplicity, the diagram displays traffic flow for situations where both (or neither) an intrusion and a file
policy are associated with an access control rule. You can, however, configure one without the other. Without
a file policy, traffic flow is determined by the intrusion policy; without an intrusion policy, traffic flow is
determined by the file policy.
Regardless of whether the traffic is inspected or dropped by an intrusion or file policy, the system can inspect
it using network discovery. However, allowing traffic does not automatically guarantee discovery inspection.
The system performs discovery only for connections involving IP addresses that are explicitly monitored by
your network discovery policy; additionally, application discovery is limited for encrypted sessions.
Related Topics
Logging for Allowed Connections, on page 2434
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Bulk edit of certain settings in access 6.6 In the list of rules in a policy, shift-click or
control rules control-click to select multiple rules, then
right-click and choose an option. Example
bulk operations: You can enable or disable
the rules, select a rule action, and edit most
inspection and logging settings.
New/modified pages: Access control rules
page.
Supported platforms: FMC
Time ranges for rule application 6.6 Ability to specify an absolute or recurring
time or time range for a rule to be applied.
The rule is applied based on the time zone
of the device that processes the traffic.
New/modified pages:
• A new option on the access control
Add Rule page.
• A related new option on the Devices
> Platform Settings > FTD page to
specify time zones for managed
devices.
View object details from access control rule pre-6.6 To see information about an object in a list
pages of rules or from the rule configuration
dialog, right-click the object.
New/modified pages: Policies > Access
Control > Access Control, and Add Rule
page.
Supported platforms: FMC
• Reputation—How likely the URL is to be used for purposes that might be against your organization’s
security policy. Reputations range from Unknown risk (level 0) or Untrusted (level 1) to Trusted (level
5).
Related Topics
Snort® Restart Scenarios, on page 388
Category Descriptions
A description of each URL category is available from https://www.talosintelligence.com/categories.
Be sure to click Threat Categories to see those categories.
cloud. If there is still no match, the system looks up the URL in the Cisco cloud and adds the result to the
cache.
The set of URL categories may change periodically. When you receive notification of such changes, you
should review the URL rules in your policies to see if you need to make changes. For more information, see
If the URL Category Set Changes, Take Action, on page 1383.
Configure Your Policy to Examine the Packets That Must Pass Before a URL Can Be Identified
The system cannot filter URLs before:
• A monitored connection is established between a client and server.
• The system identifies the HTTP or HTTPS application in the session.
• The system identifies the requested URL (for encrypted sessions, from either the ClientHello message
or the server certificate).
This identification should occur within 3 to 5 packets, or after the server certificate exchange in the TLS/SSL
handshake if the traffic is encrypted.
Important! To ensure that your system examines these initial packets that would otherwise pass, see Inspection
of Packets That Pass Before Traffic Is Identified, on page 1848 and subtopics.
If early traffic matches all other rule conditions but identification is incomplete, the system allows the packet
to pass and the connection to be established (or the TLS/SSL handshake to complete). After the system
completes its identification, the system applies the appropriate rule action to the remaining session traffic.
For additional guidelines for rules, see the following topics: Best Practices for Access Control Rules, on page
1332 and Rule Condition Mechanics, on page 407.
HTTP/2
The system can extract HTTP/2 URLs from TLS certificates, but not from a payload.
Related Topics
Inspection of Packets That Pass Before Traffic Is Identified, on page 1848
Tip In an SSL policy, you can handle and decrypt traffic to specific URLs by defining a distinguished name SSL
rule condition. The common name attribute in a certificate’s subject distinguished name contains the site’s
URL. Decrypting HTTPS traffic allows access control rules to evaluate the decrypted session, which improves
URL filtering.
To configure a rule that matches only HTTP or HTTPS traffic, add an application condition to the rule. For
example, you could allow HTTPS access to a site while disallowing HTTP access by constructing two access
control rules, each with an application and URL condition.
The first rule allows HTTPS traffic to the website:
Action: Allow
Application: HTTPS
URL: example.com
The second rule blocks HTTP access to the same website:
Action: Block
Application: HTTP
URL: example.com
Classic License
• Category and reputation filtering—URL Filtering
• Manual filtering—No additional license.
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
Step 1 If you will use category and Cisco Firepower NGIPSv Quick Start Guide for VMware
reputation-based URL filtering on an
NGIPSv device, allocate the required
amount of memory.
Step 2 Ensure that you have the correct licenses. Licensing the Firepower System, on page 89, including:
.
• URL Filtering Licenses for Firepower Threat
Defense Devices, on page 100
• URL Filtering Licenses for Classic Devices, on page
131
Step 3 Ensure that your Firepower Management Internet Access Requirements, on page 2650 and
Center can communicate with the cloud Communication Port Requirements, on page 2653.
to obtain URL filtering data.
Step 4 Understand limitations and guidelines and Best Practices for URL Filtering, on page 1371
take any necessary actions.
Step 5 Enable the URL Filtering feature. Enable URL Filtering Using Category and Reputation,
on page 1376
Step 6 Configure rules to filter URLs by category Configuring URL Conditions, on page 1378
and reputation.
For the best protection against malicious sites, you must
block sites by reputation AND block URLs in all Threat
categories.
(Optional) Supplement or Selectively Override Category
and Reputation-Based URL Filtering, on page 1381
Step 7 (Optional) Allow users to bypass a HTTP Response Pages and Interactive Blocking, on page
website block by clicking through a 1389
warning page.
Step 8 Order your rules so that traffic hits key URL Rule Order, on page 1336
rules first.
Step 9 (Optional) Configure advanced options For information about advanced options, including the
related to URL filtering following, see Access Control Policy Advanced Settings,
on page 1349.
• Maximum URL characters to store in connection
events
• Allow an Interactive Block to bypass blocking
for (seconds)
• Retry URL cache miss lookup
Step Ensure that your system receives future Configure URL Filtering Health Monitors, on page 1382
11 URL data updates as expected.
Step Be sure you have enabled other Firepower See Security Intelligence Block Listing, on page 1393
12 features that protect your network from
malicious sites
When you enable URL filtering, depending on how long since URL filtering was last enabled, or if this is the
first time you are enabling URL filtering, the Firepower Management Center downloads URL data from the
Cisco cloud. This process may take some time.
Update Now
You can perform a one-time, on-demand update by clicking the Update Now button at the top of this dialog
box, but you should also either enable automatic updates or create a recurring task using the scheduler. You
cannot start an on-demand update if an update is already in progress.
Although daily updates tend to be small, if it has been more than five days since your last update, new URL
data may take up to 20 minutes to download, depending on your bandwidth. Then, it may take up to 30 minutes
to perform the update itself.
Step 1 In the rule editor, click the following for URL conditions:
• Access control or QoS—Click URLs.
• SSL—Click Category.
Step 2 Find and choose the URL categories that you want to control:
In an access control or QoS rule, click Category.
For effective protection from malicious sites, you must block URLs in all Threat categories in addition to blocking URLs
with poor or questionable reputation. For a list of Threat categories, see URL Category and Reputation Descriptions, on
page 1370.
Be sure to click the arrows at the bottom of the list to see all available categories.
If you change the rule action, the system automatically changes the reputation levels in URL conditions.
What to do next
• (Optional) Supplement or Selectively Override Category and Reputation-Based URL Filtering, on page
1381
• Return to How to Configure URL Filtering with Category and Reputation, on page 1375.
• If you are done making changes, Deploy configuration changes; see Deploy Configuration Changes, on
page 385.
If you configure exceptions to a rule, put the exception above the other rule.
For example, you might use access control to block a category of websites that are not appropriate for your
organization. However, if the category contains a website that is appropriate, and to which you want to provide
access, you can create a manual Allow rule for that site and place it before the Block rule for the category.
You can perform this type of URL filtering without a special license.
Manual URL filtering is not supported in SSL rules; instead, use distinguished name conditions.
Caution Depending on how you implement manual URL filtering, URL matching may not be what you intend. See
Manual URL Filtering Options, on page 1380.
Related Topics
Security Intelligence Lists and Feeds, on page 474
Option Description
(Best practice) This is the recommended method for manual URL filtering.
Use custom Security You can create a new list or feed, or choose an existing one from the URLs
Intelligence URL list or feed sub-tab of the URLs tab in an access control or QoS rule.
objects.
For more information, see Custom Security Intelligence Lists and Feeds, on
This is the New URL List page 478 and subtopics.
option on the rule page in the
web interface.
Option Description
Use URL objects, To determine whether network traffic matches a URL condition, the system
individually or as groups. performs a simple substring match. Matching is NOT anchored at the top level
domain. If the allowed string matches any part of the requested URL, the
(URL objects are described
URLs are considered to match.
at URL Objects, on page 454.)
Example 1:
Enter URLs directly into the
access control rule. You want to explicitly block ign.com (a gaming site). However, substring
matching means that blocking ign.com also blocks verisign.com.
(The Enter URL option on
the rule page in the web Example 2:
interface.) If you allow all traffic to example.com, your users could browse to URLs
including:
• malicious-site.com/example.com
• malicious-example.com
• example.com.malicious-site.com
• example.com.mx
• example.com/
• example.com/newexample
• www.example.com/
Step 1 Navigate to the access control or QoS policy in which you will define your rule.
Step 2 Create or edit the rule in which you will add your new condition:
• If you are supplementing a category- or reputation-based URL filtering rule, edit the existing rule.
• If you are overriding or creating exceptions to a category- or reputation-based URL filtering rule, create a new rule.
Step 3 If you are creating a new rule, configure the rule name, position, action, and other options at the top of the rule.
Important! If the list or feed you are configuring in this procedure contains exceptions to category- or reputation-based
rules, put this rule above those rules in the rule order.
What to do next
(Optional) In SSL rules, use distinguished name conditions to configure parallel behavior.
To ensure that these are configured the way you want them, see Health Modules, on page 309 and Configuring
Health Monitoring, on page 315.
Step 1 In the Firepower Management Center web interface, do one of the following:
Cloud Services a. Navigate to the System > Integration > Cloud Services page.
configuration page
b. Select Dispute URL categories and reputations.
Manual URL Lookup a. Navigate to the manual URL Lookup page: Analysis > Advanced > URL.
page
b. Look up the URL in question.
c. To see Dispute at the end of the table row, hover over the relevant entry in the list of results,
then click dispute.
URL Connection Event a. Navigate to any page under the Analysis > Connections menu that has a table that includes
URLs.
b. Right-click an item in the URL Category or URL Reputation column (show hidden columns
if needed) and select an option.
The set of URL Filtering categories may occasionally change, in order to accommodate new web trends and
evolving usage patterns.
These changes affect both policies and events.
Shortly before URL category changes are scheduled to occur, and after they occur, you will see alerts in the
list of rules in any access control, SSL, and QoS policy that is affected by the changes, and on URL or Category
in rules that you edit.
You should take action when you see these alerts.
Note Updates to the URL category set as described in this topic are distinct from the changes that simply add new
URLs to existing categories or re-classify misclassified URLs. This topic does not apply to category changes
for individual URLs.
Step 1 If you see an alert beside a rule in an access control policy, hover over the alert to see details.
Step 2 If the alert mentions changes to URL categories, edit the rule to see further details.
Step 3 Hover over the URL or Category in the rule dialog to see general information about the type of changes.
Step 4 If you see an alert beside a category, click the alert to view details.
Step 5 If you see a "More information" link in the description of a change, click it to view information about the category on
the Talos web site.
Alternately, see a list and descriptions all categories at the link in URL Category and Reputation Descriptions, on page
1370.
Type of Category Change What The System Will Do What You Should Do
Existing category will soon be Nothing yet. You have a few weeks to Remove this category from all rules
deprecated change affected rules. that include it. If there is a similar new
category, consider using that category
If you do not take action in that time,
instead.
the system eventually will not be able
to redeploy the policy.
New category is added By default, the system does not use Consider creating new rules for the new
newly added categories. category.
Existing category is deleted The category will appear in the rule in You must delete the obsolete category
strikethrough text (that is, with a line from the rule before you can deploy the
through the category name.) policy.
Step 7 Check your SSL rules (Category) for these changes and take action as needed.
Step 8 Check your QoS rules (URL) for these changes and take action as needed.
What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Error when attempting a manual lookup: "Cloud Lookup Failure for <URL>"
Make sure the feature is properly enabled. See the prerequisites in Finding URL Category and Reputation,
on page 2330.
URL appears to be incorrectly handled based on its URL category and reputation
Problem: The system does not handle the URL correctly based on its URL category and reputation.
Solutions:
• Verify that the URL category and reputation associated with the URL are what you think they are. See
Finding URL Category and Reputation, on page 2330.
• The following issues may be addressed by settings described in URL Filtering Options, on page 1376,
accessible using Enable URL Filtering Using Category and Reputation, on page 1376.
• The URL cache may hold stale information. See information about the Cached URLs Expire setting
in URL Filtering Options, on page 1376.
• The local data set may not be updated with current information from the cloud. See information
about the Enable Automatic Updates setting in URL Filtering Options, on page 1376.
• The system may be configured to not check the cloud for current data. See information about the
Query Cisco cloud for unknown URLs setting in URL Filtering Options, on page 1376.
• Your access control policy may be configured to pass traffic to the URL without checking the cloud. See
information about the Retry URL cache miss lookup setting in Access Control Policy Advanced Settings,
on page 1349.
• See also Best Practices for URL Filtering, on page 1371.
• If the URL is processed using an SSL rule, see TLS/SSL Rule Guidelines and Limitations, on page 1485
and SSL Rule Order, on page 1335
• Verify that the URL is being handled using the access control rule that you think it is being handled by,
and that the rule does what you think it does. Consider rule order.
• Verify that the local URL category and reputation database on the Firepower Management Center is
successfully being updated from the cloud and that managed devices are successfully being updated from
the Firepower Management Center.
Status of these processes are reported in the Health Monitor, in the URL Filtering Monitor module and
the Threat Data Updates on Devices module. For details, see Health Monitoring, on page 307.
If you want to immediately update the local URL category and reputation database, go to System > Integration,
click Cloud Services, then click Update Now. For more information, see URL Filtering Options, on page
1376.
New and changed URL categories 6.5 The following changes apply to URL rules
in access control and QoS policies and to
New names for reputation levels
Category rules in SSL policies:
The set of URL categories has changed.
There are now two "pages" of categories
from which to select when you create a
URL rule.
The name associated with each reputation
level has changed.
For descriptions of the new categories and
reputation names, see URL Category and
Reputation Descriptions, on page 1370.
For complete details specific to upgrades,
see also the Release Notes and upgrade
instructions for version 6.5.
If there are future category set changes,
your rules will display icons to alert you.
Modified screens: URL rules in access
control policies, SSL policies, and QoS
policies; event data related to URL
categories.
Supported Platforms: FMC and devices
running release 6.5.
Minor change to classic device licensing 6.5 For devices that use classic licenses, URL
filtering will not be enabled until the device
is registered to the FMC and a URL
Filtering license is assigned to the device.
Supported Platforms: NGIPSv and ASA
with FirePOWER Services devices.
Addresses for retrieving URL data from the 6.5 See the URL Filtering row in Internet
Cisco cloud have changed Access Requirements, on page 2650.
Opportunity to dispute an assigned URL 6.5 If you disagree with the category that the
Category system assigns to a URL, you can submit
a request to change the category.
New/Modified screens:
• New menu option when right-clicking
a URL category or reputation in tables
of connection events under the
Analysis menu.
• New button on the URL Lookups page
(Analysis > Advanced > URL).
(Hover your pointer over the URL to
display the button.)
• New option on the System >
Integration > Cloud Services page
The Cisco CSI tab is renamed to Cloud 6.4 Modified screens and navigation:System
Services > Integration > Cisco CSI is now System
> Integration > Cloud Services
Supported platforms: FMC
Moved URL Filtering information from 6.3 Moved information about configuring cloud
various locations to this new URL Filtering communications for URL Filtering to the
chapter new URL Filtering chapter. Moved certain
other URL Filtering information from other
locations to this chapter. Made related
changes to the structure of the Cisco CSI
topics in the chapter.
New option: Cached URLs Expire 6.3 Use this new control to balance
performance with freshness of URL
category and reputation data in order to
minimize instances of URLs matching on
stale data.
Modified screens: System > Integration
> Cisco CSI.
Supported Platforms: All.
Changed menu path 6.3 The path to the manual URL Lookup page
has changed from Analysis > Lookup >
URL to Analysis > Advanced > URL.
If you do not choose a response page, the system blocks sessions without interaction or explanation.
Note that all non-web traffic that matches the rule is blocked with reset.
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
Step 2 Choose the Block Response Page and Interactive Block Response Page:
• System-provided—Displays a generic response. Click View ( ) to view the code for this page.
• Custom—Create a custom response page. A pop-up window appears, prepopulated with system-provided code that
you can replace or modify by clicking Edit ( ). A counter shows how many characters you have used.
• None—Disables the response page and blocks sessions without interaction or explanation. To quickly disable
interactive blocking for the whole access control policy, choose this option.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Tip To quickly disable interactive blocking for the whole access control policy, display neither the system-provided
page nor a custom page. The system then blocks all connections without interaction.
If a user does not bypass an interactive block, matching traffic is denied without further inspection. If a user
bypasses an interactive block, the access control rule allows the traffic, although the traffic may still be subject
to deep inspection and blocking.
By default, a user bypass is in effect for 10 minutes (600 seconds) without displaying the warning page on
subsequent visits. You can set the duration to as long as a year, or you can force the user to bypass the block
every time. This limit applies to every Interactive Block rule in the policy. You cannot set the limit per rule.
Logging options for interactively blocked traffic are identical to those in allowed traffic, but if a user does
not bypass the interactive block, the system can log only beginning-of-connection events. When the system
initially warns the user, it marks any logged beginning-of-connection event with the Interactive Block
or Interactive Block with reset action. If the user bypasses the block, additional connection
events logged for the session have an action of Allow.
Step 1 As part of access control, configure an access control rule that matches web traffic; see Create and Edit Access Control
Rules, on page 1361:
• Action—Set the rule action to Interactive Block or Interactive Block with reset; see Access Control Rule Interactive
Blocking Actions, on page 1365.
• Conditions—Use URL conditions to specify the web traffic to interactively block; see URL Conditions (URL
Filtering), on page 426.
• Logging—Assume users will bypass the block and choose logging options accordingly; see Logging for Allowed
Connections, on page 2434.
• Inspection—Assume users will bypass the block and choose deep inspection options accordingly; see Understanding
Access Control, on page 1323.
Step 2 (Optional) On access control policy HTTP Responses, choose a custom interactive-block HTTP response page; see
Choosing HTTP Response Pages, on page 1391.
Step 3 (Optional) On access control policy Advanced, change the user bypass timeout; see Setting the User Bypass Timeout
for a Blocked Website, on page 1392.
After a user bypasses a block, the system allows the user to browse to that page without warning until the timeout period
elapses.
If View ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify
the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 In the Allow an Interactive Block to bypass blocking for (seconds) field, type the number of seconds that must elapse
before the user bypass expires. Specifying zero forces your users to bypass the block every time.
Step 4 Click OK.
Step 5 Click Save to save the policy.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note You cannot use a Block list to block fastpathed traffic. Prefilter evaluation occurs before Security Intelligence
filtering. Fastpathed traffic bypasses all further evaluation, including Security Intelligence.
Although you can configure custom Block lists, Cisco provides access to regularly updated intelligence feeds.
Sites representing security threats such as malware, spam, botnets, and phishing appear and disappear faster
than you can update and deploy custom configurations.
You can refine Security Intelligence Block listing with Allow lists and monitor-only Block lists. These
mechanisms exempt traffic from being blocked by a Block list, but do not automatically trust or fastpath
matching traffic. Traffic added to an Allow list or monitored at the Security Intelligence stage is intentionally
subject to further analysis with the rest of access control.
Related Topics
Security Intelligence Lists and Feeds, on page 474
Other Connections You Can Log, on page 2431
Using Connection and Security Intelligence Event Tables, on page 2468
• To test new feeds, or for passive deployments, set the action from block to monitor only. See Security
Intelligence Monitoring, on page 1401.
• If you need to exclude specific sites or addresses from Security Intelligence blocking, see Override
Security Intelligence Blocking, on page 1402.
• If your Firepower deployment is integrated with SecureX or the related tool Cisco SecureX threat response
(formerly known as Cisco Threat Response or CTR), and you use custom Security Intelligence lists and
feeds, be sure to update Security Services Exchange (SSE) with these lists and feeds. For details, see
instructions for configuring auto-promotion of events in the SSE online help. For general information
about this integration, see Integrate with Cisco SecureX, on page 2333.
• System-provided Security Intelligence categories may change over time and without notification; you
should plan to check periodically for changes, and modify your policies accordingly.
Classic License
Protection
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
While reviewing events, you can immediately add an event's IP address, URL, or domain to the applicable
Global Block List so that Security Intelligence will handle future traffic from that source. See Blacklist
Now, Whitelist Now, and Global Lists, on page 476.
• Global Allow lists (one each for Network, URL and DNS)
While reviewing events, you can immediately add an event's IP address, URL, or domain to the applicable
Global Allow List if you do not want Security Intelligence to block future traffic from that source. See
Blacklist Now, Whitelist Now, and Global Lists, on page 476.
Note 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. Using override-enabled objects
allows descendant domain administrators to tailor Global configurations to their local environments.
Step 3 Find the Available Objects you want to add to the Allow list or Block list. You have the following options:
• Search the available objects by typing in the Search by name or value field. Clear the search string by clicking
Reload ( ) or Clear ( ).
• If no existing list or feed meets your needs, click Add ( ), select New Network List or New URL List, and proceed
as described in Creating Security Intelligence Feeds, on page 480 or Uploading New Security Intelligence Lists to
the Firepower Management Center, on page 482.
• If no existing object meets your needs, click Add ( ), select New Network Object or New URL Object, and
proceed as described in Creating Network Objects, on page 450.
Step 6 Click Add to Allow list or Add to Block list, or click and drag the selected objects to either list.
To remove an object from an Allow list or Block list, click Delete ( ) To remove multiple objects, choose the objects
and right-click to Delete Selected.
Step 7 (Optional) Set objects on the Block list to monitor-only by right-clicking the object under Block List, then choosing
Monitor-only (do not block).
You cannot set system-provided global Security Intelligence lists to monitor only.
Step 8 Choose a DNS policy from the DNS Policy drop-down list.
Step 9 Click Save.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Security Intelligence Lists and Feeds, on page 474
Snort® Restart Scenarios, on page 388
Available Objects
Available objects include:
• Security Intelligence categories populated by the system-provided feed.
For details, see Security Intelligence Categories, on page 1399.
• System-provided Global Block and Allow lists.
For descriptions, see Security Intelligence Sources, on page 1395.
• Security Intelligence lists and feeds that you create on the Object Management pages.
For descriptions, see Security Intelligence Sources, on page 1395.
• Network and URL objects and groups that are configured on the respective pages under Object > Object
Management.
For details about network objects, see Network Objects, on page 448. (Using URL objects and groups is
not recommended.)
Available Zones
Except for the system-provided Global lists, you can constrain Security Intelligence filtering by zone.
For example: To improve performance, you may want to target enforcement. As a more specific example,
you can block spam only for a security zone that handles email traffic.
To enforce Security Intelligence filtering for an object on multiple zones, you must add the object to the Allow
list or the Block list separately for each zone.
DNS Policy
In order to match DNS traffic using Security Intelligence, you must select a DNS policy for your Security
Intelligence configuration.
Using Block or Allow lists, or monitoring traffic based on a DNS list or feed, also requires that you:
• Configure DNS Security Intelligence lists and feeds. See Security Intelligence Lists and Feeds, on page
474.
• Create a DNS policy. See Creating Basic DNS Policies, on page 1408 for more information.
• Configure DNS rules that reference your DNS lists or feeds. See Creating and Editing DNS Rules, on
page 1410 for more information.
• Because you deploy the DNS policy as part of your access control policy, you must associate both policies.
See DNS Policy Deploy, on page 1415 for more information.
Allow List
See Override Security Intelligence Blocking, on page 1402.
To select all objects in the list, right-click an object.
Block List
See Configuration Example: Security Intelligence Blocking, on page 1400 and other topics in this chapter.
For explanations of the visual indicators in the Block list, see Block List Icons, on page 1400.
To select all objects in the list, right-click an object.
Logging
Security Intelligence logging, enabled by default, logs all blocked and monitored connections handled by an
access control policy’s target devices. However, the system does not log Allow list matches; logging of
connections on the Allow list depends on their eventual disposition. Logging must be enabled for connections
on the Block list before you can set objects on that list to monitor-only.
To enable, disable, or view logging settings, right-click an object in the Block list.
Related Topics
Blacklist Now, Whitelist Now, and Global Lists, on page 476
Security Intelligence Lists and Multitenancy, on page 477
Note If your organization is using Cisco Threat Intelligence Director (TID): When viewing events, you may see
categories that indicate that the action was taken by TID, such as TID URL Block.
Categories are updated by Talos from the cloud, and this list may change independently of Firepower releases.
Banking_fraud Sites that engage in fraudulent activities that relate to electronic banking
Cryptomining Hosts providing remote access to pools and wallets for the purpose of mining
cryptocurrency
Dga Malware algorithms used to generate a large number of domain names acting as
rendezvous points with their command-and-control servers
High_risk Domains and hostnames that match against the OpenDNS predictive security
algorithms from security graph
Ioc Hosts that have been observed to engage in Indicators of Compromise (IOC)
Malicious Sites exhibiting malicious behavior that do not necessarily fit into another, more
granular, threat category
Newly_seen Domains that have recently been registered, or not yet seen via telemetry
Open_relay Open mail relays that are known to be used for spam
Response IP addresses and URLs that are actively participating in malicious or suspicious
activity
Spyware Sites that are known to contain, serve, or support spyware and adware activities
Suspicious Files that appear to be suspicious and have characteristics that resemble known
malware
Tor_exit_node Hosts known to offer exit node services for the Tor Anonymizer network
An object is displayed in strikethrough text The same object is also on the Allow list, which overrides
the block.
Note 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. Using override-enabled objects
allows descendant domain administrators to tailor Global configurations to their local environments.
What to do next
• Enable logging for these connections; see Logging Connections with Security Intelligence, on page 2442.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Consider a scenario where you want to test a third-party feed before you implement blocking using that
feed. When you set the feed to monitor-only, the system allows connections that would have been blocked
to be further analyzed by the system, but also logs a record of each of those connections for your
evaluation.
• Passive deployments, to optimize performance.
Managed devices that are deployed passively cannot affect traffic flow; there is no advantage to configuring
the system to block traffic. Additionally, because blocked connections are not actually blocked in passive
deployments, the system may report multiple beginning-of-connection events for each blocked connection.
Note If configured, Cisco Threat Intelligence Director (TID) may impact the action taken (Monitor or Block.) For
more information, see TID-Firepower Management Center Action Prioritization, on page 1604.
Note Entries on an Allow list are not automatically trusted or fastpathed; this traffic is intentionally subject to further
analysis with the rest of access control.
Step 1 Option 1: Add an IP address, URL, or domain from an event to the Global Allow List. See Blacklist Now, Whitelist Now,
and Global Lists, on page 476.
Step 2 Option 2: Use a custom Security Intelligence list or feed.
a) Create the custom Security Intelligence list or feed. See Custom Security Intelligence Lists, on page 481 or Creating
Security Intelligence Feeds, on page 480.
b) For IP addresses (Networks) and URLs: Edit your access control policy, click the Security Intelligence tab, then click
the custom list or feed in the Networks or URLs sub-tab, then click Add to Allow List.
c) Save your changes.
d) For domains (DNS): See the "DNS Policy" section in the Security Intelligence Options, on page 1397 topic.
e) Deploy your changes.
New Security Intelligence All Talos has added the following new Security Intelligence categories:
categories
• banking_fraud
• ioc
• high_risk
• link_sharing
• malicious
• newly_seen
• spyware
You should update your access control and DNS policies to address the new
categories, and check periodically for future changes.
New/modified pages: Security Intelligence tab, Networks and URLs sub-tabs; DNS
rules in DNS policies
Supported platforms: FMC
Note DNS-based Security Intelligence may not work as intended for a domain name unless the DNS server deletes
a domain cache entry due to expiration, or a client’s DNS cache or the local DNS server’s cache is cleared or
expires.
You configure DNS-based Security Intelligence using a DNS policy and associated DNS rules. To deploy it
to your devices, you must associate your DNS policy with an access control policy, then deploy your
configuration to managed devices.
Note If multitenancy is enabled for your Firepower Management Center, the system is organized into a hierarchy
of domains, including ancestor and descendant domains. These domains are distinct and separate from
the domain names used in DNS management.
A descendant list contains the domains on the Allow or Block lists of Firepower System subdomain
users. From an ancestor domain, you cannot view the contents of descendant lists. If you do not want
subdomain users to add domains to an Allow or Block list:
• disable the descendant list rules, and
• enforce Security Intelligence using the access control policy inheritance settings
Usually, the system handles DN-based network traffic according to the first DNS rule where all the rule’s
conditions match the traffic. If no DNS rules match the traffic, the system continues evaluating the traffic
based on the associated access control policy's rules. DNS rule conditions can be simple or complex.
Classic License
Protection
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
• Create—To create a new DNS policy, click Add DNS Policy and proceed as described in Creating Basic DNS
Policies, on page 1408.
• Delete—To delete a DNS policy, click Delete ( ), then confirm you want to delete the policy.
• Edit—To modify an existing DNS policy, click Edit ( )) and proceed as described in Editing DNS Policies, on
page 1408.
What to do next
Configure the policy. See Editing DNS Policies, on page 1408.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
What to do next
• Optionally, further configure the new policy as described in Logging Connections with Security
Intelligence, on page 2442.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
DNS Rules
DNS rules handle traffic based on the domain name requested by a host. As part of Security Intelligence, this
evaluation happens after any traffic decryption, and before access control evaluation.
The system matches traffic to DNS rules in the order you specify. In most cases, the system handles network
traffic according to the first DNS rule where all the rule’s conditions match the traffic. When you create DNS
rules, the system places Allow list rules before monitor and Block list rules, and evaluates traffic against
Allow list rules first.
In addition to its unique name, each DNS rule has the following basic components:
State
By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and
stops generating warnings and errors for that rule.
Position
Rules in a DNS policy are numbered, starting at 1. The system matches traffic to rules in top-down order by
ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that
handles that traffic.
Conditions
Conditions specify the specific traffic the rule handles. A DNS rule must contain a DNS feed or list condition,
and can also match traffic by security zone, network, or VLAN.
Action
A rule’s action determines how the system handles matching traffic:
• Traffic on an Allow list is allowed, subject to further access control inspection.
• Monitored traffic is subject to further evaluation by remaining DNS Block list rules. If the traffic does
not match a DNS Block list rule, it is inspected with access control rules. The system logs a Security
Intelligence event for the traffic.
• Traffic on a Block list is dropped without further inspection. You can also return a Domain Not Found
response, or redirect the DNS query to a sinkhole server.
Related Topics
About Security Intelligence, on page 1393
Step 1 In the DNS policy editor, you have the following options:
• To add a new rule, click Add DNS Rule.
• To edit an existing rule, click Edit ( ).
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the DNS policy editor, right-click the rule and choose a rule state.
Step 2 Click Save.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
If configured, TID also impacts action prioritization. For more information, see TID-Firepower Management
Center Action Prioritization, on page 1604.
Whitelist Action
The Whitelist action allows traffic to pass to the next phase of inspection, which is access control rules.
The system does not log Allow list matches. Logging of these connections depends on their eventual disposition.
Monitor Action
The Monitor action is designed to force connection logging; matching traffic is neither immediately allowed
nor blocked. Rather, traffic is matched against additional rules to determine whether to permit or deny it. The
first non-Monitor DNS rule matched determines whether the system blocks the traffic. If there are no additional
matching rules, the traffic is subject to access control evaluation.
For connections monitored by a DNS policy, the system logs end-of-connection Security Intelligence and
connection events to the Firepower Management Center database.
Block Actions
These actions block traffic without further inspection of any kind:
• The Drop action drops the traffic.
• The Domain Not Found action returns a non-existent internet domain response to the DNS query, which
prevents the client from resolving the DNS request.
• The Sinkhole action returns a sinkhole object's IPv4 or IPv6 address in response to the DNS query. The
sinkhole server can log, or log and block, follow-on connections to the IP address. If you configure a
Sinkhole action, you must also configure a sinkhole object.
For a connection blocked based on the Drop or Domain Not Found actions, the system logs
beginning-of-connection Security Intelligence and connection events. Because blocked traffic is immediately
denied without further inspection, there is no unique end of connection to log.
For a connection blocked based on the Sinkhole action, logging depends on the sinkhole object configuration.
If you configure your sinkhole object to only log sinkhole connections, the system logs end-of-connection
connection events for the follow-on connection. If you configure your sinkhole object to log and block sinkhole
connections, the system logs beginning-of-connection connection events for the follow-on connection, then
blocks that connection.
Note On an ASA FirePOWER device, if you configure a DNS rule with a sinkhole action, and traffic matches the
rule, the ASA blocks the follow-on sinkhole connection by default. As a workaround, run the following
commands from the ASA command line:
asa(config)# policy-map global_policy
asa(config-pmap)# class inspection_default
asa(config-pmap-c)# no inspect dns preset_dns_map
Related Topics
How Rules and Policy Actions Affect Logging, on page 2431
• If you do not configure a particular condition for a rule, the system does not match traffic based on that
criterion.
• You can configure multiple conditions per rule. Traffic must match all the conditions in the rule for the
rule to apply to traffic. For example, a rule with a DNS feed or list condition and network condition but
no VLAN tag condition evaluates traffic based on the domain name and source or destination, regardless
of any VLAN tagging in the session.
• For each condition in a rule, you can add up to 50 criteria. Traffic that matches any of a condition’s
criteria satisfies the condition. For example, you can use a single rule to block traffic based on up to 50
DNS lists and feeds.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• To add a network object on the fly, which you can then add to the condition, click Add ( ) above the Available
Networks list and proceed as described in Creating Network Objects, on page 450.
• To search for network objects to add, click the Search by name or value prompt above the Available Networks
list, then type an object name or the value of one of the object’s components. The list updates as you type to display
matching objects.
Step 4 Add any source IP addresses or address blocks that you want to specify manually. Click the Enter an IP address prompt
below the Source Networks list; then type an IP address or address block and click Add.
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. Using override-enabled objects allows descendant domain
administrators to tailor Global configurations to their local environments.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• To add a VLAN tag object on the fly, which you can then add to the condition, click Add ( ) above the Available
VLAN Tags list and proceed as described in Creating VLAN Tag Objects, on page 453.
• To search for VLAN tag objects and groups to add, click the Search by name or value prompt above the Available
VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in the object. The list updates
as you type to display matching objects.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• To add a DNS list or feed on the fly, which you can then add to the condition, click Add ( ) above the DNS Lists
and Feeds list and proceed as described in Creating Security Intelligence Feeds, on page 480 .
• To search for DNS lists, feeds, or categories to add, click the Search by name or value prompt above the DNS
Lists and Feeds list, then type an object name or the value of one of the object’s components. The list updates as
you type to display matching objects.
• For descriptions of the system-provided threat categories, see Security Intelligence Categories, on page 1399.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
About Prefiltering
Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation.
Prefiltering is simple, fast, and early. Prefiltering uses limited outer-header criteria to quickly handle traffic.
Compare this to subsequent evaluation, which uses inner headers and has more robust inspection capabilities.
Configure prefiltering to:
• Improve performance— The sooner you exclude traffic that does not require inspection, the better. You
can fastpath or block certain types of plaintext, passthrough tunnels based on their outer encapsulation
headers, without inspecting their encapsulated connections. You can also fastpath or block any other
connections that benefit from early handling.
• Tailor deep inspection to encapsulated traffic—You can rezone certain types of tunnels, so that you can
later handle their encapsulated connections using the same inspection criteria. Rezoning is necessary
because after prefiltering, access control uses inner headers.
Primary function Quickly fastpath or block certain Inspect and control all network About Prefiltering, on page 1417
types of plaintext, passthrough traffic, using simple or complex
tunnels (see Encapsulation criteria, including contextual
Conditions, on page 417), or tailor information and deep inspection
subsequent inspection to their results.
encapsulated traffic.
Fastpath or block any other
connections that benefit from early
handling.
Implementation Prefilter policy. Access control policy. About Prefilter Policies, on page 1422
The prefilter policy is invoked by The access control policy is a main Associating Other Policies with
the access control policy. configuration. In addition to Access Control, on page 1352
invoking subpolicies, access
control policies have their own
rules.
Bypass capability Fastpath rule action. Trust rule action. Introduction to Access Control
Rules, on page 1355
Fastpathing traffic in the prefilter Traffic trusted by access control
stage bypasses all further inspection rules is only exempt from deep
and handling, including: inspection and discovery.
• Security Intelligence
• authentication requirements
imposed by an identity policy
• SSL decryption
• access control rules
• deep inspection of packet
payloads
• discovery
• rate limiting
Rezone encapsulated Rezones tunneled traffic. Uses tunnel zones. Tunnel Zones and Prefiltering, on
connections for page 1425
Tunnel zones allow you to tailor Access control uses the tunnel
further analysis
subsequent inspection to prefiltered, zones you assign during
encapsulated traffic. prefiltering.
Connection logging Fastpathed and blocked traffic only. Any connection. Other Connections You Can Log,
Allowed connections may still be on page 2431
logged by other configurations.
Supported devices Firepower Threat Defense only. All. Best Practices for Prefiltering, on
page 1420
Some network security devices, such as Cisco ASA firewalls running Cisco ASA Software (rather than
Firepower Threat Defense), enforce security policies using outer IP headers. Even for plaintext tunnels, these
devices have no control over or insight into individual encapsulated connections and their payloads.
By contrast, the Firepower System leverages access control as follows:
• Outer header evaluation—First, prefiltering uses outer headers to handle traffic. You can block or fastpath
entire plaintext, passthrough tunnels at this stage.
• Inner header evaluation—Next, the rest of access control (and other features such as QoS) use the
innermost detectable level of headers to ensure the most granular level of inspection and handling possible.
If a passthrough tunnel is not encrypted, the system acts on its individual encapsulated connections at
this stage. You must rezone a tunnel (see Tunnel Zones and Prefiltering, on page 1425) to act on all its
encapsulated connections.
Access control has no insight into encrypted passthrough tunnels. For example, access control rules see a
passthrough VPN tunnel as one connection. The system handles the entire tunnel using only the information
in its outer, encapsulation header.
Model Requirements
Prefiltering is supported on Firepower Threat Defense devices only. Prefilter configurations have no effect
on other devices.
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
Configure Prefiltering
To perform custom prefiltering, configure and deploy prefilter policies to managed devices, as a part of access
control.
Only one person should edit a policy at a time, using a single browser window. If multiple users save the same
policy, the last saved changes are retained. For your convenience, the system displays information on who (if
anyone) is currently editing each policy. To protect the privacy of your session, a warning appears after 30
minutes of inactivity on the policy editor. After 60 minutes, the system discards your changes.
Step 3 Configure the prefilter policy's default action and its logging options.
• Default action—Choose a default action for supported plaintext, passthrough tunnels: Analyze all tunnel traffic
(with access control) or Block all tunnel traffic.
• Default action logging—Click Logging ( ) next to the default action; see Logging Connections with a Policy
Default Action, on page 2443. You can configure default action logging for blocked tunnels only.
For detailed information on configuring rule components, see Tunnel and Prefilter Rule Components, on page 1423 and
Rule Management: Common Characteristics, on page 403.
Step 5 Evaluate rule order. To move a rule, click and drag or use the right-click menu to cut and paste.
Properly creating and ordering rules is a complex task, but one that is essential to building an effective deployment. If
you do not plan carefully, rules can preempt other rules or contain invalid configurations. For more information, see Best
Practices for Access Control Rules, on page 1332.
Step 9 Deploy configuration changes; see Deploy Configuration Changes, on page 385.
What to do next
If you will deploy time-based rules, specify the time zone of the device to which the policy is assigned. See
Configure Device Time Zone for Policy Application, on page 1193.
Connection Logging
You can log connections fastpathed and blocked by the prefilter policy; see Other Connections You Can Log,
on page 2431.
Connection events contain information on whether and how logged connections—including entire tunnels—were
prefiltered. You can view this information in event views (workflows), dashboards, and reports, and use it as
correlation criteria. Keep in mind that because fastpathed and blocked connections are not subject to deep
inspection, associated connection events contain limited information.
The system uses a default policy if you do not configure custom prefiltering. Initially, this system-provided
policy passes all traffic to the next phase of access control. You can change the policy's default action and
configure its logging options, but you cannot add rules to it or delete it.
Primary function Quickly fastpath, block, or rezone plaintext, Quickly fastpath or block any other
passthough tunnels. connection that benefits from early
handling.
Encapsulation and Encapsulation conditions match only Port conditions can use a wider range of
port/protocol criteria plaintext tunnels over selected protocols, port and protocol constraints than tunnel
listed in Encapsulation Conditions, on page rules; see Port and ICMP Code Conditions,
417. on page 415.
Network criteria Tunnel endpoint conditions constrain the Network conditions constrain the source
endpoints of the tunnels you want to and destination hosts in each connection;
handle; see Tunnel Endpoint Conditions, see Network Conditions, on page 410.
on page 413.
Rezone sessions for Supported, using tunnel zones; see Tunnel Not supported.
further analysis Zones and Prefiltering, on page 1425.
Position
Rules are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule
number. The first rule that traffic matches is the rule that handles that traffic, regardless of rule type (tunnel
vs prefilter).
Action
A rule's action determines how the system handles and logs matching traffic:
• Fastpath—Exempts matching traffic from all futher inspection and control, including access control,
identity requirements, and rate limiting. Fastpathing a tunnel fastpaths all encapsulated connections.
• Block—Blocks matching traffic without further inspection of any kind. Blocking a tunnel blocks all
encapsulated connections.
• Analyze—Allows traffic to continue to be analyzed by the rest of access control, using inner headers. If
passed by access control and any related deep inspection, this traffic may also be rate limited. For tunnel
rules, enables rezoning with the Assign Tunnel Zone option.
Caution Exercise caution when assigning tunnel zones. Connections in rezoned tunnels may not match security zone
constraints in later evaluation. See Using Tunnel Zones, on page 1426 for a brief walkthrough of a tunnel zone
implementation, and a discussion of the implications of rezoning without explicitly handling rezoned traffic.
Conditions
Conditions specify the specific traffic the rule handles. Traffic must match all a rule's conditions to match the
rule. Each condition type has its own tab in the rule editor.
Applicable Time
You can specify days and times that a rule is applicable.
Logging
A rule's logging settings govern the records the system keeps of the traffic it handles.
In tunnel and prefilter rules, you can log fastpathed and blocked traffic (the Fastpath and Block actions). For
traffic subject to further analysis (the Analyze action), logging in the prefilter policy is disabled, although
matching connections may still be logged by other configurations. For more information, see Logging
Connections with Tunnel and Prefilter Rules, on page 2440.
Comments
Each time you save changes to a rule you can add comments. For example, you might summarize the overall
configuration for the benefit of other users, or note when you change a rule and the reason for the change.
You cannot edit or delete these comments after you save the rule.
Related Topics
Best Practices for Access Control Rules, on page 1332
Caution For configurations that support tunnel zone constraints, connections in rezoned tunnels do not match security
zone constraints. For example, after you rezone a tunnel, access control rules can match its encapsulated
connections with their newly assigned tunnel zone, but not with any original security zone.
See Using Tunnel Zones, on page 1426 for a brief walkthough of a tunnel zone implementation, and a discussion
of the implications of rezoning without explicitly handling rezoned traffic.
You accomplish this task by rezoning GRE tunnels. Rezoning ensures that access control associates
GRE-encapsulated connections with a custom tunnel zone, rather than their original Trusted security zone.
Rezoning is required due to the way the Firepower System and access control handle encapsulated traffic; see
Passthrough Tunnels and Access Control, on page 1419 and Tunnel Zones and Prefiltering, on page 1425.
Step 1 Configure custom intrusion and file policies that tailor deep inspection to encapsulated traffic, and another set of intrusion
and file policies tailored to nonencapsulated traffic.
Step 2 Configure custom prefiltering to rezone GRE tunnels flowing through the Trusted security zone.
Create a custom prefilter policy and associate it with access control. In that custom prefilter policy, create a tunnel rule
(in this example, GRE_tunnel_rezone) and a corresponding tunnel zone (GRE_tunnel). For more information,
see Configure Prefiltering, on page 1421.
Interface object condition Match internal-only tunnels by using the Trusted security zone as both a Source Interface
Object and Destination Interface Object constraint.
Tunnel endpoint condition Specify the source and destination endpoints for the GRE tunnels used in your organization.
Tunnel rules are bidirectional by default. If you do not change the Match tunnels from...
option, it does not matter which endpoints you specify as source and which as destination.
Assign Tunnel Zone Create the GRE_tunnel tunnel zone, and assign it to tunnels that match the rule.
Security zone condition Match rezoned tunnels by using the GRE_tunnel security zone as a Source Zone constraint;
see Interface Conditions, on page 408.
Caution If you skip this step, the rezoned connections may match any access control rule not constrained by security
zone. If the rezoned connections do not match any access control rules, they are handled by the access control
policy default action. Make sure this is your intent.
Step 4 Configure access control to handle nonencapsulated connections flowing through the Trusted security zone.
In the same access control policy, configure a rule (in this example, internal_default_inspection) that handles
non-rezoned traffic in the Trusted security zone.
Security zone condition Match non-rezoned internal-only traffic by using the Trusted security zone as both a
Source Zone and Destination Zone constraint.
Step 5 Evaluate the position of the new access control rules relative to preexisting rules. Change rule order if necessary.
If you place the two new access control rules next to each other, it does not matter which you place first. Because you
rezoned GRE tunnels, the two rules cannot preempt each other.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
What to do next
• Assign tunnel zones to plaintext, passthrough tunnels as part of custom prefiltering; see Configure
Prefiltering, on page 1421.
• High Performance Computing (HPC) Research sites, where the Firepower Threat Defense device is
deployed between storage and high compute stations. When one research site backs up using FTP file
transfer or file sync over NFS, the large amount of data traffic affects all connections. Offloading FTP
file transfer and file sync over NFS reduces the impact on other traffic.
• High Frequency Trading (HFT), where the Firepower Threat Defense device is deployed between
workstations and the Exchange, mainly for compliance purposes. Security is usually not a concern, but
latency is a major concern.
Important For details, exceptions, and limitations to the above, see Flow Offload Limitations, on page 1430.
Note that dynamic offload occurs only if static flow offload is enabled, regardless of whether prefiltering is
configured.
• Flows on interfaces configured in passive, inline, or inline tap mode. Routed and switched interfaces
are the only types supported.
• Flows that require inspection by Snort or other inspection engines. In some cases, such as FTP, the
secondary data channel can be offloaded although the control channel cannot be offloaded.
• IPsec and TLS/DTLS VPN connections that terminate on the device.
• Flows for which you configured a policy to decrement the time-to-live (TTL) value.
• Flows that require encryption or decryption. For example, connections decrypted due to an SSL
policy.
• Multicast flows in routed mode. They are supported in transparent mode if there are only two member
interfaces in a bridge group.
• TCP Intercept flows.
• Flows matching a packet capture filter with the trace option.
• Flows tagged with security groups.
• Reverse flows that are forwarded from a different cluster node, in case of asymmetric flows in a
cluster.
• Centralized flows in a cluster, if the flow owner is not the control unit.
• Flows that include IP options cannot be dynamically offloaded.
Additional Limitations
• Flow offload and Dead Connection Detection (DCD) are not compatible. Do not configure DCD
on connections that can be offloaded.
• If more than one flow that matches flow offload conditions are queued to be offloaded at the same
time to the same location on the hardware, only the first flow is offloaded. The other flows are
processed normally. This is called a collision. Use the show flow-offload flow command in the CLI
to display statistics for this situation.
• Dynamic flow offload disables all TCP normalizer checks.
View Object Details from prefilter rule 6.6 Feature introduced: Option to view details
page for an object or object group when viewing
prefilter rules.
New options: Right-clicking a value in any
of the following columns in the prefilter
rule list offers an option to view object
details: Source Networks, Destination
Networks, Source Port, Destination Port,
and VLAN Tag.
Supported platforms: Firepower
Management Center
Introduction to IAB
IAB identifies applications that you trust to traverse your network without further inspection if performance
and flow thresholds are exceeded. For example, if a nightly backup significantly impacts system performance,
you can configure thresholds that, if exceeded, trust traffic generated by your backup application. Optionally,
you can configure IAB so that, when an inspection performance threshold is exceeded, IAB trusts all traffic
that exceeds any flow bypass threshold, regardless of the application type.
The system implements IAB on traffic allowed by access control rules or the access control policy's default
action, before the traffic is subject to deep inspection. A test mode allows you to determine whether thresholds
are exceeded and, if so, to identify the application flows that would have been bypassed if you had actually
enabled IAB (called bypass mode).
The following graphic illustrates the IAB decision-making process:
IAB Options
State
Enables or disables IAB.
Applications/Filters
Provides an editor where you can specify bypassable applications and sets of applications (filters). See
Application Conditions (Application Control), on page 417.
All applications including unidentified applications
When an inspection performance threshold is exceeded, trusts all traffic that exceeds any flow bypass
threshold, regardless of the application type.
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
Caution Not all deployments require IAB, and those that do might use it in a limited fashion. Do not enable IAB unless
you have expert knowledge of your network traffic, especially application traffic, and system performance,
including the causes of predictable performance issues. Before you run IAB in bypass mode, make sure that
trusting the specified traffic does not expose you to risk.
Step 1 In the access control policy editor, click Advanced, then click Edit ( ) next to Intelligent Application Bypass Settings.
If View ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify
the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
• Click All applications including unidentified applications so that, when an inspection performance threshold
is exceeded, IAB trusts all traffic that exceeds any flow bypass threshold, regardless of the application type.
• Inspection Performance Thresholds—Click Configure and enter at least one threshold value.
• Flow Bypass Thresholds—Click Configure and enter at least one threshold value.
You must specify at least one inspection performance threshold and one flow bypass threshold; both must be exceeded
for IAB to trust traffic. If you enter more than one threshold of each type, only one of each type must be exceeded. For
detailed information, see IAB Options, on page 1434.
What to do next
• Because some packets must be allowed to pass before an application can be detected, you must configure
your system to examine those packets.
See Best Practices for Handling Packets That Pass Before Traffic Identification, on page 1848 and Specify
a Policy to Handle Packets That Pass Before Traffic Identification, on page 1848.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Allow -
indicates that the applied IAB configuration was in test mode and traffic for the application specified
by Application Protocol remains available for inspection.
Trust -
indicates that the applied IAB configuration was in bypass mode and traffic for the application
specified by Application Protocol has been trusted to traverse the network without further inspection.
Reason
Intelligent App Bypass indicates that IAB triggered the event in bypass or test mode.
Application Protocol
This field displays the application protocol that triggered the event.
Example
In the following truncated graphic, some fields are omitted. The graphic shows the Action, Reason,
and Application Protocol fields for two connection events resulting from different IAB settings in
two separate access control policies.
For the first event, the Trust action indicates that IAB was enabled in bypass mode and Bonjour
protocol traffic was trusted to pass without further inspection.
For the second event, the Allow action indicates that IAB was enabled in test mode, so Ubuntu Update
Manager traffic was subject to further inspection but would have been bypassed if IAB had been in
bypass mode.
Example
In the following truncated graphic, some fields are omitted. The flow in the second event was both
bypassed (Action: Trust; Reason: Intelligent App Bypass) and inspected by an intrusion rule
(Reason: Intrusion Monitor). The Intrusion Monitor reason indicates that an intrusion rule set
to Generate Events detected but did not block an exploit during the connection. In the example, this
happened before the application was detected. After the application was detected, IAB recognized
the application as bypassable and trusted the flow.
• Field: any
• Aggregate: either of:
• IAB Bypassed Connections
• Filter: any
Examples
In the following Custom Analysis dashboard widget examples:
• The Bypassed example shows statistics for application traffic bypassed because the applications
were specified as bypassable and IAB was enabled in bypass mode in the deployed access
control policy.
• The Would Have Bypassed example shows statistics for application traffic that would have been
bypassed because the applications were specified as bypassable and IAB was enabled in test
mode in the deployed access control policy. .
• Preset: None
• Filter: any
• X-Axis: any
• Y-Axis: either of:
• IAB Bypassed Connections
Examples
The following graphic shows two abbreviated report examples:
• The Bypassed example shows statistics for application traffic bypassed because the applications
were specified as bypassable and IAB was enabled in bypass mode in the deployed access
control policy.
• The Would Have Bypassed example shows statistics for application traffic that would have been
bypassed because the applications were specified as bypassable and IAB was enabled in test
mode in the deployed access control policy.
Related Topics
Connection and Security Intelligence Event Fields, on page 2447
The Custom Analysis Widget, on page 292
Adding Widgets to a Dashboard, on page 301
Report Templates, on page 2247
You can use two methods to configure the system to enforce these features:
Method: Access Control Rules
Content restriction features communicate the restricted status of a search or content query via an element
in the request URI, an associated cookie, or a custom HTTP header element. You can configure access
control rules to modify these elements as the system processes traffic.
Method: DNS Sinkhole
For Google searches, you can configure the system to redirect traffic to the Google SafeSearch Virtual
IP Address (VIP), which imposes filters for Safe Search (including YouTube Restricted Mode).
The table below describes the differences between these enforcement methods.
The system logs different values for the Reason field in connection events, depending on the method:
• Access Control Rules—Content Restriction
• DNS Sinkhole—DNS Block
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
Caution To avoid rule preemption, position rules governing YouTube EDU above rules governing Safe Search in both
SSL and access control policies; see Content Restriction Rule Order, on page 1334.
Note When safe search or YouTube EDU is enabled in an access control rule, inline normalization is enabled
automatically. For more information, see The Inline Normalization Preprocessor, on page 1940.
Step 1 Create an SSL policy; see Create Basic SSL Policies, on page 1481.
Step 2 Add SSL rules for handling Safe Search and YouTube EDU traffic:
• Choose Decrypt - Resign as the Action for the rules. The system does not support any other action for content
restriction handling.
• In Applications, add selections to the Selected Applications and Filters list:
• YouTube EDU—Add the YouTube and YouTube Upload applications.
• Safe Search—Add the Category: search engine filter.
For more information, see Application Conditions (Application Control), on page 417
Step 3 Set rule positions for the SSL rules you added. Click and drag, or use the right-click menu to cut and paste.
To avoid preemption, position the Safe Search rule after the YouTube EDU rule.
Step 4 Create or edit an access control policy, and associate the SSL policy with the access control policy.
For more information, see Associating Other Policies with Access Control, on page 1352.
Step 5 In the access control policy, add rules for handling Safe Search and YouTube EDU traffic:
• Choose Allow as the Action for the rules. The system does not allow any other action for content restriction handling.
• In Applications, click dimmed for either Safe search ( ) or YouTube EDU ( ), and set related options; see
Safe Search Options for Access Control Rules, on page 1444 and YouTube EDU Options for Access Control Rules,
on page 1444.
These options are disabled, rather than dimmed, if you choose any Action other than Allow for the rule.
You cannot enable Safe Search and YouTube EDU restrictions for the same access control rule.
• In Applications, refine application selections in the Selected Applications and Filters list.
In most cases, enabling Safe Search or YouTube EDU populates the Selected Applications and Filters list with
the appropriate values. The system does not automatically populate the list if a Safe Search or YouTube application
is already present in the list when you enable the feature. If applications do not populate as expected, manually add
them as follows:
• YouTube EDU—Add the YouTube and YouTube Upload applications.
• Safe Search—Add the Category: search engine filter.
For more information, see Configuring Application Conditions and Filters, on page 418.
Step 6 Set rule positions for the access control rules you added. Click and drag, or use the right-click menu to cut and paste.
To avoid preemption, position the Safe Search rule after the YouTube EDU rule.
Step 7 Configure the HTTP response page that the system displays when it blocks restricted content; see Choosing HTTP
Response Pages, on page 1391.
Step 8 Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note If you check Enable YouTube EDU, you must enter a Custom ID. This ID is defined externally by
YouTube. The system does not validate what you enter against the YouTube system. If you enter an
invalid ID, YouTube EDU restrictions may not perform as expected.
Caution If your network includes proxy servers, this content restriction method is not effective unless you position
your Firepower Threat Defense devices between the proxy servers and the Internet.
This procedure describes enforcing content restriction for Google searches only. To enforce content restriction
for other search engines, see Using Access Control Rules to Enforce Content Restriction, on page 1443.
Step 1 Obtain a list of supported Google domains via the following URL: https://www.google.com/supported_domains.
Step 2 Create a custom DNS list on your local computer, and add the following entries:
• To enforce Google SafeSearch, add an entry for each supported Google domain.
• To enforce YouTube Restricted Mode, add a "youtube.com" entry.
The custom DNS list must be in text file (.txt) format. Each line of the text file must specify an individual domain name,
stripped of any leading periods. For example, the supported domain ".google.com" must appear as "google.com".
Step 3 Upload the custom DNS list to the Firepower Management Center; see Uploading New Security Intelligence Lists to the
Firepower Management Center, on page 482.
Step 4 Determine the IPv4 address for the Google SafeSearch VIP. For example, run nslookup on forcesafesearch.google.com.
Step 5 Create a sinkhole object for the SafeSearch VIP; see Creating Sinkhole Objects, on page 483.
Use the following values for this object:
• IPv4 Address—Enter the SafeSearch VIP address.
• IPv6 Address—Enter the IPv6 loopback address (::1).
• Log Connections to Sinkhole—Click Log Connections.
• Type—Choose None.
Step 6 Create a basic DNS policy; see Creating Basic DNS Policies, on page 1408.
Step 7 Add a DNS rule for the sinkhole; see Creating and Editing DNS Rules, on page 1410.
For this rule:
• Check the Enabled check box.
• Choose Sinkhole from the Action drop-down list.
• Choose the sinkhole object you created from the Sinkhole drop-down list.
• Add the custom DNS list you created to the Selected Items list on DNS.
• (Optional) Choose a network in Networks to limit content restriction to specific users. For example, if you want to
limit content restriction to student users, assign students to a different subnet than faculty, and specify that subnet
in this rule.
Step 8 Associate the DNS policy with an access control policy; see Associating Other Policies with Access Control, on page
1352.
Step 9 Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either
protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure
TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only.
The exception is SSL policies. Because the FMC configuration option is Policies > Access Control > SSL,
we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic.
For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the
Difference?.
Note that access control rules also handle encrypted traffic when your TLS/SSL inspection configuration
allows it to pass. However, some access control rule conditions require unencrypted traffic, so encrypted
traffic might match fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted
payloads. This helps reduce false positives and improves performance when an encrypted connection matches
an access control rule that has intrusion and file inspection configured.
If the system detects a TLS/SSL handshake over a TCP connection, it determines whether it can decrypt the
detected traffic. If it cannot, it applies a configured action:
• Block the encrypted traffic
• Block the encrypted traffic and reset the TCP connection
• Not decrypt the encrypted traffic
If the system can decrypt the traffic, it blocks the traffic without further inspection, evaluates undecrypted
traffic with access control, or decrypts it using one of the following methods:
• Decrypt with a known private key. When an external host initiates a TLS/SSL handshake with a server
on your network, the system matches the exchanged server certificate with a server certificate previously
uploaded to the system. It then uses the uploaded private key to decrypt the traffic.
• Decrypt by resigning the server certificate. When a host on your network initiates a TLS/SSL handshake
with an external server, the system resigns the exchanged server certificate with a previously uploaded
certificate authority (CA) certificate. It then uses the uploaded private key to decrypt the traffic.
Note The Firepower System does not support mutual authentication; that is, you cannot upload a client certificate
to the FMC and use it for either Decrypt - Resign or Decrypt - Known Key TLS/SSL rule actions. For more
information, see Decrypt and Resign (Outgoing Traffic), on page 1459. and Known Key Decryption (Incoming
Traffic), on page 1459.
Decrypted traffic is subject to the same traffic handling and analysis as originally unencrypted traffic: network,
reputation, and user-based access control; intrusion detection and prevention; Cisco Advanced Malware
Protection (Cisco AMP); and discovery. If the system does not block the decrypted traffic post-analysis, it
re-encrypts the traffic before passing it to the destination host.
Note Set up decrypt rules only if your managed device handles encrypted traffic. Decryption rules require processing
overhead that can impact performance.
The Firepower System does not currently support TLS version 1.3 encryption or decryption. When users visit
a web site that negotiates TLS 1.3 encryption, users might see errors similar to the following in their web
browser:
• ERR_SSL_PROTOCOL_ERROR
• SEC_ERROR_BAD_SIGNATURE
• ERR_SSL_VERSION_INTERFERENCE
For more information about how to control this behavior, contact Cisco TAC.
Although the data transmitted in the session is encrypted, the handshake messages are not.
After a TLS/SSL handshake completes, the managed device caches encrypted session data, which allows
session resumption without requiring the full handshake. The managed device also caches server certificate
data, which allows faster handshake processing in subsequent sessions.
Zones ClientHello
Networks ClientHello
Ports ClientHello
Users ClientHello
Versions ServerHello
If the ClientHello message does not match a Decrypt - Resign rule, the system does not modify the message.
It then determines whether the message passes access control evaluation (which can include deep inspection).
If the message passes, the system transmits it to the destination server.
If the message matches a Decrypt - Resign rule, the system modifies the ClientHello message as follows:
• Compression methods—Strips the compression_methods element, which specifies the compression
methods the client supports. The Firepower System cannot decrypt compressed sessions. This modification
reduces the Compressed Session type of undecryptable traffic.
• Cipher suites—Strips cipher suites from the cipher_suites element if the Firepower System does not
support them. If the Firepower System does not support any of the specified cipher suites, the system
transmits the original, unmodified element. This modification reduces the Unknown Cipher Suite and
Unsupported Cipher Suite types of undecryptable traffic.
• Session identifiers—Strips any value from the Session Identifier element and the SessionTicket
extension that does not match cached session data. If a ClientHello value matches cached data, an
interrupted session can resume without the client and server performing the full TLS/SSL handshake.
This modification increases the chances of session resumption and reduces the Session Not Cached type
of undecryptable traffic.
• Elliptic curves—Strips elliptic curves from the Supported Elliptic Curves extension if the Firepower
System does not support them. If the Firepower System does not support any of the specified elliptic
curves, the managed device removes the extension and strips any related cipher suites from the
cipher_suites element.
• ALPN extensions—Strips any value from the Application-Layer Protocol Negotiation (ALPN) extension
that is unsupported in the Firepower System (for example, the SPDY and HTTP/2 protocols).
• Other Extensions—Strips the Next Protocol Negotiation (NPN) and TLS Channel IDs extensions.
Note The system performs these ClientHello modifications by default. If your SSL policy is configured correctly,
this default behavior results in more frequent decryption of traffic. To tune the default behavior for your
individual network, contact Cisco TAC.
After the system modifies the ClientHello message, it determines whether the message passes access control
evaluation (which can include deep inspection). If the message passes, the system transmits it to the destination
server.
Direct communication between the client and server is no longer possible during the TLS/SSL handshake,
because after message modification the Message Authentication Codes (MACs) computed by the client and
server no longer match. For all subsequent handshake messages (and for the encrypted session once established),
the managed device acts as a man-in-the-middle (MITM). It creates two TLS/SSL sessions, one between client
and managed device, one between managed device and server. As a result, each session contains different
cryptographic session details.
Note The cipher suites that the Firepower System can decrypt are frequently updated and do not correspond directly
to the cipher suites you can use in TLS/SSL rule conditions. For the current list of decryptable cipher suites,
contact Cisco TAC.
Related Topics
Default Handling Options for Undecryptable Traffic, on page 1479
Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment, on page 1472
If the server changes its certificate between the initial connection with the client and subsequent
connections, you must import the new server certificate in the Firepower Management Center for future
connections to be decrypted.
Action: Decrypt - Resign
The managed device processes the server certificate message and re-signs the server certificate with the
previously imported or generated certificate authority (CA). The TLS/SSL handshake continues to
completion. The managed device then uses the uploaded private key to decrypt and reencrypt the
application data exchanged during the TLS/SSL session.
Note The Firepower System does not support mutual authentication; that is, you cannot upload a client certificate
to the FMC and use it for either Decrypt - Resign or Decrypt - Known Key TLS/SSL rule actions. For more
information, see Decrypt and Resign (Outgoing Traffic), on page 1459. and Known Key Decryption (Incoming
Traffic), on page 1459.
Supported Hardware
The following hardware models support TLS crypto acceleration:
• Firepower 2100 with Firepower Threat Defense
• Firepower 4100/9300 with Firepower Threat Defense
For information about TLS crypto acceleration support on Firepower 4100/9300 FTD container instances,
see the FXOS Configuration Guide.
TLS crypto acceleration is not supported on any virtual appliances or on any hardware except for the preceding.
Note For more information about TLS crypto acceleration and the 4100/9300, see the FXOS Configuration Guide.
HTTP-only performance
Using TLS crypto acceleration on a managed device that is not decrypting traffic can affect performance.
FIPS is enabled when you configure the Firepower Management Center and managed devices to operate in
a security certifications compliance mode. To allow connections when operating in those modes, you can
configure web browsers to accept more secure options.
For more information:
• Ciphers supported by FIPS: About SSL Settings, on page 1166.
• Security Certifications Compliance Modes, on page 1197.
• Common Criteria.
TLS heartbeat
Some applications use the TLS heartbeat extension to the Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) protocols defined by RFC6520. TLS heartbeat provides a way to confirm
the connection is still alive—either the client or server sends a specified number of bytes of data and requests
the other party echo the response. If this is successful, encrypted data is sent.
When a managed device with TLS crypto acceleration enabled encounters a packet that uses the TLS heartbeat
extension,the managed device takes the action specified by the setting for Decryption Errors in the SSL
policy's Undecryptable Actions:
• Block
For more information, see Default Handling Options for Undecryptable Traffic, on page 1479.
To determine whether applications are using TLS heartbeat, see Troubleshoot TLS Heartbeat, on page 1528.
If your managed device does not support or if TLS crypto acceleration is disabled, you can configure a Max
Heartbeat Length in a Network Analysis Policy (NAP) to determine how to handle TLS heartbeats. For
more information, see The SSL Preprocessor, on page 1920.
TLS/SSL oversubscription
TLS/SSL oversubscription is a state where a managed device is overloaded with TLS/SSL traffic. Any managed
device can experience TLS/SSL oversubscription but only managed devices that support TLS crypto acceleration
provide a configurable way to handle it.
When a managed device with TLS crypto acceleration enabled is oversubscribed, any packet received by the
managed device is acted on according to the setting for Handshake Errors in the SSL policy's Undecryptable
Actions:
• Inherit default action
• Do not decrypt
• Block
• Block with reset
If the setting for Handshake Errors in the SSL policy's Undecryptable Actions is Do Not decrypt and the
associated access control policy is configured to inspect the traffic, inspection occurs; decryption does not
occur.
If a significant amount of oversubscription is occurring, you have the following options:
• Upgrade your managed devices to increase TLS/SSL processing capacity.
• Change your SSL policies to add Do Not Decrypt rules for traffic that is not a high priority to decrypt.
Note Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either
protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure
TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only.
The exception is SSL policies. Because the FMC configuration option is Policies > Access Control > SSL,
we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic.
For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the
Difference?.
Related Topics
The Case for Decryption, on page 1457
When to Decrypt Traffic, When Not to Decrypt, on page 1458
Other TLS/SSL Rule Actions, on page 1460
TLS/SSL Rule Components, on page 1462
TLS/SSL Rule Order Evaluation, on page 1463
Keep in mind that decrypting and then re-encrypting traffic adds a processing load on the device, which can
reduce overall system performance.
In summary:
• Encrypted traffic can be allowed or blocked by policy; encrypted traffic cannot be inspected
• Decrypted traffic is subject to threat defense and policy enforcement; decrypted traffic can be allowed
or blocked by policy
Related Topics
Deep Inspection Using File and Intrusion Policies, on page 1325
If you elect to bypass decryption for certain types of traffic, no processing is done on the traffic. The encrypted
traffic is first evaluated by SSL policy and then proceeds to the access control policy, where a final allow or
block decision is made. Encrypted traffic can be allowed or blocked on any TLS/SSL rule condition, including,
but not limited to:
• Certificate status (for example, expired or invalid certificate)
• Protocol (for example, the nonsecure SSL protocol)
• Network (security zone, IP address, VLAN tag, and so on)
• Exact URL or URL category
• Port
• User group
SSL policies provide a Do Not Decrypt action for this traffic; for more information, see TLS/SSL Rule Do
Not Decrypt Action, on page 1499.
Note The related information links at the end of this topic explain how some aspects of rule evaluation work.
Conditions such as URL and application filtering have limitations with respect to encrypted traffic. Make sure
you understand those limitations.
The Firepower System provides two methods of decryption, which are discussed in the following sections.
Related Topics
Decrypt and Resign (Outgoing Traffic), on page 1459
Known Key Decryption (Incoming Traffic), on page 1459
TLS/SSL Rule Guidelines and Limitations, on page 1485
SSL Rule Order, on page 1335
URL Conditions (URL Filtering), on page 426
Application Rule Order, on page 1334
Note The Firepower System does not support mutual authentication; that is, you cannot upload a client certificate
to the FMC and use it for either Decrypt - Resign or Decrypt - Known Key TLS/SSL rule actions. For more
information, see Decrypt and Resign (Outgoing Traffic), on page 1459. and Known Key Decryption (Incoming
Traffic), on page 1459.
Related Topics
TLS/SSL Rule Decrypt Actions, on page 1500
External Certificate Objects, on page 499
Note The Firepower System does not support mutual authentication; that is, you cannot upload a client certificate
to the FMC and use it for either Decrypt - Resign or Decrypt - Known Key TLS/SSL rule actions. For more
information, see Decrypt and Resign (Outgoing Traffic), on page 1459. and Known Key Decryption (Incoming
Traffic), on page 1459.
Related Topics
TLS/SSL Rule Decrypt Actions, on page 1500
Internal Certificate Objects, on page 499
Step 1 Log in to the Firepower Management System if you have not already done so.
Step 2 Click Policies > Access Control > SSL.
Step 3 Add or edit an SSL policy.
Step 4 Click Add Rule.
Step 5 In the Name field, enter a name for the rule.
Step 6 From the Action list, click Block or Block with reset.
Step 7 Click Version page.
Step 8 Check the check boxes for protocols that are no longer secure, such as SSL v3.0, TLS 1.0, and TLS 1.1. Clear the
check boxes for any protocols that are still considered secure.
The following figure shows an example.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
TLS/SSL Rule Conditions, on page 1497
State
By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and
stops generating warnings and errors for that rule.
Position
Rules in an SSL policy are numbered, starting at 1. The system matches traffic to rules in top-down order by
ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that
handles that traffic.
Conditions
Conditions specify the specific traffic the rule handles. Conditions can match traffic by security zone, network
or geographical location, VLAN, port, application, requested URL, user, certificate, certificate subject or
issuer, certificate status, cipher suite, or encryption protocol version. The use of conditions can depend on
target device licenses.
Action
A rule’s action determines how the system handles matching traffic. You can monitor, allow, block, or decrypt
encrypted matching traffic. Decrypted and allowed encrypted traffic is subject to further inspection. Note that
the system does not perform inspection on blocked encrypted traffic.
Logging
A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record
of traffic that matches a rule. You can log a connection when the system blocks an encrypted session or allows
it to pass without decryption, according to the settings in an SSL policy. You can also force the system to log
connections that it decrypts for further evaluation by access control rules, regardless of how the system later
handles or inspects the traffic. You can log connections to the Firepower Management Center database, as
well as to the system log (syslog) or to an SNMP trap server.
For more information about logging, see Best Practices for Connection Logging, on page 2438.
Tip Properly creating and ordering TLS/SSL rules is a complex task. If you do not plan your policy carefully,
rules can preempt other rules, require additional licenses, or contain invalid configurations. To help ensure
that the system handles traffic as you expect, the SSL policy interface has a robust warning and error feedback
system for rules.
Related Topics
Interface Conditions, on page 408
Network Conditions, on page 410
VLAN Conditions, on page 414
Port and ICMP Code Conditions, on page 415
Application Conditions (Application Control), on page 417
Tip Proper TLS/SSL rule order reduces the resources required to process network traffic, and prevents rule
preemption. Although the rules you create are unique to every organization and deployment, there are a few
general guidelines to follow when ordering rules that can optimize performance while still addressing your
needs.
In addition to ordering rules by number, you can group rules by category. By default the system provides
three categories: Administrator, Standard, and Root. You can add custom categories, but you cannot delete
the system-provided categories or change their order.
Related Topics
Best Practices for Access Control Rules, on page 1332
Default Handling Options for Undecryptable Traffic, on page 1479
SSL Rule Order, on page 1335
Multi-Rule Example
The following scenario summarizes the ways that SSL rules handle traffic in an inline deployment.
and unencrypted traffic identically. The system can block traffic as a result of this additional inspection.
All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match
the SSL rule continues to the next rule.
• SSL Policy Default Action handles all traffic that does not match any of the TLS/SSL rules. The default
action either blocks encrypted traffic without further inspection or does not decrypt it, passing it for
access control inspection.
Procedure
Step 5 For Decrypt - Resign (to decrypt outbound traffic to a The internal CA object uses a CA and private key. See
server outside of your network) TLS/SSL rules, create an Internal Certificate Authority Objects, on page 492.
internal certificate authority (CA) object.
Step 6 Create your TLS/SSL rules: • Block, Block with reset, Interactive block:
Configuring TLS/SSL Rule Actions, on page 1500.
• Do Not Decrypt, see Configuring TLS/SSL Rule
Actions, on page 1500.
• Decrypt - Resign, see Configuring a Decrypt - Resign
Action, on page 1501.
Step 7 Associate the SSL policy with an access control policy. Unless you associate your SSL policy with an access control
policy, it has no effect. After you do this, you can choose
to allow or block traffic that matches the access control rule
and take other actions. See Associating Other Policies with
Access Control, on page 1352.
Step 8 Configure your access control rules to allow or block See Access Control Policy Components, on page 1340.
decrypted traffic.
Step 9 Deploy the access control policy to managed devices. Before your policy can take effect, it must be deployed to
managed devices. See Deploy Configuration Changes, on
page 385.
LifeIns places junior underwriters on six-month training periods. Lately, these underwriters have been
incorrectly submitting encrypted medical regulation requests to MedRepo’s customer service department.
MedRepo has submitted multiple complaints to LifeIns in response. LifeIns plans on extending their new
underwriter training period to also audit underwriter requests to MedRepo.
LifeIns plans to deploy a device in an inline deployment for the Underwriting department.
Traffic from MedRepo’s network goes to MedRepo’s router. It routes traffic to LifeIns’s network. The managed
device receives the traffic, passes allowed traffic to LifeIns’s router, and sends events to the managing Firepower
Management Center. LifeIns’s router routes traffic to the destination host.
On the managing Firepower Management Center, a user in the Access Control and SSL Editor custom role
configures an SSL access control rule to:
• log all encrypted traffic sent to the Underwriting department
• block all encrypted traffic incorrectly sent from LifeIns’s underwriting department to MedRepo’s customer
service department
• decrypt all encrypted traffic sent from MedRepo to LifeIns’s underwriting department, and from LifeIns’s
junior underwriters to MedRepo’s requests department
• not decrypt encrypted traffic sent from the senior underwriters
The user also configures access control to inspect decrypted traffic with a custom intrusion policy and:
• block decrypted traffic if it contains a spoof attempt, and log the spoof attempt
• block decrypted traffic that contains information not compliant with regulations, and log the improper
information
• allow all other encrypted and decrypted traffic
The system reencrypts allowed decrypted traffic before sending it to the destination host.
You can also cause the system to decrypt and resign the traffic using a TLS/SSL control rule with the action
Decrypt - Resign. If traffic matches the TLS/SSL rule, after the system modifies the ClientHello message,
it determines whether the message passes access control evaluation (which can include deep inspection). If
the message passes, the system transmits it to the destination server. For more information, see ClientHello
Message Handling, on page 1451
In the following scenarios, the user submits information online to a remote server. The user’s browser establishes
a TCP connection with the server, then initiates an SSL handshake. The managed device receives this traffic;
based on handshake and connection details, the system logs the connection and acts on the traffic. If the system
blocks the traffic, it also closes the TCP connection. Otherwise, the client and server complete the SSL
handshake, establishing the encrypted session.
4. The external router receives the traffic and routes it to the Requests department server.
5. The Underwriting department server receives the encrypted information request (AaBb) and decrypts it to
plain text (help).
6. The Firepower Management Center receives the connection event.
In contrast, any decrypted traffic that is a spoof attempt is dropped. The system logs the connection and the
spoof attempt.
Note When decrypting traffic in an inline deployment by re-signing the server certificate, the device acts as a
man-in-the-middle. It creates two TLS/SSL sessions, one between client and managed device, one between
managed device and server. As a result, each session contains different cryptographic session details.
Note Traffic encrypted with a re-signed server certificate causes client browsers to warn that the certificate is not
trusted. To avoid this, add the CA certificate to the organization’s domain root trusted certificates store or the
client trusted certificates store.
In contrast, any decrypted traffic that contains information that does not meet regulatory requirements is
dropped. The system logs the connection and the non-conforming information.
Changes to category- and reputation- based 6.5 For details, see History for URL Filtering, on page 1387.
URL Filtering
TLS crypto acceleration cannot be disabled 6.4 TLS crypto acceleration is enabled on all supported devices.
On a managed device with native interfaces, TLS crypto acceleration
cannot be disabled.
Support for TLS crypto acceleration on FTD container instances is limited
as discussed in the next row of this table.
Removed commands:
system support ssl-hw-accel enable
system support ssl-hw-accel disable
system support ssl-hw-status
Support for TLS crypto acceleration on one 6.4 You can now enable TLS crypto acceleration for one FTD container
FTD container instance on a Firepower instance on a module/security engine. TLS crypto acceleration is disabled
4100/9300 module/security engine for other container instances, but enabled for native instances.
New/Modified commands:
config hwCrypto enable
show crypto accelerator status replaces system support ssl-hw-status)
TLS/SSL hardware acceleration is now 6.4 The name change reflects that TLS/SSL encryption and decryption
referred to as TLS crypto acceleration acceleration is supported on more devices. Depending on the device,
acceleration might be performed in software or in hardware.
Affected screen: To view the status of TLS crypto acceleration, Devices >
Device Management > Device, General page.
Extended Master Secret extension 6.3.0.1 The TLS Extended Master Secret extension is supported for SSL policies;
supported (see RFC 7627) specifically, policies with a rule action of Decrypt - Resign or Decrypt
- Known Key.
Extended Master Secret extension not 6.3 The extension is stripped during ClientHello modification for Decrypt
supported - Resign rules.
TLS/SSL hardware acceleration enabled by 6.3 TLS/SSL hardware acceleration is enabled by default on all supported
default devices but can be disabled if desired.
Extended Master Secret extension 6.2.3.9 The TLS Extended Master Secret extension is supported for SSL policies;
supported (see RFC 7627) specifically, policies with a rule action of Decrypt - Resign or Decrypt
- Known Key.
Aggressive TLS 1.3 downgrade 6.2.3.7 Using the system support ssl-client-hello-enabled
aggressive-tls13-downgrade {true|false} CLI command, you can
determine the behavior for downgrading TLS 1.3 traffic to TLS 1.2. For
details, see the Command Reference for Firepower Threat Defense.
TLS/SSL hardware acceleration introduced 6.2.3 Certain managed device models perform TLS/SSL encryption and
decryption in hardware, improving performance. By default, the feature
is enabled.
Affected screen: To view the status of TLS/SSL hardware acceleration,
Devices > Device Management > Device, General page.
Category and reputation conditions 6.2.2 Access control rules or SSL rules with category/reputation conditions.
supported
SafeSearch supported 6.1.0 • The system displays an HTTP response page for connections
decrypted by the SSL policy, then blocked (or interactively blocked)
either by access control rules or by the access control policy default
action. In these cases, the system encrypts the response page and
sends it at the end of the reencrypted SSL stream.
• SafeSearch filters objectionable content and stops people from
searching adult sites.
Caution Adding or removing an SSL policy restarts the Snort process when you deploy configuration changes,
temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without
further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior, on
page 390 for more information.
The simplest SSL policy, as shown in the following diagram, directs the device where it is deployed to handle
encrypted traffic with a single default action. You can set the default action to block decryptable traffic without
further inspection, or to inspect undecrypted decryptable traffic with access control. The system can then
either allow or block the encrypted traffic. If the device detects undecryptable traffic, it either blocks the traffic
without further inspection or does not decrypt it, inspecting it with access control.
A more complex SSL policy can handle different types of undecryptable traffic with different actions, control
traffic based on whether a certificate authority (CA) issued or trusts the encryption certificate, and use SSL
rules to exert granular control over encrypted traffic logging and handling. These rules can be simple or
complex, matching and inspecting encrypted traffic using multiple criteria.
Note Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either
protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure
TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only.
The exception is SSL policies. Because the FMC configuration option is Policies > Access Control > SSL,
we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic.
For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the
Difference?.
Related Topics
TLS/SSL Rule Conditions, on page 1497
Block with reset Block the TLS/SSL session without further inspection and reset
the TCP connection. Choose this option if traffic uses a
connectionless protocol like UDP. In that case, the connectionless
protocol tries to reestablish the connection until it is reset.
This action also displays a connection reset error in the browser
so the user is informed that the connection is blocked.
Related Topics
Create Basic SSL Policies, on page 1481
Compressed Session The TLS/SSL session applies a Inherit default action Do not decrypt
data compression method.
Block
Block with reset
Inherit default action
SSLv2 Session The session is encrypted with Inherit default action Do not decrypt
SSL version 2.
Block
Note that traffic is decryptable
Block with reset
if the ClientHello message is
SSL 2.0, and the remainder of Inherit default action
the transmitted traffic is SSL
3.0.
Unknown Cipher Suite The system does not recognize Inherit default action Do not decrypt
the cipher suite.
Block
Block with reset
Inherit default action
Unsupported Cipher Suite The system does not support Inherit default action Do not decrypt
decryption based on the detected
Block
cipher suite.
Block with reset
Inherit default action
Session not cached The TLS/SSL session has Inherit default action Do not decrypt
session reuse enabled, the client
Block
and server reestablished the
session with the session Block with reset
identifier, and the system did
Inherit default action
not cache that session identifier.
Handshake Errors An error occurred during Inherit default action Do not decrypt
TLS/SSL handshake
Block
negotiation.
Block with reset
Inherit default action
When you first create an SSL policy, logging connections that are handled by the default action is disabled
by default. Because the logging settings for the default action also apply to undecryptable traffic handling,
logging connections handled by the undecryptable traffic actions is disabled by default.
Note that if your browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic
by re-signing the server certificate. For more information, see TLS/SSL Rule Guidelines and Limitations, on
page 1485.
Related Topics
Set Default Handling for Undecryptable Traffic, on page 1482
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
• Copy—Click Copy ( ).
• Create—Click New Policy; see Create Basic SSL Policies, on page 1481.
• Delete—Click Delete ( ). If the controls are dimmed, the configuration belongs to an ancestor domain, or you do
not have permission to modify the configuration.
• Deploy—Choose Deploy > Deployment; see Deploy Configuration Changes, on page 385.
• Edit—Click Edit ( ); see Editing an SSL Policy, on page 1483. If View ( ) appears instead, the configuration
belongs to an ancestor domain, or you do not have permission to modify the configuration.
• Import/Export—See About Configuration Import/Export, on page 201.
What To Do Next
• Configure rules to add to your SSL policy; see Creating and Modifying TLS/SSL Rules, on page 1492.
• Set the default handling for undecryptable traffic; see Set Default Handling for Undecryptable Traffic,
on page 1482.
• Configure logging options for default handling of undecryptable traffic; see Logging Connections with
a Policy Default Action, on page 2443.
• Associate the SSL policy with an access control policy as described in Associating Other Policies with
Access Control, on page 1352.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Example
For example, to block all SSLv2 traffic, set the options as follows:
What to do next
• Configure default logging for connections handled by the undecryptable traffic actions; see Logging
Connections with a Policy Default Action, on page 2443.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
• Delete—To delete a rule, click Delete ( ) next to the rule, then click OK.
• Disable—To disable an enabled rule, right-click a selected rule, choose State, then choose Disable.
• Display—To display the configuration page for a specific rule attribute, click the name or value in the column for
the condition on the row for the rule. For example, click the name or value in the Source Networks column to
display the Networks page for the selected rule. See Network Conditions, on page 410.
What to do next
• If the SSL policy is not already associated with an access control policy, associate it as described in
Associating Other Policies with Access Control, on page 1352.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Creating and Modifying TLS/SSL Rules, on page 1492
Note Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either
protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure
TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only.
The exception is SSL policies. Because the FMC configuration option is Policies > Access Control > SSL,
we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic.
For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the
Difference?.
In addition, rules can preempt each other, require additional licenses, or contain invalid configurations.
Thoughtfully configured rules can also reduce the resources required to process network traffic. Creating
overly complex rules and ordering rules the wrong way can adversely affect performance.
For detailed information, see Best Practices for Access Control Rules, on page 1332.
For guidelines related specifically to TLS crypto acceleration, see TLS Crypto Acceleration, on page 1454.
Related Topics
Rule and Other Policy Warnings, on page 436
Best Practices for Access Control Rules, on page 1332
Guideline for Using TLS/SSL Decryption, on page 1486
TLS/SSL Rule Unsupported Features, on page 1486
TLS/SSL Do Not Decrypt Guidelines, on page 1487
TLS/SSL Decrypt - Resign Guidelines, on page 1487
TLS/SSL Decrypt - Known Key Guidelines, on page 1489
TLS/SSL Block Guidelines, on page 1489
TLS/SSL Certificate Pinning Guidelines, on page 1489
TLS/SSL Heartbeat Guidelines, on page 1490
TLS/SSL Anonymous Cipher Suite Limitation, on page 1490
TLS/SSL Normalizer Guidelines, on page 1490
Other TLS/SSL Rule Guidelines, on page 1491
SSL Rule Order, on page 1335
• ERR_SSL_VERSION_INTERFERENCE
For more information about how to control this behavior, contact Cisco TAC.
If you elect to bypass decryption for certain types of traffic, no processing is done on the traffic. The encrypted
traffic is first evaluated by SSL policy and then proceeds to the access control policy, where a final allow or
block decision is made. Encrypted traffic can be allowed or blocked on any TLS/SSL rule condition, including,
but not limited to:
• Certificate status (for example, expired or invalid certificate)
• Protocol (for example, the nonsecure SSL protocol)
• Network (security zone, IP address, VLAN tag, and so on)
• Exact URL or URL category
• Port
• User group
Best practices
We recommend the following:
• Use the Decrypt - Resign rule action for decrypting outgoing traffic, as opposed to incoming traffic for
which we recommend the Decrypt - Known Key rule action.
For more information about Decrypt - Known Key, see TLS/SSL Decrypt - Known Key Guidelines,
on page 1489.
• Always check the Replace Key Only check box when you set up a Decrypt - Resign rule action.
When a user browses to a web site that uses a self-signed certificate, the user sees a security warning in
the web browser and is aware that they are communicating with an unsecure site.
When a user browses to a web site that uses a trusted certificate, the user does not see a security warning.
Details
If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced
internal CA certificate’s signature algorithm type, in addition to any configured rule conditions. Because you
associate one CA certificate with a Decrypt - Resign action, you cannot create a TLS/SSL rule that decrypts
multiple types of outgoing traffic encrypted with different signature algorithms. In addition, any external
certificate objects and cipher suites you add to the rule must match the associated CA certificate encryption
algorithm type.
For example, outgoing traffic encrypted with an elliptic curve (EC) algorithm matches a Decrypt - Resign
rule only if the action references an EC-based CA certificate; you must add EC-based external certificates
and cipher suites to the rule to create certificate and cipher suite rule conditions.
Similarly, a Decrypt - Resign rule that references an RSA-based CA certificate matches only outgoing traffic
encrypted with an RSA algorithm; outgoing traffic encrypted with an EC algorithm does not match the rule,
even if all other configured rule conditions match.
rule with a Decrypt - Resign action, when the application receives a resigned certificate from a managed
device, validation fails and the connection is aborted.
Because TLS/SSL pinning is used to avoid man-in-the-middle attacks, there is no way to prevent or work
around it. You have the following options:
• Create a Do Not Decrypt for those applications rule ordered before Decrypt - Resign rules.
• Instruct users to access the applications using a web browser.
For more information about rule ordering, see SSL Rule Order, on page 1335.
To determine whether applications are using TLS/SSL pinning, see Troubleshoot TLS/SSL Pinning, on page
1530.
Note In order to fully process traffic based on URL category, you must also configure URL filtering. See the
URL Filtering, on page 1369 chapter.
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
If the following error displays, see Verify TLS/SSL Cipher Suites, on page 1532: Traffic cannot match this rule; none
of your selected cipher suites contain a signature algorithm that the resigning CA's signature algorithm.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the SSL rule editor, from the Insert drop-down list, select Into Category, then select the category you want to use.
Step 2 Click Save.
Tip When you save the rule, it is placed last in that category.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the SSL rule editor, from the Insert drop-down list, select above rule or below rule, then type the appropriate rule
number.
Step 2 Click Save.
Tip When you save the rule, it is placed where you specified.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Each rule also has an action, which determines whether you monitor, block, or inspect matching encrypted
or decrypted traffic with access control. Note that the system does not further inspect encrypted traffic it
blocks. It does inspect encrypted and undecryptable traffic with access control. However, some access control
rule conditions require unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the
system disables intrusion and file inspection of encrypted payloads.
The following scenario summarizes the ways that SSL rules handle traffic in an inline deployment.
The system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted
before being allowed to the destination. Traffic that does not match the SSL rule continues to the next
rule.
• TLS/SSL Rule 5: Decrypt - Resign is the final rule. If traffic matches this rule, the system re-signs the
server certificate with an uploaded CA certificate, then acts as a man-in-the-middle to decrypt traffic.
The decrypted traffic is then evaluated against access control rules. Access control rules treat decrypted
and unencrypted traffic identically. The system can block traffic as a result of this additional inspection.
All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match
the SSL rule continues to the next rule.
• SSL Policy Default Action handles all traffic that does not match any of the TLS/SSL rules. The default
action either blocks encrypted traffic without further inspection or does not decrypt it, passing it for
access control inspection.
A cipher suite list containing one or more cipher suites The cipher suite used to negotiate the encrypted session matches
a cipher suite in the cipher suite list
A trusted CA object by uploading a CA certificate your The trusted CA trusts the server certificate used to encrypt the
organization trusts session, whether:
• The CA issued the certificate directly
• The CA issued a certificate to an intermediate CA that issued
the server certificate
An external certificate object by uploading a server certificate The server certificate used to encrypt the session matches the
uploaded server certificate
A distinguished name object containing a certificate subject or The subject or issuer common name, country, organization, or
issuer distinguished name organizational unit on the certificate used to encrypt the session
matches the configured distinguished name
Related Topics
Cipher Suite Lists, on page 489
Distinguished Name Objects, on page 489
PKI Objects, on page 491
Tip Proper TLS/SSL rule order reduces the resources required to process network traffic, and prevents rule
preemption. Although the rules you create are unique to every organization and deployment, there are a few
general guidelines to follow when ordering rules that can optimize performance while still addressing your
needs.
In addition to ordering rules by number, you can group rules by category. By default the system provides
three categories: Administrator, Standard, and Root. You can add custom categories, but you cannot delete
the system-provided categories or change their order.
Related Topics
Best Practices for Access Control Rules, on page 1332
Default Handling Options for Undecryptable Traffic, on page 1479
SSL Rule Order, on page 1335
Your TLS/SSL inspection configuration handles, inspects, and logs decrypted traffic:
• The SSL policy’s undecryptable actions handle traffic that the system cannot decrypt.
• The policy’s default action handles traffic that does not meet the condition of any non-Monitor TLS/SSL
rule.
You can log a connection event when the system blocks or trusts an encrypted session. You can also force
the system to log connections that it decrypts for further evaluation by access control rules, regardless of how
the system later handles or inspects the traffic. Connection logs for encrypted sessions contain details about
the encryption, such as the certificate used to encrypt that session. You can log only end-of-connection events,
however:
• For blocked connections (Block, Block with reset), the system immediately ends the sessions and generates
an event
• For trusted connections (Do not decrypt), the system generates an event when the session ends
Zones Entering or leaving a device via an interface A security zone is a logical grouping of one
in a specific security zone or more interfaces according to your
deployment and security policies. Interfaces
in a zone may be located across multiple
devices.
Note You cannot decrypt traffic on an
inline or tap mode interface.
Networks By its source or destination IP address, You can explicitly specify IP addresses.
country, or continent The geolocation feature also allows you to
control traffic based on its source or
destination country or continent.
VLAN Tags Tagged by VLAN The system uses the innermost VLAN tag
to identify a packet by VLAN.
Ports By its source or destination port You can control encrypted traffic based on
the TCP port.
Users By the user involved in the session You can control encrypted traffic based on
the LDAP user logged into a host involved
in an encrypted, monitored session. You
can control traffic based on individual users
or groups retrieved from a Microsoft Active
Directory server.
Applications By the application detected in a session You can control access to individual
applications in encrypted sessions, or filter
access according to basic characteristics:
type, risk, business relevance, and
categories.
Categories By the URL requested in the session, based You can limit the websites that users on
on the certificate subject distinguished your network can access based on the
name URL’s general classification and risk level.
Distinguished Names The URL the user enters in the browser You can control encrypted traffic based on
matches the Common Name (CN), or the the CA that issued a server certificate, or
URL is contained in the certificate's Subject the server certificate holder.
Alternative Name (SAN)
Certificates By the server certificate used to negotiate You can control encrypted traffic based on
the encrypted session the server certificate passed to the user’s
browser in order to negotiate the encrypted
session.
Certificate Status By properties of the server certificate used You can control encrypted traffic based on
to negotiate the encrypted session a server certificate’s status.
Cipher Suites By the cipher suite used to negotiate the You can control encrypted traffic based on
encrypted session the cipher suite selected by the server to
negotiate the encrypted session.
Versions By the version of SSL or TLS used to You can control encrypted traffic based on
encrypt the session the version of SSL or TLS used to encrypt
the session.
Related Topics
Network-Based TLS/SSL Rule Conditions
User-Based TLS/SSL Rule Conditions
Reputation-Based URL Blocking in Encrypted Traffic
Server Certificate-Based TLS/SSL Rule Conditions, on page 1506
ClientHello Message Handling, on page 1451
For more information, see Default Handling Options for Undecryptable Traffic, on page 1479
Tip You cannot use the Block or Block with reset action in a passive or inline (tap mode) deployment because
the device does not directly inspect the traffic. If you create a rule with the Block or Block with reset action
that contains passive or inline (tap mode) interfaces within a security zone condition, the policy editor displays
a warning ( ) next to the rule.
Step 1 In the SSL policy editor, you have the following options:
• To add a new rule, click Add Rule.
What to do next
• Configure rule conditions as discussed in Introduction to Rules, on page 403.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the SSL rule editor, select Decrypt - Resign from the Action list.
Step 2 Select an internal CA certificate object from the list.
Step 3 Check Replace Key Only .
Always check the Replace Key Only check box when you set up a Decrypt - Resign rule action.
When a user browses to a web site that uses a self-signed certificate, the user sees a security warning in the web browser
and is aware that they are communicating with an unsecure site.
When a user browses to a web site that uses a trusted certificate, the user does not see a security warning.
b) Add the CA certificate corresponding to your known key to the SSL policy.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the SSL rule editor, select Decrypt - Known Key from the Action drop-down list.
Step 2 Click the Click to select decryption certs field.
Step 3 Select one or more internal certificate objects in the Available Certificates list, then click Add to Rule.
Step 4 Click OK.
Step 5 Click Add.
Step 6 Optional. To use a Trusted CA certificate in your SSL policy so you can avoid Invalid Issuer in the SSL Certificate
Status column in connection events, add the certificate to the policy:
a) In the SSL policy editor page, click Trusted CA Certificates.
b) Add the CA certificate corresponding to your known key to the SSL policy.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
You can navigate to each previous or next matching rule. A status message displays the current match and
the total number of matches.
Matches may occur on any page of a multi-page rule list. When the first match is not on the first page, the
page where the first match occurs is displayed. Selecting the next match when you are at the last match takes
you to the first match, and selecting the previous match when you are at the first match takes you to the last
match.
Step 1 In the SSL policy editor, click the Search Rules prompt, type a search string, then press Enter.
Tip Columns for rules with matching values are highlighted, with differentiated highlighting for the indicated (first)
match.
• To refresh the page and clear the search string and any highlighting, click Clear ( ).
Step 1 In the SSL policy editor, right-click a rule and choose a rule state.
Step 2 Click Save.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Step 1 In the SSL policy editor, select the rules by clicking in a blank area for each rule.
Step 2 Right-click the rule and select Cut.
Step 3 Right-click a blank area for a rule next to where you want to paste the cut rules and select Paste above or Paste below.
Tip You cannot copy and paste TLS/SSL rules between two different SSL policies.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note When traffic matches a rule, the device applies the configured rule action to the traffic. When the connection
ends, the device logs the traffic if configured to do so.
Each rule condition allows you to specify one or more properties of traffic you want to match against; these
properties include details of:
• The flow of traffic, including the security zone through which it travels, IP address and port, country of
origin or destination, and origin or destination VLAN.
• The user associated with a detected IP address.
• The traffic payload, including the application detected in the traffic.
• The connection encryption, including the TLS/SSL protocol version and cipher suite and server certificate
used to encrypt the connection.
• The category and reputation of the URL specified in the server certificate’s distinguished name..
Related Topics
Interface Conditions, on page 408
Network Conditions, on page 410
VLAN Conditions, on page 414
User, Realm, and ISE Attribute Conditions (User Control), on page 426
Supported Domains
Any
User Roles
• Admin
• Access Admin
• Network Admin
• Session conditions in TLS/SSL rules allow you to inspect encrypted traffic based on the SSL or TLS
version used to encrypt the traffic.
To detect multiple cipher suites in a rule, the certificate issuer, or the certificate holder, you can create reusable
cipher suite list and distinguished name objects and add them to your rule. To detect the server certificate and
certain certificate statuses, you must create external certificate and external CA objects for the rule.
Note 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.
You can match against multiple subject and issuer distinguished names in a single certificate status rule
condition; only one common or distinguished name needs to match to match the rule.
If you add a distinguished name manually, it can contain the common name attribute (CN). If you add a
common name without CN=, the system prepends CN= before saving the object.
You can also add a distinguished name with one each of the following attributes, separated by commas: C,
CN, O, OU.
In a single DN condition, you can add a maximum of 50 literal values and distinguished name objects to the
Subject DNs, and 50 literal values and distinguished name objects to the Issuer DNs.
The system-provided DN object group, Cisco-Undecryptable-Sites, contains websites whose traffic the system
cannot decrypt. You can add this group to a DN condition to block or not decrypt traffic to or from these
websites, without wasting system resources attempting to decrypt that traffic. You can modify individual
entries in the group. You cannot delete the group. System updates can modify the entries on this list, but the
system preserves user changes.
The first time the system detects an encrypted session to a new server, DN data is not available for ClientHello
processing, which can result in an undecrypted first session. After the initial session, the managed device
caches data from the server Certificate message. For subsequent connections from the same client, the system
can match the ClientHello message conclusively to rules with DN conditions and process the message to
maximize decryption potential.
• To add a distinguished name object on the fly, which you can then add to the condition, click Add ( ) above the
Available DNs list.
• To search for distinguished name objects and groups to add, click the Search by name or value prompt above the
Available DNs list, then type either the name of the object, or a value in the object. The list updates as you type to
display matching objects.
Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Subject or Add to Issuer.
Tip You can also drag and drop selected objects.
Step 5 Add any literal common names or distinguished names that you want to specify manually. Click the Enter DN or CN
prompt below the Subject DNs or Issuer DNs list; then type a common name or distinguished name and click Add.
Step 6 Add or continue editing the rule.
Example
The following figure shows a distinguished name rule condition searching for certificates issued to
goodbakery.example.com or issued by goodca.example.com. Traffic encrypted with these certificates
is allowed, subject to access control.
The following figure shows a distinguished name rule condition searching for certificates issued to
badbakery.example.com and associated domains, or certificates issued by badca.example.com. Traffic
encrypted with these certificates is decrypted using a re-signed certificate.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Distinguished Name Objects, on page 489
You can choose to match against multiple certificates in a single certificate rule condition; if the certificate
used to encrypt the traffic matches any of the uploaded certificates, the encrypted traffic matches the rule.
You can add a maximum of 50 external certificate objects and external certificate object groups to the Selected
Certificates in a single certificate condition.
Note the following:
• You cannot configure a certificate condition if you also select the Decrypt - Known Key action. Because
that action requires you to select a server certificate to decrypt traffic, the implication is that the certificate
already matches the traffic.
• If you configure a certificate condition with an external certificate object, any cipher suites you add to
a cipher suite condition, or internal CA objects you associate with the Decrypt - Resign action, must
match the external certificate’s signature algorithm type. For example, if your rule’s certificate condition
references an EC-based server certificate, any cipher suites you add, or CA certificates you associate
with the Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types in
this case, the policy editor displays a warning next to the rule.
• The first time the system detects an encrypted session to a new server, certificate data is not available
for ClientHello processing, which can result in an undecrypted first session. After the initial session, the
managed device caches data from the server Certificate message. For subsequent connections from the
same client, the system can match the ClientHello message conclusively to rules with certificate conditions
and process the message to maximize decryption potential.
• To add an external certificate object on the fly, which you can then add to the condition, click Add ( ) above the
Available Certificates list.
• To search for certificate objects and groups to add, click the Search by name or value prompt above the Available
Certificates list, then type either the name of the object, or a value in the object. The list updates as you type to
display matching objects.
Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected objects.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
External Certificate Objects, on page 499
• If you're configuring a Decrypt - Resign rule, the default behavior is to decrypt traffic with an expired
certificate. To change that behavior, click No for Expired so traffic with an expired certificate is not
decrypted and resigned.
• If you're configuring a Block rule, the default behavior is to allow traffic with an expired certificate. To
change that behavior click Yes for Expired so traffic with an expired certificate is blocked.
The following table describes how the system evaluates encrypted traffic based on the encrypting server
certificate’s status.
Revoked The policy trusts the CA that issued The policy trusts the CA that issued
the server certificate, and the CA the server certificate, and the CA
certificate uploaded to the policy certificate uploaded to the policy
contains a CRL that revokes the does not contain a CRL that
server certificate. revokes the certificate.
Valid All of the following are true: At least one of the following is true:
• The policy trusts the CA that • The policy does not trust the
issued the certificate. CA that issued the certificate.
• The signature is valid. • The signature is invalid.
• The issuer is valid. • The issuer is invalid.
• None of the policy’s trusted • A trusted CA in the policy
CAs revoked the certificate. revoked the certificate.
• The current date is between • The current date is before the
the certificate Valid From and certificate Valid From date.
Valid To date.
• The current date is after the
certificate Valid To date.
Invalid issuer The issuer CA certificate is not The issuer CA certificate is stored
stored in the policy’s list of trusted in the policy’s list of trusted CA
CA certificates. certificates.
Expired The current date is after the The current date is before or on the
certificate Valid To date. certificate Valid To date.
Not yet valid The current date is before the The current date is after or on the
certificate Valid From date. certificate Valid From date.
Invalid certificate The certificate is not valid. At least The certificate is valid. All of the
one of the following is true: following are true:
• Invalid or inconsistent • Valid certificate extension.
certificate extension; that is, a
certificate extension had an • The certificate can be used for
invalid value (for example, an the specified purpose.
incorrect encoding) or some • Valid Basic Constraints path
value inconsistent with other length.
extensions.
• Valid values for Not Before
• The certificate cannot be used and Not After.
for the specified purpose.
• Valid name constraint.
• The Basic Constraints path
length parameter has been • The root certificate is trusted
exceeded. for the specified purpose.
For more information, see • The root certificate accepts the
RFC 5280, section 4.2.1.9. specified purpose.
• The certificate's value for Not
Before or Not After is invalid.
These dates can be encoded as
UTCTime or GeneralizedTime
For more information, see
RFC 5280 section 4.1.2.5.
• The format of the name
constraint is not recognized;
for example, an email address
format of a form not
mentioned in RFC 5280,
section 4.2.1.10. This could
be caused by an improper
extension or some new feature
not currently supported.
An unsupported name
constraint type was
encountered. OpenSSL
currently supports only
directory name, DNS name,
email, and URI types.
• The root certificate authority
is not trusted for the specified
purpose.
• The root certificate authority
rejects the specified purpose.
Invalid CRL The Certificate Revocation List The CRL is valid. All of the
(CRL) digital signature is not valid. following are true:
At least one of the following is true:
• Next Update and Last Update
• The value of the CRL's Next fields are valid.
Update or Last Update field is
invalid. • The CRL's date is valid.
Server mismatch The server name does not match The server name matches the SNI
the server's Server Name Indication name of the server to which the
(SNI) name, which could indicate client is requesting access.
an attempt to spoof the server
name.
Note that even though a certificate might match more than one status, the rule causes an action to be taken on
the traffic only once.
Checking whether a CA issued or revoked a certificate requires uploading root and intermediate CA certificates
and associated CRLs as objects. You then add these trusted CA objects to an SSL policy’s list of trusted CA
certificates.
• To add a trusted CA object on the fly, which you can then add to the condition, click Add ( ) above the Available
Trusted CAs list.
• To search for trusted CA objects and groups to add, click the Search by name or value prompt above the Available
Trusted CAs list, then type either the name of the object, or a value in the object. The list updates as you type to
display matching objects.
Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected objects.
What to do next
• Add a certificate status TLS/SSL rule condition to your SSL rule. See Matching Traffic on Certificate
Status, on page 1514 for more information.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Trusted Certificate Authority Objects, on page 496
Tip Upload all certificates within a root CA’s chain of trust to the list of trusted CA certificates, including the root
CA certificate and all intermediate CA certificates. Otherwise, it is more difficult to detect trusted certificates
issued by intermediate CAs. Also, if you configure certificate status conditions to trust traffic based on the
root issuer CA, all traffic within a trusted CA’s chain of trust can be allowed without decryption, rather than
unnecessarily decrypting it.
When you create an SSL policy, the system populates the Trusted CA Certificates tab with a default Trusted
CA object group, Cisco Trusted Authorities.
You can modify individual entries in the group, and choose whether to include this group in your SSL policy.
You cannot delete the group. System updates can modify the entries on this list, but user changes are preserved.
Step 1 In the Firepower Management Center, choose Policies > Access Control > SSL.
Example
The organization trusts the Verified Authority certificate authority. The organization does not trust
the Spammer Authority certificate authority. The system administrator uploads the Verified Authority
certificate and an intermediate CA certificate issued by Verified Authority to the system. Because
Verified Authority revoked a certificate it previously issued, the system administrator uploads the
CRL that Verified Authority provided.
The following figure shows a certificate status rule condition checking for valid certificates, those
issued by a Verified Authority, are not on the CRL, and still within the Valid From and Valid To
date. Because of the configuration, traffic encrypted with these certificates is not decrypted and
inspected with access control.
The following figure shows a certificate status rule condition checking for the absence of a status.
In this case, because of the configuration, it matches against traffic encrypted with a certificate that
has not expired and monitors that traffic.
The following graphic illustrates a certificate status rule condition that matches on the presence or
absence of several statuses. Because of the configuration, if the rule matches incoming traffic encrypted
with a certificate issued by an invalid user, self-signed, invalid, or expired, it decrypts the traffic with
a known key.
The following graphic illustrates a certificate status rule condition that matches if the SNI of the
request matches the server name or if the CRL is not valid. Because of the configuration, if the rule
matches either condition, traffic is blocked.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note You cannot add new cipher suites. You can neither modify nor delete predefined cipher suites.
You can add a maximum of 50 cipher suites and cipher suite lists to the Selected Cipher Suites in a single
cipher suite condition. The system supports adding the following cipher suites to a cipher suite condition:
• SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
• SSL_RSA_FIPS_WITH_DES_CBC_SHA
• TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_DHE_RSA_WITH_DES_CBC_SHA
• TLS_DH_Anon_WITH_AES_128_GCM_SHA256
• TLS_DH_Anon_WITH_AES_256_GCM_SHA384
• TLS_DH_Anon_WITH_CAMELLIA_128_CBC_SHA
• TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DH_Anon_WITH_CAMELLIA_256_CBC_SHA
• TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_NULL_SHA
• TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_NULL_SHA
• TLS_ECDHE_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_NULL_MD5
• TLS_RSA_WITH_NULL_SHA
• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA
an EC-based cipher suite, any server certificates you add, or CA certificates you associate with the
Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types in this case,
the policy editor displays a warning icon next to the rule.
• You can add an anonymous cipher suite to the Cipher Suite condition in an SSL rule, but keep in mind:
• The system automatically strips anonymous cipher suites during ClientHello processing. For the
system to use the rule, you must also configure your TLS/SSL rules in an order that prevents
ClientHello processing. For more information, see SSL Rule Order, on page 1335.
• You cannot use either the Decrypt - Resign or Decrypt - Known Key action in the rule, because
the system cannot decrypt traffic encrypted with an anonymous cipher suite.
• When specifying a cipher suite as a rule condition, consider that the rule matches on the negotiated cipher
suite in the ServerHello message, rather than on the full list of cipher suites specified in the ClientHello
message. During ClientHello processing, the managed device strips unsupported cipher suites from the
ClientHello message. However, if this results in all specified cipher suites being stripped, the system
retains the original list. If the system retains unsupported cipher suites, subsequent evaluation results in
an undecrypted session.
• To add a cipher suite list on the fly, which you can then add to the condition, click Add ( ) above the Available
Cipher Suites list.
• To search for cipher suites and lists to add, click the Search by name or value prompt above the Available Cipher
Suites list, then type either the name of the cipher suite, or a value in the cipher suite. The list updates as you type
to display matching cipher suites.
Step 3 To select a cipher suite, click it. To select all cipher suites, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected cipher suites.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Cipher Suite Lists, on page 489
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Note Use the show counters description command to see explanations for each counter. To view only counters
related to TLS crypto acceleration, use show counters description | include TLS_TRK.
Informational Counters
If a system under load is working well, you should see large counts for the following counters. Because there
are 2 sides to the tracker process per connection, you can see these counters increase by 2 per connection. The
PRIV_KEY_RECV and SECU_PARAM_RECV counters are the most important, and are highlighted. The
CONTEXT_CREATED and CONTEXT_DESTROYED counters relate to the allocation of cryptographic
chip memory.
Alert Counters
We implemented the following counters according to the TLS 1.2 specification. FATAL or BAD alerts could
indicate issues; however, ALERT_RX_CLOSE_NOTIFY is normal.
For details, see RFC 5246 section 7.2.
TLS_TRK ALERT_RX_CNT 311 Summary
TLS_TRK ALERT_TX_CNT 2 Summary
TLS_TRK ALERT_TX_IN_HANDSHAKE_CNT 2 Summary
TLS_TRK ALERT_RX_IN_HANDSHAKE_CNT 2 Summary
TLS_TRK ALERT_RX_WARNING_ALERT 308 Summary
TLS_TRK ALERT_RX_FATAL_ALERT 3 Summary
TLS_TRK ALERT_TX_FATAL_ALERT 2 Summary
TLS_TRK ALERT_RX_CLOSE_NOTIFY 308 Summary
TLS_TRK ALERT_RX_BAD_RECORD_MAC 2 Summary
TLS_TRK ALERT_TX_BAD_RECORD_MAC 2 Summary
TLS_TRK ALERT_RX_BAD_CERTIFICATE 1 Summary
Error Counters
These counters indicate system errors. These counts should be low on a healthy system. The BY_PASS
counters indicate packets that have been passed directly to or from the inspection engine (Snort) process
(which runs in software) without decryption. The following example lists some of the bad counters.
Counters with a value of 0 are not displayed. To view a complete list of counters, use the command show
counters description | include TLS_TRK
Fatal Counters
The fatal counters indicate serious errors. These counters should be at or near 0 on a healthy system. The
following example lists the fatal counters.
The RING_FULL counter is not a fatal counter, but indicates how often the system overloaded the cryptographic
chip. The ACCELERATOR_RESET counter is the number of times the TLS crypto acceleration process
failed unexpectedly, which also causes the failure of pending operations, which are the numbers you see in
ACCELERATOR_CORE_TIMEOUT and RSA_PRIVATE_DECRYPT_FAILED.
If you have persistent problems, disable TLS crypto acceleration (system support ssl-hw-offload disable or
config hwCrypto disable) and work with Cisco TAC to resolve the issues.
Note You can do additional troubleshooting using the show snort tls-offload and debug snort tls-offload commands.
Use the clear snort tls-offload command to reset the counters displayed in the show snort tls-offload command
to zero.
If the setting for Handshake Errors in the SSL policy's Undecryptable Actions is Do Not decrypt and the
associated access control policy is configured to inspect the traffic, inspection occurs; decryption does not
occur.
Step 1 If you haven't done so already, log in to the Firepower Management Center.
Step 2 Click Analysis > Connections > Events.
Step 3 Click Table View of Connection Events.
Step 4 In the table view of connection events, click x on any column to add at least the SSL Flow Flags column to the table.
The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow Messages,
SSL Policy, and SSL Rule columns to the table of connection events. (Look in the Disabled Columns section of the
dialog box.)
The columns are added in the order discussed in Connection and Security Intelligence Event Fields, on page 2447.
Step 6 If TLS/SSL oversubscription is occurring, log in to the managed device and enter any of the following commands:
Command Result
Related Topics
Using Connection and Security Intelligence Event Tables, on page 2468
Connection and Security Intelligence Event Fields, on page 2447
Information Available in Connection Event Fields, on page 2464
Event Searches, on page 2399
When a managed device with TLS crypto acceleration enabled encounters a packet that uses the TLS heartbeat
extension,the managed device takes the action specified by the setting for Decryption Errors in the SSL
policy's Undecryptable Actions:
• Block
• Block with reset
Related Topics
Troubleshoot TLS Heartbeat, on page 1528
Step 1 If you haven't done so already, log in to the Firepower Management Center.
Step 2 Click Analysis > Connection > Events.
Step 3 Click Table View of Connection Events.
Step 4 In the table view of connection events, click x on any column to add at least the SSL Flow Messages column to the table.
The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow Messages,
SSL Policy, and SSL Rule columns to the table of connection events.
The columns are added in the order discussed in Connection and Security Intelligence Event Fields, on page 2447.
Related Topics
Troubleshoot TLS Heartbeat, on page 1528
About TLS Heartbeat, on page 1527
Using Connection and Security Intelligence Event Tables, on page 2468
Connection and Security Intelligence Event Fields, on page 2447
Information Available in Connection Event Fields, on page 2464
Event Searches, on page 2399
If applications in your network use SSL pinning, see TLS/SSL Rule Guidelines and Limitations, on page 1485
Related Topics
Troubleshoot TLS/SSL Pinning, on page 1530
Step 1 If you haven't done so already, log in to the Firepower Management Center.
Step 2 Click Analysis > Connections > Events.
Step 3 Click Table View of Connection Events.
Step 4 Click x on any column to add additional columns to at least the SSL Flow Flags and SSL Flow Messages columns the
connection events table.
The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow Messages,
SSL Policy, and SSL Rule columns to the table of connection events.
The columns are added in the order discussed in Connection and Security Intelligence Event Fields, on page 2447.
What to do next
You can use TLS/SSL connection events to confirm TLS/SSL pinning is occurring by looking for any of the
following:
• Applications that send an SSL ALERT Message as soon as the client receives the SERVER_HELLO,
SERVER_CERTIFICATE, SERVER_HELLO_DONE message from the server, followed by a TCP
Reset, exhibit the following symptoms. (The alert, Unknown CA (48), can be viewed using a packet
capture.)
• The SSL Flow Flags column displays ALERT_SEEN but not APP_DATA_C2S or APP_DATA_S2C.
• If your managed device has SSL hardware acceleration enabled, the SSL Flow Messages column
typically displays: CLIENT_ALERT, CLIENT_HELLO, SERVER_HELLO,
SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE.
• If your managed device doesn't support SSL hardware acceleration or if the feature is disabled, the
SSL Flow Messages column typically displays: CLIENT_HELLO, SERVER_HELLO,
SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE.
• Success is displayed in the SSL Flow Error column.
• Applications that send no alerts but instead send TCP Reset after the SSL handshake is finished exhibit
the following symptoms:
• The SSL Flow Flags column does not display ALERT_SEEN, APP_DATA_C2S, or
APP_DATA_S2C.
• If your managed device has SSL hardware acceleration enabled, the SSL Flow Messages column
typically displays: CLIENT_HELLO, SERVER_HELLO, SERVER_CERTIFICATE,
SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE, CLIENT_KEY_EXCHANGE,
CLIENT_CHANGE_CIPHER_SPEC, CLIENT_FINISHED, SERVER_CHANGE_CIPHER_SPEC,
SERVER_FINISHED.
• If your managed device doesn't support SSL hardware acceleration or if the feature is disabled, the
SSL Flow Messages column typically displays: CLIENT_HELLO, SERVER_HELLO,
SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE,
CLIENT_KEY_EXCHANGE, CLIENT_CHANGE_CIPHER_SPEC,
CLIENT_FINISHED,SERVER_CHANGE_CIPHER_SPEC, SERVER_FINISHED.
• Success is displayed in the SSL Flow Error column.
Related Topics
Using Connection and Security Intelligence Event Tables, on page 2468
Connection and Security Intelligence Event Fields, on page 2447
Information Available in Connection Event Fields, on page 2464
Event Searches, on page 2399
The error indicates that one or more of the cipher suites you chose for the TLS/SSL rule condition are
incompatible with the certificate used in the TLS/SSL rule. To resolve the issue, you must have access to the
certificate you're using.
Note The tasks in this topic assume knowledge of how TLS/SSL encryption works.
Step 1 When you attempt to save an SSL rule with either Decrypt - Resign or Decrypt - Known Key with specified cipher
suites, the following error is displayed:
Example:
Traffic cannot match this rule; none of your selected cipher suites contain a
signature algorithm that the resigning CA's signature algorithm
Step 2 Locate the certificate you're using to decrypt traffic and, if necessary, copy the certificate to a system that can run openssl
commands.
Step 3 Run the following command to display the signature algorithm used by the certificate:
openssl x509 -in CertificateName -text -noout
The first few lines of output are displayed similar to the following:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4105 (0x1009)
Signature Algorithm: ecdsa-with-SHA256
Step 5 Search a resource such as OpenSSL at University of Utah for cipher suites that match those values. The cipher suite must
be in RFC format.
You can also search a variety of other sites, such as Server Side TLS at the Mozilla wiki or Appendix C of RFC 5246.
Cipher Suites in TLS/SSL (Schannel SSP) in Microsoft documentation has a detailed explanation of cipher suites.
Step 6 If necessary, translate the OpenSSL name to an RFC name that the Firepower Management System uses.
See the RFC mapping list on the on the https://testssl.sh site.
Step 7 The previous example, ecdsa-with-SHA256, can be found in the Modern Compatibility List on the Mozilla wiki.
a) Choose only cipher suites that have ECDSA and SHA-256 in the name. These cipher suites follow:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
b) Find the corresponding RFC cipher suite on RFC mapping list. These cipher suites follow:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
File Policies
A file policy is a set of configurations that the system uses to perform malware protection and file control, as
part of your overall access control configuration. This association ensures that before the system passes a file
in traffic that matches an access control rule’s conditions, it first inspects the file. Consider the following
diagram of a simple access control policy in an inline deployment.
The policy has two access control rules, both of which use the Allow action and are associated with file
policies. The policy’s default action is also to allow traffic, but without file policy inspection. In this scenario,
traffic is handled as follows:
• Traffic that matches Rule 1 is inspected by File Policy A.
• Traffic that does not match Rule 1 is evaluated against Rule 2. Traffic that matches Rule 2 is inspected
by File Policy B.
• Traffic that does not match either rule is allowed; you cannot associate a file policy with the default
action.
By associating different file policies with different access control rules, you have granular control over how
you identify and block files transmitted on your network.
Block or allow all files of a particular type (for example, Threat (for FTD Allow, Block, Block with
block all .exe files) devices) Reset
Protection (for
Classic devices)
Selectively allow or block files based on a judgment that Threat (for FTD Malware Cloud Lookup,
it contains or is likely to contain malware devices) Block Malware
Protection (for
Classic devices)
Malware
Store files Threat (for FTD Any file rule action with
devices) Store Files selected
Protection (for
Classic devices)
Malware
Step 6 Test your system to be sure it is processing malicious files as you expect it to.
Step 7 Set Up Maintenance and Monitoring of Malware Protection, on page 1543
What to do next
• (Optional) To further enhance detection of malware in your network, deploy and integrate Cisco's AMP
for Endpoints product. See (Optional) Malware Protection with AMP for Endpoints, on page 1570 and
subtopics.
• Understand how to investigate file and malware events.
See File/Malware Events and Network File Trajectory, on page 2521.
Step 2 Understand how file policies and malware protection fit into your access control plan.
Step 4 Determine whether you will use public clouds or private (on-premises) clouds for malware protection (file analysis and
dynamic analysis.)
See Cloud Connections for Malware Protection, on page 1543 and subtopics.
Step 5 If you will use private (on-premises) clouds for malware protection: Purchase, deploy, and test those products.
For information, contact your Cisco sales representative or authorized reseller.
Step 6 Configure your firewall to allow communications with your chosen clouds.
See Security, Internet Access, and Communication Ports, on page 2649.
Step 7 Configure connections between Firepower and the malware protection clouds (public or private).
• For the AMP cloud, see Change AMP Options, on page 1548.
• If you deployed an on-premises Cisco Threat Grid appliance, see Connect to an On-Premises Dynamic Analysis
Appliance, on page 1549. (Access to the public Threat Grid cloud does not require configuration.)
What to do next
Continue with the next step in the malware protection workflow:
See How to Configure Malware Protection, on page 1539.
What to do next
Continue with the next step in the malware protection workflow:
See How to Configure Malware Protection, on page 1539.
Step 1 Review guidelines for file policies in access control policies. (These are different from the file rule and file policy
guidelines that you looked at previously.)
Review File and Intrusion Inspection Order, on page 1327.
What to do next
Continue with the next step in the malware protection workflow:
See How to Configure Malware Protection, on page 1539.
Caution Enabling or disabling Store files in a Detect Files or Block Files rule, or adding the first or removing the last
file rule that combines the Malware Cloud Lookup or Block Malware file rule action with an analyis option
(Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files option
(Malware, Unknown, Clean, or Custom), restarts the Snort process when you deploy configuration changes,
temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without
further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior, on
page 390 for more information.
Note Inline normalization is enabled automatically when a file policy is included in an access control rule. For more
information, see The Inline Normalization Preprocessor, on page 1940.
Step 1 In the access control rule editor (from Policies > Access Control), choose an Action of Allow, Interactive Block, or
Interactive Block with reset.
Step 2 Click Inspection.
Step 3 Choose a File Policy to inspect traffic that matches the access control rule, or choose None to disable file inspection for
matching traffic.
Step 4 (Optional) Disable logging of file or malware events for matching connections by clicking Logging and unchecking Log
Files.
Note Cisco recommends that you leave file and malware event logging enabled.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Create or Edit a File Policy, on page 1555
Snort® Restart Scenarios, on page 388
Step 1 Ensure that your system always has the most current and effective protection.
See Maintain Your System: Update File Types Eligible for Dynamic Analysis, on page 1551.
What to do next
Review "What to do next items" in the malware protection workflow:
See How to Configure Malware Protection, on page 1539.
AMP Clouds
The Advanced Malware Protection (AMP) cloud is a Cisco-hosted server that uses big data analytics and
continuous analysis to provide intelligence that the system uses to detect and block malware on your network.
The AMP cloud provides dispositions for possible malware detected in network traffic by managed devices,
as well as data updates for local malware analysis and file pre-classification.
If your organization has deployed AMP for Endpoints and configured Firepower to import its data, the system
imports this data from the AMP cloud, including scan records, malware detections, quarantines, and indications
of compromise (IOC).
Cisco offers the following options for obtaining data from the Cisco cloud about known malware threats:
• AMP public cloud
Your Firepower Management Center communicates directly with the public Cisco cloud. There are three
public AMP clouds, in the United States, Europe, and Asia.
• An AMP private cloud
An AMP private cloud is deployed on your network and acts as a compressed, on-premises AMP cloud,
as well as an anonymized proxy to connect to the public AMP cloud. For details, see Cisco AMP Private
Cloud, on page 1546.
If you integrate with AMP for Endpoints, the AMP private cloud has some limitations. See AMP for
Endpoints and AMP Private Cloud, on page 1572.
What to do next
• If your deployment is a high-availability configuration, see Requirements and Best Practices for AMP
Cloud Connections, on page 1545.
• (Optional) Change AMP Options, on page 1548.
Note The AMP private cloud does not perform dynamic analysis, nor does it support anonymized retrieval of threat
intelligence for other features that rely on Cisco Collective Security Intelligence (CSI), such as URL and
Security Intelligence filtering.
For information about AMP private cloud (sometimes referred to as "AMPv"), see https://www.cisco.com/c/
en/us/products/security/fireamp-private-cloud-virtual-appliance/index.html.
Step 5 In the Host field, enter the private cloud host name that you configured when you set up the private cloud.
Step 6 Click Browse next to the Certificate Upload Path field to browse to the location of a valid TLS or SSL encryption
certificate for the private cloud. For more information, see the AMP private cloud documentation.
Step 7 If you want to use this private cloud for both AMP for Networks and AMP for Endpoints, select the Use for AMP for
Firepower check box.
If you configured a different private cloud to handle AMP for Networks communications, you can clear this check box;
if this is your only AMP private cloud connection, you cannot.
In a multidomain deployment, this check box appears only in the Global domain. Each Firepower Management Center
can have only one AMP for Networks connection.
Step 8 To communicate with the AMP private cloud using a proxy, check the Use Proxy for Connection check box.
Step 9 Click Register, confirm that you want to disable existing direct connections to the AMP cloud, and finally confirm
that you want to continue to the AMP private cloud management console to complete registration.
Step 10 Log into the management console and complete the registration process. For further instructions, see the AMP private
cloud documentation.
What to do next
In high availability configurations, you must configure AMP cloud connections independently on the Active
and Standby instances of the Firepower Management Center; these configurations are not synchronized.
Caution For disabled connections, the public or private AMP cloud can store malware events, indications of compromise,
and so on until you re-enable the connection. In rare cases—for example, with a very high event rate or a
long-term disabled connection—the cloud may not be able to store all information generated while the
connection is disabled.
In a multidomain deployment, the system displays connections created in the current domain, which you can
manage. It also displays connections created in ancestor domains, which you cannot manage. To manage
connections in a lower domain, switch to that domain. Each Firepower Management Center can have only
one AMP for Networks connection, which belongs to the Global domain.
What to do next
In high availability configurations, you must configure AMP cloud connections independently on the Active
and Standby instances of the Firepower Management Center; these configurations are not synchronized.
Option Description
Enable Automatic Local Malware Detection The local malware detection engine statically analyzes and preclassifies
Updates files using signatures provided by Cisco. If you enable this option, the
Firepower Management Center checks for signature updates once every
30 minutes.
Share URI from Malware Events with Cisco The system can send information about the files detected in network traffic
to the AMP cloud. This information includes URI information associated
with detected files and their SHA-256 hash values. Although sharing is
opt-in, transmitting this information to Cisco helps future efforts to identify
and track malware.
Use Legacy Port 32137 for AMP for By default, Firepower uses port 443/HTTPS to communicate with the
Networks AMP public or private cloud to obtain file disposition data. This option
allows the system to use port 32137.
If you updated from a previous version of the system, this option may be
enabled.
This option will be greyed out if the FMC is configured with Proxy
settings.
• If you want to connect to the on-premises appliance using a proxy, configure the proxy; see Modify FMC
Management Interfaces, on page 1102.
• Managed devices must have direct or proxied access to the Cisco Threat Grid appliance on port 443.
Step 6 If you want to use a configured proxy to establish the connection, select Use Proxy When Available.
Step 7 Click Register.
Step 8 Click Yes to display the on-premises Cisco Threat Grid appliance login page.
Step 9 Enter your username and password to the on-premises Cisco Threat Grid appliance.
Step 10 Click Sign in.
Step 11 You have the following options:
• If you previously registered the Firepower Management Center to the on-premises appliance, click Return.
• If you did not register the Firepower Management Center, click Activate.
Step 2 Click Associate ( ) in the table row corresponding to the Cisco Threat Grid public cloud.
A Cisco Threat Grid portal window opens.
If you have difficulties with this process, contact your Cisco Threat Grid representative at Cisco TAC.
It may take up to 24 hours for this change to take effect.
What to do next
After the association is activated, see Viewing Dynamic Analysis Results in the Cisco Threat Grid Public
Cloud, on page 2541.
Maintain Your System: Update File Types Eligible for Dynamic Analysis
The list of file types eligible for Dynamic Analysis is determined by the vulnerability database (VDB), which
is updated periodically (but no more than once per day.) If you are an Admin user, you can update file types
eligible for dynamic analysis.
To ensure that your system has the current list:
If you choose this option, we recommend that you schedule regular reminders to do this.
Step 2 If your file policies specify individual file types instead of the Dynamic Analysis Capable file type category, update
your file policies to use the newly supported file types.
Step 3 If the list of eligible file types changes, deploy to managed devices.
• If a file matches a rule with an application protocol condition, file event generation occurs after the
system successfully identifies a file’s application protocol. Unidentified files do not generate file events.
• FTP transfers commands and data over different channels. In a passive or inline tap mode deployment,
the traffic from an FTP data session and its control session may not be load-balanced to the same internal
resource.
• If the total number of bytes for all file names for files in a POP3, POP, SMTP, or IMAP session exceeds
1024, file events from the session may not reflect the correct file names for files that were detected after
the file name buffer filled.
• When transmitting text-based files over SMTP, some mail clients convert newlines to the CRLF newline
character standard. Since Mac-based hosts use the carriage return (CR) character and Unix/Linux-based
hosts use the line feed (LF) character, newline conversion by the mail client can modify the size of the
file. Note that some mail clients default to newline conversion when processing an unrecognizable file
type.
• To detect ISO files, set the "Limit the number of bytes inspected when doing file type detection" option
to a value greater than 36870, as described in File and Malware Inspection Performance and Storage
Options, on page 1577.
• .Exe files inside some .rar archives cannot be detected, including possibly rar5.
• In a cluster environment, if an existing SMB session is moved to a new device due to a cluster role change
or a device failure, then the files in any ongoing file transfers may not be inspected.
• Some SMB file transfers between Microsoft Windows systems use very high TCP window size for quick
file transfers. To detect or block such file transfers, it is recommended that you increase the value of
Maximum Queued Bytes and Maximum Queued Segments under Network Analysis Policy > TCP
Stream Configuration > Troubleshooting Options.
• If you configure Firepower Threat Defense high availability, and failover occurs while the original active
device is identifying the file, the file type is not synced. Even if your file policy blocks that file type, the
new active device downloads the file.
Supported Domains
Any
User Roles
• Admin
• Access Admin
Step 1 Select Policies > Access Control > Malware & File .
Step 2 Create a new policy, or edit an existing policy.
If you are editing an existing policy: If View ( ) appears instead, the configuration belongs to an ancestor domain, or
you do not have permission to modify the configuration.
Tip
To make a copy of an existing file policy, click Copy ( ), then type a unique name for the new policy in the
dialog box that appears. You can then modify the copy.
Step 3 Add one or more rules to the file policy as described in Creating File Rules, on page 1568.
Step 4 Optionally, select Advanced and configure advanced options as described in Advanced and Archive File Inspection
Options, on page 1555.
Step 5 Save the file policy.
What to do next
• If you are configuring policies for malware protection, see other required procedures in Configure File
Policies, on page 1540.
• Otherwise:
• Add the file policy to an access control rule as described in Add File Policies to Your Access Control
Configuration, on page 1541.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
• If you set a threshold threat score, files with an AMP cloud verdict of Unknown are considered
malware if their Dynamic Analysis score is equal to or worse than the threshold.
• If you select a lower threshold value, you increase the number of files treated as malware. Depending
on the action selected in your file policy, this can result in an increase of blocked files.
• For numeric threat score ranges, see Threat Scores and Dynamic Analysis Summary Reports, on
page 2541.
The Advanced Settings in the file policy editor has the following archive file inspection options:
• Inspect Archives—Enables inspection of the contents of archive files, for archive files as large as the
Maximum file size to store advanced access control setting.
• Block Encrypted Archives—Blocks archive files that have encrypted contents.
• Block Uninspectable Archives—Blocks archive files with contents that the system is unable to inspect
for reasons other than encryption. This usually applies to corrupted files, or those that exceed your
specified maximum archive depth.
• Max Archive Depth—Blocks nested archive files that exceed the specified depth. The top-level archive
file is not considered in this count; depth begins at 1 with the first nested file .
Archive Files
Archive files are files that contain other files, such as .zip or .rar files.
If any individual file in an archive matches a file rule with a block action, the system blocks the entire archive,
not just the individual file.
For details about options for archive file inspection, see Advanced and Archive File Inspection Options, on
page 1555.
If you choose not to block files that exceed the maximum archive file depth of 3, when archive files that
contain some extractable contents and some contents nested at a depth of 3 or greater appear in monitored
traffic, the system examines and reports data only for the files it was able to inspect.
All features applicable to uncompressed files (such as dynamic analysis and file storage) are available
for nested files inside archive files.
• Encrypted files
You can configure the system to block archives whose contents are encrypted or otherwise cannot be
inspected.
• Archives that are not inspected
If traffic that contains an archive file is on a Security Intelligence Block list or Allow list, or if the top-level
archive file’s SHA-256 value is on the custom detection list, the system does not inspect the contents of
the archive file.
If a nested file is blocked, the entire archive is blocked; however, if a nested file is allowed, the archive
is not automatically passed (depending on any other nested files and characteristics).
.Exe files inside some .rar archives cannot be detected, including possibly rar5.
Archive File Disposition Number of Unknown Files Number of Clean Files Number of Malware Files
Clean 0 1 or more 0
Archive files, like other files, may have dispositions of Custom Detection or Unavailable if the conditions
for those dispositions apply.
On subsequent detection, the device either allows or blocks the file without reevaluating the file's disposition.
You can use the clean list or custom detection list per file policy.
Note To calculate a file's SHA-256 value, you must configure a rule in the file policy to either perform a malware
cloud lookup or block malware on matching files.
For complete information about using file lists in Firepower, see File Lists, on page 484.
Alternatively, if applicable, use Centralized File Lists from AMP for Endpoints, on page 1558.
To create and deploy these lists, see the documentation or online help for AMP for Endpoints.
Note File lists created in Firepower override file lists created in AMP for Endpoints.
Note The system checks for updates to the list of file types eligible for dynamic analysis (no more than once a day).
If the list of eligible file types changes, this constitutes a change in the file policy; any access control policy
using the file policy is marked out-of-date if deployed to any devices. You must deploy policies before the
updated file policy can take effect on the device. See Maintain Your System: Update File Types Eligible for
Dynamic Analysis, on page 1551.
Step 1 Select Policies > Access Control > Malware & File .
Step 2 Manage your file policies:
• Compare—Click Compare Policies; see Comparing Policies, on page 394.
• Create — To create a file policy, click New File Policy and proceed as described in Create or Edit a File Policy, on
page 1555.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to
modify the configuration.
• Delete — If you want to delete a file policy, click Delete ( ), then click Yes and OK as prompted.
If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission to modify
the configuration.
• Deploy—Choose Deploy > Deployment; see Deploy Configuration Changes, on page 385.
File Rules
A file policy, like its parent access control policy, contains rules that determine how the system handles files
that match the conditions of each rule. You can configure separate file rules to take different actions for
different file types, application protocols, or directions of transfer.
For example, when a file matches a rule, the rule can:
• allow or block files based on simple file type matching
• block files based on disposition (whether or not evaluation indicates that it is malicious)
• store files to the device (For information, see Captured Files and File Storage, on page 1566)
• submit stored (captured) files for local malware, Spero, or dynamic analysis
• automatically treat a file as if it is clean or malware based on entries in the clean list or custom detection
list
• treat a file as if it is malware if the file’s threat score exceeds a configurable threshold
• inspect the contents of archive files (such as .zip or .rar)
• block archive files whose contents are encrypted, nested beyond a specified maximum archive depth, or
otherwise uninspectable
application protocol The system can detect and inspect files transmitted via FTP,
HTTP, SMTP, IMAP, POP3, and NetBIOS-ssn (SMB). Any, the
default, detects files in HTTP, SMTP, IMAP, POP3, FTP, and
NetBIOS-ssn (SMB) traffic. To improve performance, you can
restrict file detection to only one of those application protocols
on a per-file rule basis.
direction of transfer You can inspect incoming FTP, HTTP, IMAP, POP3, and
NetBIOS-ssn (SMB) traffic for downloaded files; you can inspect
outgoing FTP, HTTP, SMTP, and NetBIOS-ssn (SMB) traffic
for uploaded files.
Tip Use Any to detect files over multiple application
protocols, regardless of whether users are sending or
receiving.
file categories and types The system can detect various types of files. These file types are
grouped into basic categories, including multimedia (swf, mp3),
executables (exe, torrent), and PDFs. You can configure file rules
that detect individual file types, or on entire categories of file
types.
For example, you could block all multimedia files, or just
ShockWave Flash (swf) files. Or, you could configure the system
to alert you when a user downloads a BitTorrent (torrent) file.
Note that executables include file types that can run macros and
scripts, since these can contain malware.
For a list of file types the system can inspect, select Policies >
Access Control > Malware & File, create a temporary new file
policy, then click Add Rule. Select a file type category and the
file types that the system can inspect appear in the File Types
list.
Note Frequently triggered file rules can affect system
performance. For example, detecting multimedia files
in HTTP traffic (YouTube, for example, transmits
significant Flash content) could generate an
overwhelming number of events.
file rule action A file rule’s action determines how the system handles traffic that
matches the conditions of the rule.
Depending on the selected action, you can configure whether the
system stores the file or performs Spero, local malware, or
dynamic analysis on a file. If you select a Block action, you can
also configure whether the system also resets the blocked
connection.
For descriptions of these actions and options, see File Rule
Actions, on page 1561.
File rules are evaluated in rule-action, not numerical, order. For
details, see File Rule Actions: Evaluation Order, on page 1568.
• Block Files rules allow you to block specific file types. You can configure options to reset the connection
when a file transfer is blocked, and store captured files to the managed device.
• Malware Cloud Lookup rules allow you to obtain and log the disposition of files traversing your network,
while still allowing their transmission.
• Block Malware rules allow you to calculate the SHA-256 hash value of specific file types, query the
AMP cloud to determine if files traversing your network contain malware, then block files that represent
threats.
File Rule Action Block Files Block Malware Detect Files Malware Cloud
Option capable? capable? capable? Lookup capable?
Spero Analysis* for no yes, you can submit no yes, you can submit
MSEXE executable files executable files
Dynamic Analysis* no yes, you can submit no yes, you can submit
executable files with executable files with
Unknown file Unknown file
dispositions dispositions
Store files yes, you can store all yes, you can store yes, you can store all yes, you can store
matching file types file types matching matching file types file types matching
the file dispositions the file dispositions
you select you select
* For complete information about these options, see Malware Protection Options (in File Rule Actions), on
page 1562 and its subtopics.
Caution Enabling or disabling Store files in a Detect Files or Block Files rule, or adding the first or removing the last
file rule that combines the Malware Cloud Lookup or Block Malware file rule action with an analysis option
(Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files option
(Malware, Unknown, Clean, or Custom), restarts the Snort process when you deploy configuration changes,
temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without
further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior, on
page 390 for more information.
Depending on the options you enable in a file rule, the system inspects files using the following tools, in order:
1. Spero Analysis, on page 1564 and AMP Cloud Lookup, on page 1565
2. Local Malware Analysis, on page 1565
3. Dynamic Analysis, on page 1565
For a comparison of these tools, see Comparison of Malware Protection Options, on page 1563.
(You can also, if you choose, block all files based on their file type. For more information, see Block All Files
by Type, on page 1568.)
See also information about Cisco's AMP for Endpoints product at (Optional) Malware Protection with AMP
for Endpoints, on page 1570 and subtopics.
Spero analysis Structural analysis of Less thorough than Disposition changes from
executable files, local malware analysis Unknown to Malware only on
submits Spero signature or dynamic analysis, positive identification of
to the AMP Cloud for only for executable files malware.
analysis
Local malware analysis Consumes fewer Less thorough results Disposition changes from
resources than dynamic than dynamic analysis Unknown to Malware only on
analysis, and returns positive identification of
results more quickly, malware.
especially if the
detected malware is
common
Dynamic analysis Thorough analysis of Eligible files are Threat score determines
unknown files using uploaded to the public maliciousness of a file.
Cisco Threat Grid cloud or an on-premises Disposition can be based on the
appliance. It takes some threat score threshold configured
time to complete in the file policy.
analysis
Spero analysis and local Consumes fewer Less thorough than Disposition changes from
malware analysis resources than dynamic analysis, Spero Unknown to Malware only on
configuring local analysis only for positive identification of
malware analysis and executable files malware.
dynamic analysis, while
still using AMP cloud
resources to identify
malware
Spero analysis and Uses full capabilities of Results obtained less Threat score changes based on
dynamic analysis AMP cloud in quickly than if using dynamic analysis results for files
submitting files and local malware analysis preclassified as possible
Spero signatures malware. Disposition changes
based on configured threat score
threshold in the file policy, and
from Unknown to Malware if
the Spero analysis identifies
malware.
Local malware analysis Thorough results in Consumes more Threat score changes based on
and dynamic analysis using both types of file resources than either dynamic analysis results for files
analysis alone preclassified as possible
malware. Disposition changes
from Unknown to Malware if
local malware analysis identifies
malware, or based on configured
threat score threshold in the file
policy.
Spero analysis, local Most thorough results Consumes most Threat score changes based on
malware analysis and resources in running all dynamic analysis results for files
dynamic analysis three types of file preclassified as possible
analysis malware. Disposition changes
from Unknown to Malware if
Spero analysis or local malware
analysis identifies malware, or
based on configured threat score
threshold in the file policy.
(Block transmission of Does not require a Legitimate files will (No analysis is performed.)
all files of a specified Malware license also be blocked
file type)
(This option is not
technically a malware
protection option.)
Note Preclassification does not itself determine a file's disposition; it is merely one of the factors that determine
whether a file is eligible for Dynamic Analysis.
Spero Analysis
Spero analysis examines structural characteristics such as metadata and header information in executable files.
After generating a Spero signature based on this information, if the file is an eligible executable file, the device
submits it to the Spero heuristic engine in the AMP cloud. Based on the Spero signature, the Spero engine
determines whether the file is malware. You can also configure rules to submit files for Spero analysis without
also submitting them to the AMP cloud.
Note that you cannot manually submit files for Spero analysis.
If a query against the cache identifies a cached disposition that timed out, the system re-queries the local
malware analysis database and the AMP cloud for a new disposition.
Dynamic Analysis
You can configure your file policy to automatically submit files for dynamic analysis using Cisco Threat Grid
(formerly AMP Threat Grid), Cisco’s file analysis and threat intelligence platform.
Devices submit eligible files to Cisco Threat Grid (either the public cloud or to an on-premises appliance,
whichever you have specified) regardless of whether the device stores the file.
Cisco Threat Grid runs the file in a sandbox environment, analyzes the file's behavior to determine whether
the file is malicious, and returns a threat score that indicates the likelihood that a file contains malware. From
the threat score, you can view a dynamic analysis summary report with the reasons for the assigned threat
score. You can also look in Cisco Threat Grid to view detailed reports for files that your organization submitted,
as well as scrubbed reports with limited data for files that your organization did not submit.
For more information about Cisco Cisco Threat Grid, see https://www.cisco.com/c/en/us/products/security/
threat-grid/index.html
To configure your system to perform dynamic analysis, see the topics under Dynamic Analysis Connections,
on page 1549.
Additionally:
• The system submits only files that match the file rules you configure.
• The file must have a malware cloud lookup disposition of Unknown or Unavailable at the time the file
is sent for analysis.
• The system must preclassify the file as potential malware.
Note that once a device stores a file, it will not re-capture it if the file is detected in the future and the device
still has that file stored.
Note When a file is detected for the first time on your network, you can generate a file event that represents the
file’s detection. However, if your file rule performs a malware cloud lookup, the system requires additional
time to query the AMP cloud and return a disposition. Due to this delay, the system cannot store this file until
the second time it is seen on your network, and the system can immediately determine the file’s disposition.
You configure file rules in a file policy to capture and store files of a specific type, or with a particular file
disposition, if available. After you associate the file policy with an access control policy and deploy it to your
devices, matching files in traffic are captured and stored. You can also limit the minimum and maximum file
sizes to store.
Stored files are not included in system backups.
You can view captured file information under Analysis > Files > Captured Files, and download a copy for
offline analysis.
Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device. Installing an unsupported
hard drive may damage the device. Malware storage pack kits are available for purchase only from Cisco.
Contact Support if you require assistance with the malware storage pack. See the Firepower System Malware
Storage Pack Guide for more information.
Without a malware storage pack installed, when you configure a device to store files, it allocates a set portion
of the primary hard drive’s space to captured file storage. If you configure capacity handling to temporarily
store files for dynamic analysis, the system uses the same hard drive allocation to store these files until it can
resubmit them to the cloud.
When you install a malware storage pack in a device and configure file storage or capacity handling, the
device allocates the entire malware storage pack for storing these files. The device cannot store any other
information on the malware storage pack.
When the allocated space for captured file storage fills to capacity, the system deletes the oldest stored files
until the allocated space reaches a system-defined threshold. Based on the number of files stored, you may
see a substantial drop in disk usage after the system deletes files.
If a device has already stored files when you install a malware storage pack, the next time you restart the
device, any captured files or capacity handling files stored on the primary hard drive are moved to the malware
storage pack. Any future files the device stores are stored to the malware storage pack.
If configured, TID also impacts action prioritization. For more information, see TID-Firepower Management
Center Action Prioritization, on page 1604.
Caution Enabling or disabling Store files in a Detect Files or Block Files rule, or adding the first or removing the last
file rule that combines the Malware Cloud Lookup or Block Malware file rule action with an analyis option
(Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files option
(Malware, Unknown, Clean, or Custom), restarts the Snort process when you deploy configuration changes,
temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without
further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior, on
page 390 for more information.
Tip Hover your pointer over a file type to view its description.
Step 4 Select a file rule Action as described in File Rule Actions, on page 1561, with consideration for File Rule Actions: Evaluation
Order, on page 1568.
The actions available to you depend on the licenses you have installed. See License Requirements for File and Malware
Policies, on page 1538.
* For information about these options, see File Rule Actions, on page 1561 and Malware Protection Options (in File Rule
Actions), on page 1562 and its subtopics.
What to do next
• If you are configuring policies for malware protection, return to Configure File Policies, on page 1540.
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
File type detection and blocking method In network traffic, using access control and Not supported
(file control) file policies
Malware detection and blocking method In network traffic, using access control and On individual endpoints (end-user
file policies computers and mobile devices), using a
connector that communicates with the AMP
cloud
Network traffic inspected Traffic passing through a managed device None; connectors installed on endpoints
directly inspect files
Malware intelligence data source AMP cloud (public or private) AMP cloud (public or private)
Malware analysis choices FMC-based, plus analysis in the AMP cloud FMC-based, plus additional options on the
AMP for Endpoints management console
Malware mitigation Malware blocking in network traffic, AMP for Endpoints-based quarantine and
FMC-initiated remediations outbreak control options, FMC-initiated
remediations
Events generated File events, captured files, malware events, Malware events
and retrospective malware events
Information in malware events Basic malware event information, plus In-depth malware event information; no
connection data (IP address, port, and connection data
application protocol)
Network file trajectory FMC-based FMC and the AMP for Endpoints
management console each have a network
file trajectory. Both are useful.
Required licenses or subscriptions Licenses required to perform file control AMP for Endpoints subscription. No license
and AMP for Networks is required to bring AMP for Endpoints data
into FMC.
Important If you use a Cisco AMP Private Cloud, see limitations at AMP for Endpoints and AMP Private Cloud, on
page 1572.
You can configure multiple private clouds to support the capacity you require.
Caution In a multidomain deployment, configure AMP for Endpoints connections at the leaf level only, especially if
your leaf domains have overlapping IP space. If multiple subdomains have hosts with the same IP-MAC
address pair, the system could save malware events that are generated by AMP for Endpoints to the wrong
leaf domain, or associate IOCs with the wrong hosts.
However, you can configure AMP for Endpoints connections at any domain level, provided you use a separate
AMP for Endpoints account for each connection. For example, each client of an MSSP might have its own
AMP for Endpoints deployment.
Note An AMP for Endpoints connection that has not registered successfully does not affect AMP for Networks.
Step 4 If you want to use this cloud for both AMP for Networks and AMP for Endpoints, select the Use for AMP for Firepower
check box.
If you configured a different cloud to handle AMP for Networks (AMP for Firepower) communications, you can clear
this check box; if this is your only AMP cloud connection, you cannot.
In a multidomain deployment, this check box appears only in the Global domain. Each Firepower Management Center
can have only one AMP for Networks connection.
Step 6 Confirm that you want to continue to the AMP for Endpoints management console, then log into the management
console.
Step 7 Using the management console, authorize the AMP cloud to send AMP for Endpoints data to the Firepower Management
Center.
Step 8 If you want to restrict the data that the FMC receives, select specific groups within your organization for which you
want to receive information.
By default, the AMP cloud sends data for all groups. To manage groups, choose Management > Groups on the AMP
for Endpoints management console. For detailed information, see the management console online help.
Step 9 Click Allow to enable the connection and start the transfer of data.
Clicking Deny returns you to the Firepower Management Center, where the connection is marked as denied. If you
navigate away from the Applications page on the AMP for Endpoints management console, and neither deny nor allow
the connection, the connection is marked as pending on the Firepower Management Center’s web interface. The health
monitor does not alert you of a failed connection in either of these situations. If you want to connect to the AMP cloud
later, delete the failed or pending connection, then recreate it.
Incomplete registration of an AMP for Endpoints connection does not disable the AMP for Networks connection.
What to do next
• In the AMP for Endpoints console window, configure settings as needed. For example, define group
membership for your management center and assign policies. For information, see the AMP for Endpoints
online help or other documentation.
• In high availability configurations, you must configure AMP cloud connections independently on the
Active and Standby instances of the Firepower Management Center; these configurations are not
synchronized.
• The default health policy warns you if the Firepower Management Center cannot connect to the AMP
for Endpoints portal after an initial successful connection, or if the connection is deregistered using the
AMP portal.
Verify that the AMP for Endpoints Status monitor is enabled under System > Health > Policy.
Chapter restructure Changes were made in 6.4 timeframe, but Restructured this chapter's content to reduce
will appear in any version that is confusion.
republished
Some content was moved to or from the
chapter for File/Malware Events and
Network File Trajectory, on page 2521.
Moved URL Filtering information to the 6.3 Moved information about configuring cloud
new URL Filtering chapter communications for URL Filtering to the
new URL Filtering chapter. Made related
changes to the structure of the Cisco CSI
topics in the chapter.
Table 115: Advanced Access Control File and AMP for Networks Options
Limit the number of bytes Specifies the number of bytes inspected 0 - 4294967295 (4GB)
inspected when doing file when performing file type detection.
0 removes the restriction.
type detection
The default value is the maximum segment size of a TCP
packet (1460 bytes). In most cases, the system can identify
common file types using the first packet.
To detect ISO files, enter a value greater than 36870.
Allow file if cloud lookup Specifies how long the system will hold the 0 - 30 seconds
for Block Malware takes last byte of a file that matches a Block
Do not set this option to 0 without contacting Support.
longer than (seconds) Malware rule and that does not have a
cached disposition, while malware cloud Cisco recommends that you use the default value to avoid
lookup occurs. If the time elapses without blocking traffic because of connection failures.
the system obtaining a disposition, the file
passes. Dispositions of Unavailable are not
cached.
Do not calculate SHA-256 Prevents the system from storing files larger 0 - 4294967295 (4GB)
hash values for files larger than a certain size, performing a malware
0 removes the restriction.
than (in bytes) cloud lookup on the files, or blocking the
files if added to the custom detection list. This value must be greater than or equal to Maximum file
size to store (bytes) and Maximum file size for dynamic
analysis testing (bytes).
Minimum file size for Specifies the minimum file size the system 0 -10485760 (10MB)
dynamic analysis testing can submit to the AMP cloud for dynamic
Must be less than or equal to Maximum file size for
(bytes) analysis.
dynamic analysis testing (bytes) and Do not calculate
SHA-256 hash values for files larger than (in bytes).
The file size for dynamic analysis must be within the limits
defined by the minimum and maximum settings for file
analysis.
The system checks the AMP cloud for updates to the
minimum file size you can submit (no more than once a
day). If the new minimum size is larger than your current
value, your current value is updated to the new minimum,
and your policy is marked out-of-date.
Maximum file size for Specifies the maximum file size the system 0 -10485760 (10MB)
dynamic analysis testing can submit to the AMP cloud for dynamic
Must be greater than or equal to Minimum file size for
(bytes) analysis.
dynamic analysis testing (bytes), and less than or equal
to Do not calculate SHA-256 hash values for files larger
than (in bytes).
The file size for dynamic analysis must be within the limits
defined by the minimum and maximum settings for file
analysis.
The system checks the AMP cloud for updates to the
maximum file size you can submit (no more than once a
day). If the new maximum size is smaller than your current
value, your current value is updated to the new maximum,
and your policy is marked out-of-date.
If View ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify
the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 Set any of the options described in File and Malware Inspection Performance and Storage Options, on page 1577.
Step 4 Click OK.
Step 5 Click Save to save the policy.
What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 385.
Related Topics
Snort® Restart Scenarios, on page 388
After the observables are published to the elements, the elements monitor traffic and report observations to
the Firepower Management Center when the system identifies observables in traffic.
The Firepower Management Center collects observations from all elements, evaluates the observations against
TID indicators, and generates or updates incidents associated with the observable's parent indicator(s).
An incident is fully realized when an indicator's pattern is fulfilled. An incident is partially realized if traffic
matches one or more observables in the indicator but not the entire pattern. For more information, see
Observation and Incident Generation, on page 1596.
The following diagram shows data flow in a sample Firepower System configuration.
Figure 69: Firepower Management Center Data Flow
When a TID incident is fully or partially realized, the system takes the configured action (monitor, block,
partially block, or no action). For details, see Factors That Affect the Action Taken, on page 1603.
For information about what the system does when either Security Intelligence or TID could handle a particular
incident, see TID-Firepower Management Center Action Prioritization, on page 1604.
Managed Device
There is no exceptional performance impact. TID impacts performance identically to the Firepower Management
Center Security Intelligence feature.
RequirementsandPrerequisitesforThreatIntelligenceDirector
Model Support
Any
Supported Domains
Any
User Roles
Admin
Threat Intelligence Director (TID) User
Additional Requirements
The following topics explain additional requirements for using Threat Intelligence Director.
Elements
You can use any Firepower Management Center-managed device as a TID element if the device is running
Version 6.2.2 or later of the Firepower System.
Licensing
If you want to configure file policies for SHA-256 observable publishing, the Firepower System requires a
Malware license (Classic or Smart).
For more information, see Configure Policies to Support TID, on page 1589 and About Firepower Licenses, on
page 89.
Source Requirements
Source Type Requirements:
STIX
Files must be STIX Version 1.0, 1.1, 1.1.1, or 1.2 and adhere to the guidelines in the STIX documentation:
http://stixproject.github.io/documentation/suggested-practices/.
STIX files can include complex indicators.
The maximum size for a STIX file is 40MB when configured via URL download or file upload. If you have
STIX files larger than this, we recommend using a TAXII server.
Flat File
Files must be ASCII text files with one observable value per line.
Flat files include only simple indicators (one observable per indicator.)
Flat files can be up to 500 MB.
TID does not support:
• Delimiter characters separating observable values (e.g. observable, is invalid).
• Enclosing characters around observable values (e.g. "observable" is invalid).
Note TID normalizes any URLs that contain port, protocol, or authentication
information, and uses the normalized version when detecting indicators. For
example, TID normalizes any of the following URLs:
http://google.com/index.htm
http://google.com:8080/index.htm
google.com:8080/index.htm
google.com/index.htm
as:
google.com/index.htm
http://[email protected]:8080/index.htm
as
[email protected]/index.htm/
Note If you encounter an issue during TID configuration or operation, see Troubleshoot Cisco Threat Intelligence
Director (TID), on page 1620.
Step 1 Ensure that your installation meets the requirements for running TID.
See Platform, Element, and License Requirements, on page 1586
Step 2 For each managed device, configure the policies required to support TID and deploy those policies to the devices.
See Configure Policies to Support TID, on page 1589.
You can configure elements before or after you ingest intelligence data sources.
Step 3 Configure the intelligence sources that you want TID to ingest.
See Source Requirements, on page 1587 and the topics under Options for Ingesting Data Sources, on page 1590.
Step 4 Publish data to the elements if you have not yet done so. See Pause or Publish TID Data at the Source, Indicator, or
Observable Level, on page 1618.
What to do next
• Include TID in your regularly scheduled backups. See About Backing Up and Restoring TID Data, on
page 1595.
If your Firepower Management Center deployment is a high availability configuration, see also Cisco
Threat Intelligence Director (TID) and High Availability Configurations, on page 235.
• (Optional) Grant administrative access to TID functionality as desired. See User Roles with TID Access,
on page 1595 and User Accounts for FMC, on page 41.
• As needed during operation, fine-tune your configuration. For example, add observables that produce
false-positive incidents to the Allow list. See View and Change Cisco Threat Intelligence Director (TID)
Configurations, on page 1607.
Step 1 Verify that the Enable Threat Intelligence Director check box is checked in Advanced Settings of the access control
policy. This option is enabled by default.
For more information, see Access Control Policy Advanced Settings, on page 1349.
Step 2 Add rules to the access control policy if they are not already present. TID requires that the access control policy specify
at least one rule.
For more information, see Creating a Basic Access Control Policy, on page 1343.
Step 3 If you choose Intrusion Prevention as the default action for the access control policy and you want to decrypt traffic
for TID detection, associate an SSL policy with the access control policy; see Associating Other Policies with Access
Control, on page 1352.
Step 4 If you want SHA-256 observables to generate observations and Firepower Management Center events:
a) Create a file policy containing one or more Malware Cloud Lookup or Block Malware file rules.
For more information, see Configure File Policies, on page 1540.
b) Associate this file policy with one or more rules in the access control policy.
Step 5 If you want IPv4, IPv6, URL, or Domain Name observations to generate connection and security intelligence events, enable
connection and security intelligence logging in the access control policy:
a) In access control rules where you invoked a file policy, enable Log at End of Connection and File Events: Log
Files, if not already enabled.
For more information, see Logging Connections with Access Control Rules, on page 2442.
b) Verify that default logging (DNS Policy, Networks, and URLs) is enabled in your Security Intelligence settings.
For more information, see Logging Connections with Security Intelligence, on page 2442.
Step 6 Deploy configuration changes; see Deploy Configuration Changes, on page 385.
What to do next
Complete remaining items in How To Set Up Cisco Threat Intelligence Director (TID), on page 1588
Step 1 Make sure your source meets the requirements in Source Requirements, on page 1587
Step 2 Choose Intelligence > Sources.
Step 6 If you want to immediately begin publishing to elements, confirm that the Publish Slider ( ) is enabled.
When this option is enabled, the system automatically publishes the initial source data and any subsequent changes.
For details, see Pause or Publish TID Data at the Source, Indicator, or Observable Level, on page 1618.
What to do next
• TAXII feeds can contain a lot of data, it may take some time for the system to ingest all of the data. To
view ingestion status, refresh the Sources page.
• If you see an error for this source, hover over status for details.
• If you are doing initial TID configuration, return to How To Set Up Cisco Threat Intelligence Director
(TID), on page 1588.
Step 1 Make sure your source meets the requirements in Source Requirements, on page 1587
Step 2 Choose Intelligence > Sources.
Step 6 If you want to immediately begin publishing to elements, confirm that the Publish Slider ( ) is enabled.
When this option is enabled, the system automatically publishes the initial source data and any subsequent changes.
For details, see Pause or Publish TID Data at the Source, Indicator, or Observable Level, on page 1618.
What to do next
• To view ingestion status, refresh the Sources page. If you see an error, hover over status for details.
• If you are doing initial TID configuration, return to How To Set Up Cisco Threat Intelligence Director
(TID), on page 1588.
Step 1 Make sure your file meets the requirements in Source Requirements, on page 1587
Step 2 Choose Intelligence > Sources.
Step 6 If you want to immediately begin publishing to elements, confirm that the Publish Slider ( ) is enabled.
If you do not publish the source at ingestion, you cannot publish all source indicators at once later; instead, you must
publish each observable individually. See Pause or Publish TID Data at the Source, Indicator, or Observable Level, on
page 1618.
What to do next
• To view ingestion status, refresh the Sources page. If you see an error, hover over status for details.
• If you are doing initial TID configuration, return to How To Set Up Cisco Threat Intelligence Director
(TID), on page 1588.
Step 1 In the Edit Source dialog, expand the SSL Settings section.
Step 2 If your server certificate is self-signed:
a) Enable Self-Signed Certificate.
b) Choose a SSL Hostname Verification method.
• Strict—TID requires the source URL to match the hostname provided in the server certificate.
If the hostname includes a wildcard, TID cannot match more than one subdomain.
• Browser Compatible—TID requires the source URL to match the hostname provided in the server certificate.
If the hostname includes a wildcard, TID matches all subdomains.
• Allow All—TID does not require the source URL to match the hostname provided in the server certificate.
For example, if subdomain1.subdomain2.cisco.com is your source URL and *.cisco.com is the hostname
provided in the server certificate:
• Strict hostname verification fails.
• Browser Compatible hostname verification succeeds.
• Allow All hostname verification ignores the hostname values completely.
Open the private key file in a text editor and copy the entire block of text, including the BEGIN RSA PRIVATE
KEY and END RSA PRIVATE KEY lines. Enter this entire string into the field.
What to do next
• Take note of the certificate's expiration date. You may want to set a calendar reminder to enter a new
server certificate after the current certificate expires.
• Continue configuring the source:
• Fetch TAXII Feeds to Use as Sources, on page 1590
• Fetch Sources from a URL, on page 1591
In addition, you can use Firepower Management Center user accounts with the Admin, Access Admin, or
Network Admin user role to enable or disable TID in your access control policies.
For more information about user accounts, see User Accounts for FMC, on page 41.
Note If you host TID on the active Firepower Management Center in a high availability configuration, the system
does not synchronize TID configurations and TID data to the standby Firepower Management Center. We
recommend performing regular backups of TID data on your active Firepower Management Center so that
you can restore the data after failover.
TID configurations and TID data Back Up Threat Intelligence Restore Threat Intelligense
Director Director Data
Note When evaluating an indicator's pattern, TID ignores unsupported and invalid objects and observables on the
Allow list.
If TID ingested the observables from the example above and the observables were seen in order, incident
generation would proceed as follows:
1. When the system identifies Observable A in traffic, TID:
• Generates a fully-realized incident for Indicator 1.
• Generates partially-realized incidents for Indicator 2 and Indicator 3.
If a particular indicator exists in multiple sources, you may see duplicate incidents. For more information, see
Troubleshoot Cisco Threat Intelligence Director (TID), on page 1620.
Note that incidents are generated only by actual traffic. If there is an observable for URL B, and a user visits
URL A which displays a link to URL B, no incident occurs unless the user clicks the URL B link.
• Click Filter ( ) to add one or more filters. The default filter is 6 hours. For more information, see Filter TID Data
in Table Views, on page 1614.
• To view the date and time an incident was last updated by TID, hover the cursor over the value in the Last Updated
column.
• To view more information about the indicator associated with the incident, click the text in the Indicator Name
column; see View and Manage Indicators, on page 1610.
Field Description
Last Updated The number of days since either the system or a user last updated the incident. To view the date and time of the
update, hover the cursor over the value in this column.
Incident ID The unique identifier for the incident. This ID has the following format:
<type>-<date>-<number>
• <type>—The type of indicator or observable involved in the incident. For simple indicators, this value
indicates the observable type: IP (IPv4 or IPv6), URL (URL), DOM (domain), or SHA (SHA-256). For complex
indicators, this value is COM.
• <date>—The date (yyyymmdd) on which the incident was created.
• <number>—The daily incident number, that is, a number specifying where the incident occurs in the daily
sequence of incidents. Note that this sequence starts at 0. For example, DOM-20170828-10 is the 11th incident
created on that day.
Next to the identifier, the system displays an icon that indicates whether the incident is Partially Realized or
Fully Realized. For more information, see Observation and Incident Generation, on page 1596.
Field Description
Indicator Name The name of the indicator involved in the incident. To view additional information about the indicator, click
the value in this column; see View and Manage Indicators, on page 1610.
Action Taken The action taken by the system in relation to the incident. For more information, see Incident Details, on page
1599.
Status The status of your investigation into the incident. For more information, see Incident Details, on page 1599.
Incident Details
The Incident Details window displays information about a single TID incident. This window is divided into
two sections:
• Incident Details: Basic Information, on page 1599
• Incident Details: Indicator and Observations, on page 1600
Field Description
Partially-Realized An icon indicating the incident's status (partially-realized or fully-realized), as well as the unique identifier
IncidentID or for the incident.
Fully-Realized
Note When determining an incident's status, TID ignores unsupported and invalid observables and
IncidentID
observables on the Allow list.
Opened The date and time the incident was last updated.
Field Description
Confidence An optional rating that you can manually select to indicate the relative importance of the incident.
Action Taken The action taken by the system: Monitored, Blocked, or Partially Blocked.
Partially Blocked indicates that the incident contained both Monitored and Blocked observations.
Note The Action Taken indicates the action taken by the system, not necessarily the action selected
in TID. For more information, see TID-Firepower Management Center Action Prioritization,
on page 1604.
Category A custom, optional tag or keyword that you manually add to the incident.
Status A value indicating the current stage of your analysis of the incident. All incidents are New until you change
the Status for the first time.
This field is optional. Depending on the needs of your organization, consider using the status values as
follows:
• New—The incident requires investigation, but you have not started investigating.
• Open—You are currently investigating the incident.
• Closed—You investigated the incident and took action.
• Rejected—You investigated the incident and determined there was no action to take.
Indicator Section
When you first view indicator details, this section displays only the indicator name.
Click the indicator name to view the indicator on the Indicators page.
Click the down arrow next to the indicator name to view more indicator details without leaving the incident.
Detail fields include:
Field Description
Source The source that contained the indicator. Click this link to access full source details.
Expires The date and time the incident will expire, based on the source's TTL value.
Action The action associated with the indicator. For more information, see Edit TID Actions
at the Source, Indicator, or Observable Level, on page 1616.
Field Description
Publish The publish setting for the indicator. For more information, see Pause or Publish TID
Data at the Source, Indicator, or Observable Level, on page 1618.
Download STIX If the source type is STIX, click this button to download the STIX file.
Indicator Pattern
The indicator pattern is a graphical representation of the observables and operators that comprise the indicator.
Operators link the observables within the indicator. AND relationships are indicated with the AND operator.
OR relationships are indicated with the OR operator or by a close grouping of several observables.
If an observable in the pattern has already been seen, the observable box is white. If an observable has not
already been seen, the observable box is grey.
In the indicator pattern:
• Click the Whitelist icon to add the observable to the Allow list. This icon is present in both white and
grey observable boxes. For more information, see About Adding TID Observables to the Allow List, on
page 1619.
• If you hover the cursor over a white observable box, the system highlights the related observation in the
Observations section.
• If you click a white observable box, the system highlights the related observation in the Observations
section, scrolls that observation into view (if multiple observations are present), and expands that
observation's detailed display.
• If you hover the cursor over or click a grey observable box in the indicator pattern, there is no change in
the Observations section. Because the observable is unseen, there are no observation details to display
yet.
Observations Section
By default, the Observations section displays summary information, which includes:
• The type of observable that triggered the observation (for example, Domain)
• The data that comprises the observable
• Whether the observation is the first observation or a subsequent observation (for example, 1st or 3rd)
Note If a single observable has been seen three or more times, TID displays the first
and last observation details. The details for intermediary observations are not
available.
If you hover the cursor over an observation in the Observations section, the system highlights the related
observable in the indicator pattern.
If you click an observation in the Observations section, the system highlights the related observable(s) in the
indicator pattern and scrolls the first related observable into view (if multiple observables are present). Clicking
an observation also expands the details of the observation in the Observations section.
Observation details include the following fields:
Field Description
SOURCE The source IP address and port for the traffic that
triggered the observation.
DESTINATION The destination IP address and port for the traffic that
triggered the observation.
Observation Connection Events Table Security Intelligence Events File Events Table Malware Events Table
Content Table
Specifically:
Table 123: TID URL Observable Action vs. Security Intelligence Action
Setting: Security Intelligence Setting: TID Observable TID Incidents Security Intelligence Events Fields:
Action Action Field: Action
Taken Action Security Intelligence Reason
Category
Table 124: TID IPv4/IPv6 Observable Action vs. Security Intelligence Action
Setting: Security Intelligence Setting: TID Observable TID Incidents Security Intelligence Events Fields:
Action Action Field: Action
Taken Action Security Intelligence Reason
Category
Setting: Security Intelligence Setting: TID Observable TID Incidents Security Intelligence Events Fields:
Action Action Field: Action
Taken Action Security Intelligence Reason
Category
Table 125: TID Domain Name Observable Action vs. DNS Policy Action
Setting: DNS Policy Action Setting: TID TIDIncidents Security Intelligence Events Fields:
Domain Name Field: Action
Observable Taken Action Security Intelligence Reason
Action Category
Drop, Domain Not Found Monitor Blocked Block as determined by system DNS Block
analysis; see Security
Sinkhole—Log
Intelligence Categories,
Sinkhole—Block and Log on page 1399
Setting: DNS Policy Action Setting: TID TIDIncidents Security Intelligence Events Fields:
Domain Name Field: Action
Observable Taken Action Security Intelligence Reason
Action Category
Table 126: TID SHA-256 Observable Action vs. Malware Cloud Lookup File Policy
File Disposition TID SHA-256 Observable Action Taken in TID Action in File Events Action in Malware
Action Incidents Events
Note TID matching occurs before the system sends a file for dynamic analysis.
Table 127: TID SHA-256 Observable Action vs. Block Malware File Policy
File Disposition TID SHA-256 Observable Action Taken in TID Action in File Events Action in Malware
Action Incidents Events
on page 1589) will receive all currently-published observables, including those ingested before the element was
added.
• To filter the sources displayed on the page, click Filter ( ). For more information, see Filter TID Data in Table
Views, on page 1614.
• To view detailed ingestion status, hover the cursor over the text in the Status column. For more information, see
Source Status Details, on page 1609.
• To edit the Publish setting, click Slider ( ). For more information, see Pause or Publish TID Data at the Source,
Indicator, or Observable Level, on page 1618.
• To pause or resume TID updating the source, click Pause Updates or Resume Updates. If you pause updates,
updating is paused but existing indicators and observables remain in TID.
• To delete the source, click Delete ( ). Delete is greyed out if the source is still processing. Deleting a source
deletes all indicators associated with that source. Associated observables may also be deleted; they are retained if
they are associated with indicators remaining in the system.
Field Description
Action The action (Block or Monitor) that the system is configured to perform on traffic matching the data contained
within this source.
For more information about TID actions, including availability, inheritance, and overriding inheritance, see
Factors That Affect the Action Taken, on page 1603.
Publish On or Off toggle specifying whether TID publishes data from the source to registered elements (managed devices
configured to support TID).
Indicators can inherit Publish settings from a parent source, and observables can inherit Publish settings from
a parent indicator. For more information, see Inheritance in TID Configurations, on page 1615.
Last Updated The date and time TID last updated the source.
Clicking this icon allows you to edit settings for the source.
Edit ( )
Data Description
Data Description
Last Updated Specifies the date and time TID last updated the source.
Next Update For TAXII and URL sources, this value specifies when TID will update the source next.
• To filter the indicators displayed on the page, click Filter ( ). For more information, see Filter TID Data in Table
Views, on page 1614.
• To view additional details about an indicator (including associated observables), click the indicator name. For more
information, see Indicator Details, on page 1612.
• In the Incidents column, click the number to view information about incidents associated with an indicator, or hover
the cursor over Incidents to view whether the incidents are fully- or partially-realized.
• To determine whether TID finished ingesting an indicator from the source, view the Status column.
Field Description
Type • Indicators that have a single observable list the data type of that observable (URL,
SHA-256, etc.)
• Indicators that have two or more observables are listed as Complex.
Source The source that contained the indicator (the parent source).
Field Description
Action The action associated with the indicator. For more information, see Edit TID Actions at the
Source, Indicator, or Observable Level, on page 1616.
Indicators can inherit Action settings from a parent source, and observables can inherit
Action settings from a parent indicator. For more information, see Inheritance in TID
Configurations, on page 1615.
Publish The publish setting for the indicator. For more information, see Pause or Publish TID Data
at the Source, Indicator, or Observable Level, on page 1618.
Indicators can inherit Publish settings from a parent source, and observables can inherit
Publish settings from a parent indicator. For more information, see Inheritance in TID
Configurations, on page 1615.
Last Updated The date and time TID last updated the indicator.
Indicator Details
The Indicator Details page displays indicator and observable data for an incident.
Field Description
Expires The date and time the indicator will expire, based on the source's TTL value.
Action The action associated with the indicator. For more information, see Edit TID Actions at the Source,
Indicator, or Observable Level, on page 1616.
Indicators can inherit the Action setting from a parent source, and observables can inherit the Action
setting from a parent indicator. For more information, see Inheritance in TID Configurations, on page
1615.
Publish The publish setting for the indicator. For more information, see Pause or Publish TID Data at the Source,
Indicator, or Observable Level, on page 1618.
Indicators can inherit the Publish setting from a parent source, and observables can inherit the Publish
setting from a parent indicator. For more information, see Inheritance in TID Configurations, on page
1615.
Field Description
Indicator Pattern The observables and operators that form the indicator's pattern. Operators link the observables within the
indicator. AND relationships are indicated with the AND operator. OR relationships are indicated with
the OR operator or by a close grouping of several observables.
Optionally, click the Whitelist icon to add an observable to the Allow list. For more information, see
About Adding TID Observables to the Allow List, on page 1619.
• To filter the observables displayed on the page, click Filter ( ). For more information, see Filter TID Data in
Table Views, on page 1614.
• If the information in the Value column is cut off, hover over the value.
• To view indicators that contain the observable, click the number in the Indicators column. The Incidents page opens
with the observable value as the filter. For more information, see View and Manage Indicators, on page 1610.
Field Description
Type The type of observable data: SHA-256, Domain, URL, IPv4, or IPv6.
Action The action configured for the observable. For more information, see Edit TID Actions at
the Source, Indicator, or Observable Level, on page 1616.
Indicators can inherit Action settings from a parent source, and observables can inherit
Action settings from a parent indicator. For more information, see Inheritance in TID
Configurations, on page 1615.
Publish The publish setting for the observable; see Pause or Publish TID Data at the Source, Indicator,
or Observable Level, on page 1618.
Indicators can inherit Publish settings from a parent source, and observables can inherit
Publish settings from a parent indicator. For more information, see Inheritance in TID
Configurations, on page 1615.
Updated At The date and time TID last updated the observable.
Expires The date that the observable will be automatically purged from TID based on TTL for the
parent indicator.
Whitelist icon Clicking this icon adds the observable to the Allow list; see About Adding TID Observables
to the Allow List, on page 1619.
Step 4 (Optional) To filter by multiple attributes, click Filter ( ) and repeat Step 2 and Step 3.
Step 5 To cancel the changes you have made since you last applied the filter, click Cancel.
Step 6 Click Apply to refresh the table with the filter applied.
Step 7 To remove a filter attribute individually, click Remove ( ) next to the filter attribute and click Apply to refresh the
table.