FPMC Config Guide v70

Firepower Management Center Configuration Guide, Version 7.
0
First Published: 2021-05-26
Last Modified: 2021-05-27
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)
© 2021 Cisco Systems, Inc. All rights reserved.
CONTENTS
CHAPTER 1 Getting Started With Firepower 1
Quick Start: Basic Setup 2

Installing and Performing Initial Setup on Physical Appliances 2
Deploying Virtual Appliances 2
Logging In for the First Time 3
Setting Up Basic Policies and Configurations 5
Firepower Devices 6
End of Sale for Firepower 7000/8000 Series Devices 7
Firepower Features 7
Appliance and System Management Features 7
High Availability and Scalability Features by Platform 9
Features for Detecting, Preventing, and Processing Potential Threats 10
Integration with External Tools 11
Search the FMC 11
Search for Web Interface Menu Options 13
Search for Policies 14
Search for Objects 15
Switching Domains on the Firepower Management Center 19
The Context Menu 19
Sharing Data with Cisco 21
Firepower Online Help, How To, and Documentation 21
Top-Level Documentation Listing Pages for FMC Deployments 22
License Statements in the Documentation 24
Supported Devices Statements in the Documentation 24
Access Statements in the Documentation 24
Firepower System IP Address Conventions 24
Firepower Management Center Configuration Guide, Version 7.0

iii
Contents
Additional Resources 25
History for Getting Started with Firepower 25
PART I Your User Account 27
CHAPTER 2 Logging into the Firepower System 29
Firepower System User Accounts 29

Firepower System User Interfaces 31
Web Interface Considerations 33
Session Timeout 33
Logging Into the Firepower Management Center Web Interface 34
Logging Into the FMC Web Interface Using SSO 35
Logging Into the Firepower Management Center with CAC Credentials 36
Logging Into the FMC Command Line Interface 37
Logging Into the CLI on ASA FirePOWER and NGIPSv Devices 37
Logging Into the Command Line Interface on FTD Devices 38
View Your Last Login 39
Logging Out of a Firepower System Web Interface 39
History for Logging into the Firepower System 40
CHAPTER 3 Specifying User Preferences 43
User Preferences Introduction 43

Changing Your Password 43
Changing an Expired Password 44
Change the Web Interface Appearance 44
Specifying Your Home Page 45
Configuring Event View Settings 45
Event View Preferences 46
File Download Preferences 47
Default Time Windows 47
Default Workflows 49
Setting Your Default Time Zone 50
Specifying Your Default Dashboard 50
History for Specifying User Preferences 51

iv
Contents
CHAPTER 4 User Accounts for FMC 53

About User Accounts for FMC 53
Internal, External, and SSO Users 53
Web Interface and CLI Access 54
User Roles 54
User Passwords 56
Guidelines and Limitations for User Accounts for FMC 58
Requirements and Prerequisites for User Accounts for FMC 59
Add an Internal User 59
Configure External Authentication 61
About External Authentication 61
About LDAP 62
About RADIUS 62
Add an LDAP External Authentication Object for FMC 63
Add a RADIUS External Authentication Object for FMC 70
Enable External Authentication for Users on the FMC 75
Configure Common Access Card Authentication with LDAP 76
Configure SAML Single Sign-On 77
About SAML Single Sign-On 77
SSO Guidelines for the FMC 78
SSO User Accounts 78
User Role Mapping for SSO Users 79
Enable Single Sign-On at the FMC 80
Configure Single Sign-On with Okta 81
Review the Okta Org 81
Configure an FMC Service Provider Application for Okta 82

Configure the FMC for Okta SSO 83
Configure User Role Mapping for Okta at the FMC 84
Configure User Role Mapping at the Okta IdP 85
Okta User Role Mapping Examples 88
Configure Single Sign-On with OneLogin 92
Review the OneLogin Subdomain 93
Configure an FMC Service Provider Application for OneLogin 93

v
Contents
Configure the FMC for OneLogin SSO 95

Configure User Role Mapping for OneLogin at the FMC 96
Configure User Role Mapping at the OneLogin IdP 97
OneLogin User Role Mapping Examples 100
Configure Single Sign-On with Azure AD 104
Review the Azure Tenant 105
Configure an FMC Service Provider Application for Azure 105
Configure the FMC for Azure SSO 107
Configure User Role Mapping for Azure at the FMC 108
Configure User Role Mapping at the Azure IdP 109
Azure User Role Mapping Examples 112
Configure Single Sign-On with PingID 116
Review the PingID PingOne for Customers Environment 117
Configure an FMC Service Provider Application for PingID PingOne for Customers 117
Configure the FMC for SSO with PingID PingOne for Customers 119
Configure Single Sign-On with Any SAML 2.0-Compliant SSO Provider 120
Familiarize Yourself with the SSO Identity Provider and the SSO Federation 121
Configure an FMC Service Provider Application for Any SAML 2.0-Compliant SSO Provider
121
Configure the FMC for SSO Using Any SAML 2.0-Compliant SSO Provider 123
Configure User Role Mapping at the FMC for SAML 2.0-Compliant SSO Providers 124
Configure FMC User Role Mapping at the IdP for SAML 2.0-Compliant SSO Providers 125
Customize User Roles for the Web Interface 126
Create Custom User Roles 126
Deactivate User Roles 128
Enable User Role Escalation 128
Set the Escalation Target Role 129
Configure a Custom User Role for Escalation 129
Escalate Your User Role 130
Troubleshooting LDAP Authentication Connections 130
History for User Accounts for FMC 132
CHAPTER 5 User Accounts for Devices 135
About User Accounts for Devices 135

vi
Contents
Internal and External Users 135

CLI Access 136
CLI User Roles 136
Requirements and Prerequisites for User Accounts for Devices 136
Guidelines and Limitations for User Accounts for Devices 137
Add an Internal User at the CLI 137
Configure External Authentication for the FTD 139
About External Authentication for the FTD 139
About LDAP 140
About RADIUS 140
Add an LDAP External Authentication Object for FTD 140
Add a RADIUS External Authentication Object for FTD 146
Enable External Authentication for Users on FTD Devices 151
Troubleshooting LDAP Authentication Connections 151
History for User Accounts for Devices 153
PART II Firepower System Management 155
CHAPTER 6 Licensing the Firepower System 157
About Firepower Licenses 157

Requirements and Prerequisites for Licensing 158
License Requirements for Firepower Management Center 158
Firepower Management Center Virtual Licenses 158
Evaluation License Caveats 159
Smart vs. Classic Licenses 159
License Firepower Threat Defense Devices (FTD) 160
How to License Firepower Threat Defense Devices 160
Smart Software Manager (CSSM) 163
Periodic Communication with the License Authority 164
Service Subscriptions for FTD Features 164
FTD License Types and Restrictions 165
Base Licenses 166
Malware Licenses for Firepower Threat Defense Devices 167
Threat Licenses 167

vii
Contents
URL Filtering Licenses for Firepower Threat Defense Devices 168

AnyConnect Licenses 168
Licensing for Export-Controlled Functionality 169
Licensing for High-Availability Configurations 170
Licensing for FTD Clusters 170
Licensing for Multi-Instance Deployments 170
Create a Smart Account to Hold Your Licenses 171
How to Configure Smart Licensing with Direct Internet Access 172
Obtain a Product License Registration Token for Smart Licensing 173
Register Smart Licenses 174
Enabling the Export Control Feature (for Accounts Without Global Permission) 175
Disabling the Export Control Feature (for Accounts without Global Permission) 176
Licensing Options for Air-Gapped Deployments 177
Smart Software Manager On-Prem Overview 177
How to Deploy Smart Software Manager On-Prem 178
Specific License Reservation (SLR) 179
Best Practices for Specific License Reservation 180
Requirements for Specific License Reservation 180
How to Implement Specific License Reservation 180
Update a Specific License Reservation 185
Important! Maintain Your SLR Deployment 187
Specific License Reservation Status 187
Expired Specific License Reservation 188
Renew Specific License Reservation Entitlements 188
Deactivate and Return the Specific License Reservation 189
Troubleshoot Specific License Reservation 191
Assign Licenses to Multiple Managed Devices 192
View FTD Licenses and License Status 193
FTD License Status 194
Move or Remove Licenses from FTD Devices 195
Transfer FTD Licenses to a Different Firepower Management Center 195
If FTD License Status is Out of Compliance 195
Deregister a Firepower Management Center from the Cisco Smart Software Manager 196
Synchronize a Firepower Management Center with the Cisco Smart Software Manager 196

viii
Contents
Troubleshoot FTD Licensing 197

FTDv Licensing 197
FTDv Performance Tier Licensing Guidelines and Limitations 198
License Classic Devices (ASA FirePOWER and NGIPSv) 199
Product License Registration Portal 199
Service Subscriptions for Firepower Features (Classic Licensing) 199
Classic License Types and Restrictions 200
Protection Licenses 201
Control Licenses 201
URL Filtering Licenses for Classic Devices 202
Malware Licenses for Classic Devices 202
View Your Classic Licenses 203
Identify the License Key 204
Generate a Classic License and Add It to the Firepower Management Center 204
How to Convert a Classic License for Use on an FTD Device 205
Assign Licenses to Managed Devices from the Device Management Page 207
License Expiration 208
Other Licensing Information in This Guide 211
Additional Information about Firepower Licensing 213
Cisco Success Network 213
Cisco Success Network Telemetry Data 214
Enrolled Device Data 214
Software Version Data 215
Managed Device Data 215
Deployment Information 216
TLS/SSL Inspection Event Data 217
Snort Restart Data 220
Snort3 Data 220
Contextual Cross-Launch Data 222
Telemetry Example File 222
Changing Cisco Success Network Enrollment 227
Cisco Support Diagnostics 227
Changing Cisco Support Diagnostics Enrollment 228
End-User License Agreement 228

ix
Contents
History for Licensing 228
CHAPTER 7 System Updates 231
About System Updates 231

Requirements and Prerequisites for System Updates 233
Guidelines and Limitations for System Updates 233
Upgrade System Software 234
Upgrade Firepower Threat Defense 234
Update the Vulnerability Database (VDB) 237
Manually Update the VDB 238
Schedule VDB Updates 239
Update the Geolocation Database (GeoDB) 239
Manually Update the GeoDB (Internet Connection) 239
Manually Update the GeoDB (No Internet Connection) 240
Schedule GeoDB Updates 240
Update Intrusion Rules 241
Update Intrusion Rules One-Time Manually 242
Update Intrusion Rules One-Time Automatically 243
Schedule Intrusion Rule Updates 243
Best Practices for Importing Local Intrusion Rules 244
Import Local Intrusion Rules 245
Rule Update Log 246
Intrusion Rule Update Log Table 246
Viewing the Intrusion Rule Update Log 247
Fields in an Intrusion Rule Update Log 247
Viewing Details of the Intrusion Rule Update Import Log 249
Maintain Your Air-Gapped Deployment 250
History for System Updates 250
CHAPTER 8 Backup and Restore 257
About Backup and Restore 257

Requirements for Backup and Restore 259
Guidelines and Limitations for Backup and Restore 260
Configuration Import/Export Guidelines for Firepower 4100/9300 260

x
Contents
Best Practices for Backup and Restore 261

Backing Up FMCs or Managed Devices 265
Back up the FMC 265
Back up a Device from the FMC 266
Exporting an FXOS Configuration File 267
Create a Backup Profile 268
Restoring FMCs and Managed Devices 269
Restore an FMC from Backup 270
Restore FTD from Backup: Firepower 1000/2100, ASA-5500-X, ISA 3000 (Non-Zero-Touch) 271
Zero-Touch Restore FTD from Backup: ISA 3000 274
Restore FTD from Backup: Firepower 4100/9300 Chassis 276

Importing a Configuration File 279
Restore FTD from Backup: FTDv 280
Manage Backups and Remote Storage 282
Backup Storage Locations 284
History for Backup and Restore 285
CHAPTER 9 Configuration Import and Export 287
About Configuration Import/Export 287

Configurations that Support Import/Export 287
Special Considerations for Configuration Import/Export 288
Requirements and Prerequisites for Configuration Import/Export 289
Exporting Configurations 289
Importing Configurations 290
Import Conflict Resolution 291
CHAPTER 10 Task Scheduling 293
About Task Scheduling 293

Requirements and Prerequisites for Task Scheduling 294
Configuring a Recurring Task 294
Scheduled Backups 295
Schedule FMC Backups 296
Schedule Remote Device Backups 296
Configuring Certificate Revocation List Downloads 297

xi
Contents
Automating Policy Deployment 298

Nmap Scan Automation 299
Scheduling an Nmap Scan 299
Automating Report Generation 300
Specify Report Generation Settings for a Scheduled Report 301
Automating Firepower Recommendations 302
Software Update Automation 303
Automating Software Downloads 304
Automating Software Pushes 305
Automating Software Installs 306
Vulnerability Database Update Automation 306
Automating VDB Update Downloads 307
Automating VDB Update Installs 308
Automating URL Filtering Updates Using a Scheduled Task 309
Scheduled Task Review 310
Task List Details 310
Viewing Scheduled Tasks on the Calendar 311
Editing Scheduled Tasks 312
Deleting Scheduled Tasks 312
History for Scheduled Tasks 312
CHAPTER 11 Data Storage 315
Data Stored on the FMC 315

Purging Data from the FMC Database 316
External Data Storage 317
Comparison of Cisco Security Analytics and Logging Remote Event Storage Options 317
Remote Data Storage in the Stealthwatch Cloud 318
Remote Data Storage on a Stealthwatch Appliance 318
History for Data Storage 319
CHAPTER 12 Firepower Management Center High Availability 321
About Firepower Management Center High Availability 321

Roles v. Status in Firepower Management Center High Availability 322
Event Processing on Firepower Management Center High Availability Pairs 322

xii
Contents
AMP Cloud Connections and Malware Information 322

URL Filtering and Security Intelligence 323
User Data Processing During Firepower Management Center Failover 323
Configuration Management on Firepower Management Center High Availability Pairs 323
Cisco Threat Intelligence Director (TID) and High Availability Configurations 323
Single Sign-On and High Availability Pairs 323
Firepower Management Center High Availability Behavior During a Backup 324
Firepower Management Center High Availability Split-Brain 324
Upgrading Firepower Management Centers in a High Availability Pair 324
Troubleshooting Firepower Management Center High Availability 325
Requirements for Firepower Management Center High Availability 326
Hardware Requirements 327
Virtual Platform Requirements 327
Software Requirements 327
License Requirements for FMC High Availability Configurations 328
Prerequisites for Firepower Management Center High Availability 329
Establishing Firepower Management Center High Availability 329
Viewing Firepower Management Center High Availability Status 331
Configuration Data Synced between Firepower Management Centers during High Availability 332
Configuring External Access to the FMC Database in a High Availability Pair 332
Using CLI to Resolve Device Registration in Firepower Management Center High Availability 333
Switching Peers in a Firepower Management Center High Availability Pair 333
Pausing Communication Between Paired Firepower Management Centers 334
Restarting Communication Between Paired Firepower Management Centers 334
Changing the IP address of a Firepower Management Center in a High Availability Pair 335
Disabling Firepower Management Center High Availability 335
Replacing FMCs in a High Availability Pair 336
Replace a Failed Primary FMC (Successful Backup) 336
Replace a Failed Primary FMC (Unsuccessful Backup) 337
Replace a Failed Secondary FMC (Successful Backup) 338
Replace a Failed Secondary FMC (Unsuccessful Backup) 339
History for FMC High Availability 340
CHAPTER 13 Device Management Basics 341

xiii
Contents
About Device Management 341

About the Firepower Management Center and Device Management 341
What Can Be Managed by a Firepower Management Center? 342
Beyond Policies and Events 342
About Device Management Interfaces 343
Management Interfaces on Managed Devices 343
About Using an FTD Data interface for Management 343
Management Interface Support Per Device Model 344
Network Routes on Device Management Interfaces 345
NAT Environments 346
Management and Event Traffic Channel Examples 348
Requirements and Prerequisites for Device Management 349
Complete the FTD Initial Configuration 349
Add a Device to the FMC 355
Delete a Device from the FMC 358
Add a Device Group 359
Configure Device Settings 360
Managing System Shut Down 360
Edit Management Settings 360
Update the Hostname or IP Address in FMC 360
Change the FMC Access Interface from Management to Data 361
Change the FMC Access Interface from Data to Management 364
View FMC Access Details for Data Interface Management 366
Modify Device Management Interfaces at the CLI 370
Modify the FTD Data Interface Used for Management at the CLI 376
Roll Back the Configuration if the FMC Loses Connectivity 378
Troubleshoot Management Connectivity on a Data Interface 380
Edit General Settings 385
Copy a Configuration to Another Device 385
Edit License Settings 386
Edit Advanced Settings 387
Configure Automatic Application Bypass 387
Configure Object Group Search 388
Configure Interface Object Optimization 389

xiv
Contents
Change the Manager for the Device 390

Edit the FMC IP Address or Hostname on the Device 390
Identify a New FMC 391
Switch from Firepower Device Manager to FMC 392
Switch from FMC to Firepower Device Manager 393
Viewing Device Information 395
Device Management Page Information 395
General Information 396
License Information 396
System Information 396
Health Information 397
Management Information 397
Advanced Settings 398
History for Device Management Basics 399
PART III System Monitoring and Troubleshooting 401
CHAPTER 14 Dashboards 403
About Dashboards 403

Firepower System Dashboard Widgets 404
Widget Availability 404
Dashboard Widget Availability by User Role 405
Predefined Dashboard Widgets 406
The Appliance Information Widget 406
The Appliance Status Widget 407
The Correlation Events Widget 407
The Current Interface Status Widget 407
The Current Sessions Widget 408
The Custom Analysis Widget 408
The Disk Usage Widget 412
The Interface Traffic Widget 413
The Intrusion Events Widget 413
The Network Compliance Widget 414
The Product Licensing Widget 414

xv
Contents
The Product Updates Widget 415

The RSS Feed Widget 415
The System Load Widget 415
The System Time Widget 416
The Allow List Events Widget 416
Managing Dashboards 416
Adding a Dashboard 417
Adding Widgets to a Dashboard 417
Configuring Widget Preferences 418
Creating Custom Dashboards 418
Custom Dashboard Options 419
Customizing the Widget Display 420
Editing Dashboards Options 421
Modifying Dashboard Time Settings 421
Renaming a Dashboard 422
Viewing Dashboards 423
CHAPTER 15 Health Monitoring 425
Requirements and Prerequisites for Health Monitoring 425

About Health Monitoring 425
Health Modules 427
Configuring Health Monitoring 436
Health Policies 437
Default Health Policy 437
Creating Health Policies 437
Applying Health Policies 438
Editing Health Policies 439
Deleting Health Policies 440
The Health Monitor Blocklist 440
Blacklisting Appliances 441
Blacklisting Health Policy Modules 442
Health Monitor Alerts 442
Health Monitor Alert Information 442
Creating Health Monitor Alerts 443

xvi
Contents
Editing Health Monitor Alerts 444

Deleting Health Monitor Alerts 444
About the Health Monitor 445
Using the FMC Health Monitor 446
Running All Modules for an Appliance 447
Running a Specific Health Module 447
Generating Health Module Alert Graphs 448
Device Health Monitors 448
Viewing System Details and Troubleshooting 449
Viewing the Device Health Monitor 450
Health Monitor Status Categories 459
Health Event Views 460
Viewing Health Events 460
Viewing Health Events by Module and Appliance 460
Viewing the Health Events Table 461
The Health Events Table 462
History for Health Monitoring 464
CHAPTER 16 Monitoring the System 467

About System Statistics 467
The Host Statistics Section 467
The Disk Usage Section 468
The Processes Section 468
Process Status Fields 468
System Daemons 470
Executables and System Utilities 472
The SFDataCorrelator Process Statistics Section 474
The Intrusion Event Information Section 475
Viewing System Statistics 476
CHAPTER 17 Auditing the System 477

The System Log 477
Viewing the System Log 477
Syntax for System Log Filters 478

xvii
Contents
About System Auditing 479

Audit Records 479
Viewing Audit Records 479
Suppressing Audit Records 482
About Sending Audit Logs to an External Location 486
CHAPTER 18 SNMP 487
About SNMP 487

SNMP Terminology 487
MIBs and Traps 488
Supported Tables and Objects in MIBs 489
CHAPTER 19 Troubleshooting the System 493
First Steps for Troubleshooting 493

System Messages 493
Message Types 494
Message Management 495
View Basic System Information 496
View Appliance Information 496
Managing System Messages 496
Viewing Deployment Messages 497
Viewing Health Messages 498
Viewing Task Messages 498
Managing Task Messages 499
Configuring Notification Behavior 500
Memory Usage Thresholds for Health Monitor Alerts 500
Disk Usage and Drain of Events Health Monitor Alerts 501
Health Monitor Reports for Troubleshooting 504
Producing Troubleshooting Files for Specific System Functions 505
Downloading Advanced Troubleshooting Files 506
General Troubleshooting 506
Connection-based Troubleshooting 507
Troubleshoot a Connection 507
Advanced Troubleshooting for the Firepower Threat Defense Device 508

xviii
Contents
Using the FTD CLI from the Web Interface 508

Packet Tracer Overview 509
Use the Packet Tracer 509
Packet Capture Overview 510
Use the Capture Trace 512
Feature-Specific Troubleshooting 513
PART IV Deployment Management 515
CHAPTER 20 Domain Management 517

Introduction to Multitenancy Using Domains 517
Domains Terminology 518
Domain Properties 519
Requirements and Prerequisites for Domains 520
Managing Domains 520
Creating New Domains 521
Moving Data Between Domains 522
Moving Devices Between Domains 523
History for Domain Management 524
CHAPTER 21 Policy Management 525

Requirements and Prerequisites for Policy Management 525
Policy Deployment 525
Best Practices for Deploying Configuration Changes 526
Restart Warnings for Firepower Threat Defense Devices 527
Deployment Status 528
Deployment Estimate 529
Deployment Notes 529
Deployment Preview 529
Filter Support for Deployment 532
Selective Policy Deployment 532
Deploy Configuration Changes 535
Redeploy Existing Configurations to a Device 538
View Deployment History 539

xix
Contents
View Deployment History Preview 540

HA Scenarios where Preview is not Supported 541
Deployment Rollback 541
Roll Back Deployment on a Device 543
View the Deployment Rollback Transcript 544
Snort® Restart Scenarios 545
Inspect Traffic During Policy Apply 545
Snort® Restart Traffic Behavior 546
Configurations that Restart the Snort Process When Deployed or Activated 548
Changes that Immediately Restart the Snort Process 549
Policy Comparison 550
Comparing Policies 550
Policy Reports 551
Generating Current Policy Reports 551
Out-of-Date Policies 552
Performance Considerations for Limited Deployments 553
Discovery Without Intrusion Prevention 553
Intrusion Prevention Without Discovery 554
History for Policy Management 555
CHAPTER 22 Rule Management: Common Characteristics 561
Requirements and Prerequisites for Rule Management 561

Introduction to Rules 561
Rule Condition Types 563
Rule Condition Mechanics 565
Interface Conditions 566
Configuring Interface Conditions 567
Network Conditions 568
Configuring Network Conditions 569
Tunnel Endpoint Conditions 571
Configuring Tunnel Endpoint Conditions 571
VLAN Conditions 572
Port and ICMP Code Conditions 573
Configuring Port Conditions 574

xx
Contents
Encapsulation Conditions 575

Application Conditions (Application Control) 575
Configuring Application Conditions and Filters 576
Application Characteristics 578
Best Practices for Application Control 579
Best Practices for Configuring Application Control 581
Application-Specific Notes and Limitations 582
Troubleshoot Application Control Rules 583
URL Conditions (URL Filtering) 585
User, Realm, and ISE Attribute Conditions (User Control) 585
User Control Prerequisites 586
Configuring User and Realm Conditions 587
Configuring ISE Attribute Conditions 587
Troubleshoot User Control 588
External Attributes Conditions 589
External Attributes Conditions 590
Configure External Attributes Conditions 590
Custom SGT Conditions 591
ISE SGT vs Custom SGT Rule Conditions 592
Autotransition from Custom SGTs to ISE SGTs 592
Configuring Custom SGT Conditions 592
Troubleshooting Custom SGT Conditions 593
Apply Rules Based on Day and Time 593
Searching for Rules 594
Filtering Rules by Device 594
Identify Rules with Issues 595
Rule and Other Policy Warnings 596
History for Rule Management: Common Characteristics 597
CHAPTER 23 Reusable Objects 599

Introduction to Reusable Objects 600
The Object Manager 602
Importing Objects 602
Editing Objects 605

xxi
Contents
Viewing Objects and Their Usage 606

Filtering Objects or Object Groups 607
Object Groups 607
Grouping Reusable Objects 608
Object Overrides 609
Managing Object Overrides 610
Allowing Object Overrides 610
Adding Object Overrides 611
Editing Object Overrides 611
Network Objects 612
Creating Network Objects 613
Importing Network Objects 614
Port Objects 614
Creating Port Objects 615
Importing Port Objects 615
Tunnel Zones 616
Application Filters 616
VLAN Tag Objects 616
Creating VLAN Tag Objects 616
Security Group Tag Objects 617
Creating Security Group Tag Objects 617
URL Objects 618
Creating URL Objects 619
Geolocation Objects 619
Creating Geolocation Objects 619
Interface Objects: Interface Groups and Security Zones 620
Creating Security Zone and Interface Group Objects 621
Time Range Objects 622
Creating Time Range Objects 622
Time Zone Object 623
Variable Sets 623
Variable Sets in Intrusion Policies 625
Variables 625
Predefined Default Variables 626

xxii
Contents
Network Variables 628

Port Variables 629
Advanced Variables 630
Variable Reset 631
Adding Variables to Sets 631
Nesting Variables 633
Managing Variable Sets 634
Creating Variable Sets 635
Managing Variables 636
Adding Variables 637
Editing Variables 638
Security Intelligence Lists and Feeds 638
How to Modify Security Intelligence Objects 640
Global and Domain Security Intelligence Lists 640
Security Intelligence Lists and Multitenancy 641
Add Entries to Global Security Intelligence Lists 642
Delete Entries from Global Security Intelligence Lists 643
List and Feed Updates for Security Intelligence 644
Changing the Update Frequency for Security Intelligence Feeds 644
Custom Security Intelligence Lists and Feeds 645
Custom Lists and Feeds: Requirements 645
URL Lists and Feeds: URL Syntax and Matching Criteria 645
Custom Security Intelligence Feeds 646
Custom Security Intelligence Lists 648
Sinkhole Objects 650
Creating Sinkhole Objects 650
File Lists 651
Source Files for File Lists 651
Adding Individual SHA-256 Values to File Lists 652
Uploading Individual Files to File Lists 653
Uploading Source Files to File Lists 653
Editing SHA-256 Values in File Lists 654
Downloading Source Files from File Lists 655
Cipher Suite Lists 656

xxiii
Contents
Creating Cipher Suite Lists 656

Distinguished Name Objects 656
Creating Distinguished Name Objects 658
PKI Objects 658
Internal Certificate Authority Objects 659
CA Certificate and Private Key Import 660
Importing a CA Certificate and Private Key 660
Generating a New CA Certificate and Private Key 661
New Signed Certificates 661
Creating an Unsigned CA Certificate and CSR 662
Uploading a Signed Certificate Issued in Response to a CSR 662
CA Certificate and Private Key Downloads 663
Downloading a CA Certificate and Private Key 663
Trusted Certificate Authority Objects 664
Trusted CA Object 664
Adding a Trusted CA Object 664
Certificate Revocation Lists in Trusted CA Objects 665
Adding a Certificate Revocation List to a Trusted CA Object 665
External Certificate Objects 666
Adding External Certificate Objects 666
Internal Certificate Objects 667
Adding Internal Certificate Objects 667
Certificate Enrollment Objects 668
Adding Certificate Enrollment Objects 669
Certificate Enrollment Object EST Options 671
Certificate Enrollment Object SCEP Options 672
Certificate Enrollment Object Certificate Parameters 672
Certificate Enrollment Object Key Options 673
Certificate Enrollment Object Revocation Options 675
Key Chain Objects 676
Creating Key Chain Objects 677
DNS Server Group Objects 678
Creating DNS Server Group Objects 678
About Dynamic Objects 679

xxiv
Contents
Add or Edit a Dynamic Object 679

SLA Monitor Objects 679
Prefix Lists 681
Configure IPv6 Prefix List 681
Configure IPv4 Prefix List 682
Route Maps 682
Access List 685
Configure Extended ACL Objects 686
Configure Standard ACL Objects 687
AS Path Objects 688
Community Lists 688
Policy Lists 690
VPN Objects 691
FTD IKE Policies 691
Configure IKEv1 Policy Objects 691
Configure IKEv2 Policy Objects 693
FTD IPsec Proposals 694

Configure IKEv1 IPsec Proposal Objects 695
Configure IKEv2 IPsec Proposal Objects 695
FTD Group Policy Objects 696
Configure Group Policy Objects 696
Group Policy General Options 697
Group Policy AnyConnect Options 699
Group Policy Advanced Options 702
FTD File Objects 703
FTD Certificate Map Objects 705
AnyConnect Custom Attributes Objects 706
Add AnyConnect Custom Attributes Objects 706
Add Custom Attributes to a Group Policy 708
Address Pools 708
FlexConfig Objects 709
RADIUS Server Groups 710
RADIUS Server Group Options 710
RADIUS Server Options 711

xxv
Contents
Add a Single Sign-on Server 712

History for Reusable Objects 714
CHAPTER 24 Firepower Threat Defense Certificate-Based Authentication 717
Requirements and Prerequisites for FTD Certificate-Based Authentication 717

Firepower Threat Defense VPN Certificate Guidelines and Limitations 718
Managing FTD Certificates 718
Installing a Certificate Using Self-Signed Enrollment 720
Installing a Certificate Using SCEP Enrollment 720

Installing a Certificate using EST Enrollment 721
Installing a Certificate Using Manual Enrollment 722
Installing a Certificate Using a PKCS12 File 723
Troubleshooting FTD Certificates 723
History for Firepower Threat Defense Certificate-Based Authentication 724
PART V Classic Device Configuration Basics 725
CHAPTER 25 Classic Device Management Basics 727
Requirements and Prerequisites for Classic Device Management 727

Remote Management Configuration (Classic Devices) 727
Changing the Management Port 727
Interface Configuration Settings 728
The Interfaces Page 728
Interface Icons 729
Configuring Sensing Interfaces 730
Disabling Interfaces 730
Managing Cisco ASA FirePOWER Interfaces 731
MTU Ranges for NGIPSv 732
Synchronizing Security Zone Object Revisions 732
CHAPTER 26 IPS Device Deployments and Configuration 735
Introduction to IPS Device Deployment and Configuration 735

License Requirements for IPS Device Deployment 735
Requirements and Prerequisites for IPS Device Deployment 735

xxvi
Contents
Passive IPS Deployments 736

Passive Interfaces on the Firepower System 736
Configuring Passive Interfaces 736
Inline IPS Deployments 737
Inline Interfaces on the Firepower System 739
Configuring Inline Interfaces 739
Inline Sets on the Firepower System 740
Viewing Inline Sets 741
Adding Inline Sets 741
Advanced Inline Set Options 742
Configuring Advanced Inline Set Options 742
Deleting Inline Sets 743
PART VI Firepower Threat Defense Getting Started 745
CHAPTER 27 Transparent or Routed Firewall Mode for Firepower Threat Defense 747
About the Firewall Mode 747

About Routed Firewall Mode 747
About Transparent Firewall Mode 748
Using the Transparent Firewall in Your Network 748
Passing Traffic For Routed-Mode Features 748
About Bridge Groups 749
Bridge Virtual Interface (BVI) 749
Bridge Groups in Transparent Firewall Mode 749
Bridge Groups in Routed Firewall Mode 750
Allowing Layer 3 Traffic 751
Allowed MAC Addresses 751
BPDU Handling 751
MAC Address vs. Route Lookups 752
Unsupported Features for Bridge Groups in Transparent Mode 753
Unsupported Features for Bridge Groups in Routed Mode 754
Default Settings 755
Guidelines for Firewall Mode 755
Set the Firewall Mode 756

xxvii
Contents
CHAPTER 28 Logical Devices for the Firepower Threat Defense on the Firepower 4100/9300 759
About Firepower Interfaces 759

Chassis Management Interface 759
Interface Types 760
FXOS Interfaces vs. Application Interfaces 761
Shared Interface Scalability 763
Shared Interface Best Practices 764
Shared Interface Usage Examples 765
Viewing Shared Interface Resources 771
Inline Set Link State Propagation for the Firepower Threat Defense 772
About Logical Devices 772
Standalone and Clustered Logical Devices 772
Logical Device Application Instances: Container and Native 773
Container Instance Interfaces 773
How the Chassis Classifies Packets 773
Classification Examples 774
Cascading Container Instances 777
Typical Multi-Instance Deployment 778
Automatic MAC Addresses for Container Instance Interfaces 779
Container Instance Resource Management 780
Performance Scaling Factor for Multi-Instance Capability 780
Container Instances and High Availability 780
Container Instances and Clustering 780
Licenses for Container Instances 780
Requirements and Prerequisites for Logical Devices 781
Requirements and Prerequisites for Hardware and Software Combinations 781
Requirements and Prerequisites for Container Instances 783
Requirements and Prerequisites for High Availability 784
Guidelines and Limitations for Logical Devices 785
Guidelines and Limitations for Firepower Interfaces 785
General Guidelines and Limitations 787
Configure Interfaces 788
Enable or Disable an Interface 788

xxviii
Contents
Configure a Physical Interface 788

Add an EtherChannel (Port Channel) 789
Add a VLAN Subinterface for Container Instances 791
Configure Logical Devices 792
Add a Resource Profile for Container Instances 792
Add a Standalone Firepower Threat Defense 793
Add a High Availability Pair 798
Change an Interface on a Firepower Threat Defense Logical Device 799
Connect to the Console of the Application 801
History for Firepower Threat Defense Logical Devices 802
PART VII Firepower Threat Defense Interfaces and Device Settings 809
CHAPTER 29 Interface Overview for Firepower Threat Defense 811
Management/Diagnostic Interface 811

Management Interface 811
Diagnostic Interface 811
Interface Mode and Types 812
Security Zones and Interface Groups 813
Auto-MDI/MDIX Feature 814
Default Settings for Interfaces 814
Enable the Physical Interface and Configure Ethernet Settings 815
Sync Interface Changes with the Firepower Management Center 816
CHAPTER 30 Regular Firewall Interfaces for Firepower Threat Defense 821
Requirements and Prerequisites for Regular Firewall Interfaces 821

Configure Firepower 1010 Switch Ports 822
About Firepower 1010 Switch Ports 822
Understanding Firepower 1010 Ports and Interfaces 822
Auto-MDI/MDIX Feature 823
Guidelines and Limitations for Firepower 1010 Switch Ports 823
Configure Switch Ports and Power Over Ethernet 824
Enable or Disable Switch Port Mode 824
Configure a VLAN Interface 825

xxix
Contents
Configure Switch Ports as Access Ports 826

Configure Switch Ports as Trunk Ports 828
Configure Power Over Ethernet 830
Configure EtherChannel and Redundant Interfaces 831
About EtherChannels and Redundant Interfaces 832
About Redundant Interfaces (ASA Platform Only) 832
About EtherChannels 832
Guidelines for EtherChannels and Redundant Interfaces 834
Configure a Redundant Interface (ASA Platform Only) 836
Configure an EtherChannel 837
Configure VLAN Subinterfaces and 802.1Q Trunking 839
Guidelines and Limitations for VLAN Subinterfaces 839
Maximum Number of VLAN Subinterfaces by Device Model 840
Add a Subinterface 840
Configure Routed and Transparent Mode Interfaces 841
About Routed and Transparent Mode Interfaces 841
Dual IP Stack (IPv4 and IPv6) 842
31-Bit Subnet Mask 842
Guidelines and Limitations for Routed and Transparent Mode Interfaces 843
Configure Routed Mode Interfaces 844
Configure Bridge Group Interfaces 848
Configure General Bridge Group Member Interface Parameters 848
Configure the Bridge Virtual Interface (BVI) 850
Configure IPv6 Addressing 851
About IPv6 851
Configure a Global IPv6 Address 852
Configure IPv6 Neighbor Discovery 854
Configure Advanced Interface Settings 856
About Advanced Interface Configuration 856
About MAC Addresses 856
About the MTU 858
About the TCP MSS 859
ARP Inspection for Bridge Group Traffic 860
MAC Address Table 860

xxx
Contents
Default Settings 860

Guidelines for ARP Inspection and the MAC Address Table 861
Configure the MTU 861
Configure the MAC Address 862
Add a Static ARP Entry 863
Add a Static MAC Address and Disable MAC Learning for a Bridge Group 864
Set Security Configuration Parameters 864
History for Regular Firewall Interfaces for Firepower Threat Defense 866
CHAPTER 31 Inline Sets and Passive Interfaces for Firepower Threat Defense 869
About IPS Interfaces 869

IPS Interface Types 869
About Hardware Bypass for Inline Sets 870
Hardware Bypass Triggers 870
Hardware Bypass Switchover 871
Snort Fail Open vs. Hardware Bypass 871
Hardware Bypass Status 871
Requirements and Prerequisites for Inline Sets 871
Guidelines for Inline Sets and Passive Interfaces 872
Configure a Passive Interface 873
Configure an Inline Set 875
History for Inline Sets and Passive Interfaces for Firepower Threat Defense 878
CHAPTER 32 DHCP and DDNS Services for Threat Defense 881
About DHCP and DDNS Services 881

About the DHCPv4 Server 881
DHCP Options 881
About the DHCP Relay Agent 882
Requirements and Prerequisites for DHCP and DDNS 882
Guidelines for DHCP and DDNS Services 882
Configure the DHCP Server 884
Configure the DHCP Relay Agent 885
Configure Dynamic DNS 886

xxxi
Contents
CHAPTER 33 SNMP for the Firepower 1000/2100 893
About SNMP for the Firepower 1000/2100 Series 893

Enabling SNMP and Configuring SNMP Properties for Firepower 1000/2100 893
Creating an SNMP Trap for Firepower 1000/2100 894
Creating an SNMP User for Firepower 1000/2100 896
CHAPTER 34 Quality of Service (QoS) for Firepower Threat Defense 897
Introduction to QoS 897

About QoS Policies 897
Requirements and Prerequisites for QoS 898
Rate Limiting with QoS Policies 898
Creating a QoS Policy 899
Setting Target Devices for a QoS Policy 900
Configuring QoS Rules 900
QoS Rule Components 901
History for QOS 902
PART VIII Firepower Threat Defense High Availability and Scalability 905
CHAPTER 35 High Availability for Firepower Threat Defense 907
About Firepower Threat Defense High Availability 907

High Availability System Requirements 907
Hardware Requirements 907
Software Requirements 908
License Requirements for FTD Devices in a High Availability Pair 908
Failover and Stateful Failover Links 909
Failover Link 909
Stateful Failover Link 910
Avoiding Interrupted Failover and Data Links 910
MAC Addresses and IP Addresses in High Availability 912
Stateful Failover 913
Supported Features 914
Unsupported Features 915

xxxii
Contents
Bridge Group Requirements for High Availability 916

Failover Health Monitoring 916
Unit Health Monitoring 916
Interface Monitoring 917
Failover Triggers and Detection Timing 918
About Active/Standby Failover 919
Primary/Secondary Roles and Active/Standby Status 919
Active Unit Determination at Startup 920
Failover Events 920
Requirements and Prerequisites for High Availability 921
Guidelines for High Availability 921
Add a Firepower Threat Defense High Availability Pair 923
Configure Optional High Availability Parameters 925
Configure Standby IP Addresses and Interface Monitoring 925
Edit High Availability Failover Criteria 926
Configure Virtual MAC addresses 926
Manage High Availability 927
Switch the Active Peer in a Firepower Threat Defense High Availability Pair 927
Refresh Node Status in a Firepower Threat Defense High Availability Pair 927
Suspend and Resume High Availability 928
Replace a Unit in an FTD High Availability Pair 929
Replace a Primary FTD HA Unit with no Backup 929
Replace a Secondary FTD HA Unit with no Backup 930
Separate Units in a High Availability Pair 930
Unregister a High Availability Pair 931
Monitoring High Availability 932
View Failover History 932
View Stateful Failover Statistics 932
CHAPTER 36 Clustering for the Firepower Threat Defense 935
About Clustering on the Firepower 4100/9300 Chassis 935

Bootstrap Configuration 936
Cluster Members 936
Cluster Control Link 936

xxxiii
Contents
Size the Cluster Control Link for Inter-Chassis Clustering 937

Cluster Control Link Redundancy for Inter-Chassis Clustering 937
Cluster Control Link Reliability for Inter-Chassis Clustering 938
Cluster Control Link Network 938
Management Network 938
Management Interface 938
Cluster Interfaces 939
Spanned EtherChannels 939
Connecting to a VSS or vPC 940
Configuration Replication 940
Licenses for Clustering 940
Requirements and Prerequisites for Clustering 941
Clustering Guidelines and Limitations 944
Configure Clustering 948
FXOS: Add a Firepower Threat Defense Cluster 948
Create a Firepower Threat Defense Cluster 948
Add More Cluster Units 959
FMC: Add a Cluster 960
FMC: Configure Cluster, Data, and Diagnostic Interfaces 966
FXOS: Remove a Cluster Unit 967
FMC: Manage Cluster Members 969
Add a New Cluster Member 969
Replace a Cluster Member 970
Deactivate a Member 971
Rejoin the Cluster 972
Delete a Data Unit 972
Change the Control Unit 973
Reconcile Cluster Members 974
FMC: Monitoring the Cluster 974
Reference for Clustering 976
Firepower Threat Defense Features and Clustering 976
Unsupported Features with Clustering 976
Centralized Features for Clustering 976
Dynamic Routing and Clustering 977

xxxiv
Contents
Connection Settings 978

FTP and Clustering 978
NAT and Clustering 978
SIP Inspection and Clustering 979
SNMP and Clustering 979
Syslog and Clustering 980
TLS/SSL Connections and Clustering 980
Cisco TrustSec and Clustering 980
VPN and Clustering 980
Performance Scaling Factor 980
Control Unit Election 981
High Availability Within the Cluster 981
Chassis-Application Monitoring 981
Unit Health Monitoring 982
Interface Monitoring 982
Decorator Application Monitoring 982
Status After Failure 982
Rejoining the Cluster 983
Data Path Connection State Replication 983
How the Cluster Manages Connections 984
Connection Roles 984
New Connection Ownership 985
Sample Data Flow 985
History for Clustering 986
PART IX Firepower Threat Defense Routing 991
CHAPTER 37 Routing Overview for Firepower Threat Defense 993
Path Determination 993

Supported Route Types 994
Static Versus Dynamic 994
Single-Path Versus Multipath 994
Flat Versus Hierarchical 994
Link-State Versus Distance Vector 995

xxxv
Contents
Supported Internet Protocols for Routing 995

Routing Table 996
How the Routing Table Is Populated 996
Administrative Distances for Routes 996
Backup Dynamic and Floating Static Routes 997
How Forwarding Decisions Are Made 998
Dynamic Routing and High Availability 998
Dynamic Routing in Clustering 998
Routing Table for Management Traffic 999
Equal-Cost Multi-Path (ECMP) Routing 999
About Route Maps 1000
Permit and Deny Clauses 1001
Match and Set Clause Values 1001
CHAPTER 38 Virtual Routing for Firepower Threat Defense 1003
About Virtual Routers and Virtual Routing and Forwarding (VRF) 1003
Applications of Virtual Routers 1004
Global and User-Defined Virtual Routers 1004
Configuring Policies to be Virtual-Router-Aware 1005

Interconnecting Virtual Routers 1006
Overlapping IP Addresses 1006
Configuring SNMP on User-Defined Virtual Routers 1007
Maximum Number of Virtual Routers By Device Model 1008
Requirements and Prerequisites for Virtual Routers 1009
Guidelines and Limitations for Virtual Routers 1009
Modifications to FMC Web Interface - Routing Page 1011
Manage Virtual Routers Page 1011
Create a Virtual Router 1011
Configure a Virtual Router 1012
Modify a Virtual Router 1013
Remove Virtual Routers 1014
Configuration Examples for Virtual Routers 1015
How to Route to a Distant Server through Virtual Routers 1015
How to Provide Internet Access with Overlapping Address Spaces 1019

xxxvi
Contents
How to Allow RA VPN Access to Internal Networks in Virtual Routing 1026

How to Secure Traffic from Networks in Multiple Virtual Routers over a Site-to-Site VPN 1029
How to Route Traffic between Two Overlapping Network Host in Virtual Routing 1032
How to Manage Overlapping Segments in Routed Firewall Mode with BVI Interfaces 1035
How to Configure User Authentication with Overlapping Networks 1039

History for Virtual Routers in Firepower Threat Defense 1045
CHAPTER 39 Static and Default Routes for Firepower Threat Defense 1047
About Static and Default Routes 1047

Default Route 1047
Static Routes 1048
Route to null0 Interface to Drop Unwanted Traffic 1048
Route Priorities 1048
Transparent Firewall Mode and Bridge Group Routes 1048
Static Route Tracking 1049
Requirements and Prerequisites for Static Routes 1049
Guidelines for Static and Default Routes 1050
Add a Static Route 1050
CHAPTER 40 OSPF for Firepower Threat Defense 1053
OSPF for Firepower Threat Defense 1053

About OSPF 1053
OSPF Support for Fast Hello Packets 1055
Prerequisites for OSPF Support for Fast Hello Packets 1055
OSPF Hello Interval and Dead Interval 1055
OSPF Fast Hello Packets 1055
Benefits of OSPF Fast Hello Packets 1055
Implementation Differences Between OSPFv2 and OSPFv3 1056
Requirements and Prerequisites for OSPF 1056
Guidelines for OSPF 1056
Configure OSPFv2 1058
Configure OSPF Areas, Ranges, and Virtual Links 1058
Configure OSPF Redistribution 1061
Configure OSPF Inter-Area Filtering 1062

xxxvii
Contents
Configure OSPF Filter Rules 1064

Configure OSPF Summary Addresses 1064
Configure OSPF Interfaces and Neighbors 1065
Configure OSPF Advanced Properties 1068
Configure OSPFv3 1070
Configure OSPFv3 Areas, Route Summaries, and Virtual Links 1070
Configure OSPFv3 Redistribution 1072
Configure OSPFv3 Summary Prefixes 1074
Configure OSPFv3 Interfaces, Authentication, and Neighbors 1074
Configure OSPFv3 Advanced Properties 1077
CHAPTER 41 BGP for Firepower Threat Defense 1081
About BGP 1081

Routing Table Changes 1081
When to Use BGP 1082
BGP Path Selection 1082
BGP Multipath 1083
Requirements and Prerequisites for BGP 1084
Guidelines for BGP 1084
Configure BGP 1085
Configure BGP Basic Settings 1085
Configure BGP General Settings 1087
Configure BGP Neighbor Settings 1089
Configure BGP Aggregate Address Settings 1092
Configure BGPv4 Filtering Settings 1093
Configure BGP Network Settings 1094
Configure BGP Redistribution Settings 1094
Configure BGP Route Injection Settings 1095
CHAPTER 42 RIP for Firepower Threat Defense 1097
About RIP 1097

Routing Update Process 1097
RIP Routing Metric 1098
RIP Stability Features 1098

xxxviii
Contents
RIP Timers 1098

Requirements and Prerequisites for RIP 1099
Guidelines for RIP 1099
Configure RIP 1100
CHAPTER 43 Multicast Routing for Firepower Threat Defense 1103
About Multicast Routing 1103

IGMP Protocol 1104
Stub Multicast Routing 1104
PIM Multicast Routing 1105
PIM Source Specific Multicast Support 1105
Multicast Bidirectional PIM 1105
PIM Bootstrap Router (BSR) 1106
PIM Bootstrap Router (BSR) Terminology 1106
Multicast Group Concept 1107
Multicast Addresses 1107
Clustering 1107
Requirements and Prerequisites for Multicast Routing 1107
Guidelines for Multicast Routing 1107
Configure IGMP Features 1108
Enable Multicast Routing 1109
Configure IGMP Protocol 1109
Configure IGMP Access Groups 1111
Configure IGMP Static Groups 1111
Configure IGMP Join Groups 1112
Configure PIM Features 1112
Configure PIM Protocol 1113
Configure PIM Neighbor Filters 1114
Configure PIM Bidirectional Neighbor Filters 1115
Configure PIM Rendezvous Points 1115
Configure PIM Route Trees 1116
Configure PIM Request Filters 1117
Configure the Firepower Threat Defense Device as a Candidate Bootstrap Router 1118
Configure Multicast Routes 1119

xxxix
Contents
Configure Multicast Boundary Filters 1119
PART X Firepower Threat Defense VPN 1121
CHAPTER 44 VPN Overview for Firepower Threat Defense 1123
VPN Types 1123

VPN Basics 1124
Internet Key Exchange (IKE) 1124
IPsec 1125
VPN Packet Flow 1126
VPN Licensing 1126
How Secure Should a VPN Connection Be? 1126
Complying with Security Certification Requirements 1127
Deciding Which Encryption Algorithm to Use 1127
Deciding Which Hash Algorithms to Use 1128
Deciding Which Diffie-Hellman Modulus Group to Use 1128
Deciding Which Authentication Method to Use 1129
Pre-shared Keys 1129
PKI Infrastructure and Digital Certificates 1129
Removed or Deprecated Hash Algorithms, Encryption Algorithms, and Diffie-Hellman Modulus

Groups 1131
VPN Topology Options 1131
Point-to-Point VPN Topology 1132
Hub and Spoke VPN Topology 1132
Full Mesh VPN Topology 1133
Implicit Topologies 1134
CHAPTER 45 Site-to-Site VPNs for Firepower Threat Defense 1135
About Firepower Threat Defense Site-to-site VPNs 1135

Firepower Threat Defense Site-to-site VPN Guidelines and Limitations 1136
Requirements and Prerequisites for Site-to-Site VPN 1137
Managing Firepower Threat Defense Site-to-site VPNs 1138
Configuring Firepower Threat Defense Site-to-site VPNs 1138
FTD VPN Endpoint Options 1139

xl
Contents
FTD VPN IKE Options 1142

FTD VPN IPsec Options 1145
FTD Advanced Site-to-site VPN Deployment Options 1147
FTD VPN Advanced IKE Options 1147
FTD VPN Advanced IPsec Options 1148
FTD Advanced Site-to-site VPN Tunnel Options 1148
About Virtual Tunnel Interfaces 1149
Backup Tunnel for VTI 1150
Guidelines and Limitations for Virtual Tunnel Interfaces 1150
Add a VTI Interface 1152
Create a Route-based Site-to-Site VPN 1153
Additional Configurations for VTI 1155
History for Site-to-Site VPNs 1156
CHAPTER 46 Remote Access VPNs for Firepower Threat Defense 1159
Remote Access VPN Overview 1159

Remote Access VPN Features 1160
AnyConnect Components 1161
Remote Access VPN Authentication 1162
Understanding Policy Enforcement of Permissions and Attributes 1163
Understanding AAA Server Connectivity 1164
License Requirements for Remote Access VPN 1165
Requirements and Prerequisites for Remote Access VPN 1165
Remote Access VPN Guidelines and Limitations 1166
Configuring a New Remote Access VPN Connection 1168
Prerequisites for Configuring Remote Access VPN 1168
Create a New Remote Access VPN Policy 1169
Update the Access Control Policy on the Firepower Threat Defense Device 1171
(Optional) Configure NAT Exemption 1172
Configure DNS 1173
Add an AnyConnect Client Profile XML File 1173
(Optional) Configure Split Tunneling 1174
Verify the Configuration 1174
Setting Target Devices for a Remote Access VPN Policy 1175

xli
Contents
Additional Remote Access VPN Configurations 1175

Configure Connection Profile Settings 1175
Configure Multiple Connection Profiles 1176
Configure IP Addresses for VPN Clients 1177
Configure AAA Settings for Remote Access VPN 1178
Create or Update Aliases for a Connection Profile 1184
Configure Access Interfaces for Remote Access VPN 1185
Configuring Remote Access VPN Advanced Options 1187
Cisco AnyConnect Remote Access VPN Client Images 1187
Remote Access VPN Address Assignment Policy 1188
Configure Certificate to Connection Profile Mapping 1189
Configure Group Policies 1190
Configuring LDAP Attribute Mapping 1191
Configuring VPN Load Balancing 1192
Configure IPsec Settings 1195
Configure AnyConnect Management VPN Tunnel 1200
Requirements and Prerequisites for AnyConnect Management VPN Tunnel 1201
Limitations of AnyConnect Management VPN Tunnel 1201
Configuring AnyConnect Management VPN Tunnel on FTD 1202
Multiple Certificate Authentication 1204
Limitations of Multiple Certificate Authentication 1204
Configuring Multiple Certificate Authentication 1204
Customizing Remote Access VPN AAA Settings 1205
Authenticate VPN Users via Client Certificates 1205
Configure Remote Access VPN Login via Client Certificate and AAA Server 1207
Manage Password Changes over VPN Sessions 1208
Send Accounting Records to the RADIUS Server 1209
Delegating Group Policy Selection to Authorization Server 1210
Override the Selection of Group Policy or Other Attributes by the Authorization Server 1211
Deny VPN Access to a User Group 1211

Restrict Connection Profile Selection for a User Group 1212
Update the AnyConnect Client Profile for Remote Access VPN Clients 1213
RADIUS Dynamic Authorization 1214
Configuring RADIUS Dynamic Authorization 1214

xlii
Contents
Two-Factor Authentication 1215

Configuring RSA Two-Factor Authentication 1215
Configuring Duo Two-Factor Authentication 1216
Secondary Authentication 1218
Configure Remote Access VPN Secondary Authentication 1219
Single Sign-on Authentication with SAML 2.0 1221
Configuring a SAML Single Sign-on Authentication 1221

Configuring SAML Authorization 1222
Configure SAML Authorization 1223
Remote Access VPN Examples 1224
How to Limit AnyConnect Bandwidth Per User 1224
Create and Set up an Active Directory Realm 1224
Create a QoS Policy and Rule 1225
Create or Update a Remote Access VPN Policy 1226
How to Use VPN Identity for User-id Based Access Control Rules 1226
Create and Set up an Active Directory Realm 1227
Create an Identity Policy and an Identity Rule 1227
Associate an Identity Policy with an Access Control Policy 1228
Create or Update a Remote Access VPN Policy 1229
History for Remote Access VPNs 1229
CHAPTER 47 Firepower Threat Defense Dynamic Access Policies Overview 1231
About Firepower Threat Defense Dynamic Access Policy 1231

Hierarchy of Policy Enforcement of Permissions and Attributes in FTD 1231
Licensing for Dynamic Access Policies 1233
Prerequisites for Dynamic Access Policy 1233
Guidelines and Limitations for Dynamic Access Policies 1233

Configure a Dynamic Access Policy (DAP) 1234
Create a Dynamic Access Policy 1234
Create a Dynamic Access Policy Record 1234
Configure AAA Criteria Settings for a DAP 1235
Configure Endpoint Attribute Selection Criteria in a DAP 1235
Add an Anti-Malware Endpoint Attribute to a DAP 1236
Add a Device Endpoint Attribute to a DAP 1237

xliii
Contents
Add AnyConnect Endpoint Attributes to a DAP 1237

Add NAC Endpoint Attributes to a DAP 1238
Add an Application Attribute to a DAP 1238
Add a Personal Firewall Endpoint Attribute to a DAP 1238
Add an Operating System Endpoint Attribute to a DAP 1239
Add a Process Endpoint Attribute to a DAP 1239
Add a Registry Endpoint Attribute to a DAP 1239
Add a File Endpoint Attribute to a DAP 1240
Add Certificate Authentication Attributes to DAP 1240
Configure Advanced Settings for a DAP 1241
Associate a DAP with a Remote Access VPN 1241
History for Dynamic Access Policy 1242
CHAPTER 48 VPN Monitoring for Firepower Threat Defense 1243
VPN Summary Dashboard 1243

Viewing the VPN Summary Dashboard 1243
VPN Session and User Information 1244
Viewing Remote Access VPN Active Sessions 1244
Viewing Remote Access VPN User Activity 1244
VPN Health Events 1245
Viewing VPN Health Events 1245
CHAPTER 49 VPN Troubleshooting for Firepower Threat Defense 1247
System Messages 1247

VPN System Logs 1247
Viewing VPN System Logs 1248
Debug Commands 1248
debug aaa 1250
debug crypto 1250
debug crypto ca 1251
debug crypto ikev1 1252
debug crypto ikev2 1252
debug crypto ipsec 1253
debug ldap 1253

xliv
Contents
debug ssl 1254

debug webvpn 1254
PART XI Firepower Threat Defense Advanced Settings 1257
CHAPTER 50 Threat Defense Service Policies 1259
About Firepower Threat Defense Service Policies 1259

How Service Policies Relate to FlexConfig and Other Features 1260
What Are Connection Settings? 1260
Requirements and Prerequisites for Service Policies 1261
Guidelines and Limitations for Service Policies 1261
Configure Firepower Threat Defense Service Policies 1262
Configure a Service Policy Rule 1263
Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass) 1265
The Asynchronous Routing Problem 1266
Guidelines and Limitations for TCP State Bypass 1267
Configure TCP State Bypass 1267
Disable TCP Sequence Randomization 1269
Examples for Service Policy Rules 1270
Protect Servers from a SYN Flood DoS Attack (TCP Intercept) 1270
Make the Firepower Threat Defense Device Appear on Traceroutes 1273
Monitoring Service Policies 1274
History for Firepower Threat Defense Service Policy 1275
CHAPTER 51 FlexConfig Policies for Firepower Threat Defense 1277
FlexConfig Policy Overview 1277

Recommended Usage for FlexConfig Policies 1278
CLI Commands in FlexConfig Objects 1278
Determine the ASA Software Version and Current CLI Configuration 1279
Prohibited CLI Commands 1279
Template Scripts 1281
FlexConfig Variables 1281
How to Process Variables 1282
How to See What a Variable Will Return for a Device 1285

xlv
Contents
FlexConfig Policy Object Variables 1286

FlexConfig System Variables 1287
Predefined FlexConfig Objects 1288
Predefined Text Objects 1292
Requirements and Prerequisites for FlexConfig Policies 1297
Guidelines and Limitations for FlexConfig 1297
Customizing Device Configuration with FlexConfig Policies 1297
Configure FlexConfig Objects 1299
Add a Policy Object Variable to a FlexConfig Object 1302
Configure Secret Keys 1302
Configure FlexConfig Text Objects 1303
Configure the FlexConfig Policy 1305
Set Target Devices for a FlexConfig Policy 1306
Preview the FlexConfig Policy 1306
Verify the Deployed Configuration 1307
Remove Features Configured Using FlexConfig 1309
Convert from FlexConfig to Managed Feature 1310
Examples for FlexConfig 1311
How to Configure Precision Time Protocol (ISA 3000) 1311
How to Configure Automatic Hardware Bypass for Power Failure (ISA 3000) 1315
How to Configure Policy Based Routing 1317
History for FlexConfig 1325
CHAPTER 52 Alarms for the Cisco ISA 3000 1329
About Alarms 1329

Alarm Input Interfaces 1330
Alarm Output Interface 1330
Syslog Alarms 1331
SNMP Alarms 1331
Defaults for Alarms 1331
Requirements and Prerequisites for Alarms 1332
Configure the Alarms for the ISA 3000 1332
Configure Alarm Input Contacts 1332

Configure Power Supply Alarms 1335

xlvi
Contents
Configure Temperature Alarms 1337

Monitoring Alarms 1340
Monitoring Alarm Status 1340
Monitoring Syslog Messages for Alarms 1340
Turning Off the External Alarm 1341
History for Alarms 1341
PART XII Appliance Platform Settings 1343
CHAPTER 53 System Configuration 1345
Requirements and Prerequisites for the System Configuration 1346

About System Configuration 1346
Navigating the Firepower Management Center System Configuration 1346
System Configuration Settings 1346
Appliance Information 1348
HTTPS Certificates 1349
Default HTTPS Server Certificates 1350
Custom HTTPS Server Certificates 1350
HTTPS Server Certificate Requirements 1350
HTTPS Client Certificates 1352
Viewing the Current HTTPS Server Certificate 1352
Generating an HTTPS Server Certificate Signing Request 1352
Importing HTTPS Server Certificates 1354
Requiring Valid HTTPS Client Certificates 1355
Renewing the Default HTTPS Server Certificate 1356
External Database Access Settings 1356
Enabling External Access to the Database 1357
Database Event Limits 1358
Configuring Database Event Limits 1358
Database Event Limits 1358
Management Interfaces 1361
About FMC Management Interfaces 1361
Management Interfaces on the FMC 1361
Management Interface Support Per FMC Model 1362

xlvii
Contents
Network Routes on FMC Management Interfaces 1362

NAT Environments 1363
Management and Event Traffic Channel Examples 1364
Modify FMC Management Interfaces 1365
Shut Down or Restart 1369
Shut Down or Restart the FMC 1369
Remote Storage Management 1370
Configuring Local Storage 1370
Configuring NFS for Remote Storage 1370
Configuring SMB for Remote Storage 1371
Configuring SSH for Remote Storage 1372
Remote Storage Management Advanced Options 1373
Change Reconciliation 1373
Configuring Change Reconciliation 1374
Change Reconciliation Options 1374
Policy Change Comments 1375
Configuring Comments to Track Policy Changes 1375
Access List 1375
Configure an Access List 1376
Audit Logs 1377
Stream Audit Logs to Syslog 1377
Stream Audit Logs to an HTTP Server 1378
Audit Log Certificate 1379
Securely Stream Audit Logs 1380
Obtain a Signed Audit Log Client Certificate for the FMC 1381
Import an Audit Log Client Certificate into the FMC 1382
Require Valid Audit Log Server Certificates 1382
View the Audit Log Client Certificate on the FMC 1384
Dashboard Settings 1384
Enabling Custom Analysis Widgets for Dashboards 1384
DNS Cache 1384

Configuring DNS Cache Properties 1385
Email Notifications 1385
Configuring a Mail Relay Host and Notification Address 1386

xlviii
Contents
Language Selection 1386

Set the Language for the Web Interface 1386
Login Banners 1387
Customize the Login Banner 1387
SNMP Polling 1387
Configure SNMP Polling 1388
Time and Time Synchronization 1389
Synchronize Time on the FMC with an NTP Server 1389
Synchronize Time Without Access to a Network NTP Server 1391
About Changing Time Synchronization Settings 1392
View Current System Time, Source, and NTP Server Connection Status 1392
NTP Server Status 1393
Global User Configuration Settings 1393
Set Password Reuse Limit 1395
Track Successful Logins 1395
Enabling Temporary Lockouts 1396
Set Maximum Number of Concurrent Sessions 1396
Session Timeouts 1397
Configure Session Timeouts 1397
Vulnerability Mapping 1397
Mapping Vulnerabilities for Servers 1398
Remote Console Access Management 1398
Configuring Remote Console Settings on the System 1398
Lights-Out Management User Access Configuration 1400
Enabling Lights-Out Management User Access 1400
Serial Over LAN Connection Configuration 1400
Configuring Serial Over LAN with IPMItool 1401
Configuring Serial Over LAN with IPMIutil 1402
Lights-Out Management Overview 1402
Configuring Lights-Out Management with IPMItool 1403
Configuring Lights-Out Management with IPMIutil 1404
REST API Preferences 1404
Enabling REST API Access 1404
VMware Tools and Virtual Systems 1405

xlix
Contents
Enabling VMware Tools on the Firepower Management Center for VMware 1405
(Optional) Opt Out of Web Analytics Tracking 1405
History for System Configuration 1406
CHAPTER 54 Platform Settings Policies 1411
Introduction to Platform Settings 1411

Requirements and Prerequisites for Platform Settings Policies 1412
Managing Platform Settings Policies 1412
Create a Platform Settings Policy 1413
Setting Target Devices for a Platform Settings Policy 1413
CHAPTER 55 Platform Settings for Classic Devices 1415
About Platform Settings for Classic Devices 1415

Requirements for Platform Settings for Classic Devices 1416
Configure Platform Settings for Classic Devices 1416
Configure Access Lists for Classic Devices 1417
Stream Audit Logs from Classic Devices 1417
Require Valid Audit Log Server Certificates for Classic Devices 1419
Filter Syslogs from Audit Logs 1420
Customize the Login Banner for Classic Devices 1420
Synchronize Time on Classic Devices with an NTP Server 1421

Configure Session Timeouts for Classic Devices 1422
Configure SNMP Polling on Classic Devices 1422
CHAPTER 56 Platform Settings for Firepower Threat Defense 1425
Configure ARP Inspection 1425

Configure Banners 1427
Configure DNS 1427
Configure External Authentication for SSH 1429
Configure Fragment Handling 1433
Configure HTTP 1434
Configure ICMP Access Rules 1436
Configure SSL Settings 1437
About SSL Settings 1438

l
Contents
Configure Secure Shell 1441

Configure SMTP 1442
Configure SNMP for Threat Defense 1443
Add SNMPv3 Users 1444
Add SNMP Hosts 1446
Configure SNMP Traps 1448
About Configuring Syslog 1450
About Syslog 1450
Severity Levels 1451
Syslog Message Filtering 1451
Syslog Message Classes 1452
Guidelines for Logging 1455
Configure Syslog Logging for FTD Devices 1456
FTD Platform Settings That Apply to Security Event Syslog Messages 1457
Enable Logging and Configure Basic Settings 1457
Enable Logging Destinations 1458
Send Syslog Messages to an E-mail Address 1459
Create a Custom Event List 1460
Limit the Rate of Syslog Message Generation 1461
Configure Syslog Settings 1462
Configure a Syslog Server 1463
Configure Global Timeouts 1465
Configure NTP Time Synchronization for Threat Defense 1467
Configure Device Time Zone for Policy Application 1468
History for Firepower Threat Defense Platform Settings 1469
CHAPTER 57 Security Certifications Compliance 1473
Security Certifications Compliance Modes 1473

Security Certifications Compliance Characteristics 1474
Security Certifications Compliance Recommendations 1475
Appliance Hardening 1476
Protecting Your Network 1477
Enable Security Certifications Compliance 1478

li
Contents
PART XIII Network Address Translation (NAT) 1481
CHAPTER 58 NAT Policy Management 1483

Requirements and Prerequisites for NAT Policies 1483
Managing NAT Policies 1483
Creating NAT Policies 1484
Configuring NAT Policies 1485
Configuring NAT Policy Targets 1486
Copying NAT Policies 1487
CHAPTER 59 Network Address Translation (NAT) for Firepower Threat Defense 1489
Why Use NAT? 1489

NAT Basics 1490
NAT Terminology 1490
NAT Types 1490
NAT in Routed and Transparent Mode 1491
NAT in Routed Mode 1491
NAT in Transparent Mode or Within a Bridge Group 1492
Auto NAT and Manual NAT 1493
Auto NAT 1493
Manual NAT 1493
Comparing Auto NAT and Manual NAT 1494
NAT Rule Order 1494
NAT Interfaces 1496
Configuring Routing for NAT 1497
Addresses on the Same Network as the Mapped Interface 1497
Addresses on a Unique Network 1497
The Same Address as the Real Address (Identity NAT) 1497
Guidelines for NAT 1498
Firewall Mode Guidelines for NAT 1498
IPv6 NAT Guidelines 1498
IPv6 NAT Best Practices 1499
NAT Support for Inspected Protocols 1499

lii
Contents
Additional Guidelines for NAT 1501

Configure NAT for Threat Defense 1503
Customizing NAT Rules for Multiple Devices 1504
Searching and Filtering the NAT Rule Table 1507
Dynamic NAT 1507
About Dynamic NAT 1508
Dynamic NAT Disadvantages and Advantages 1509
Configure Dynamic Auto NAT 1509
Configure Dynamic Manual NAT 1511
Dynamic PAT 1513
About Dynamic PAT 1513
Dynamic PAT Disadvantages and Advantages 1514
PAT Pool Object Guidelines 1514
Configure Dynamic Auto PAT 1515
Configure Dynamic Manual PAT 1517
Configure PAT with Port Block Allocation 1520
Static NAT 1522
About Static NAT 1522
Configure Static Auto NAT 1526
Configure Static Manual NAT 1528
Identity NAT 1531
Configure Identity Auto NAT 1531
Configure Identity Manual NAT 1533
NAT Rule Properties for Firepower Threat Defense 1535
Interface Objects NAT Properties 1536
Translation Properties for Auto NAT 1536
Translation Properties for Manual NAT 1537
PAT Pool NAT Properties 1538
Advanced NAT Properties 1539
Translating IPv6 Networks 1540
NAT64/46: Translating IPv6 Addresses to IPv4 1541
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet 1541
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet and DNS Translation 1544
NAT66: Translating IPv6 Addresses to Different IPv6 Addresses 1547

liii
Contents
NAT66 Example, Static Translation between Networks 1547

NAT66 Example, Simple IPv6 Interface PAT 1550
Monitoring NAT 1553
Examples for NAT 1554
Providing Access to an Inside Web Server (Static Auto NAT) 1554
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server 1556
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT, One-to-Many) 1561
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation) 1564
Different Translation Depending on the Destination (Dynamic Manual PAT) 1569
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT) 1574
NAT and Site-to-Site VPN 1579
Rewriting DNS Queries and Responses Using NAT 1583
DNS64 Reply Modification 1584
DNS Reply Modification, DNS Server on Outside 1591
DNS Reply Modification, DNS Server on Host Network 1594
History for FTD NAT 1597
PART XIV Access Control 1599
CHAPTER 60 Understanding Access Control 1601
Introduction to Access Control 1601

Access Control Policy Default Action 1601
Deep Inspection Using File and Intrusion Policies 1603
Access Control Traffic Handling with Intrusion and File Policies 1604
File and Intrusion Inspection Order 1605
Access Control Policy Inheritance 1607
CHAPTER 61 Best Practices for Access Control 1609
General Best Practices for Access Control 1609

Best Practices for Access Control Rules 1610
Best Practices for Ordering Rules 1610
Rule Preemption 1611
Rule Actions and Rule Order 1611
Content Restriction Rule Order 1612

liv
Contents
Application Rule Order 1613

SSL Rule Order 1613
URL Rule Order 1614
Best Practices for Simplifying and Focusing Rules 1614
Maximum Number of Access Control Rules and Intrusion Policies 1615
CHAPTER 62 Access Control Policies 1617
Access Control Policy Components 1618

Requirements and Prerequisites for Access Control Policies 1619
Managing Access Control Policies 1620
System-Created Access Control Policies 1620
Creating a Basic Access Control Policy 1621
Editing an Access Control Policy 1622
Managing Access Control Policy Inheritance 1623
Choosing a Base Access Control Policy 1624
Inheriting Access Control Policy Settings from the Base Policy 1625
Locking Settings in Descendant Access Control Policies 1625
Requiring an Access Control Policy in a Domain 1626
Setting Target Devices for an Access Control Policy 1626
Logging Settings for Access Control Policies 1627
Access Control Policy Advanced Settings 1628
Associating Other Policies with Access Control 1632
Viewing Policy Hit Counts 1633
History for Access Control Policies 1634
CHAPTER 63 Access Control Rules 1637
Introduction to Access Control Rules 1637

Access Control Rule Management 1639
Access Control Rule Components 1640
Access Control Rule Order 1641
Requirements and Prerequisites for Access Control Rules 1642
Adding an Access Control Rule Category 1642
Create and Edit Access Control Rules 1643
Enabling and Disabling Access Control Rules 1644

lv
Contents
Copying Access Control Rules from One Access Control Policy to Another 1645
Moving Access Control Rules to a Prefilter Policy 1646
Positioning an Access Control Rule 1648
Access Control Rule Actions 1648
Access Control Rule Monitor Action 1648
Access Control Rule Trust Action 1649
Access Control Rule Blocking Actions 1649
Access Control Rule Interactive Blocking Actions 1650
Access Control Rule Allow Action 1651
Access Control Rule Comments 1651
Adding Comments to an Access Control Rule 1652
History for Access Control Rules 1652
CHAPTER 64 URL Filtering 1655
URL Filtering Overview 1655

About URL Filtering with Category and Reputation 1655
URL Category and Reputation Descriptions 1656
URL Filtering Data from the Cisco Cloud 1656
Best Practices for URL Filtering 1657

Filtering HTTPS Traffic 1660
License Requirements for URL Filtering 1660
Requirements and Prerequisites for URL Filtering 1661
How to Configure URL Filtering with Category and Reputation 1661
Enable URL Filtering Using Category and Reputation 1662
URL Filtering Options 1663
Configuring URL Conditions 1664
Rules with URL Conditions 1666
URL Rule Order 1666
DNS Filtering: Identify URL Reputation and Category During DNS Lookup 1666
Enable DNS Filtering to Identify URLs During Domain Lookup 1666
DNS Filtering Limitations 1667

DNS Filtering and Events 1667
Manual URL Filtering 1667
Manual URL Filtering Options 1668

lvi
Contents
Supplement or Selectively Override Category and Reputation-Based URL Filtering 1669

Configure URL Filtering Health Monitors 1670
Dispute URL Category and Reputation 1670
If the URL Category Set Changes, Take Action 1671
URL Category and Reputation Changes: Effect on Events 1672
Troubleshoot URL Filtering 1673
History for URL Filtering 1675
CHAPTER 65 HTTP Response Pages and Interactive Blocking 1679

About HTTP Response Pages 1679
Limitations to HTTP Response Pages 1679
Requirements and Prerequisites for HTTP Response Pages 1680
Choosing HTTP Response Pages 1681
Interactive Blocking with HTTP Response Pages 1681
Configuring Interactive Blocking 1682
Setting the User Bypass Timeout for a Blocked Website 1682
CHAPTER 66 Blocking Traffic with Security Intelligence 1685
About Security Intelligence 1685

Best Practices for Security Intelligence 1686
License Requirements for Security Intelligence 1686
Requirements and Prerequisites for Security Intelligence 1687
Security Intelligence Sources 1687
Configure Security Intelligence 1688
Security Intelligence Options 1689
Security Intelligence Categories 1691
Block List Icons 1692
Configuration Example: Security Intelligence Blocking 1693
Security Intelligence Monitoring 1694
Override Security Intelligence Blocking 1694
Troubleshooting Security Intelligence 1695
Security Intelligence Categories Are Missing from the Available Options List 1695
Troubleshooting Memory Use 1696
History for Security Intelligence Block Listing 1696

lvii
Contents
CHAPTER 67 DNS Policies 1697
DNS Policy Overview 1697

DNS Policy Components 1698
License Requirements for DNS Policies 1699
Requirements and Prerequisites for DNS Policies 1699
Managing DNS Policies 1699
Creating Basic DNS Policies 1700
Editing DNS Policies 1700
DNS Rules 1701
Creating and Editing DNS Rules 1702
DNS Rule Management 1702
Enabling and Disabling DNS Rules 1702
DNS Rule Order Evaluation 1703
DNS Rule Actions 1704
DNS Rule Conditions 1705
Controlling Traffic Based on DNS and Security Zone 1705
Controlling Traffic Based on DNS and Network 1706
Controlling Traffic Based on DNS and VLAN 1706
Controlling Traffic Based on DNS List, Feed, or Category 1707
DNS Policy Deploy 1708
CHAPTER 68 Prefiltering and Prefilter Policies 1709
About Prefiltering 1709

Prefiltering vs Access Control 1709
Passthrough Tunnels and Access Control 1711
Best Practices for Prefiltering 1712
Encapsulated Traffic Handling Best Practices 1712
Requirements and Prerequisites for Prefilter Policies 1714
Configure Prefiltering 1714
About Prefilter Policies 1715
Tunnel vs Prefilter Rules 1716
Tunnel and Prefilter Rule Components 1717
Tunnel Zones and Prefiltering 1718

lviii
Contents
Using Tunnel Zones 1719

Creating Tunnel Zones 1721
Moving Prefilter Rules to an Access Control Policy 1722
Prefilter Policy Hit Counts 1723
Large Flow Offloads 1723
Flow Offload Limitations 1725
History for Prefiltering 1726
CHAPTER 69 Intelligent Application Bypass 1729
Introduction to IAB 1729

IAB Options 1730
Requirements and Prerequisites for Intelligent Application Bypass 1732
Configuring Intelligent Application Bypass 1732
IAB Logging and Analysis 1733
CHAPTER 70 Access Control Using Content Restriction 1737
About Content Restriction 1737

Requirements and Prerequisites for Content Restriction 1738
Using Access Control Rules to Enforce Content Restriction 1739
Safe Search Options for Access Control Rules 1740
YouTube EDU Options for Access Control Rules 1740
Using a DNS Sinkhole to Enforce Content Restriction 1741
PART XV Encrypted Traffic Handling 1743
CHAPTER 71 Understanding Traffic Decryption 1745
Traffic Decryption Explained 1745

TLS/SSL Handshake Processing 1747
ClientHello Message Handling 1747
ServerHello and Server Certificate Message Handling 1749
TLS Crypto Acceleration 1750
TLS Crypto Acceleration Guidelines and Limitations 1751
View the Status of TLS Crypto Acceleration 1752
TLS/SSL Best Practices 1753

lix
Contents
The Case for Decryption 1753

When to Decrypt Traffic, When Not to Decrypt 1754
Decrypt and Resign (Outgoing Traffic) 1755
Known Key Decryption (Incoming Traffic) 1756
Other TLS/SSL Rule Actions 1756
TLS 1.3 Server Identity Discovery 1756
TLS/SSL Rule Examples 1757
Block Nonsecure Protocols 1757
TLS/SSL Rule Components 1759
TLS/SSL Rule Order Evaluation 1760
Multi-Rule Example 1761
How to Configure TLS/SSL Policies and Rules 1762
TLS/SSL Inspection Appliance Deployment Scenarios 1763
Traffic Decryption in an Inline Deployment 1764
Encrypted Traffic Monitoring in an Inline Deployment 1766
Undecrypted Encrypted Traffic in an Inline Deployment 1766
Encrypted Traffic Blocking in an Inline Deployment 1767
Encrypted Traffic Inspection with a Private Key in an Inline Deployment 1768
Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment 1770
History for TLS/SSL 1772
CHAPTER 72 Start Creating SSL Policies 1775
SSL Policies Overview 1775

SSL Policy Default Actions 1776
Default Handling Options for Undecryptable Traffic 1777
Requirements and Prerequisites for SSL Policies 1778
Manage SSL Policies 1778
Create Basic SSL Policies 1779
Set Default Handling for Undecryptable Traffic 1780
Editing an SSL Policy 1781
CHAPTER 73 Get Started with TLS/SSL Rules 1783
TLS/SSL Rules Overview 1783

TLS/SSL Rule Guidelines and Limitations 1783

lx
Contents
Guideline for Using TLS/SSL Decryption 1784

TLS/SSL Rule Unsupported Features 1784
TLS/SSL Do Not Decrypt Guidelines 1785
TLS/SSL Decrypt - Resign Guidelines 1785
TLS/SSL Decrypt - Known Key Guidelines 1787
TLS/SSL Block Guidelines 1788
TLS/SSL Certificate Pinning Guidelines 1788
TLS/SSL Heartbeat Guidelines 1788
TLS/SSL Anonymous Cipher Suite Limitation 1789
TLS/SSL Normalizer Guidelines 1789
Other TLS/SSL Rule Guidelines 1789
Requirements and Prerequisites for TLS/SSL Rules 1790
Creating and Modifying TLS/SSL Rules 1790
Adding a TLS/SSL Rule to a Rule Category 1791
Positioning a TLS/SSL Rule by Number 1792
TLS/SSL Rule Traffic Handling 1792
Encrypted Traffic Inspection Configuration 1794
TLS/SSL Rule Order Evaluation 1795
TLS/SSL Rule Conditions 1796
TLS/SSL Rule Condition Types 1796
TLS/SSL Rule Actions 1798
TLS/SSL Rule Monitor Action 1798
TLS/SSL Rule Do Not Decrypt Action 1798
TLS/SSL Rule Blocking Actions 1798
TLS/SSL Rule Decrypt Actions 1799
Configuring TLS/SSL Rule Actions 1799
Configuring a Decrypt - Resign Action 1800
Configuring a Decrypt - Known Key Action 1800
TLS/SSL Rules Management 1801
TLS/SSL Rule Search 1801
Searching TLS/SSL Rules 1802
Enabling and Disabling TLS/SSL Rules 1802
Moving a TLS/SSL Rule 1802
Adding a New TLS/SSL Rule Category 1803

lxi
Contents
CHAPTER 74 Decryption Tuning Using TLS/SSL Rules 1805
TLS/SSL Rule Conditions Overview 1805

Requirements and Prerequisites for Decryption Tuning 1806
Server Certificate-Based TLS/SSL Rule Conditions 1806
Certificate Distinguished Name TLS/SSL Rule Conditions 1807
Controlling Encrypted Traffic by Certificate Distinguished Name 1807
Certificate TLS/SSL Rule Conditions 1809
Controlling Encrypted Traffic by Certificate 1810
Certificate Status TLS/SSL Rule Conditions 1810
Trusting External Certificate Authorities 1814
Matching Traffic on Certificate Status 1815
Cipher Suite TLS/SSL Rule Conditions 1818
Controlling Encrypted Traffic by Cipher Suite 1820
Encryption Protocol Version TLS/SSL Rule Conditions 1821
Controlling Traffic by Encryption Protocol Version 1821
CHAPTER 75 Monitor SSL Hardware Acceleration 1823
Informational Counters 1823

Alert Counters 1824
Error Counters 1824
Fatal Counters 1825
CHAPTER 76 Troubleshoot TLS/SSL Rules 1827
About TLS/SSL Oversubscription 1827

Troubleshoot TLS/SSL Oversubscription 1827
About TLS Heartbeat 1830
Troubleshoot TLS Heartbeat 1830
About TLS/SSL Pinning 1831
Troubleshoot TLS/SSL Pinning 1832
Troubleshoot Unknown or Bad Certificates or Certificate Authorities 1834
Verify TLS/SSL Cipher Suites 1836
PART XVI Advanced Malware Protection (AMP) and File Control 1839

lxii
Contents
CHAPTER 77 File Policies and Malware Protection 1841
About File Policies and Advanced Malware Protection 1841

File Policies 1841
Requirements and Prerequisites for File Policies 1842
License Requirements for File and Malware Policies 1843
Best Practices for File Policies and Malware Detection 1843
File Rule Best Practices 1843

File Detection Best Practices 1844
File Blocking Best Practices 1844
File Policy Best Practices 1845
How to Configure Malware Protection 1846
Plan and Prepare for Malware Protection 1846
Configure File Policies 1847
Add File Policies to Your Access Control Configuration 1848
Configuring an Access Control Rule to Perform Malware Protection 1849
Set Up Maintenance and Monitoring of Malware Protection 1850
Cloud Connections for Malware Protection 1850
AMP Cloud Connection Configurations 1851
Requirements and Best Practices for AMP Cloud Connections 1852
Choose an AMP Cloud 1852
Cisco AMP Private Cloud 1853
Managing Connections to the AMP Cloud (Public or Private) 1854
Change AMP Options 1855

Dynamic Analysis Connections 1856
Requirements for Dynamic Analysis 1856
Viewing the Default Dynamic Analysis Connection 1856
Dynamic Analysis On-Premises Appliance (Cisco Threat Grid) 1856
Enabling Access to Dynamic Analysis Results in the Public Cloud 1858

Maintain Your System: Update File Types Eligible for Dynamic Analysis 1859
File Policies and File Rules 1859
Create or Edit a File Policy 1859
Advanced and Archive File Inspection Options 1860
Managing File Policies 1863

lxiii
Contents
File Rules 1864

File Rule Components 1864
File Rule Actions 1866
Creating File Rules 1873
Access Control Rule Logging for Malware Protection 1874
Retrospective Disposition Changes 1874
(Optional) Malware Protection with AMP for Endpoints 1874
Comparison of Malware Protection: Firepower vs. AMP for Endpoints 1875
About Integrating Firepower with AMP for Endpoints 1876
Benefits of Integrating Firepower and AMP for Endpoints 1876
AMP for Endpoints and AMP Private Cloud 1876
Integrate Firepower and AMP for Endpoints 1877
History for File Policies and Malware Protection 1879
CHAPTER 78 File and Malware Inspection Performance and Storage Tuning 1881
File and Malware Inspection Performance and Storage Options 1881

Tuning File and Malware Inspection Performance and Storage 1883
PART XVII TID Intelligence and Threat Analysis 1885
CHAPTER 79 Cisco Threat Intelligence Director (TID) 1887

Cisco Threat Intelligence Director (TID) Overview 1887
TID and Security Intelligence 1889
Performance Impact of Threat Intelligence Director 1889
Cisco Threat Intelligence Director (TID) and High Availability Configurations 1890
Requirements and Prerequisites for Threat Intelligence Director 1890
Platform, Element, and License Requirements 1890
Source Requirements 1891
Source Content Limitations 1892
How To Set Up Cisco Threat Intelligence Director (TID) 1892
Configure Policies to Support TID 1893
Options for Ingesting Data Sources 1894
Fetch TAXII Feeds to Use as Sources 1895
Fetch Sources from a URL 1896

lxiv
Contents
Upload a Local File to Use as a Source 1897

Handling of Duplicate Indicators 1898
Configure TLS/SSL Settings for a TID Source 1898
User Roles with TID Access 1899
About Backing Up and Restoring TID Data 1900
Analyze TID Incident and Observation Data 1900
Observation and Incident Generation 1900
View and Manage Incidents 1902
Incident Summary Information 1903
Incident Details 1903
View Events for a TID Observation 1907
TID Observations in Firepower Management Center Events 1907
Factors That Affect the Action Taken 1908
TID-Firepower Management Center Action Prioritization 1908
View and Change Cisco Threat Intelligence Director (TID) Configurations 1912
View TID Status of Elements (Managed Devices) 1912
View and Manage Sources 1912
Source Summary Information 1913
Source Status Details 1914
View and Manage Indicators 1915
Indicator Summary Information 1916
Indicator Details 1917
View and Manage Observables 1918
Observable Summary Information 1919
Filter TID Data in Table Views 1919
Inheritance in TID Configurations 1920
Inheritance of TID Settings from Multiple Parents 1920
About Overriding Inherited TID Settings 1921
Edit TID Actions at the Source, Indicator, or Observable Level 1921
About Pausing Publishing 1922
Pause TID and Purge TID Data from Elements 1923
Pause or Publish TID Data at the Source, Indicator, or Observable Level 1923
Modify the Observable Publication Frequency 1924
About Adding TID Observables to the Do Not Block List 1925

lxv
Contents
Add TID Observables to a Do Not Block List 1925

View a STIX Source File 1926
Troubleshoot Cisco Threat Intelligence Director (TID) 1926
History for Cisco Threat Intelligence Director (TID) 1929
PART XVIII Intrusion Detection and Prevention 1933
CHAPTER 80 An Overview of Intrusion Detection and Prevention 1935
Network Analysis and Intrusion Policy Basics 1935

How Policies Examine Traffic For Intrusions 1936
Decoding, Normalizing, and Preprocessing: Network Analysis Policies 1937
Access Control Rules: Intrusion Policy Selection 1938
Intrusion Inspection: Intrusion Policies, Rules, and Variable Sets 1939
Intrusion Event Generation 1940
System-Provided and Custom Network Analysis and Intrusion Policies 1941
System-Provided Network Analysis and Intrusion Policies 1941
Benefits of Custom Network Analysis and Intrusion Policies 1943
Benefits of Custom Network Analysis Policies 1943
Benefits of Custom Intrusion Policies 1944
Limitations of Custom Policies 1945
License Requirements for Network Analysis and Intrusion Policies 1947
Requirements and Prerequisites for Network Analysis and Intrusion Policies 1947
The Navigation Panel: Network Analysis and Intrusion Policies 1947
Conflicts and Changes: Network Analysis and Intrusion Policies 1949
Exiting a Network Analysis or Intrusion Policy 1950
CHAPTER 81 Layers in Intrusion and Network Analysis Policies 1951
Layer Basics 1951

License Requirements for Network Analysis and Intrusion Policy Layers 1951
Requirements and Prerequisites for Network Analysis and Intrusion Policy Layers 1952
The Layer Stack 1952
The Base Layer 1953
System-Provided Base Policies 1953
Custom Base Policies 1953

lxvi
Contents
The Effect of Rule Updates on Base Policies 1954

Changing the Base Policy 1955
The Firepower Recommendations Layer 1955
Layer Management 1956
Shared Layers 1957
Managing Layers 1958
Navigating Layers 1959
Intrusion Rules in Layers 1959
Configuring Intrusion Rules in Layers 1961
Removing Rule Settings from Multiple Layers 1961
Accepting Rule Changes from a Custom Base Policy 1963
Preprocessors and Advanced Settings in Layers 1963
Configuring Preprocessors and Advanced Settings in Layers 1964
CHAPTER 82 Getting Started with Intrusion Policies 1967
Intrusion Policy Basics 1967

License Requirements for Intrusion Policies 1968
Requirements and Prerequisites for Intrusion Policies 1969
Managing Intrusion Policies 1969
Custom Intrusion Policy Creation 1970
Creating a Custom Snort 2 Intrusion Policy 1970
Editing Snort 2 Intrusion Policies 1971
Intrusion Policy Changes 1972
Access Control Rule Configuration to Perform Intrusion Prevention 1972
Access Control Rule Configuration and Intrusion Policies 1973
Configuring an Access Control Rule to Perform Intrusion Prevention 1973
Drop Behavior in an Inline Deployment 1973
Setting Drop Behavior in an Inline Deployment 1974
Drop Behavior in a Dual System Deployment 1974
Intrusion Policy Advanced Settings 1975
Optimizing Performance for Intrusion Detection and Prevention 1976
CHAPTER 83 Tuning Intrusion Policies Using Rules 1977
Intrusion Rule Tuning Basics 1977

lxvii
Contents
Intrusion Rule Types 1977

License Requirements for Intrusion Rules 1978
Requirements and Prerequisites for Intrusion Rules 1979
Viewing Intrusion Rules in an Intrusion Policy 1979
Intrusion Rules Page Columns 1979
Intrusion Rule Details 1980
Viewing Intrusion Rule Details 1981
Setting a Threshold for an Intrusion Rule 1982
Setting Suppression for an Intrusion Rule 1982
Setting a Dynamic Rule State from the Rule Details Page 1983
Setting an SNMP Alert for an Intrusion Rule 1984
Adding a Comment to an Intrusion Rule 1984
Intrusion Rule Filters in an Intrusion Policy 1984
Intrusion Rule Filters Notes 1985
Intrusion Policy Rule Filters Construction Guidelines 1985
Intrusion Rule Configuration Filters 1988
Intrusion Rule Content Filters 1988
Intrusion Rule Categories 1989
Intrusion Rule Filter Components 1990
Intrusion Rule Filter Usage 1991
Setting a Rule Filter in an Intrusion Policy 1991
Intrusion Rule States 1992
Intrusion Rule State Options 1992
Setting Intrusion Rule States 1993
Intrusion Event Notification Filters in an Intrusion Policy 1994
Intrusion Event Thresholds 1994
Intrusion Event Thresholds Configuration 1994
Adding and Modifying Intrusion Event Thresholds 1996
Viewing and Deleting Intrusion Event Thresholds 1997
Intrusion Policy Suppression Configuration 1998
Intrusion Policy Suppression Types 1998
Suppressing Intrusion Events for a Specific Rule 1998
Viewing and Deleting Suppression Conditions 1999
Dynamic Intrusion Rule States 2000

lxviii
Contents
Dynamic Intrusion Rule State Configuration 2001

Setting a Dynamic Rule State from the Rules Page 2001
Adding Intrusion Rule Comments 2003
CHAPTER 84 Tailoring Intrusion Protection to Your Network Assets 2005
About Firepower Recommended Rules 2005

Default Settings for Firepower Recommendations 2006
Advanced Settings for Firepower Recommendations 2007
Generating and Applying Firepower Recommendations 2008
Script Detection 2009
CHAPTER 85 Sensitive Data Detection 2011
Sensitive Data Detection Basics 2011

Global Sensitive Data Detection Options 2012
Individual Sensitive Data Type Options 2013
System-Provided Sensitive Data Types 2014
License Requirements for Sensitive Data Detection 2015
Requirements and Prerequisites for Sensitive Data Detection 2015
Configuring Sensitive Data Detection 2016
Monitored Application Protocols and Sensitive Data 2017
Selecting Application Protocols to Monitor 2018
Special Case: Sensitive Data Detection in FTP Traffic 2019
Custom Sensitive Data Types 2019
Data Patterns in Custom Sensitive Data Types 2020
Configuring Custom Sensitive Data Types 2022
Editing Custom Sensitive Data Types 2023
CHAPTER 86 Globally Limiting Intrusion Event Logging 2025
Global Rule Thresholding Basics 2025

Global Rule Thresholding Options 2026
License Requirements for Global Thresholds 2028
Requirements and Prerequisites for Global Thresholds 2028
Configuring Global Thresholds 2029
Disabling the Global Threshold 2029

lxix
Contents
CHAPTER 87 The Intrusion Rules Editor 2031
An Introduction to Intrusion Rule Editing 2031

License Requirements for the Intrusion Rule Editor 2032
Requirements and Prerequisites for the Intrusion Rule Editor 2032
Rule Anatomy 2032
The Intrusion Rule Header 2033
Intrusion Rule Header Action 2034
Intrusion Rule Header Protocol 2034
Intrusion Rule Header Direction 2035
Intrusion Rule Header Source and Destination IP Addresses 2035
Intrusion Rule Header Source and Destination Ports 2038
Intrusion Event Details 2039
Adding a Custom Classification 2042
Defining an Event Priority 2043
Defining an Event Reference 2043
Custom Rule Creation 2044
Writing New Rules 2045
Modifying Existing Rules 2046
Viewing Rule Documentation 2047
Adding Comments to Intrusion Rules 2047
Deleting Custom Rules 2048
Searching for Rules 2049
Search Criteria for Intrusion Rules 2049
Rule Filtering on the Intrusion Rules Editor Page 2050
Filtering Guidelines 2051
Keyword Filtering 2051
Character String Filtering 2052
Combination Keyword and Character String Filtering 2053
Filtering Rules 2053
Keywords and Arguments in Intrusion Rules 2053
The content and protected_content Keywords 2054
Basic content and protected_content Keyword Arguments 2055
content and protected_content Keyword Search Locations 2056

lxx
Contents
Overview: HTTP content and protected_content Keyword Arguments 2059

Overview: content Keyword Fast Pattern Matcher 2062
The replace Keyword 2065
The byte_jump Keyword 2066
The byte_test Keyword 2069
The byte_extract Keyword 2071
The byte_math Keyword 2073
Overview: The pcre Keyword 2076
pcre Syntax 2077
pcre Modifier Options 2078
pcre Example Keyword Values 2081
The metadata Keyword 2083
Service Metadata 2085
Metadata Search Guidelines 2089
IP Header Values 2090
ICMP Header Values 2093
TCP Header Values and Stream Size 2094
The stream_reassembly Keyword 2097
SSL Keywords 2098
The appid Keyword 2099
Application Layer Protocol Values 2100
The RPC Keyword 2100
The ASN.1 Keyword 2101
The urilen Keyword 2102
DCE/RPC Keywords 2103
SIP Keywords 2106
GTP Keywords 2108
SCADA Keywords 2119
Modbus Keywords 2119
DNP3 Keywords 2121
CIP and ENIP Keywords 2123
S7Commplus Keywords 2124
Packet Characteristics 2125
Active Response Keywords 2127

lxxi
Contents
The resp Keyword 2128

The react Keyword 2129
The detection_filter Keyword 2129
The tag Keyword 2130
The flowbits Keyword 2131
flowbits Keyword Options 2132
Guidelines for Using the flowbits Keyword 2133
flowbits Keyword Examples 2134
The http_encode Keyword 2139
http_encode Keyword Syntax 2140
http_encode Keyword example: Using Two http_endcode Keywords to Search for Two Encodings
2140
Overview: The file_type and file_group Keywords 2140

The file_type and file_group Keywords 2141
The file_data Keyword 2142
The pkt_data Keyword 2143
The base64_decode and base64_data Keywords 2143
CHAPTER 88 Intrusion Prevention Performance Tuning 2145
About Intrusion Prevention Performance Tuning 2145

License Requirements for Intrusion Prevention Performance Tuning 2146
Requirements and Prerequisites for Intrusion Prevention Performance Tuning 2146
Limiting Pattern Matching for Intrusions 2146
Regular Expression Limits Overrides for Intrusion Rules 2147
Overriding Regular Expression Limits for Intrusion Rules 2148
Per Packet Intrusion Event Generation Limits 2149
Limiting Intrusion Events Generated Per Packet 2149
Packet and Intrusion Rule Latency Threshold Configuration 2150
Latency-Based Performance Settings 2150
Packet Latency Thresholding 2150
Packet Latency Thresholding Notes 2151
Enabling Packet Latency Thresholding 2152
Configuring Packet Latency Thresholding 2152
Rule Latency Thresholding 2153

lxxii
Contents
Rule Latency Thresholding Notes 2154

Configuring Rule Latency Thresholding 2155
Intrusion Performance Statistic Logging Configuration 2156
Configuring Intrusion Performance Statistic Logging 2156
PART XIX Advanced Network Analysis and Preprocessing 2159
CHAPTER 89 Advanced Access Control Settings for Network Analysis and Intrusion Policies 2161
About Advanced Access Control Settings for Network Analysis and Intrusion Policies 2161
Requirements and Prerequisites for Advanced Access Control Settings for Network Analysis and
Intrusion Policies 2161
Inspection of Packets That Pass Before Traffic Is Identified 2162
Best Practices for Handling Packets That Pass Before Traffic Identification 2162
Specify a Policy to Handle Packets That Pass Before Traffic Identification 2162
Advanced Settings for Network Analysis Policies 2163
Setting the Default Network Analysis Policy 2164
Network Analysis Rules 2165
Configuring Network Analysis Rules 2165
Managing Network Analysis Rules 2166
CHAPTER 90 Getting Started with Network Analysis Policies 2167
Network Analysis Policy Basics 2167

License Requirements for Network Analysis Policies 2168
Requirements and Prerequisites for Network Analysis Policies 2168
Managing Network Analysis Policies 2168
Custom Network Analysis Policy Creation for Snort 3 2169
Network Analysis Policy Mapping 2173

View Network Analysis Policy Mapping 2173
Create a Network Analysis Policy 2173
Modify the Network Analysis Policy 2173
Customize the Network Analysis Policy 2174
Custom Network Analysis Policy Creation for Snort 2 2178
Creating a Custom Network Analysis Policy 2178

Network Analysis Policy Management for Snort 2 2179

lxxiii
Contents
Network Analysis Policy Settings and Cached Changes 2179

Editing Network Analysis Policies 2180
Preprocessor Configuration in a Network Analysis Policy for Snort 2 2181
Preprocessor Traffic Modification in Inline Deployments 2182

Preprocessor Configuration in a Network Analysis Policy Notes 2182
CHAPTER 91 Application Layer Preprocessors 2185
Introduction to Application Layer Preprocessors 2185

License Requirements for Application Layer Preprocessors 2186
Requirements and Prerequisites for Application Layer Preprocessors 2186
The DCE/RPC Preprocessor 2186
Connectionless and Connection-Oriented DCE/RPC Traffic 2187
DCE/RPC Target-Based Policies 2188
RPC over HTTP Transport 2189
DCE/RPC Global Options 2189
DCE/RPC Target-Based Policy Options 2191
Traffic-Associated DCE/RPC Rules 2195
Configuring the DCE/RPC Preprocessor 2195
The DNS Preprocessor 2197
DNS Preprocessor Options 2198
Configuring the DNS Preprocessor 2200
The FTP/Telnet Decoder 2201
Global FTP and Telnet Options 2201
Telnet Options 2201
Server-Level FTP Options 2202
FTP Command Validation Statements 2204
Client-Level FTP Options 2205
Configuring the FTP/Telnet Decoder 2207
The HTTP Inspect Preprocessor 2208
Global HTTP Normalization Options 2209
Server-Level HTTP Normalization Options 2210
Server-Level HTTP Normalization Encoding Options 2218
Configuring The HTTP Inspect Preprocessor 2221
Additional HTTP Inspect Preprocessor Rules 2222

lxxiv
Contents
The Sun RPC Preprocessor 2223

Sun RPC Preprocessor Options 2223
Configuring the Sun RPC Preprocessor 2224
The SIP Preprocessor 2225
SIP Preprocessor Options 2226
Configuring the SIP Preprocessor 2228
Additional SIP Preprocessor Rules 2229
The GTP Preprocessor 2230
GTP Preprocessor Rules 2230
Configuring the GTP Preprocessor 2231
The IMAP Preprocessor 2232
IMAP Preprocessor Options 2232
Configuring the IMAP Preprocessor 2233
Additional IMAP Preprocessor Rules 2234
The POP Preprocessor 2234
POP Preprocessor Options 2235
Configuring the POP Preprocessor 2236
Additional POP Preprocessor Rules 2237
The SMTP Preprocessor 2237
SMTP Preprocessor Options 2238
Configuring SMTP Decoding 2242
The SSH Preprocessor 2243
SSH Preprocessor Options 2244
Configuring the SSH Preprocessor 2246
The SSL Preprocessor 2247
How SSL Preprocessing Works 2247
SSL Preprocessor Options 2248
Configuring the SSL Preprocessor 2250
SSL Preprocessor Rules 2251
CHAPTER 92 SCADA Preprocessors 2253
Introduction to SCADA Preprocessors 2253

License Requirements for SCADA Preprocessors 2253
Requirements and Prerequisites for SCADA Preprocessors 2254

lxxv
Contents
The Modbus Preprocessor 2254

Modbus Preprocessor Ports Option 2254
Configuring the Modbus Preprocessor 2255
Modbus Preprocessor Rules 2256
The DNP3 Preprocessor 2256
DNP3 Preprocessor Options 2256
Configuring the DNP3 Preprocessor 2257
DNP3 Preprocessor Rules 2258
The CIP Preprocessor 2258
CIP Preprocessor Options 2259
CIP Events 2259
CIP Preprocessor Rules 2260
Guidelines for Configuring the CIP Preprocessor 2260
Configuring the CIP Preprocessor 2261
The S7Commplus Preprocessor 2262
Configuring the S7Commplus Preprocessor 2262
CHAPTER 93 Transport & Network Layer Preprocessors 2265
Introduction to Transport and Network Layer Preprocessors 2265

License Requirements for Transport and Network Layer Preprocessors 2266
Requirements and Prerequisites for Transport and Network Layer Preprocessors 2266
Advanced Transport/Network Preprocessor Settings 2266
Ignored VLAN Headers 2266
Active Responses in Intrusion Drop Rules 2267
Advanced Transport/Network Preprocessor Options 2268
Configuring Advanced Transport/Network Preprocessor Settings 2269
Checksum Verification 2269
Checksum Verification Options 2270
Verifying Checksums 2270
The Inline Normalization Preprocessor 2271
Inline Normalization Options 2272
Configuring Inline Normalization 2276
The IP Defragmentation Preprocessor 2277
IP Fragmentation Exploits 2278

lxxvi
Contents
Target-Based Defragmentation Policies 2278

IP Defragmentation Options 2279
Configuring IP Defragmentation 2281
The Packet Decoder 2282
Packet Decoder Options 2283
Configuring Packet Decoding 2286
TCP Stream Preprocessing 2287
State-Related TCP Exploits 2287
Target-Based TCP Policies 2288
TCP Stream Reassembly 2288
TCP Stream Preprocessing Options 2289
Configuring TCP Stream Preprocessing 2296
UDP Stream Preprocessing 2298
UDP Stream Preprocessing Options 2298
Configuring UDP Stream Preprocessing 2299
CHAPTER 94 Detecting Specific Threats 2301
Introduction to Specific Threat Detection 2301

License Requirements for Specific Threat Detection 2301
Requirements and Prerequisites for Specific Threat Detection 2302
Back Orifice Detection 2302
Back Orifice Detection Preprocessor 2302
Detecting Back Orifice 2303
Portscan Detection 2303
Portscan Types, Protocols, and Filtered Sensitivity Levels 2304
Portscan Event Generation 2306
Portscan Event Packet View 2308
Configuring Portscan Detection 2309
Rate-Based Attack Prevention 2311
Rate-Based Attack Prevention Examples 2312
detection_filter Keyword Example 2312
Dynamic Rule State Thresholding or Suppression Example 2313
Policy-Wide Rate-Based Detection and Thresholding or Suppression Example 2314
Rate-Based Detection with Multiple Filtering Methods Example 2315

lxxvii
Contents
Rate-Based Attack Prevention Options and Configuration 2316

Rate-Based Attack Prevention, Detection Filtering, and Thresholding or Suppression 2317
Configuring Rate-Based Attack Prevention 2318
CHAPTER 95 Adaptive Profiles 2321
About Adaptive Profiles 2321

License Requirements for Adaptive Profiles 2322
Requirements and Prerequisites for Adaptive Profiles 2322
Adaptive Profile Updates 2322
Adaptive Profile Updates and Firepower Recommended Rules 2323
Adaptive Profile Options 2323
Configuring Adaptive Profiles 2324
PART XX Discovery and Identity 2327
CHAPTER 96 Introduction to Network Discovery and Identity 2329
About Detection of Host, Application, and User Data 2329

Host and Application Detection Fundamentals 2330
Passive Detection of Operating System and Host Data 2330
Active Detection of Operating System and Host Data 2331
Current Identities for Applications and Operating Systems 2331
Current User Identities 2332
Application and Operating System Identity Conflicts 2333
Netflow Data in the Firepower System 2333
Requirements for Using NetFlow Data 2334
Differences between NetFlow and Managed Device Data 2335
About User Identity 2337
Identity Terminology 2337
About User Identity Sources 2338
Best Practices for User Identity 2339
Identity Deployments 2341
How to Set Up an Identity Policy 2342
The User Activity Database 2345
The Users Database 2345

lxxviii
Contents
Firepower System Host and User Limits 2346

Firepower System Host Limit 2346
Firepower System User Limit 2347
CHAPTER 97 Host Identity Sources 2351
Overview: Host Data Collection 2351

Requirements and Prerequisites for Host Identity Sources 2352
Determining Which Host Operating Systems the System Can Detect 2352
Identifying Host Operating Systems 2352
Custom Fingerprinting 2353
Managing Fingerprints 2354
Activating and Deactivating Fingerprints 2354
Editing an Active Fingerprint 2355
Editing an Inactive Fingerprint 2355
Creating a Custom Fingerprint for Clients 2356
Creating a Custom Fingerprint for Servers 2358
Host Input Data 2361
Requirements for Using Third-Party Data 2361
Third-Party Product Mappings 2362
Mapping Third-Party Products 2362
Mapping Third-Party Product Fixes 2363
Mapping Third-Party Vulnerabilities 2364
Custom Product Mappings 2365
Creating Custom Product Mappings 2365
Editing Custom Product Mapping Lists 2367
Activating and Deactivating Custom Product Mappings 2367
Configuring the Host Input Client 2367
Nmap Scanning 2368
Nmap Remediation Options 2369
Nmap Scanning Guidelines 2376
Example: Using Nmap to Resolve Unknown Operating Systems 2377
Example: Using Nmap to Respond to New Hosts 2379
Managing Nmap Scanning 2380
Adding an Nmap Scan Instance 2380

lxxix
Contents
Editing an Nmap Scan Instance 2381

Adding an Nmap Scan Target 2382
Editing an Nmap Scan Target 2383
Creating an Nmap Remediation 2384
Editing an Nmap Remediation 2386
Running an On-Demand Nmap Scan 2386
Nmap Scan Results 2387
Viewing Nmap Scan Results 2387
Nmap Scan Results Fields 2388
Importing Nmap Scan Results 2389
History for Host Identity Sources 2390
CHAPTER 98 Application Detection 2391

Overview: Application Detection 2391
Application Detector Fundamentals 2392
Identification of Application Protocols in the Web Interface 2393
Implied Application Protocol Detection from Client Detection 2394
Host Limits and Discovery Event Logging 2395
Special Considerations for Application Detection 2395
Application Detection in Snort 2 and Snort 3 2396
Requirements and Prerequisites for Application Detection 2397

Custom Application Detectors 2397
Custom Application Detector and User-Defined Application Fields 2397
Configuring Custom Application Detectors 2400
Creating a User-Defined Application 2401
Specifying Detection Patterns in Basic Detectors 2402
Specifying Detection Criteria in Advanced Detectors 2403
Testing a Custom Application Protocol Detector 2404
Viewing or Downloading Detector Details 2405
Sorting the Detector List 2405
Filtering the Detector List 2406
Filter Groups for the Detector List 2406
Navigating to Other Detector Pages 2407
Activating and Deactivating Detectors 2407

lxxx
Contents
Editing Custom Application Detectors 2408

Deleting Detectors 2409
CHAPTER 99 Create and Manage Realms 2411
About Realms and Realm Sequences 2411

Realms and Trusted Domains 2413
Supported Servers for Realms 2416
Supported Server Object Class and Attribute Names 2417
License Requirements for Realms 2418
Requirements and Prerequisites for Realms 2418
Create a Realm and Realm Directory 2418
Realm Fields 2420
Realm Directory and Synchronize fields 2423
Connect Securely to Active Directory 2425
Find the Active Directory Server's Name 2426
Export the Active Directory Server's Root Certificate 2426
Synchronize Users and Groups 2428
Create a Realm Sequence 2428
Configure the FMC for Cross-Domain-Trust: The Setup 2430
Configure the FMC for Cross-Domain-Trust Step 1: Configure Realms and Directories 2431
Configure the FMC for Cross-Domain-Trust Step 2: Synchronize Users and Groups 2435
Configure the FMC for Cross-Domain-Trust Step 3: Resolve Issues 2436
Manage a Realm 2437
Compare Realms 2438
Troubleshoot Realms and User Downloads 2438
Detect Realm or User Mismatches 2441
Troubleshoot Cross-Domain Trust 2442
History for Realms 2446
CHAPTER 100 Control Users with ISE/ISE-PIC 2447

The ISE/ISE-PIC Identity Source 2447
Destination Security Group Tag (SGT) Matching 2448
License Requirements for ISE/ISE-PIC 2449
Requirements and Prerequisites for ISE/ISE-PIC 2449

lxxxi
Contents
ISE/ISE-PIC Guidelines and Limitations 2449

How to Configure ISE/ISE-PIC for User Control 2452
How to Configure ISE Without a Realm 2452
How to Configure ISE/ISE-PIC for User Control Using a Realm 2453
Configure ISE/ISE-PIC 2454
Configure Security Groups and SXP Publishing in ISE 2454
Export Certificates from the ISE/ISE-PIC Server for Use in the FMC 2456
Export a System Certificate 2457
Import ISE/ISE-PIC Certificates 2457
Configure ISE/ISE-PIC for User Control 2458
ISE/ISE-PIC Configuration Fields 2460
Troubleshoot the ISE/ISE-PIC or Cisco TrustSec Issues 2461
History for ISE/ISE-PIC 2462
CHAPTER 101 Control Users with Captive Portal 2465
The Captive Portal Identity Source 2465

License Requirements for Captive Portal 2466
Requirements and Prerequisites for Captive Portal 2466
Captive Portal Guidelines and Limitations 2466
How to Configure the Captive Portal for User Control 2468
Configure the Captive Portal Part 1: Create an Identity Policy 2470
Configure the Captive Portal Part 2: Create a TCP Port Access Control Rule 2471
Configure the Captive Portal Part 3: Create a User Access Control Rule 2472
Configure Captive Portal Part 4: Create an SSL Decrypt-Resign Policy 2473
Configure Captive Portal Part 5: Associate Identity and SSL Policies with the Access Control Policy
2474
Captive Portal Fields 2475

Exclude Applications from Captive Portal 2476
Troubleshoot the Captive Portal Identity Source 2477
History for Captive Portal 2478
CHAPTER 102 Control Users with Remote Access VPN 2479

The Remote Access VPN Identity Source 2479
Configure RA VPN for User Control 2480

lxxxii
Contents
Troubleshoot the Remote Access VPN Identity Source 2480

History for RA VPN 2481
CHAPTER 103 Control Users with the TS Agent 2483
The Terminal Services (TS) Agent Identity Source 2483

TS Agent Guidelines 2483
Configure the TS Agent for User Control 2484
Troubleshoot the TS Agent Identity Source 2484
History for TS Agent 2485
CHAPTER 104 Create and Manage Identity Policies 2487
About Identity Policies 2487

License Requirements for Identity Policies 2488
Requirements and Prerequisites for Identity Policies 2488
Create an Identity Rule 2489
Identity Rule Fields 2490
Create an Identity Policy 2492
Create an Identity Mapping Filter 2493
Manage an Identity Rule 2494
Manage an Identity Policy 2495
CHAPTER 105 Network Discovery Policies 2497
Overview: Network Discovery Policies 2497

Requirements and Prerequisites for Network Discovery Policies 2498
Network Discovery Customization 2498
Configuring the Network Discovery Policy 2499
Network Discovery Rules 2499
Configuring Network Discovery Rules 2500
Actions and Discovered Assets 2501
Monitored Networks 2501
Port Exclusions 2504
Zones in Network Discovery Rules 2505
The Traffic-Based Detection Identity Source 2506
Configuring Advanced Network Discovery Options 2508

lxxxiii
Contents
Network Discovery General Settings 2509

Configuring Network Discovery General Settings 2510
Network Discovery Identity Conflict Settings 2510
Configuring Network Discovery Identity Conflict Resolution 2511
Network Discovery Vulnerability Impact Assessment Options 2511
Enabling Network Discovery Vulnerability Impact Assessment 2512
Indications of Compromise 2512
Enabling Indications of Compromise Rules 2513
Adding NetFlow Exporters to a Network Discovery Policy 2514
Network Discovery Data Storage Settings 2514
Configuring Network Discovery Data Storage 2516
Configuring Network Discovery Event Logging 2516
Adding Network Discovery OS and Server Identity Sources 2517
Troubleshooting Your Network Discovery Strategy 2518
PART XXI Correlation and Compliance 2521
CHAPTER 106 Compliance Allow Lists 2523
Introduction to Compliance Allow Lists 2523

Compliance Allow List Target Networks 2524
Compliance Allow List Host Profiles 2525
Operating System-Specific Host Profiles 2526
Shared Host Profiles 2526
Allow Violation Triggers 2527
Requirements and Prerequisites for Compliance 2528
Creating a Compliance Allow List 2528
Setting Target Networks for a Compliance Allow List 2530
Building Allow List Host Profiles 2530
Adding an Application Protocol to a Compliance Allow List 2532
Adding a Client to a Compliance Allow List 2532
Adding a Web Application to a Compliance Allow List 2533
Adding a Protocol to a Compliance Allow List 2533
Managing Compliance Allow Lists 2534
Editing a Compliance Allow List 2534

lxxxiv
Contents
Managing Shared Host Profiles 2536
CHAPTER 107 Correlation Policies 2537
Introduction to Correlation Policies and Rules 2537

Requirements and Prerequisites for Compliance 2538
Configuring Correlation Policies 2539
Adding Responses to Rules and Allow Lists 2539
Managing Correlation Policies 2540
Configuring Correlation Rules 2541
Syntax for Intrusion Event Trigger Criteria 2542
Syntax for Malware Event Trigger Criteria 2545
Syntax for Discovery Event Trigger Criteria 2546
Syntax for User Activity Event Trigger Criteria 2549
Syntax for Host Input Event Trigger Criteria 2550
Syntax for Connection Event Trigger Criteria 2551
Syntax for Traffic Profile Changes 2554
Syntax for Correlation Host Profile Qualifications 2556
Syntax for User Qualifications 2559
Connection Trackers 2560
Adding a Connection Tracker 2561
Syntax for Connection Trackers 2561
Syntax for Connection Tracker Events 2564
Sample Configuration for Excessive Connections From External Hosts 2564
Sample Configuration for Excessive BitTorrent Data Transfers 2566
Snooze and Inactive Periods 2568
Correlation Rule Building Mechanics 2568
Adding and Linking Conditions in Correlation Rules 2570
Using Multiple Values in Correlation Rule Conditions 2571
Managing Correlation Rules 2571
Configuring Correlation Response Groups 2572
Managing Correlation Response Groups 2573
CHAPTER 108 Traffic Profiling 2575
Introduction to Traffic Profiles 2575

lxxxv
Contents
Traffic Profile Conditions 2577

Requirements and Prerequisites for Traffic Profiles 2579
Managing Traffic Profiles 2579
Configuring Traffic Profiles 2580
Adding Traffic Profile Conditions 2581
Adding Host Profile Qualifications to a Traffic Profile 2581
Syntax for Traffic Profile Conditions 2582
Syntax for Host Profile Qualifications in a Traffic Profile 2583
Using Multiple Values in a Traffic Profile Condition 2585
CHAPTER 109 Remediations 2587
Requirements and Prerequisites for Remediations 2587

Introduction to Remediations 2587
Cisco ISE EPS Remediations 2588
Configuring ISE EPS Remediations 2589
Cisco IOS Null Route Remediations 2590
Configuring Remediations for Cisco IOS Routers 2591
Nmap Scan Remediations 2595
Set Attribute Value Remediations 2596
Configuring Set Attribute Remediations 2596
Managing Remediation Modules 2597
Managing Remediation Instances 2598
Managing Instances for a Single Remediation Module 2598
PART XXII Reporting and Alerting 2601
CHAPTER 110 Working with Reports 2603
Requirements and Prerequisites for Reports 2603

Introduction to Reports 2603
Risk Reports 2604
Generating, Viewing, and Printing Risk Reports 2604
Standard Reports 2605
About Designing Reports 2605
Report Templates 2605

lxxxvi
Contents
Report Template Fields 2606

Report Template Creation 2607
Report Template Configuration 2611
Managing Report Templates 2622
About Generating Reports 2623
Generating Reports 2623
Report Generation Options 2625
Distributing Reports by Email at Generation Time 2625
Schedule Future Reports 2626
About Working with Generated Reports 2626
Viewing Reports 2626
Downloading Reports 2626
Storing Reports Remotely 2627
Moving Reports to Remote Storage 2628
Deleting Reports 2628
History for Reporting 2629
CHAPTER 111 External Alerting with Alert Responses 2631
Firepower Management Center Alert Responses 2631

Configurations Supporting Alert Responses 2632
Requirements and Prerequisites for Alert Responses 2632
Creating an SNMP Alert Response 2633
Creating a Syslog Alert Response 2634
Syslog Alert Facilities 2635
Syslog Severity Levels 2636
Creating an Email Alert Response 2637
Configuring Impact Flag Alerting 2637
Configuring Discovery Event Alerting 2638
Configuring AMP for Networks Alerting 2638
CHAPTER 112 External Alerting for Intrusion Events 2641
About External Alerting for Intrusion Events 2641

License Requirements for External Alerting for Intrusion Events 2642
Requirements and Prerequisites for External Alerting for Intrusion Events 2642

lxxxvii
Contents
Configuring SNMP Alerting for Intrusion Events 2642

Intrusion SNMP Alert Options 2643
Configuring Syslog Alerting for Intrusion Events 2644
Facilities and Severities for Intrusion Syslog Alerts 2645
Configuring Email Alerting for Intrusion Events 2646
Intrusion Email Alert Options 2646
PART XXIII Event and Asset Analysis Tools 2649
CHAPTER 113 Using the Context Explorer 2651
About the Context Explorer 2651

Differences Between the Dashboard and the Context Explorer 2652
The Traffic and Intrusion Event Counts Time Graph 2652
The Indications of Compromise Section 2653
The Hosts by Indication Graph 2653
The Indications by Host Graph 2653
The Network Information Section 2653
The Operating Systems Graph 2653
The Traffic by Source IP Graph 2654
The Traffic by Source User Graph 2654
The Connections by Access Control Action Graph 2654
The Traffic by Destination IP Graph 2655
The Traffic by Ingress/Egress Security Zone Graph 2655
The Application Information Section 2655
Focusing the Application Information Section 2656
The Traffic by Risk/Business Relevance and Application Graph 2656
The Intrusion Events by Risk/Business Relevance and Application Graph 2656
The Hosts by Risk/Business Relevance and Application Graph 2657
The Application Details List 2657
The Security Intelligence Section 2657
The Security Intelligence Traffic by Category Graph 2658
The Security Intelligence Traffic by Source IP Graph 2658
The Security Intelligence Traffic by Destination IP Graph 2658
The Intrusion Information Section 2658

lxxxviii
Contents
The Intrusion Events by Impact Graph 2659

The Top Attackers Graph 2659
The Top Users Graph 2659
The Intrusion Events by Priority Graph 2659
The Top Targets Graph 2659
The Top Ingress/Egress Security Zones Graph 2659
The Intrusion Event Details List 2660
The Files Information Section 2660
The Top File Types Graph 2660
The Top File Names Graph 2660
The Files by Disposition Graph 2661
The Top Hosts Sending Files Graph 2661
The Top Hosts Receiving Files Graph 2661
The Top Malware Detections Graph 2662
The Geolocation Information Section 2662
The Connections by Initiator/Responder Country Graph 2662
The Intrusion Events by Source/Destination Country Graph 2662
The File Events by Sending/Receiving Country Graph 2663
The URL Information Section 2663
The Traffic by URL Graph 2663
The Traffic by URL Category Graph 2663
The Traffic by URL Reputation Graph 2664
Requirements and Prerequisites for the Context Explorer 2664
Refreshing the Context Explorer 2664
Setting the Context Explorer Time Range 2665
Minimizing and Maximizing Context Explorer Sections 2665
Drilling Down on Context Explorer Data 2666
Filters in the Context Explorer 2667
Data Type Field Options 2668
Creating a Filter from the Add Filter Window 2670
Creating a Quick Filter from the Context Menu 2671
Saving Filtered Context Explorer Views 2671
Viewing Filter Data 2671
Deleting a Filter 2672

lxxxix
Contents
CHAPTER 114 Using the Network Map 2673
Requirements and Prerequisites for the Network Map 2673

The Network Map 2673
The Hosts Network Map 2674
The Network Devices Network Map 2675
The Mobile Devices Network Map 2676
The Indications of Compromise Network Map 2676
The Application Protocols Network Map 2676
The Vulnerabilities Network Map 2677
The Host Attributes Network Map 2678
Viewing Network Maps 2678
Custom Network Topologies 2679
Creating Custom Topologies 2680
Importing Networks from the Network Discovery Policy 2680
Manually Adding Networks to Your Custom Topology 2681
Activating and Deactivating Custom Topologies 2681
Editing Custom Topologies 2682
CHAPTER 115 Incidents 2683
About Incident Handling 2683

Definition of an Incident 2683
Common Incident Handling Processes 2684
Incident Types in the Firepower System 2686
License Requirements for Incidents 2687
Requirements and Prerequisites for Incidents 2687
Creating Custom Incident Types 2687
Creating an Incident 2688
Editing an Incident 2688
Generating Incident Reports 2689
CHAPTER 116 Using Lookups 2691
Introduction to Lookups 2691

Performing Whois Lookups 2691

xc
Contents
Finding URL Category and Reputation 2692

Finding Geolocation Information for an IP Address 2693
CHAPTER 117 Event Analysis Using External Tools 2695
Integrate with Cisco SecureX 2695

Access SecureX Using the Ribbon 2695
Event Analysis with Cisco SecureX threat response 2696
View Event Data in Cisco SecureX threat response 2696
Event Investigation Using Web-Based Resources 2697
About Managing Contextual Cross-Launch Resources 2697
Requirements for Custom Contextual Cross-Launch Resources 2698
Add Contextual Cross-Launch Resources 2698
Investigate Events Using Contextual Cross-Launch 2699
Configure Cross-Launch Links for Stealthwatch 2700
About Sending Syslog Messages for Security Events 2701
About Configuring the System to Send Security Event Data to Syslog 2701
Best Practices for Configuring Security Event Syslog Messaging 2701
Send Security Event Syslog Messages from FTD Devices 2702
Send Security Event Syslog Messages from Classic Devices 2704
Configuration Locations for Security Event Syslogs 2706
Anatomy of Security Event Syslog Messages 2709
Facility in Security Event Syslog Messages 2712
Firepower Syslog Message Types 2712
Limitations of Syslog for Security Events 2713
eStreamer Server Streaming 2713
Comparison of Syslog and eStreamer for Security Eventing 2714
Data Sent Only via eStreamer, Not via Syslog 2714
Choosing eStreamer Event Types 2715
Configuring eStreamer Client Communications 2716
Event Analysis in Splunk 2716
Event Analysis in IBM QRadar 2717
History for Analyzing Event Data Using External Tools 2717
PART XXIV Workflows 2723

xci
Contents
CHAPTER 118 Workflows 2725
Overview: Workflows 2725

Predefined Workflows 2726
Predefined Intrusion Event Workflows 2726
Predefined Malware Workflows 2727
Predefined File Workflows 2728
Predefined Captured File Workflows 2728
Predefined Connection Data Workflows 2729
Predefined Security Intelligence Workflows 2731
Predefined Host Workflows 2731
Predefined Indications of Compromise Workflows 2731
Predefined Applications Workflows 2732
Predefined Application Details Workflows 2733
Predefined Servers Workflows 2733
Predefined Host Attributes Workflows 2733
The Predefined Discovery Events Workflow 2734
Predefined User Workflows 2734
Predefined Vulnerabilities Workflows 2734
Predefined Third-Party Vulnerabilities Workflows 2735
Predefined Correlation and Allow List Workflows 2735
Predefined System Workflows 2735
Custom Table Workflows 2736
Using Workflows 2736
Workflow Access by User Role 2738
Workflow Selection 2738
Workflow Pages 2740
Workflow Page Navigation Tools 2741
Workflow Page Traversal Tools 2741
File Trajectory Icons 2742
Host Profile Icons 2742
Threat Score Icons 2742
User Icons 2743
The Workflow Toolbar 2743

xcii
Contents
Using Drill-Down Pages 2744

Using Table View Pages 2744
Work in Firepower Management Center with Connection Events Stored on a Stealthwatch Appliance
2745
Geolocation 2746
Geolocation Detail Information 2747
Connection Event Graphs 2748
Using Connection Event Graphs 2748
Event Time Constraints 2754
Per-Session Time Window Customization for Events 2755
The Default Time Window for Events 2758
Event View Constraints 2760
Constraining Events 2761
Compound Event View Constraints 2762
Using Compound Event View Constraints 2762
Inter-Workflow Navigation 2763
Working with the Unified Event Viewer 2764
Unified Event Viewer Column Descriptions 2766
Bookmarks 2767
Creating Bookmarks 2768
Viewing Bookmarks 2768
History for Workflows 2768
CHAPTER 119 Searching for Events 2771
Event Searches 2771

Search Constraints 2771
General Search Constraints 2772
Wildcards and Symbols in Searches 2772
Objects and Application Filters in Searches 2773
Time Constraints in Searches 2773
IP Addresses in Searches 2773
URLs in Searches 2775
Managed Devices in Searches 2775
Ports in Searches 2775

xciii
Contents
Event Fields in Searches 2776

Performing a Search 2776
Saving a Search 2778
Loading a Saved Search 2778
Query Overrides Via the Shell 2779
Shell-Based Query Management Syntax 2779
Stopping Long-Running Queries 2780
History for Searching for Events 2780
CHAPTER 120 Custom Workflows 2781
Introduction to Custom Workflows 2781

Saved Custom Workflows 2781
Custom Workflow Creation 2782
Creating Custom Workflows Based on Non-Connection Data 2784
Creating Custom Connection Data Workflows 2784
Custom Workflow Use and Management 2785
Viewing Custom Workflows Based on Predefined Tables 2786
Viewing Custom Workflows Based on Custom Tables 2786
Editing Custom Workflows 2787
CHAPTER 121 Custom Tables 2789
Introduction to Custom Tables 2789

Predefined Custom Tables 2789
Possible Table Combinations 2790
User-Defined Custom Tables 2793
Creating a Custom Table 2794
Modifying a Custom Table 2795
Deleting a Custom Table 2795
Viewing a Workflow Based on a Custom Table 2796
Searching Custom Tables 2796
History for Custom Tables 2797
PART XXV Events and Assets 2799

xciv
Contents
CHAPTER 122 Connection Logging 2801
About Connection Logging 2801

Connections That Are Always Logged 2802
Other Connections You Can Log 2803
How Rules and Policy Actions Affect Logging 2803
Logging for Fastpathed Connections 2804
Logging for Monitored Connections 2804

Logging for Trusted Connections 2804
Logging for Blocked Connections 2805
Logging for Allowed Connections 2806
Beginning vs End-of-Connection Logging 2807
Firepower Management Center vs External Logging 2808
Limitations of Connection Logging 2809
When Events Appear in the Event Viewer 2809
Best Practices for Connection Logging 2810
Requirements and Prerequisites for Connection Logging 2812
Configure Connection Logging 2812
Logging Connections with Tunnel and Prefilter Rules 2812
Logging Decryptable Connections with SSL Rules 2813
Logging Connections with Security Intelligence 2814
Logging Connections with Access Control Rules 2814
Logging Connections with a Policy Default Action 2815
Limiting Logging of Long URLs 2816
CHAPTER 123 Connection and Security Intelligence Events 2817
About Connection Events 2817

Connection vs. Security Intelligence Events 2818
NetFlow Connections 2818
Connection Summaries (Aggregated Data for Graphs) 2818
Long-Running Connections 2819
Combined Connection Summaries from External Responders 2819
Connection and Security Intelligence Event Fields 2819
About Connection and Security Intelligence Event Fields 2833

xcv
Contents
A Note About Initiator/Responder, Source/Destination, and Sender/Receiver Fields 2834

Connection Event Reasons 2834
Requirements for Populating Connection Event Fields 2835
Information Available in Connection Event Fields 2837
Using Connection and Security Intelligence Event Tables 2841
Viewing Files and Malware Detected in a Connection 2843
Viewing Intrusion Events Associated with a Connection 2844
Encrypted Connection Certificate Details 2844
Viewing the Connection Summary Page 2845
History for Connection and Security Intelligence Events 2846
CHAPTER 124 Working with Intrusion Events 2849
About Intrusion Events 2849

Tools for Reviewing and Evaluating Intrusion Events 2849
License Requirements for Intrusion Events 2850
Requirements and Prerequisites for Intrusion Events 2850
Viewing Intrusion Events 2851
About Intrusion Event Fields 2851
Intrusion Event Fields 2852
Intrusion Event Impact Levels 2863
Viewing Connection Data Associated with Intrusion Events 2865
Marking Intrusion Events Reviewed 2865
Viewing Previously Reviewed Intrusion Events 2866
Marking Reviewed Intrusion Events Unreviewed 2866
Preprocessor Events 2866
Preprocessor Generator IDs 2867
Intrusion Event Workflow Pages 2869
Using Intrusion Event Workflows 2870
Intrusion Event Drill-Down Page Constraints 2872
Intrusion Event Table View Constraints 2873
Using the Intrusion Event Packet View 2873
Event Information Fields 2875
Frame Information Fields 2881
Data Link Layer Information Fields 2882

xcvi
Contents
Viewing Network Layer Information 2882

Viewing Transport Layer Information 2885
Viewing Packet Byte Information 2887
Internally Sourced Intrusion Events 2887
The Intrusion Events Clipboard 2887
Generating Clipboard Reports 2888
Deleting Events from the Clipboard 2888
Viewing Intrusion Event Statistics 2889
Host Statistics 2890
Event Overview 2890
Event Statistics 2891
Viewing Intrusion Event Performance Graphs 2891
Intrusion Event Performance Statistics Graph Types 2892
Viewing Intrusion Event Graphs 2896
History for Intrusion Events 2897
CHAPTER 125 File/Malware Events and Network File Trajectory 2899
About File/Malware Events and Network File Trajectory 2899

File and Malware Events 2900
File and Malware Event Types 2900
File Events 2900
Malware Events 2901
Retrospective Malware Events 2901
Malware Events Generated by AMP for Endpoints 2902

Using File and Malware Event Workflows 2903
File and Malware Event Fields 2904
Malware Event Sub-Types 2914
Information Available in File and Malware Event Fields 2915
View Details About Analyzed Files 2918
File Composition Report 2918
View File Details in AMP Private Cloud 2918
Threat Scores and Dynamic Analysis Summary Reports 2919
Viewing Dynamic Analysis Results in the Cisco Threat Grid Public Cloud 2920
Using Captured File Workflows 2920

xcvii
Contents
Captured File Fields 2921

Stored Files Download 2925
Manually Submit Files for Analysis 2926
Network File Trajectory 2927
Recently Detected Malware and Analyzed Trajectories 2927
Network File Trajectory Detailed View 2927
Network File Trajectory Summary Information 2928
Network File Trajectory Map and Related Events List 2929
Using a Network File Trajectory 2930
Work with Event Data in the AMP for Endpoints Console 2932
History for File and Malware Events and Network File Trajectory 2933
CHAPTER 126 Using Host Profiles 2935
Requirements and Prerequisites for Host Profiles 2935

Host Profiles 2936
Host Profile Limitations 2937
Viewing Host Profiles 2937
Basic Host Information in the Host Profile 2937
Operating Systems in the Host Profile 2939
Viewing Operating System Identities 2941
Setting the Current Operating System Identity 2942
Operating System Identity Conflicts 2942
Making a Conflicting Operating System Identity Current 2943
Resolving an Operating System Identity Conflict 2943
Servers in the Host Profile 2943
Server Details in the Host Profile 2945
Viewing Server Details 2946
Editing Server Identities 2946
Resolving Server Identity Conflicts 2947
Web Applications in the Host Profile 2948
Deleting Web Applications from the Host Profile 2949
Host Protocols in the Host Profile 2949
Deleting a Protocol From the Host Profile 2950
Indications of Compromise in the Host Profile 2950

xcviii
Contents
VLAN Tags in the Host Profile 2950

User History in the Host Profile 2951
Host Attributes in the Host Profile 2951
Predefined Host Attributes 2951
Allow List Host Attributes 2952
User-Defined Host Attributes 2952
Creating Text- or URL-Based Host Attributes 2953
Creating Integer-Based Host Attributes 2953
Creating List-Based Host Attributes 2954
Setting Host Attribute Values 2954
Allow List Violations in the Host Profile 2955
Creating Shared Allow List Host Profiles 2955
Malware Detections in the Host Profile 2956
Vulnerabilities in the Host Profile 2956
Downloading Patches for Vulnerabilities 2957
Deactivating Vulnerabilities for Individual Hosts 2958
Deactivating Individual Vulnerabilities 2958
Scan Results in the Host Profile 2959
Scanning a Host from the Host Profile 2959
History for Host Profiles 2960
CHAPTER 127 Working with Discovery Events 2961
Requirements and Prerequisites for Discovery Events 2961

Discovery and Identity Data in Discovery Events 2961
Viewing Discovery Event Statistics 2962
The Statistics Summary Section 2963
The Event Breakdown Section 2964
The Protocol Breakdown Section 2964
The Application Protocol Breakdown Section 2965
The OS Breakdown Section 2965
Viewing Discovery Performance Graphs 2965
Discovery Performance Graph Types 2966
Using Discovery and Identity Workflows 2966
Discovery and Host Input Events 2968

xcix
Contents
Discovery Event Types 2968

Host Input Event Types 2972
Viewing Discovery and Host Input Events 2974
Discovery Event Fields 2975
Host Data 2976
Viewing Host Data 2976
Host Data Fields 2976
Creating a Traffic Profile for Selected Hosts 2980
Creating a Compliance Allow List Based on Selected Hosts 2981
Host Attribute Data 2981
Viewing Host Attributes 2982
Host Attribute Data Fields 2982
Setting Host Attributes for Selected Hosts 2983
Indications of Compromise Data 2983
View and Work with Indications of Compromise Data 2984
Indications of Compromise Data Fields 2986
Editing Indication of Compromise Rule States for a Single Host or User 2986
Viewing Source Events for Indication of Compromise Tags 2987
Resolving Indication of Compromise Tags 2987
Server Data 2987
Viewing Server Data 2988
Server Data Fields 2989
Application and Application Details Data 2991
Viewing Application Data 2991
Application Data Fields 2992
Viewing Application Detail Data 2993
Application Detail Data Fields 2994
Vulnerability Data 2995
Vulnerability Data Fields 2996
Vulnerability Deactivation 2997
Viewing Vulnerability Data 2998
Viewing Vulnerability Details 2998
Deactivating Multiple Vulnerabilities 2999
Third-Party Vulnerability Data 2999

c
Contents
Viewing Third-Party Vulnerability Data 3000

Third-Party Vulnerability Data Fields 3000
Active Sessions, Users, and User Activity Data 3001
User-Related Fields 3002
Active Sessions Data 3008
User Data 3009
User Activity Data 3012
User Profile and Host History 3014
History for Working with Discovery Events 3016
CHAPTER 128 Correlation and Compliance Events 3017
Viewing Correlation Events 3017

Correlation Event Fields 3018
Using Compliance Allow List Workflows 3021
Viewing Allow List Events 3022
Allow List Event Fields 3023
Viewing Allow List Violations 3024
Allow List Violation Fields 3025
Remediation Status Events 3026
Viewing Remediation Status Events 3026
Remediation Status Table Fields 3027
Using the Remediation Status Events Table 3028
APPENDIX A Security, Internet Access, and Communication Ports 3031

Security Requirements 3031
Cisco Clouds 3031
Internet Access Requirements 3032
Communication Port Requirements 3035
APPENDIX B Classic Device Command Line Reference 3039

About the Classic Device CLI 3039
Classic Device CLI Modes 3039
Classic Device CLI Access Levels 3040
Classic Device CLI Management Commands 3040

ci
Contents
configure password 3040

exit 3041
expert 3041
history 3041
logout 3042
? (question mark) 3042
Classic Device CLI Show Commands 3043
access-control-config 3043
audit-log 3043
audit_cert 3044
cpu 3044
database Commands 3045
processes 3045
slow-query-log 3045
device-settings 3046
disk 3046
disk-manager 3047
dns 3047
hostname 3047
hosts 3048
hyperthreading 3048
inline-sets 3048
interfaces 3049
ifconfig 3049
link-state 3050
log-ips-connection 3050
managers 3050
memory 3051
model 3051
netstat 3051
network 3052
network-static-routes 3052
ntp 3052
perfstats 3053

cii
Contents
process-tree 3053
processes 3054
route 3054
serial-number 3054
ssl-policy-config 3055
summary 3055
syslog 3055
time 3056
traffic-statistics 3056
user 3057
users 3058
version 3059
vmware-tools 3059
Classic Device CLI Configuration Commands 3060
audit_cert Commands 3060
delete 3060
import 3060
log-ips-connections 3061
manager Commands 3061
add 3061
delete 3062
network Commands 3062
dns searchdomains 3062
dns servers 3063
hostname 3063
http-proxy 3063
http-proxy-disable 3064
ipv4 delete 3064
ipv4 dhcp 3064
ipv4 manual 3065
ipv6 delete 3065
ipv6 dhcp 3065
ipv6 manual 3066
ipv6 router 3066

ciii
Contents
management-interface tcpport 3066

management-port 3067
static-routes ipv4 add 3067
static-routes ipv4 delete 3067
static-routes ipv6 add 3068
static-routes ipv6 delete 3068
password 3068
user Commands 3069
access 3069
add 3069
aging 3070
delete 3070
disable 3070
enable 3070
forcereset 3071
maxfailedlogins 3071
minpasswdlen 3071
password 3072
strengthcheck 3072
unlock 3072
vmware-tools 3073
Classic Device CLI System Commands 3073
access-control Commands 3073
archive 3074
clear-rule-counts 3074
rollback 3074
compliance Commands 3074
enable cc 3075
enable ucapl 3075
show 3075
disable-http-user-cert 3076
file Commands 3076
copy 3076
delete 3077

civ
Contents
list 3077
secure-copy 3077
generate-troubleshoot 3078
ldapsearch 3079
lockdown 3079
reboot 3080
restart 3080
support Commands 3080
ssl-client-hello-display 3081
ssl-client-hello-enabled 3081
ssl-client-hello-force-reset 3083
ssl-client-hello-reset 3083
ssl-client-hello-tuning 3084
shutdown 3085
History for Classic Device CLI 3086
APPENDIX C Firepower Management Center Command Line Reference 3089

About the Firepower Management Center CLI 3089
Firepower Management Center CLI Modes 3090
Firepower Management Center CLI Management Commands 3090
exit 3090
expert 3091
? (question mark) 3091
Firepower Management Center CLI Show Commands 3091
version 3091
Firepower Management Center CLI Configuration Commands 3092
password 3092
Firepower Management Center CLI System Commands 3092
generate-troubleshoot 3092
lockdown 3093
reboot 3094
restart 3094
shutdown 3094
History for the Firepower Management Center CLI 3095

cv
Contents

cvi
CHAPTER 1
Getting Started With Firepower
Cisco Firepower is an integrated suite of network security and traffic management products, deployed either
on purpose-built platforms or as a software solution. The system is designed to help you handle network traffic
in a way that complies with your organization’s security policy—your guidelines for protecting your network.
In a typical deployment, multiple traffic-sensing managed devices installed on network segments monitor
traffic for analysis and report to a manager:
• Firepower Management Center
• Firepower Device Manager
• Adaptive Security Device Manager (ASDM)
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
• Quick Start: Basic Setup, on page 2

• Firepower Devices, on page 6
• Firepower Features, on page 7
• Search the FMC, on page 11
• Switching Domains on the Firepower Management Center, on page 19
• The Context Menu, on page 19
• Sharing Data with Cisco, on page 21
• Firepower Online Help, How To, and Documentation, on page 21
• Firepower System IP Address Conventions, on page 24
• Additional Resources, on page 25
• History for Getting Started with Firepower, on page 25

1
Quick Start: Basic Setup
Quick Start: Basic Setup

The Firepower feature set is powerful and flexible enough to support basic and advanced configurations. Use
the following sections to quickly set up a Firepower Management Center and its managed devices to begin
controlling and analyzing traffic.
Installing and Performing Initial Setup on Physical Appliances

Procedure
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
• Firepower Threat Defense managed devices

Important Ignore Firepower Device Manager documents on these pages.
• Cisco Firepower 1010 Getting Started Guide

• Cisco Firepower 1100 Series Getting Started Guide
• Cisco Firepower 2100 Series Getting Started Guide
• Cisco Firepower Threat Defense for the ASA 5508-X and ASA 5516-X Using Firepower Management
Center Quick Start Guide
• Cisco Firepower Threat Defense for the ISA 3000 Using Firepower Management Center Quick
Start Guide
• Classic managed devices

• Cisco ASA FirePOWER Module Quick Start Guide
Deploying Virtual Appliances

Follow these steps if your deployment includes virtual appliances. Use the documentation roadmap to locate
the documents listed below: http://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/
firepower-roadmap.html.

2
Logging In for the First Time
Procedure
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
• Firepower Threat Defense Virtual running on Azure: Cisco Firepower Threat Defense Virtual for Azure

Before logging in to a new FMC for the first time, prepare the appliance as described in Installing and
Performing Initial Setup on Physical Appliances, on page 2 or Deploying Virtual Appliances, on page 2.
The first time you log in to a new FMC (or an FMC newly restored to factory defaults), use the admin account
for either the CLI or the web interface and follow the instructions in the Cisco Firepower Management Center
Getting Started Guide for your FMC model. Once you complete the initial configuration process, the following
aspects of your system will be configured:
• The passwords for the two admin accounts (one for web interface access and the other for CLI access)
will be set to the same value, complying with strong password requirements as described in Guidelines
and Limitations for User Accounts. The system synchronizes the passwords for the two admin accounts
only during the initial configuration process. If you change the password for either admin account
thereafter, they will no longer be the same and the strong password requirement can be removed from
the web interface admin account. (See Add an Internal User at the Web Interface.)
• The following network settings the FMC uses for network communication through its management
interface (eth0) will be set to default values or values you supply:
• Fully qualified domain name (<hostname>.<domain>)

3
• Boot protocol for IPv4 configuration (DHCP or Static/Manual)

• 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 1365 and Time and Time Synchronization, on page 1389 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 240.
• 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 304.
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 296.
• 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 306.
• 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 Schedule Intrusion Rule Updates, on page 243.
On completion of FMC initial configuration, the web interface displays the device management page, described
in Device Management Basics, on page 341. (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 45.)

4
Setting Up Basic Policies and Configurations
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.
Setting Up Basic Policies and Configurations

You must configure and deploy basic policies in order to see data in the dashboard, Context Explorer, and
event tables.
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.
Before you begin

• Log into the web interface using the admin account for either the web interface or CLI and perform the
initial configuration as described in the Cisco Firepower Management Center Getting Started Guide for
your hardware model, available from https://www.cisco.com/c/en/us/support/security/defense-center/
products-installation-guides-list.html.
Procedure
Step 1 Set a time zone for this account as described in Setting Your Default Time Zone, on page 50.
Step 2 If needed, add licenses as described in Licensing the Firepower System, on page 157.
Step 3 Add managed devices to your deployment as described in Add a Device to the FMC, on page 355.
Step 4 Configure your managed devices as described in:
• Introduction to IPS Device Deployment and Configuration, on page 735, to configure passive or inline
interfaces on Classic devices
• Interface Overview for Firepower Threat Defense, on page 811, to configure transparent or routed mode
on Firepower Threat Defense devices
• Interface Overview for Firepower Threat Defense, on page 811, 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 1621.
• 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 1601 and
System-Provided Network Analysis and Intrusion Policies, on page 1941.
• 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 2801.
Step 6 Apply the system-provided default health policy as described in Applying Health Policies, on page 438.
Step 7 Customize a few of your system configuration settings:

5
Firepower Devices
• 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 1376.
• Understand and consider editing your database event limits as described in Configuring Database Event
Limits, on page 1358.
• If you want to change the display language, edit the language setting as described in Set the Language
for the Web Interface, on page 1386.
• If your organization restricts network access using a proxy server, edit your proxy settings as described
in Modify FMC Management Interfaces, on page 1365.
Step 8 Customize your network discovery policy as described in Configuring the Network Discovery Policy, on page
2499. 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 500.
• If you want to customize the default values for system variables, understand their use as described in
Variable Sets, on page 623.
• If you want to create additional locally authenticated user accounts to access the FMC, see Add an Internal
User, on page 59.
• If you want to use LDAP or RADIUS external authentication to allow access to the FMC, see Configure
External Authentication, on page 61.
Step 10 Deploy configuration changes; see Deploy Configuration Changes, on page 535.
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.

6
End of Sale for Firepower 7000/8000 Series Devices
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.
Firepower Threat Defense Devices

A Firepower Threat Defense (FTD) device is a next-generation firewall (NGFW) that also has NGIPS
capabilities. NGFW and platform features include site-to-site and remote access VPN, robust routing, NAT,
clustering, and other optimizations in application inspection and access control.
FTD is available on a wide range of physical and virtual platforms.
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.
End of Sale for Firepower 7000/8000 Series Devices

You cannot upgrade to or freshly install Firepower Version 6.5+ on 7000/8000 series devices. This guide and
the related online help do not contain information on configuring or managing those devices.
If you are managing 7000/8000 series devices running supported older Firepower versions, use the following
resources:
• For FMC-device compatibility, see the About Firepower Management Centers section in the Cisco
Firepower Compatibility Guide.
• For device configuration and management, see the Firepower Management Center Configuration Guide
that corresponds to your device version.
Firepower Features
These tables list some commonly used Firepower features.
Appliance and System Management Features

To locate unfamiliar documents, see: http://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/
If you want to... Configure... As described in...

Manage user accounts for logging in to Firepower authentication User Accounts for FMC, on page
your Firepower appliances 53 and User Accounts for
Devices, on page 135
Monitor the health of system hardware Health monitoring policy About Health Monitoring, on
and software page 425

7
Appliance and System Management Features

Back up data on your appliance Backup and restore Backup and Restore, on page 257
Upgrade to a new Firepower version System updates Cisco Firepower Management

Center Upgrade Guide
Firepower Release Notes
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 Updates, on page 231
or GeoDB on your appliance updates, intrusion rule updates,
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 157
Ensure continuity of appliance operations Managed device high About Firepower Threat Defense
availability and/or Firepower High Availability, on page 907
Management Center high
About Firepower Management
availability
Center High Availability, on
page 321
Configure a device to route traffic Routing Routing Overview for Firepower

between two or more interfaces Threat Defense, on page 993
Configure packet switching between two Device switching Configure Bridge Group
or more networks Interfaces, on page 848
Translate private addresses into public Network Address Translation Network Address Translation
addresses for internet connections (NAT) (NAT) for Firepower Threat
Defense, on page 1489
Establish a secure tunnel between Site-to-Site virtual private VPN Overview for Firepower
managed Firepower Threat Defense network (VPN) Threat Defense, on page 1123
Establish secure tunnels between remote Remote Access VPN VPN Overview for Firepower
users and managed Firepower Threat Threat Defense, on page 1123
Defense devices
Segment user access to managed devices, Multitenancy using domains Introduction to Multitenancy
configurations, and events Using Domains, on page 517
View and manage appliance REST API and REST API REST API Preferences, on page
configuration using a REST API client Explorer 1404
Firepower REST API Quick
Start Guide

8
High Availability and Scalability Features by Platform

Troubleshoot issues N/A Troubleshooting the System, on
page 493
High Availability and Scalability Features by Platform

High availability configurations (sometimes called failover) ensure continuity of operations. Clustered
configurations group multiple devices together as a single logical device, achieving increased throughput and
redundancy.
Platform High Availability Clustering
Firepower Management Center Yes —
Firepower Management Center Yes (See Virtual Platform —

Virtual Requirements, on page 327 for
important details)
Firepower Threat Defense: Yes —

• Firepower 1000 series
• ASA 5500-X series
• ISA 3000
Firepower Threat Defense: Yes Yes

• Firepower 4100/9300 chassis
Firepower Threat Defense Virtual: Yes —

• VMware
• KVM
Firepower Threat Defense Virtual — —

(public cloud):
• AWS
• Azure
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 907

9
Features for Detecting, Preventing, and Processing Potential Threats
About Firepower Management Center High Availability, on page 321
Features for Detecting, Preventing, and Processing Potential Threats


Inspect, log, and take action on network Access control policy, the parent Introduction to Access Control,
traffic of several other policies on page 1601
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 1685
names
Control the websites that users on your URL filtering within your policy URL Filtering, on page 1655
network can access rules
Monitor malicious traffic and intrusions Intrusion policy Intrusion Policy Basics, on page
on your network 1967
Block encrypted traffic without SSL policy SSL Policies Overview, on page
inspection 1775
Inspect encrypted or decrypted traffic
Tailor deep inspection to encapsulated Prefilter policy About Prefiltering, on page 1709
traffic and improve performance with
fastpathing
Rate limit network traffic that is allowed Quality of Service (QoS) policy About QoS Policies, on page 897
or trusted by access control
Allow or block files (including malware) File/malware policy File Policies and Malware
on your network Protection, on page 1841
Operationalize data from threat Cisco Threat Intelligence Cisco Threat Intelligence
intelligence sources Director (TID) Director (TID) Overview, on
page 1887
Configure passive or active user User awareness, user identity, About User Identity Sources, on
authentication to perform user awareness identity policies page 2338
and user control
About Identity Policies, on page
2487
Collect host, application, and user data Network Discovery policies Overview: Network Discovery
from traffic on your network to perform Policies, on page 2497
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 2695
traffic and potential threats

10
Integration with External Tools

Perform application detection and control Application detectors Overview: Application
Detection, on page 2391

page 493
Integration with External Tools


Automatically launch remediations when Remediations Introduction to Remediations,
conditions on your network violate an on page 2587
associated policy
Firepower System Remediation
API Guide
Stream event data from a Firepower eStreamer integration eStreamer Server Streaming, on
Management Center to a page 2713
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 1356
client
Firepower System Database
Access Guide
Augment discovery data by importing Host input Host Input Data, on page 2361
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 2695
resources

page 493
Search the FMC

You can use the global search feature to quickly locate and navigate to elements of your Firepower Management
Center configuration.

11
Search the FMC
Note This feature is supported in Light and Dusk themes only. To change the theme, see Change the Web Interface
Appearance, on page 44.
You can search the FMC configuration for the following entities:
• Names of web interface pages in top-level menus. (See Search for Web Interface Menu Options, on page
13.)
• For certain policy types:
• Policy names
• Policy descriptions
• Rule names
• Rule comments
(See Search for Policies, on page 14.)

• For certain object types:
• Object names
• Object descriptions
• Configured values
(See Search for Objects, on page 15 .)
Keep the following in mind when using global search:

• When you open the global search tool, the most recent ten searches appear in a history list below the
search text box. You can select an item from this list to re-execute a search.
• When you type a search expression, the interface replaces the search history with search results that
update as you type your search; you do not need to press Enter to execute the search.
• You can navigate the history list or the search results using the mouse or the keyboard arrow keys and
the Enter key. Pressing the Enter key selects the currently highlighted item in the search results. In the
case of results for web interface pages, this causes the FMC interface to display the highlighted page.
For objects and policies, this displays details about the found entity.
• Search is not case-sensitive.
• In a multidomain deployment, search returns only objects and policies defined within the current domain.
For an object search, if your search expression is found in objects defined in domains other than your
current default domain, the search results display the names of the domains within which those objects
reside. If your search expression is found in objects defined within your current domain, the search results
display the object values.
• You can use the following wildcard characters in your search:
• ? matches any single character.
• * matches any 0 or more characters.

12
Search for Web Interface Menu Options
• ^ anchors the search term it preceeds to the beginning of matched entities.

• $ anchors the search term it follows to the end of matched entitites
Wildcards cannot be escaped.

• For greater effciency, global search does not return indirect search results; that is, global search does not
return policies or objects that reference objects where a search term is found. However, you can determine
which policies or objects reference many found objects by viewing the Usages tab for the found object
in the search detail pane.
• Global search returns the top results for your search expression determined by its relevance to the most
commonly used configuration entities in the FMC. If global search fails to return something you are
expecting to find, try refining your search, try using the search or filter tool that appears at the top of
many GUI pages, or try some of the configuration-specific search features the web interface offers:
• Searching for Rules
• Searching and Filtering the NAT Rule Table
• Searching TLS/SSL Rules
• Searching for Events
• Searching Custom Tables
Search for Web Interface Menu Options

You can search to find locations of pages in the top-level menus of the web interface. For example, to view
or configure Quality of Service settings, search for QoS.
Before you begin

This feature is not available in the Classic theme. To change the theme, see Change the Web Interface
Procedure
Step 1 Use one of two methods to initiate a search:
• In the menu bar at the top of the Firepower Management Center web interface, click Search ( ).
• With focus outside of a text box, type / (forward slash).
Step 2 Enter one or more letters of the name of the menu option you seek. Search results appear below the text box
and update as you type; you do not need to press Enter to execute the search.
Step 3 Search results appear grouped by category. To go to a page listed under Navigation, click the menu path in
the search results list.

13
Search for Policies
Search for Policies

The following table indicates which policy types you can search for by name:
In Scope Out of Scope
Access Control Policy Threat Defense Platform Settings
Prefilter Policy Firepower Settings Policy
Threat Defense NAT Firepower NAT Policy

Policy
Intrusion category QoS Policy

• Intrusion Policy FlexConfig Policy
• Network Analysis
Policy
DNS Policy
Malware & File Policy
SSL Policy
Identity Policy
Network Discovery
Application Detector
Correlation Policy
VPN category
• Dynamic Access Policy
• Site To Site
• Remote Access
Global search returns polices whose names match the search term, as well as access control policies using
rules whose name or comments match the search term. If you see an access control policy in the search result
list whose name does not match the search, the match was made on the name or comments for a rule configured
within the policy.
Important Global search returns the top results for your search expression determined by its relevance to the most
commonly used configuration entities in the FMC. Your search term may exist in policy types that are not in
scope for this search feature. For a full description of the global search feature and alternative search methods,
see Search the FMC.

14
Search for Objects
Before you begin

Procedure
Step 2 Enter a search expression in the search text box. Search results appear below the text box and update as you
type; you do not need to press Enter to execute the search.
Step 3 Search results appear grouped by category. Under the Policies category you can do the following:
To: Do this:
View search results for a single policy type. Click the policy type in the search results, such as
Access Control Policy.
View details about a policy. Click the policy name in the search results list to view
the details pane and display the General tab.
View the Access Control policies that reference Click the name of the Intrusion or Network Analysis
Intrusion and Network Analysis policies. policy in the search results to view the details pane
and display the Usages tab.
Open the policy configuration page for a policy in a Click the policy name in the search results, and in the
separate browser window. details pane click Edit ( ).
Search for Objects

The following table indicates which object types listed on the Object Management page (Objects > Object
Management) are in scope for the Global Search feature:
AAA Server category Application Filters

• RADIUS Server Group Cipher Suite List
• Single Sign-On Server Community List

15
Search for Objects
Access List category Distinguished Name category

• Extended Access List • Individual Distinguished Name
Objects
• Standard Access List
• Distinguished Name Object
Groups
Address Pools category File List

• IPv4 Pools FlexConfig category
• IPv6 Pools • FlexConfig Object
• Text Object
AS Path
DNS Server Group PKI category
External Attributes Category • External Cert Groups
• Dynamic Object • External Certs
• Security Group Tag • Internal CA Groups

• Internal CAs
Geolocation
• Internal Cert Groups
Interface category
• Internal Certs
• Security Zone
• Trusted CA Groups
• Interface Group
• Trusted CAs
Key Chain
Network (includes Network, Host, Range, FQDN, Network Group)
PKI category Security Intelligence category

• Cert Enrollment • DNS Lists and Feeds
• Network Lists and Feeds
Policy List
• URL Lists and Feeds
Port (objects and groups, TCP, UDP, ICMP, ICMPv6, other)
Prefix List category Sinkhole

• IPv4 Prefix List Variable Set
• IPv6 Prefix List
Route Map VPN category
SLA Monitor • AnyConnect File
Time Range • Custom Attribute

16
Search for Objects
Time Zone
Tunnel Zone
URL (Objects, groups.)
VLAN Tag (Objects, groups.)
VPN category
• Certificate Map
• Group Policy
• IKEv1 IPsec Proposal
• IKEv1 Policy
• IKEv2 IPSec Proposal
• IKEv2 Policy
Global search returns objects whose names or description match the search term, as well as objects with
configured values that match the search term. If you see an object in the search result list whose name does
not match the search, the match was made on the description or a configured value within the object.
Important Global search returns the top results for your search expression determined by its relevance to the most
commonly used configuration entities in the FMC. Your search term may exist in object types that are not in
scope for this search feature. For a full description of the global search feature and alternative search methods,
see Search the FMC.
Object searches can be particularly useful when you need to locate network information within your deployment.
You can search for the following in object names, descriptions, or configured values:
• IPv4 and IPv6 address information, including the following formats:
• Full addresses (For example, 194.164.0.23, 2001:0db8:85a3:0000:0000:8a2e:0370:7334.)
• Partial addresses (For example, 194.164, 2001:db8.)
• Ranges (For example, 192.164.1.1-192.168.1.5 or 2001:db8::0202-2001:db8::8329. Do not

add a space before or after the hyphen.) Global search returns objects using network addresses that
match any within the specified range.
• CIDR notation. (For example 192.168.1.0/24, 2002::1234:abcd:ffff:101/64.) Global search
returns objects using network addresses that match any within the specified CIDR block.
• Port information:
• Port numbers (For example, 22 or 80.)
• Protocols. (For example, https or ssh.)

17
Search for Objects
• Fully qualified domain names. (For example, www.cisco.com.)

• URLs. (For example, http://www.cisco.com.)
• Encryption standards or hash types. (For example, AES-128 or SHA.)
• VLAN tag numbers. (For example, 568.)
Before you begin

Procedure
Step 2 Enter a search expression in the search text box. Search results appear below the text box and update as you
type; you do not need to press Enter to execute the search.
If your search expression is found in objects defined in domains other than your current default domain, the
search results display the names of the domains within which those objects reside. If your search expression
is found in objects defined within your current domain, the search results display the object values.
Step 3 Search results appear divided by category. Under the Object category you can do the following:
To: Do this:
View search results for a single object type. Click on the object type in the search results, such as
Network.
View details about an object in the search results. Click the object name in the search results to view the
details pane and display the General tab.
View a list of polices or objects that use an object in Click the object name in the search results to view the
the search results. details pane and display the Usages tab.
Note Global Search does not provide usage
information for all object types.
Open the object configuration page for an object in Click the object name in the search results, and in the
the search results in a separate browser window. details pane click Edit ( ).

18
Switching Domains on the Firepower Management Center
Switching Domains on the Firepower Management Center

In a multidomain deployment, user role privileges determine which domains a user can access and which
privileges the user has within each of those domains. You can associate a single user account with multiple
domains and assign different privileges for that user in each domain. For example, you can assign a user
read-only privileges in the Global domain, but Administrator privileges in a descendant domain.
Users associated with multiple domains can switch between domains within the same web interface session.
Under your user name in the toolbar, the system displays a tree of available domains. The tree:
• 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.
When you switch to a domain, the system displays:

• Data that is relevant to that domain only.
• Menu options determined by the user role assigned to you for that domain.
Procedure
From the drop-down list under your user name, choose the domain you want to access.
The Context Menu

Certain pages in the Firepower System web interface support a right-click (most common) or left-click context
menu that you can use as a shortcut for accessing other features in the Firepower System. The contents of the
context menu depend where you access it—not only the page but also the specific data.
For example:
• IP address hotspots provide information about the host associated with that address, including any
available whois and host profile information.
• SHA-256 hash value hotspots allow you to add a file’s SHA-256 hash value to the clean list or custom
detection list, or view the entire hash value for copying.
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.

19
The Context Menu
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 2697.
While viewing connection events, you can add items to the default Security Intelligence Block and Do
Not 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.

20
Sharing Data with Cisco
Intrusion Event Packet View

Intrusion event packet views contain IP address hotspots. The packet view uses a left-click context menu.
Dashboard
Many dashboard widgets contain hotspots to view related information in the Context Explorer. Dashboard
widgets can also contain IP address and SHA-256 hash value hotspots.
Context Explorer
The Context Explorer contains hotspots over its charts, tables, and graphs. If you want to examine data
from graphs or lists in more detail than the Context Explorer allows, you can drill down to the table views
of the relevant data. You can also view related host, user, application, file, and intrusion rule information.
The Context Explorer uses a left-click context menu, which also contains filtering and other options
unique to the Context Explorer.
Related Topics
Security Intelligence Lists and Feeds, on page 638
Sharing Data with Cisco

You can opt to share data with Cisco using the following features:
• Cisco Success Network
See Cisco Success Network, on page 213
• Web analytics
See (Optional) Opt Out of Web Analytics Tracking, on page 1405
Firepower Online Help, How To, and Documentation

You can reach the online help from the web interface:
• By clicking the context-sensitive help link on each page
• By choosing Help > Online
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.
The following walkthroughs are available on Firepower Management Center:

21
Top-Level Documentation Listing Pages for FMC Deployments
• Register FMC with Cisco Smart Account: This walkthrough guides you to register Firepower Management
Center with Cisco Smart Account.
• Set up a Device and add it to FMC: This walkthrough guides you to set up a device and to add the device
to Firepower Management Center.
• Configure Date and Time: This walkthrough guides you to configure the date and time of the Firepower
Threat Defense devices using a platform settings policy.
• Configure Interface Settings: This walkthrough guides you to configure the interfaces on the Firepower
Threat Defense devices.
• Create an Access Control Policy: An access control policy consists of a set of ordered rules, which are
evaluated from top to bottom. This walkthrough guides you to create an access control policy.
• Add an Access Control Rule - A Feature Walkthrough: This walkthrough describes the components of
an access control rule, and how you can use them in Firepower Management Center.
• 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.

The following documents may be helpful when configuring Firepower Management Center deployments,
Version 6.0+.
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 Management Center

• Firepower Management Center hardware appliances:
http://www.cisco.com/c/en/us/support/security/defense-center/tsd-products-support-series-home.html
• Firepower Management Center Virtual appliances:
• http://www.cisco.com/c/en/us/support/security/defense-center-virtual-appliance/
tsd-products-support-series-home.html
• http://www.cisco.com/c/en/us/support/security/defense-center/tsd-products-support-series-home.html

22
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/
• Firepower 1000 series:
https://www.cisco.com/c/en/us/support/security/firepower-1000-series/
• Firepower 9300:
• ASA 5500-X series:
• https://www.cisco.com/c/en/us/support/security/asa-firepower-services/
• https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/
• ISA 3000:
https://www.cisco.com/c/en/us/support/security/industrial-security-appliance-isa/
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/
• https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/
• ISA 3000 with FirePOWER Services:

https://www.cisco.com/c/en/us/support/security/industrial-security-appliance-isa/

23
License Statements in the Documentation
• NGIPSv (virtual device):

https://www.cisco.com/c/en/us/support/security/ngips-virtual-appliance/
License Statements in the Documentation

The License statement at the beginning of a section indicates which Classic or Smart license you must assign
to a managed device in the Firepower System to enable the feature described in the section.
Because licensed capabilities are often additive, the license statement provides only the highest required
license for each feature.
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 157.
Related Topics
About Firepower Licenses, on page 157
Supported Devices Statements in the Documentation

The Supported Devices statement at the beginning of a chapter or topic indicates that a feature is supported
only on the specified device series, family, or model. For example, many features are supported only on
Firepower Threat Defense devices.
For more information on platforms supported by this release, see the release notes.
Access Statements in the Documentation

The Access statement at the beginning of each procedure in this documentation indicates the predefined user
roles required to perform the procedure. Any of the listed roles can perform the procedure.
Users with custom roles may have permission sets that differ from those of the predefined roles. When a
predefined role is used to indicate access requirements for a procedure, a custom role with similar permissions
also has access. Some users with custom roles may use slightly different menu paths to reach configuration
pages. For example, users who have a custom role with only intrusion policy privileges access the network
analysis policy via the intrusion policy instead of the standard path through the access control policy.
For more information about user roles, see User Roles, on page 54 and Customize User Roles for the Web
Interface, on page 126.
Firepower System IP Address Conventions

You can use IPv4 Classless Inter-Domain Routing (CIDR) notation and the similar IPv6 prefix length notation
to define address blocks in many places in the Firepower System.

24
Additional Resources
When you use CIDR or prefix length notation to specify a block of IP addresses, the Firepower System uses
only the portion of the network IP address specified by the mask or prefix length. For example, if you type
10.1.2.3/8, the Firepower System uses 10.0.0.0/8.
In other words, although Cisco recommends the standard method of using a network IP address on the bit
boundary when using CIDR or prefix length notation, the Firepower System does not require it.
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.
History for Getting Started with Firepower

Feature Version Details
Search for certain 7.0 You can search for certain policies by name and for certain objects by name and configured
policies and objects value.
For specifics, see Search for Policies, on page 14 and Search for Objects, on page 15.
This feature uses the existing Search button at the top of the FMC web interface window.
Platform: FMC (not available when using the Classic theme)
Search for web 6.7 You can search for pages you want to view or change. For example, you can search for QoS to
interface pages locate the page to configure Quality of Service settings.
New/Modified Screens: There is a new magnifying glass button at top of the FMC web interface
window.
Platform: FMC (not available when using the Classic theme)

25
History for Getting Started with Firepower
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

26
PA R T I
Your User Account
• Logging into the Firepower System, on page 29
• Specifying User Preferences, on page 43
• User Accounts for FMC, on page 53
• User Accounts for Devices, on page 135
CHAPTER 2
Logging into the Firepower System
The following topics describe how to log into the Firepower System:
• Firepower System User Accounts, on page 29
• Firepower System User Interfaces, on page 31
• Logging Into the Firepower Management Center Web Interface, on page 34
• Logging Into the FMC Web Interface Using SSO, on page 35
• Logging Into the Firepower Management Center with CAC Credentials, on page 36
• Logging Into the FMC Command Line Interface, on page 37
• Logging Into the CLI on ASA FirePOWER and NGIPSv Devices, on page 37
• Logging Into the Command Line Interface on FTD Devices, on page 38
• View Your Last Login, on page 39
• Logging Out of a Firepower System Web Interface, on page 39
• History for Logging into the Firepower System, on page 40
Firepower System User Accounts

You must provide a username and password to obtain local access to the web interface or CLI on an FMC or
managed device. On managed devices, CLI users with Config level access can use the expert command to
access the Linux shell. On the FMC, all CLI users can use the expert command. The FTD and FMC can be
configured to use external authentication, storing user credentials on an external LDAP or RADIUS server;
you can withhold or provide CLI access rights to external users. The FMC can be configured to support Single
Sign-On (SSO) using any SSO provider conforming to the Security Assertion Markup Language (SAML)
2.0 open standard for authentication and authorization.
The FMC CLI provides a single admin user who has access to all commands. The features FMC web interface
users can access are controlled by the privileges an administrator grants to the user account. On managed
devices, the features that users can access for both the CLI and the web interface are controlled by the privileges
an administrator grants to the user account.
Note The system audits user activity based on user accounts; make sure that users log into the system with the
correct account.

29
Your User Account
Firepower System User Accounts
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.
Firepower Management Centers

Firepower Management Centers support the following user account types:
• A pre-defined admin account for web interface access, which has the administrator role and can be
managed through the web interface.
• Custom user accounts, which provide web interface access and which admin users and users with
administrator privileges can create and manage.
• A pre-defined admin account for CLI access. Users logging in with this account can use the expert
command to gain access to the Linux shell.
During initial configuration, the passwords for the CLI admin account and the web interface admin
account are synchronized but, optionally, thereafter you can configure separate passwords for the two
admin accounts.
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 NGIPSv does not support external authentication for users.

30
Your User Account
Firepower System User Interfaces
Firepower Threat Defense and Firepower Threat Defense Virtual Devices

Firepower Threat Defense and Firepower Threat Defense Virtual devices support the following user account
types:
• A pre-defined adminaccount which can be used for all forms of access to the device.
The Firepower Threat Defense supports external authentication for SSH users.
ASA FirePOWER Devices

The ASA FirePOWER module supports the following user account types:
• A pre-defined admin account.
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.

Depending on appliance type, you can interact with Firepower appliances using a web-based GUI, auxiliary
CLI, or the Linux shell. In a Firepower Management Center deployment, you perform most configuration
tasks from the FMC GUI. Only a few tasks require that you access the appliance directly using the CLI or
Linux shell. We strongly discourage using the Linux shell unless directed by Cisco TAC or explicit instructions
in the Firepower user documentation.
For information on browser requirements, see the Firepower Release Notes.
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.

31
Your User Account
Appliance Web-Based GUI Auxiliary CLI Linux Shell
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.
Firepower Threat Defense — • Supported for predefined • Supported for predefined

admin user and custom admin user and custom
Firepower Threat Defense
user accounts. user accounts.
Virtual
• Accessible in physical • Accessible by CLI users
devices using an SSH, with Config access using
serial, or keyboard and the expert command.
monitor connection.
Accessible in virtual • Should be used only for
devices via SSH or VM administration and
console. troubleshooting directed by
Cisco TAC or by explicit
• Can be used for setup and instructions in the FMC
troubleshooting directed by documentation..
Cisco TAC.
NGIPSv — • Supported for predefined • Supported for predefined

user accounts user accounts
• Accessible using an SSH • Accessible by CLI users
connection or VM console with Config access using
the expert command
• Can be used for setup and
troubleshooting directed by • Should be used only for
Cisco TAC. administration and
troubleshooting directed by
Cisco TAC or explicit
documentation..

32
Your User Account
Web Interface Considerations
Appliance Web-Based GUI Auxiliary CLI Linux Shell
ASA FirePOWER module — • Supported for predefined • Supported for predefined

user accounts. user accounts
• Accessible using an SSH • Accessible by CLI users
connection. Also with Config access using
accessible using the the expert command
console port.
• Should be used only for
• Can be used for administration and
configuration and troubleshooting directed by
management tasks. Cisco TAC or by explicit
documentation..
Related Topics
Add an Internal User, on page 59
Web Interface Considerations

• If your organization uses Common Access Cards (CACs) for authentication, external users authenticated
with LDAP can use CAC credentials to obtain access to the web interface of an appliance.
• The menus and menu options listed at the top of the default home page are based on the privileges for
your user account. However, the links on the default home page include options that span the range of
user account privileges. If you click a link that requires different privileges from those granted to your
account, the system displays a warning message and logs the activity.
• Some processes that take a significant amount of time may cause your web browser to display a message
that a script has become unresponsive. If this occurs, make sure you allow the script to continue until it
finishes.
Related Topics
Specifying Your Home Page, on page 45
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.
Note For SSO users, when the FMC session times out, the display briefly redirects to the IdP interface, and then
the FMC login page. Unless the SSO session has been terminated from elsewhere, anyone can access the
FMC without providing login credentials simply by clicking on the Single Sign-On link on the login page.
To ensure FMC security and prevent others from accessing the FMC using your SSO account, we recommend
you not leave an FMC login session unattended, and log out of the SSO federation at the IdP when you log
out of the FMC.

33
Your User Account
Logging Into the Firepower Management Center Web Interface
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 1397
Configure SAML Single Sign-On, on page 77
Logging Into the Firepower Management Center Web Interface
Note This task applies to internal users and external users authenticated by LDAP or RADIUS servers. For SSO
login, see Logging Into the FMC Web Interface Using SSO, on page 35.
Users are restricted to a single active session. If you try to log in with a user account that already has an active
session, the system prompts you to terminate the other session or log in as a different user.
In a NAT environment where multiple FMCs share the same IP address:
• Each FMC can support only one login session at a time.
• 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.
Before you begin

• If you do not have access to the web interface, contact your system administrator to modify your account
privileges, or log in as a user with Administrator access and modify the privileges for the account.
• Create user accounts as described in Add an Internal User at the Web Interface.
Procedure
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.

34
Your User Account
Logging Into the FMC Web Interface Using SSO
Step 3 Click Login.
Related Topics
Session Timeout, on page 33
Logging Into the FMC Web Interface Using SSO

The FMC can be configured to participate in any Single-Sign On (SSO) federation implemented with an SSO
provider conforming to the Security Assertion Markup Language (SAML) 2.0 open standard. SSO user
accounts must be established at the identitiy provider (IdP) and must use email addresses for their account
names. If your user name is not an email address, or SSO login fails, contact your system administrator.
Note The FMC does not support logging in with CAC credentials for SSO accounts.
Before you begin

• Configure the FMC for SSO access. See Configure SAML Single Sign-On, on page 77.
• If you do not have access to the web interface, contact your system administrator to configure your
account at the SSO IdP.
Procedure
FMC.
Note SSO users must consistently access the FMC using the login URL specifically configured for SSO
access; ask your administrator for this information.
Step 2 Click on the Single Sign-On link.

Step 3 The system responds in one of two ways:
• If you are already logged into the SSO federation, the FMC default home page appears.

35
Your User Account
Logging Into the Firepower Management Center with CAC Credentials
• If you are not already logged into the SSO federation, the FMC redirects your browser to the login page
for your IdP. After you complete the login process at the IdP, the FMC default home page appears.
Related Topics
Logging Into the Firepower Management Center with CAC

Credentials
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.
Before you begin

• If you do not have access to the web interface, contact your system administrator to modify your account
privileges, or log in as a user with Administrator access and modify the privileges for the account.
• Create user accounts as described in the Add an Internal User at the Web Interface.
• Configure CAC authentication and authorization as described in Configure Common Access Card
Authentication with LDAP.
Procedure
Step 1 Insert a CAC as instructed by your organization.

FMC.
Step 3 If prompted, enter the PIN associated with the CAC you inserted in step 1.
Step 4 If prompted, choose the appropriate certificate from the drop-down list.
Step 5 Click Continue.

36
Your User Account
Logging Into the FMC Command Line Interface
Related Topics
Configure Common Access Card Authentication with LDAP, on page 76
SSO Guidelines for the FMC, on page 78
Logging Into the FMC Command Line Interface

The admin CLI user and certain custom external users can log into the FMC CLI.
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
Before you begin

Complete the initial configuration process as the admin user. See Logging In for the First Time, on page 3.
Procedure
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.
Step 2 Use any of the available CLI commands.
Logging Into the CLI on ASA FirePOWER and NGIPSv Devices

With a minimum of basic CLI configuration access, you can log directly into Classic managed devices.
Note For all appliances, after a user makes three consecutive failed attempts to log into the CLI via SSH, the system
Before you begin

• Complete the initial setup process using the default admin user for the initial login.

37
Your User Account
Logging Into the Command Line Interface on FTD Devices
• Create additional user accounts that can log into the CLI using the configure user add command.
Procedure
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.
Logging Into the Command Line Interface on FTD Devices

You can log directly into the command line interface on FTD managed devices.
Before you begin

Complete the initial setup process using the default admin user for the initial login. Create additional user
accounts that can log into the CLI using the configure user add command.
Procedure
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 1441 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.

38
Your User Account
View Your Last Login
Step 2 Log in with the admin username and password.

Step 3 At the CLI prompt (>), use any of the commands allowed by your level of command line access.
Step 4 (Optional) Access the diagnostic CLI:
system support diagnostic-cli
Use this CLI for advanced troubleshooting. This CLI includes additional show and other commands, including
the session wlan console command needed to enter the CLI for the wireless access point on an ASA 5506W-X.
This CLI has two sub-modes: user EXEC and privileged EXEC mode. More commands are available in
privileged EXEC mode. To enter privileged EXEC mode, enter the enable command; press enter without
entering a password when prompted.
Example:
> system support diagnostic-cli

firepower> enable
Password:
firepower#
To return to the regular CLI, type Ctrl-a, d.
View Your Last Login

If you suspect that an unauthorized user has used your credentials to sign in to the Firepower Management
Center, you can see the date, time, and IP address from which your credentials were last used to log in:
Before you begin

This feature is not available if you are using the Classic theme. You can select a UI theme in User Preferences.
Procedure
Step 1 Sign in to the Firepower Management Center.

Step 2 At the top right corner of your browser window, look for the User ID that you used to sign in.
Step 3 Click your user name.
Step 4 Information about your previous login is shown at the bottom of the menu that appears.
Logging Out of a Firepower System Web Interface

When you are no longer actively using a Firepower System web interface, Cisco recommends that you log
out, even if you are only stepping away from your web browser for a short period of time. Logging out ends
your web session and ensures that no one can use the interface with your credentials.

39
Your User Account
History for Logging into the Firepower System
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.
Procedure
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

Added support for Single 6.7 Added the ability for users configured at any third-party SAML 2.0-compliant identity provider
Sign-On (SSO) using any (IdP) to log into the FMC using a new Single Sign-On link on the login page.
SAML 2.0-compliant
New/Modified screen:
SSO provider.
Login screen
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.

40
Your User Account
Ability to enable and 6.3 New/Modified screens:

disable CLI access for the
New check box available to administrators in FMC web interface: Enable CLI Access on the
FMC
System > Configuration > Console Configuration page.
• Checked: Logging into the FMC using SSH accesses the CLI.
• Unchecked: Logging into FMC using SSH accesses the Linux shell. This is the default state
for fresh Version 6.3 installations as well as upgrades to Version 6.3 from a previous release.

41
Your User Account

42
CHAPTER 3
Specifying User Preferences
The following topics describe how to specify user preferences:
• User Preferences Introduction, on page 43
• Changing Your Password, on page 43
• Changing an Expired Password, on page 44
• Change the Web Interface Appearance, on page 44
• Specifying Your Home Page, on page 45
• Configuring Event View Settings, on page 45
• Setting Your Default Time Zone, on page 50
• Specifying Your Default Dashboard, on page 50
• History for Specifying User Preferences, on page 51
User Preferences Introduction

Depending on your user role, you can specify certain preferences for your user account.
In a multidomain deployment, user preferences apply to all domains where your account has access. When
specifying home page and dashboard preferences, keep in mind that certain pages and dashboard widgets are
constrained by domain.
Changing Your Password

All user accounts are protected with a password. You can change your password at any time, and depending
on the settings for your user account, you may have to change your password periodically.
When password strength checking is enabled, passwords must comply with the strong password requirements
described in Guidelines and Limitations for User Accounts.
If you are an LDAP or a RADIUS user, you cannot change your password through the web interface.
Procedure
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Change Password.

43
Your User Account
Changing an Expired 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 5 You have two options:
• Enter your new password for New Password and Confirm Password.
• Click Generate Password to have the system create a password for you which complies with the listed
criteria. (Generated passwords are non-mnemonic; take careful note of the password if you choose this
option.)
Step 6 Click Apply.
Changing an Expired Password

Depending on the settings for your user account, your password may expire. The password expiration time
period is set when your account is created. If your password has expired, the Password Expiration Warning
page appears.
Procedure
On the Password Expiration Warning page, you have two choices:

• Click Change Password to change your password now. If you have zero warning days left, you must
change your password.
Tip When password strength checking is enabled, passwords must comply with the strong password
requirements described in Guidelines and Limitations for User Accounts.
• Click Skip to change your password later.
Change the Web Interface Appearance

You can change the way the web interface appears.
Procedure
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
• Dusk

44
Your User Account
Specifying Your Home Page
• Classic (the look and feel of releases earlier than 6.6)
Specifying Your Home Page

You can specify the page within the web interface to use as your home page for the appliance. The default
home page is the default dashboard (Overview > Dashboards), except for user accounts with no dashboard
access, such as External Database users. (See Specifying Your Default Dashboard, on page 50 to set the
default dashboard.)
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.
Procedure
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 54.
Step 4 Click Save.
Configuring Event View Settings

Use the Event View Settings page to configure characteristics of event views on the Firepower Management
Center. Note that some event view configurations are available only for specific user roles. Users with the
External Database User role can view parts of the event view settings user interface, but changing those settings
has no meaningful result.
Procedure
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 46.
Step 4 In the File Preferences section, configure file download preferences; see File Download Preferences, on page
47.
Step 5 In the Default Time Windows section, configure the default time window or windows; see Default Time
Windows, on page 47.

45
Your User Account
Event View Preferences
Step 6 In the Default Workflow sections, configure default workflows; see Default Workflows, on page 49.
Step 7 Click Save.
Event View Preferences

Use the Event Preferences section of the Event View Settings page to configure basic characteristics of event
views in the Firepower System. This section is available for all user roles, although it has little to no significance
for users who cannot view events.
The following fields appear in the Event Preferences section:
• The Confirm “All” Actions field controls whether the appliance forces you to confirm actions that affect
all events in an event view.
For example, if this setting is enabled and you click Delete All on an event view, you must confirm that
you want to delete all the events that meet the current constraints (including events not displayed on the
current page) before the appliance will delete them from the database.
• 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

46
Your User Account
File Download Preferences
• 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 1361
File Download Preferences

Use the File Preferences section of the Event View Settings page to configure basic characteristics of local
file downloads. This section is only available to users with the Administrator, Security Analyst, or Security
Analyst (Read Only) user roles.
Note that if your appliance does not support downloading captured files, these options are disabled.
The following fields appear in the File Preferences section:
• The Confirm ‘Download File’ Actions check box controls whether a File Download pop-up window
appears each time you download a file, displaying a warning and prompting you to continue or cancel.
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.
Default Time Windows

The time window, sometimes called the time range, imposes a time constraint on the events in any event view.
Use the Default Time Windows section of the Event View Settings page to control the default behavior of
the time window.
User role access to this section is as follows:
• Administrators and Maintenance Users can access the full section.
• Security Analysts and Security Analysts (Read Only) can access all options except Audit Log Time
Window.

47
Your User Account
Default Time Windows
• Access Admins, Discovery Admins, External Database Users, Intrusion Admins, Network Admins, and
Security Approvers can access only the Events Time Window option.
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 compliance
allow 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

48
Your User Account
Default Workflows
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.
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.
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.
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.
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.

49
Your User Account
Setting Your Default Time Zone
Setting Your Default Time Zone

This setting determines the times displayed in the web interface for your user account only, for things like
task scheduling and viewing dashboards. This setting does not change the system time or affect any other
user, and does not affect data stored in the system, which generally uses UTC.
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.
Procedure
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.
Specifying Your Default Dashboard

The default dashboard appears when you choose Overview > Dashboards. Unless changed, the default
dashboard for all users is the Summary dashboard. You can change the default dashboard if your user role is
Administrator, Maintenance, or Security Analyst.
In a multidomain deployment, the default dashboard you choose applies to all domains where your user
account has access. When choosing a dashboard for an account that frequently accesses multiple domains,
keep in mind that certain dashboard widgets are constrained by domain.
Procedure
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.

50
Your User Account
History for Specifying User Preferences
Related Topics
Viewing Dashboards, on page 423

UI Themes 7.0 You can choose the look and feel of the FMC web interface.
6.7 Choose the Light or Dusk theme, or use the Classic theme that appeared in previous FMC
releases.
6.6
User Name > User Preferences > General > UI Theme
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.
User Name > User Preferences > General > Change Password

51
Your User Account

52
CHAPTER 4
User Accounts for FMC
The FMC includes default admin accounts for web and CLI access. This chapter discusses how to create
custom user accounts. See Logging into the Firepower System, on page 29 for detailed information about
logging into the FMC with a user account.
• About User Accounts for FMC, on page 53
• Guidelines and Limitations for User Accounts for FMC, on page 58
• Requirements and Prerequisites for User Accounts for FMC, on page 59
• Add an Internal User, on page 59
• Configure External Authentication, on page 61
• Configure SAML Single Sign-On, on page 77
• Customize User Roles for the Web Interface, on page 126
• Troubleshooting LDAP Authentication Connections, on page 130
• History for User Accounts for FMC, on page 132
About User Accounts for FMC

You can add three kinds of custom user accounts on the FMC: internal users, external users on an LDAP or
RADIUS server, or SSO users on a SAML 2.0-compliant SSO identity provider. The FMC maintains separate
user accounts from managed devices. For example, when you add a user to the FMC, that user only has access
to the FMC; you cannot then use that username to log directly into a managed device. You must separately
add a user on the managed device.
Internal, External, and SSO Users

The FMC supports three types of users:
• Internal user—The FMC checks a local database for user authentication. For more information about
internal users, see Add an Internal User, on page 59.
• External user—If the user is not present in the local database, the system queries an external LDAP or
RADIUS authentication server. For more information about external users, see Configure External
Authentication, on page 61 .
• SSO user—If the account is configured at an SSO identity provider, the user logs in using a Single
Sign-On link on the FMC login page, and the FMC redirects the user to the IdP for authentication and
authorization. For more information about SSO users see Configure SAML Single Sign-On, on page 77.

53
Your User Account
Web Interface and CLI Access
Web Interface and CLI Access

The FMC has a web interface, CLI (accessible from the console (either the serial port or the keyboard and
monitor) or using SSH to the management interface), and Linux shell. For detailed information about the
management UIs, see Firepower System User Interfaces, on page 31.
See the following information about FMC user types, and which UI they can access:
• admin user—The FMC supports two different internal admin users: one for the web interface, and another
with CLI access. The system initialization process synchronizes the passwords for these two admin
accounts so they start out the same, but they are tracked by different internal mechanisms and may diverge
after initial configuration. See the Getting Started Guide for your model for more information on system
initialization. (To change the password for the web interface admin, use System > Users > Users. To
change the password for the CLI admin, use the FMC CLI command configure password.)
• Internal users—Internal users added in the web interface have web interface access only.
• External users—External users have web interface access, and you can optionally configure CLI access.
• SSO users—SSO users have web interface access only.
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.
Web Interface User Roles

User privileges are based on the assigned user role. For example, you can grant analysts predefined roles such
as Security Analyst and Discovery Admin and reserve the Administrator role for the security administrator
managing the device. You can also create custom user roles with access privileges tailored to your organization’s
needs.
The FMC includes the following predefined user roles:
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 1393.

54
Your User Account
User Roles
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.
User with this role can also:
• From the health monitor pages for specific devices, generate and download troubleshooting files.
• Under user preferences, set file download preferences.
• Under user preferences, set the default time window for event views (with the exception of the
Audit Log Time Window).

55
Your User Account
User Passwords
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 1473 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.

56
Your User Account
User Passwords
LOM Not Enabled LOM Enabled, admin user
Password Strength Passwords must include: Passwords must include:

Checking On
• At least eight characters, or the • Between eight and twenty characters
number of characters configured for (On MC 1000, MC 2500, and MC
the user by the administrator, 4500 the upper limit is fourteen
whichever is greater. characters rather than twenty.)
• No more than two sequentially • No more than two sequentially
repeating characters repeating characters
• At least one lower case letter • At least one lower case letter
• At least one upper case letter • At least one upper case letter
• At least one digit • At least one digit
• At least one special character such as • At least one special character such as
!@#*-_+ !@#*-_+
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.

57
Your User Account
Guidelines and Limitations for User Accounts for FMC
LOM Not Enabled LOM Enabled, admin user
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, on page 59 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 ! @ #
*-_+
The rules for special characters vary

between different series of physical FMCs.
We recommend restricting your choice of
special characters to those listed in the final
bullet above.
Do not include the user name in the
password.
Guidelines and Limitations for User Accounts for FMC

Defaults
• The FMC includes an admin user as a local user account for all forms of access; you cannot delete the
admin user. The default initial password is Admin123; the system forces you to change this during the
initialization process. See the Getting Started Guide for your model for more information about system
initialization.
• By default the following settings apply to all user accounts on the FMC:
• There are no limits on password reuse.
• The system does not track successful logins.
• The system does not enforce a timed temporary lockout for users who enter incorrect login credentials.
• There are no user-defined limits on the number of read-only and read/write sessions that can be
open at the same time.
You can change these settings for all users as a system configuration. (System > Configuration > User
Configuration) See Global User Configuration Settings, on page 1393.

58
Your User Account
Requirements and Prerequisites for User Accounts for FMC
Requirements and Prerequisites for User Accounts for FMC

Model Support
FMC
Supported Domains
• SSO configuration—Global only.
• All other features—Any.
User Roles
• SSO configuration—Only users with the Admin role authenticated internally or by LDAP or RADIUS
can configure SSO.
• All other features—Any user with the Admin role.
• Configure Common Access Card Authentication with LDAP, on page 76 also supports the Network
Admin role.
Add an Internal User

This procedure describes how to add custom internal user accounts for the FMC.
The System > Users > Users shows both internal users that you added manually and external users that were
added automatically when a user logged in with LDAP or RADIUS authentication. For external users, you
can modify the user role on this screen if you assign a role with higher privileges; you cannot modify the
password settings.
In a multidomain deployment on the FMC, users are only visible in the domain in which they are created.
Note that if you add a user in the Global domain, but then assign a user role for a leaf domain, then that user
still shows on the Global Users page where it was added, even though the user "belongs" to a leaf domain.
If you enable security certifications compliance or Lights-Out Management (LOM) on a device, different
password restrictions apply. For more information on security certifications compliance, see Security
Certifications Compliance, on page 1473.
When you add a user in a leaf domain, that user is not visible from the global domain.
Note Avoid having multiple Admin users simultaneously creating new users on the FMC, as this may cause an
error resulting from a conflict in user database access.
Procedure
Step 1 Choose System > Users.

59
Your User Account
Add an Internal User
Step 2 Click Create User.

Step 3 Enter a User Name.
The username must comply with the following restrictions:
• Maximum 32 alphanumeric characters, plus hyphen (-), underscore (_) and period (.).
• Letters may be upper or lower case.
• Cannot include any punctuation or special characters other than hyphen (-), underscore (_) and period
(.).
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 7 Set the Maximum Number of Failed Logins.

Enter an integer, without spaces, that determines the maximum number of times each user can try to log in
after a failed login attempt before the account is locked. The default setting is 5 tries; use 0 to allow an
unlimited number of failed logins. The admin account is exempt from being locked out after a maximum
number of failed logins unless you enabled security certification compliance.
Step 8 Set the Minimum Password Length.

Enter an integer, without spaces, that determines the minimum required length, in characters, of a user’s
password. The default setting is 8. A value of 0 indicates that no minimum length is required.
Step 9 Set the Days Until Password Expiration.

Enter the number of days after which the user’s password expires. The default setting is 0, which indicates
that the password never expires. If you change from the default, then the Password Lifetime column of the
Users list indicates the days remaining on each user’s password.
Step 10 Set the Days Before Password Expiration Warning.

Enter the number of warning days users have to change their password before their password actually expires.
The default setting is 0 days.
Step 11 Set user Options.

• Force Password Reset on Login—Forces users to change their passwords the next time they log in.
• Check Password Strength—Requires strong passwords. When password strength checking is enabled,
passwords must comply with the strong password requirements described in User Passwords, on page
56.
• Exempt from Browser Session Timeout—Exempts a user’s login sessions from termination due to
inactivity. Users with the Administrator role cannot be made exempt.
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 126.

60
Your User Account
Configure External Authentication
For external users, if the user role is assigned through group membership (LDAP), or based on a user attribute
(RADIUS), 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.
b. Choose a domain from the Domain drop-down list.
c. Check the user roles you want to assign the user.
d. Click Save.
Step 13 (Optional, for physical FMCs only.) If you have assigned the user the Administrator role, the Administrator
Options appear. You can select Allow Lights-Out Management Access to grant Lights-Out Management
access to the user. See Lights-Out Management Overview, on page 1402 for more information about Lights-Out
Management.
Step 14 Click Save.
Configure External Authentication

To enable external authentication, you need to add one or more external authentication objects.
About External Authentication

When you enable external authentication, the FMC verifies the user credentials with an LDAP or RADIUS
server as specified in an external authentication object.
You can configure multiple external authentication objects for web interface access. For example, if you have
5 external authentication objects, users from any of them can be authenticated to access the web interface.
You can use only one external authentication object for CLI access. If you have more than one external
authentication object enabled, then users can authenticate using only the first object in the list.
External authentication objects can be used by the FMC and FTD devices. You can share the same object
between the different appliance/device types, or create separate objects.

61
Your User Account
About LDAP
Note The timeout range is different for the FTD and the FMC, so if you share an object, be sure not to exceed the
FTD's smaller timeout range (1-30 seconds for LDAP, and 1-300 seconds for RADIUS). If you set the timeout
to a higher value, the FTD external authentication configuration will not work..
For the FMC, enable the external authentication objects directly on the System > Users > External
Authentication tab; this setting only affects FMC usage, and it does not need to be enabled on this tab for
managed device usage. For FTD devices, you must enable the external authentication object in the platform
settings that you deploy to the devices.
Web interface users are defined separately from CLI users in the external authentication object. For CLI users
on RADIUS, you must pre-configure the list of RADIUS usernames in the external authentication object. For
LDAP, you can specify a filter to match CLI users on the LDAP server.
You cannot use an LDAP object for CLI access that is also configured for CAC authentication.
Note Users with CLI access can gain Linux shell access with the expert command. Linux shell users can obtain
root privileges, which can present a security risk. Make sure that you:
• Restrict the list of users with CLI or 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 Microsoft 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.

62
Your User Account
Add an LDAP External Authentication Object for FMC

Add an LDAP server to support external users for device management.
In a multidomain deployment, external authentication objects are only available in the domain in which they
are created.
Before you begin

• You must specify DNS server(s) for domain name lookup on your device. Even if you specify an IP
address and not a hostname for the LDAP server on this procedure, the LDAP server may return a URI
for authentication that can include a hostname. A DNS lookup is required to resolve the hostname. See
Modify FMC Management Interfaces, on page 1365 to add DNS servers.
• If you are configuring an LDAP authentication object for use with CAC authentication, do not remove
the CAC inserted in your computer. You must have a CAC inserted at all times after enabling user
certificates.
Procedure

Step 2 Click the External Authentication tab.
Step 3 Click Add External Authentication Object.
Step 4 Set the Authentication Method to LDAP.
Step 5 (Optional) Check the check box for CAC if you plan to use this authentication object for CAC authentication
and authorization.
You must also follow the procedure in Configure Common Access Card Authentication with LDAP, on page
76 to fully configure CAC authentication and authorization. You cannot use this object for CLI users.
Step 6 Enter a Name and optional Description.

Step 7 Choose a Server Type from the drop-down list.
Tip If you click Set Defaults, the device populates the User Name Template, UI Access Attribute,
CLI Access Attribute, Group Member Attribute, and Group Member URL Attribute fields
with default values for the server type.
Step 8 For the Primary Server, enter a Host Name/IP Address.

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.
Step 9 (Optional) Change the Port from the default.

Step 10 (Optional) Enter the Backup Server parameters.
Step 11 Enter LDAP-Specific Parameters.
a) Enter the Base DN for the LDAP directory you want to access. For example, to authenticate names in the
Security organization at the Example company, enter ou=security,dc=example,dc=com. Alternatively
click Fetch DNs, and choose the appropriate base distinguished name from the drop-down list.
b) (Optional) Enter the Base Filter. For example, if the user objects in a directory tree have a
physicalDeliveryOfficeName attribute and users in the New York office have an attribute value of

63
Your User Account
NewYork for that attribute, to retrieve only users in the New York office, enter
(physicalDeliveryOfficeName=NewYork).
If you are using CAC authentication, to filter only active user accounts (excluding the disabled user
accounts), enter (!(userAccountControl:1.2.840.113556.1.4.803:=2)). This criteria retrieves user
accounts within AD belonging to ldpgrp group and with userAccountControl attribute value that is not
2 (disabled).
c) Enter a User Name for a user who has sufficient credentials to browse the LDAP server. For example, if
you are connecting to an OpenLDAP server where user objects have a uid attribute, and the object for
the administrator in the Security division at your example company has a uid value of NetworkAdmin,
you might enter uid=NetworkAdmin,ou=security,dc=example,dc=com.
d) Enter the user password in the Password and the Confirm Password fields.
e) (Optional) Click Show Advanced Options to configure the following advanced options.
• Encryption—Click None, TLS, or SSL.
If you change the encryption method after specifying a port, you reset the port to the default value
for that method. For None or TLS, the port resets to the default value of 389. If you choose SSL
encryption, the port resets to 636.
• SSL Certificate Upload Path—For SSL or TLS encryption, you must choose a certificate by clicking
Choose File.
If you previously uploaded a certificate and want to replace it, upload the new certificate and redeploy
the configuration to your devices to copy over the new certificate.
Note TLS encryption requires a certificate on all platforms. We recommend that you always
upload a certificate for SSL to prevent man-in-the-middle attacks.
• 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 %s@security.example.com.
This field is required for CAC authentication.
• Shell User Name Template—Provide a template that corresponds with your CLI Access Attribute
to authenticate CLI users. For example, to authenticate all users who work in the Security organization
by connecting to an OpenLDAP server where the CLI access attribute is sAMAccountName, you might
enter %s in the Shell User Name Template field.
• Timeout—Enter the number of seconds before rolling over to the backup connection, between 1 and
1024. The default is 30.
Note The timeout range is different for the FTD and the FMC, so if you share an object, be sure
not to exceed the FTD's smaller timeout range (1-30 seconds). If you set the timeout to a
higher value, the FTD LDAP configuration will not work.
Step 12 (Optional) Configure Attribute Mapping to retrieve users based on an attribute.

• 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,

64
Your User Account
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 CLI 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 CLI access attribute
to retrieve CLI access users by typing sAMAccountName.
Step 13 (Optional) Configure Group Controlled Access Roles.

If you do not configure a user’s privileges using group-controlled access roles, a user has only the privileges
granted by default in the external authentication policy.
a) (Optional) In the fields that correspond to user roles, enter the distinguished name for the LDAP groups
that contain users who should be assigned to those roles.
Any group you reference must exist on the LDAP server. You can reference static LDAP groups or
dynamic LDAP groups. Static LDAP groups are groups where membership is determined by group object
attributes that point to specific users, and dynamic LDAP groups are groups where membership is
determined by creating an LDAP search that retrieves group users based on user object attributes. Group
access rights for a role only affect users who are members of the group.
If you use a dynamic group, the LDAP query is used exactly as it is configured on the LDAP server. For
this reason, the Firepower device limits the number of recursions of a search to 4 to prevent search syntax
errors from causing infinite loops.
Example:
Enter the following in the Administrator field to authenticate names in the information technology
organization at the Example company:
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.
d) If you use dynamic groups, enter a Group Member URL Attribute.
Example:
If the memberURL attribute contains the LDAP search that retrieves members for the dynamic group you
specified for default Admin access, enter memberURL.
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 CLI 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:

65
Your User Account
• 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).
The usernames must be Linux-valid:

• 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 Users with CLI access can gain Linux shell access with the expert command. Linux shell users can
obtain root privileges, which can present a security risk. Make sure that you restrict the list of users
with CLI or Linux shell access.
Note Do not create any internal users that have the same user name as users included in the CLI Access
Filter. The only internal FMC user should be admin; do not include an admin user in the CLI
Access Filter.
Step 15 (Optional) Click Test to test connectivity to the LDAP server.

The test output lists valid and invalid user names. Valid user names are unique, and can include underscores
(_), periods (.), hyphens (-), and alphanumeric characters. Note that testing the connection to servers with
more than 1000 users only returns 1000 users because of UI page size limitations. If the test fails, see
Troubleshooting LDAP Authentication Connections, on page 130.
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.
Step 17 Click Save.

Step 18 Enable use of this server. See Enable External Authentication for Users on the FMC, on page 75.

66
Your User Account
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 shows a connection using a base distinguished name of

OU=security,DC=it,DC=example,DC=com for the security organization in the information technology
domain of the Example company.

67
Your User Account
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.
In addition, a CLIAccess 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.
Note that because no base filter is applied to this server, the Firepower System checks attributes for
all objects in the directory indicated by the base distinguished name. Connections to the server time
out after the default time period (or the timeout period set on the LDAP server).
Advanced Example
This example illustrates an advanced configuration of an LDAP login authentication object for a


68
Your User Account
domain of the Example company. However, note that this server has a base filter of (cn=*smith).
The filter restricts the users retrieved from the server to those with a common name ending in smith.
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 CLI 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.

69
Your User Account
Add a RADIUS External Authentication Object for FMC
The CLI 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.

Add a RADIUS server to support external users for device management.
are created.
Procedure

70
Your User Account
Step 2 Click External Authentication.

Step 4 Set the Authentication Method to RADIUS.
Step 8 Enter the RADIUS Secret Key.
Step 10 (Optional) Enter RADIUS-Specific Parameters.
a) Enter the Timeout in seconds before retrying the primary server, between 1 and 1024. The default is 30.
Note The timeout range is different for the FTD and the FMC, so if you share an object, be sure not
to exceed the FTD's smaller timeout range (1-300 seconds). If you set the timeout to a higher
value, the FTD RADIUS configuration will not work.
b) Enter the Retries before rolling over to the backup server. The default is 3.
c) In the fields that correspond to user roles, enter the name of each user or identifying attribute-value pair
that should be assigned to those roles.
Separate usernames and attribute-value pairs with commas.
Example:
If you know all users who should be Security Analysts have the value Analyst for their User-Category
attribute, you can enter User-Category=Analyst in the Security Analyst field to grant that role to those
users.
Example:
To grant the Administrator role to the users jsmith and jdoe, enter jsmith, jdoe in the Administrator
field.
Example:
To grant the Maintenance User role to all users with a User-Category value of Maintenance, enter
User-Category=Maintenance in the Maintenance User field.
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.
Step 11 (Optional) Define Custom RADIUS Attributes.

If your RADIUS server returns values for attributes not included in the dictionary file in /etc/radiusclient/,
and you plan to use those attributes to set roles for users with those attributes, you need to define those
attributes. You can locate the attributes returned for a user by looking at the user’s profile on your RADIUS
server.
a) Enter an Attribute Name.
When you define an attribute, you provide the name of the attribute, which consists of alphanumeric
characters. Note that words in an attribute name should be separated by dashes rather than spaces.
b) Enter the Attribute ID as an integer.

71
Your User Account
The attribute ID should be an integer and should not conflict with any existing attribute IDs in the
etc/radiusclient/dictionary file.
c) Choose the Attribute Type from the drop-down list.

You also specify the type of attribute: string, IP address, integer, or date.
d) Click Add to add the custom attribute.
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 CLI Access Filter area Administrator CLI 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:
• All lowercase
To prevent RADIUS authentication of CLI access, leave the field blank.

Note Remove any internal users that have the same user name as users included in the shell access filter.
For the FMC, the only internal CLI user is admin, so do not also create an admin external user.
Step 13 (Optional) Click Test to test FMC connectivity to the RADIUS server.
able to authenticate: enter a User Name and Password, and then click Test.
Example:

72
Your User Account
password.
Step 15 Click Save.

Step 16 Enable use of this server. See Enable External Authentication for Users on the FMC, on page 75.
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:

73
Your User Account
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.

74
Your User Account
Enable External Authentication for Users on the FMC
Enable External Authentication for Users on the FMC

When you enable external authentication for management users, the FMC verifies the user credentials with
an LDAP or RADIUS server as specified in an External Authentication object.
Before you begin

Add one or more external authentication objects according to Add an LDAP External Authentication Object
for FMC, on page 63 and Add a RADIUS External Authentication Object for FMC, on page 70.
Procedure

Step 3 Set the default user role for external web interface users.
Users without a role cannot perform any actions. Any user roles defined in the external authentication object
overrides this default user role.
a) Click the Default User Roles value (by default, none selected).
a) In the Default User Role Configuration dialog box, check the role(s) that you want to use.
b) Click Save.
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 CLI
Access Filter. Also, CLI access users can only authenticate against the server whose authentication object is
highest in the list.

75
Your User Account
Configure Common Access Card Authentication with LDAP
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 7 Click Save and Apply.
Configure Common Access Card Authentication with LDAP

If your organization uses Common Access Cards (CACs), you can configure LDAP authentication to
authenticate FMC users logging into the web interface. With CAC authentication, users have the option to
log in directly without providing a separate username and password for the device.
CAC-authenticated users are identified by their electronic data interchange personal identifier (EDIPI) numbers.
After 24 hours of inactivity, the device deletes CAC-authenticated users from the Users tab. The users are
re-added after each subsequent login, but you must reconfigure any manual changes to their user roles.
Before you begin

You must have a valid user certificate present in your browser (in this case, a certificate passed to your browser
via your CAC) to enable user certificates as part of the CAC configuration process. After you configure CAC
authentication and authorization, users on your network must maintain the CAC connection for the duration
of their 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.
Procedure
Step 1 Insert a CAC as directed by your organization.

device.
Step 3 If prompted, enter the PIN associated with the CAC you inserted in step 1.
Step 4 If prompted, choose the appropriate certificate from the drop-down list.
Step 5 On the Login page, in the Username and Password fields, log in as a user with Administrator privileges.
You cannot yet log in using your CAC credentials.
Step 6 Choose System > Users > External Authentication.
Step 7 Create an LDAP authentication object exclusively for CAC, following the procedure in Add an LDAP External
Authentication Object for FMC, on page 63. You must configure the following:
• CAC check box.
• LDAP-Specific Parameters > Show Advanced Options > User Name Template.
• Attribute Mapping > UI Access Attribute.
Step 8 Click Save.

76
Your User Account
Configure SAML Single Sign-On
Step 9 Enable external authentication and CAC authentication as described in Enable External Authentication for
Users on the FMC, on page 75.
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 1354.
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 1355.
Step 13 Log into the device according to Logging Into the Firepower Management Center with CAC Credentials, on
page 36.
Configure SAML Single Sign-On

You can configure your FMC to use Single Sign-On, a system by which a central identity provider (IdP)
provides authentication and authorization for users logging into the FMC as well as other applications within
an organization. The applications configured to take part in such an SSO arrangement are said to be federated
service provider applications. SSO users can log in once to gain access to all service provider applications
that are members of the same federation.
About SAML Single Sign-On

An FMC configured for SSO presents a link for single sign-on on the Login page. Users configured for SSO
access click on this link and are redirected to the IdP for authentication and authorization, rather than supplying
a username and password on the FMC Login page. Once successfully authenticated by the IdP, SSO users
are redirected back to the FMC web interface and logged in. All the communication between the FMC and
the IdP to accomplish this takes place using the browser as an intermediary; as a result, the FMC does not
require a network connection to directly access the identity provider.
The FMC supports SSO using any SSO provider conforming to the Security Assertion Markup Language
(SAML) 2.0 open standard for authentication and authorization. The FMC web interface offers configuration
options for the following SSO providers:
• Okta
• OneLogin
• Azure
• PingID's PingOne for Customers cloud solution
Note The Cisco Secure Sign On SSO product does not recognize the FMC as a pre-integrated service provider.

77
Your User Account
SSO Guidelines for the FMC
SSO Guidelines for the FMC

Keep the following in mind when you configure an FMC to be a member of an SSO federation:
• The FMC can support SSO with only one SSO provider at a time—you cannot configure the FMC to
use, for instance, both Okta and OneLogin for SSO.
• FMCs in a high availability configuration can support SSO, but you must keep the following considerations
in mind:
• SSO configuration is not synchronized between the members of the high availability pair; you must
configure SSO separately on each member of the pair.
• Both FMCs in a high availability pair must use the same IdP for SSO. You must configure a service
provider application at the IdP for each FMC configured for SSO.
• In a high availability pair of FMCs where both are configured to support SSO, before a user can
use SSO to access the secondary FMC for the first time, that user must first use SSO to log into the
primary FMC at least once.
• When configuring SSO for FMCs in a high availability pair:
• If you configure SSO on the primary FMC, you are not required to configure SSO on the
secondary FMC.
• If you configure SSO on the secondary FMC, you are required to configure SSO on the primary
FMC as well. (This is because SSO users must login into the primary FMC at least once before
logging into the secondary FMC.)
• 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.
• Only users with the Admin role authenticated internally or by LDAP or RADIUS can configure SSO.
• The FMC does not support SSO initiated from the IdP.
• The FMC does not support logging in with CAC credentials for SSO accounts.
• Do not configure SSO in deployments using CC mode.
• SSO activities are logged in the FMC audit log with Login or Logout specified in the Subsystem field.
Related Topics
Firepower Management Center High Availability, on page 321
Domain Management, on page 517
Logging Into the Firepower Management Center with CAC Credentials, on page 36
Security Certifications Compliance, on page 1473
Audit Records, on page 479
SSO User Accounts

Identity providers can support user and group configuration directly, or they often can import users and groups
from other user management applications such as Active Directory, RADIUS, or LDAP. This documentation
focuses on configuring the FMC to work with the IdP to support SSO assuming that IdP users and groups are

78
Your User Account
User Role Mapping for SSO Users
already established; to configure an IdP to support users and groups from other user management applications,
consult the IdP vendor documentation.
Most account characteristics for SSO users, including the user name and password, are established at the IdP.
SSO accounts do not appear on the FMC web interface Users page until those accounts log in the first time.
Note The FMC requires that user names for SSO accounts as well as the NameID attribute the IdP sends to the
FMC during the SAML login process must be both be valid email addresses. Many IdP's automatically use
the username of the user trying to logon as the NameID attribute, but you should confirm this is the case for
your IdP. Keep this in mind when configuring a service provider application at your IdP and creating IdP user
accounts that are to be granted SSO access to an FMC.
The following account characteristics for SSO users can be configured from the FMC web interface under
System > User > Edit User:
• Real Name
• Exempt from Browser Session Timeout
User Role Mapping for SSO Users

By default, all users given SSO access to an FMC are assigned the Security Analyst (Read Only) role. You
can change this default, as well as override it for specific SSO users or groups with user role mapping. After
you have established and successfully tested the FMC SSO configuration, you can configure user role mapping
to establish what FMC user roles SSO users are assigned when they log in.
User role mapping requires coordinating configuration settings at the FMC with settings at the SSO IdP
application. User roles can be assigned to users or to groups defined at the IdP application. Users may or may
not be members of groups, and user or group definitions may or may not be imported to the IdP from other
user management systems within your organization, such as Active Directory. For this reason, to effectively
configure FMC SSO user role mapping you must be familiar with how your SSO federation is organized and
how users, groups and their roles are assigned at the SSO IdP application. This documentation focuses on
configuring the FMC to work with the IdP to support user role mapping; to create users or groups within the
IdP, or import users or groups into the IdP from a user management application, consult the IdP vendor
documentation.
In user role mapping, the IdP maintains a role attribute for the FMC service provider application, and each
user or group with access to that FMC is configured with a string or expression for the role attribute
(requirements for the attribute value are different for each IdP). At the FMC the name of the that role attribute
is part of the SSO configuration. The FMC SSO configuration also contains a list of expressions assigned to
a list of FMC user roles. When a user logs into the FMC using SSO, the FMC compares the value of the role
attribute for that user (or that user's group, depending upon configuration) against the expressions for each
FMC user role. The FMC assigns the user all the roles where the expression matches the attribute value the
user has provided.
Note You can configure FMC roles to be mapped based on individual user permissions or based on group permissions,
but a single FMC application cannot support role mapping for both groups and individual users.

79
Your User Account
Enable Single Sign-On at the FMC
Enable Single Sign-On at the FMC

Before you begin
• At the SAML SSO management application, configure a service provider application for the FMC and
assign users or groups to the service provider application:
• To configure an FMC service provider application for Okta, see Configure an FMC Service Provider
Application for Okta, on page 82.
• To configure an FMC service provider application for OneLogin, see Configure an FMC Service
Provider Application for OneLogin, on page 93.
• To configure an FMC service provider application for Azure, see Configure an FMC Service Provider
Application for Azure, on page 21.
• To configure an FMC service provider application for PingID's PingOne for Customers cloud
solution, see Configure an FMC Service Provider Application for PingID PingOne for Customers,
on page 117.
• To configure an FMC service provider application for any SAML 2.0-compliant SSO provider, see
Configure an FMC Service Provider Application for Any SAML 2.0-Compliant SSO Provider, on
page 121.
Procedure
Step 1 Choose System > Users > Single Sign-On.

Step 2 Click the Single Sign-On (SSO) Configuration slider to enable SSO.
Step 3 Click the Configure SSO button.
Step 4 At the Select FMC SAML Provider dialog, click the radio button for the SSO IdP of your choice and click
Next.
What to do next
Proceed with the instructions appropriate to your choice of SSO provider:
• Configure the FMC for Okta SSO; see Configure the FMC for Okta SSO, on page 83.
• Configure the FMC for SSO using PingID's PingOne for Customers cloud solution; see Configure the
FMC for SSO with PingID PingOne for Customers, on page 119.
• Configure the FMC for Azure SSO; see Configure the FMC for Azure SSO, on page 107.
• Configure the FMC for OneLogin SSO; see Configure the FMC for OneLogin SSO, on page 95.
• Configure the FMC for SSO using any SAML 2.0-compliant provider; see Configure the FMC for SSO
Using Any SAML 2.0-Compliant SSO Provider, on page 123.

80
Your User Account
Configure Single Sign-On with Okta
Configure Single Sign-On with Okta

See the following tasks to configure SSO using Okta:
Okta UI Admin Review the Okta Org, on page 81

Console
Okta UI Admin Configure an FMC Service Provider Application for Okta, on page 82
Console
FMC Enable Single Sign-On at the FMC, on page 80
FMC Configure the FMC for Okta SSO, on page 83
FMC Configure User Role Mapping for Okta at the FMC, on page 84
Okta UI Admin Configure User Role Mapping at the Okta IdP, on page 85
Console
Review the Okta Org

In Okta, the entity that encompasses all the federated devices and applications that a user can access with the
same SSO account is called an org. Before adding the FMC to an Okta org, be familiar with its configuration;
consider the following questions:
• How many users will have access to the FMC?
• Are users within the Okta org members of groups?
• Are user and group definitions native to Okta or imported from a user management application such as
Active Directory, RADIUS, or LDAP?
• Do you need to add more users or groups to the Okta org to support SSO on the FMC?
• What kind of user role assignments do you want to make? (If you choose not to assign user roles, the
FMC automatically assigns a configurable default user role to all SSO users.)

81
Your User Account
Configure an FMC Service Provider Application for Okta
• How must users and groups within the Okta org be organized to support the required user role mapping?
Keep in mind that you can configure FMC roles to be mapped based on individual user permissions or based
on group permissions, but a single FMC application cannot support role mapping for both groups and individual
users.
This documentation assumes you are already familiar with the Okta Classic UI Admin Console, and have an
account that can perform configuration functions requiring Super Admin permissions. If you need more
information, see Okta's documentation available online.
Configure an FMC Service Provider Application for Okta

Use these instructions at the Okta Classic UI Admin Console to create an FMC service provider application
within Okta and assign users or groups to that application. You should be familiar with SAML SSO concepts
and the Okta admin console. This documentation does not describe all the Okta functions you need to establish
a fully functional SSO org; for instance, to create users and groups, or to import user and group definitions
from another user management application, see the Okta documentation.
Note If you plan to assign user groups to the FMC application, do not also assign users within those groups as
individuals.
Note The FMC cannot support role mapping using multiple SSO attributes; you must select either user role mapping
or group role mapping and configure a single attribute to convey user role information from OneLogin to the
FMC.
Before you begin

• Familiarize yourself with the SSO federation and its user and groups; see Review the Okta Org, on page
81.
• Create user accounts and/or groups in your Okta org if necessary.
Note The FMC requires that user names for SSO accounts as well as the NameID
attribute the IdP sends to the FMC during the SAML login process must be both
be valid email addresses. Many IdP's automatically use the username of the user
trying to logon as the NameID attribute, but you should confirm this is the case
for your IdP. Keep this in mind when configuring a service provider application
at your IdP and creating IdP user accounts that are to be granted SSO access to
an FMC.
• Confirm the login URL for the target FMC (https://ipaddress_or_hostname).

82
Your User Account
Configure the FMC for Okta SSO
Note If your FMC web interface can be reached with multiple URLs (for instance, a
fully-qualified domain name as well as an IP address), SSO users must consistently
access the FMC using the login URL that you configure in this task.
Procedure
Step 1 From the Okta Classic UI Admin Console, create a service provider application for the FMC. Configure the
FMC application with the following selections:
• Select Web for the Platform.
• Select SAML 2.0 for the Sign on method.
• Provide a Single sign on URL.
This is the FMC URL to which the browser sends information on behalf of the IdP.
Append the string saml/acs to the FMC login URL. For example: https://ExampleFMC/saml/acs.
• Enable Use this for Recipient URL and Destination URL.

• Enter an Audience URI (SP Entity ID).
This is a globally unique name for the service provider (the FMC), often formatted as a URL.
Append the string /saml/metadata to the FMC login URL. For example:
https://ExampleFMC/saml/metadata.
• For Name ID Format choose Unspecified.
Step 2 (Optional if you are assigning groups to the application.) Assign individual Okta users to the FMC application.
(If you plan to assign groups to the FMC application, do not assign users that are members of those groups
as individuals.)
Step 3 (Optional if you are assigning individual users to the application.) Assign Okta groups to the FMC application.
Step 4 (Optional) To make SSO setup at the FMC easier, you can download the SAML XML metadata file for the
FMC service provider application from Okta to your local computer.
What to do next
Enable single sign-on; see Enable Single Sign-On at the FMC, on page 80.
Configure the FMC for Okta SSO

Use these instructions at the FMC web interface.
Before you begin
• Create an FMC service provider application at the Okta Classic UI Admin Console; see Configure an
FMC Service Provider Application for Okta, on page 82.
• Enable single sign-on; see Enable Single Sign-On at the FMC, on page 80.

83
Your User Account
Configure User Role Mapping for Okta at the FMC
Procedure
Step 1 (This step continues directly from Enable Single Sign-On at the FMC, on page 80.) At the Configure Okta
Metadata dialog, you have two choices:
• To enter the SSO configuration information manually:
a. Click the Manual Configuration radio button.
b. Enter the following values from the Okta SSO Service Provider application. (Retrieve these values
from the Okta Classic UI Admin Console.)
• Identity Provider Single Sign-On URL
• Identity Provider Issuer
• X.509 Certificate
• If you saved the XML metadata file generated by Okta to your local computer (Step 4 in Configure an
FMC Service Provider Application for Okta, on page 82), you can upload the file to the FMC:
a. Click the Upload XML File radio button.
b. Follow the on-screen instructions to navigate to and choose the XML metadata file on your local
computer.
Step 2 Click Next.

Step 3 At the Verify Metadata dialog, review the configuration parameters and click Save.
Step 4 Click Test Configuration. If the system displays an error message, review the SSO configuration for the
FMC as well as the Okta service provider application configuration, correct any errors, and try again.
Step 5 When the system reports a successful configuration test, click Apply.
What to do next
You may optionally configure user role mapping for SSO users; see Configure User Role Mapping for Okta
at the FMC, on page 84. If you choose not to configure role mapping, by default all SSO users that log into
the FMC are assigned the user role you configure in Step 4 of Configure User Role Mapping for Okta at the
FMC, on page 84.
Configure User Role Mapping for Okta at the FMC

The fields to configure for user role mapping at the FMC web interface are the same regardless of your choice
of SSO provider. But the values you configure must take into account how the SAML SSO provider you use
implements user role mapping.
Before you begin

• Review the Okta user group mapping information; see Review the Okta Org, on page 81.
• Configure an SSO service provider application for the FMC; see Configure an FMC Service Provider

84
Your User Account
Configure User Role Mapping at the Okta IdP
• Enable and configure single sign-on at the FMC; see Enable Single Sign-On at the FMC, on page 80,
and Configure the FMC for Okta SSO, on page 83.
Procedure

Step 2 Click the Single Sign-On tab.
Step 3 Expand Advanced Configuration (Role Mapping).
Step 4 Select an FMC user role to assign users as a default value from the Default User Role drop-down.
Step 5 Enter a Group Member Attribute. This string must match an attribute name configured at the Okta FMC
provider application for user role mapping for either users or groups. (See Step 1 of Configure a User Attribute
for Role Mapping at the Okta IdP, on page 86 or Step 1 of Configure a Group Attribute for Role Mapping at
the Okta IdP, on page 87 .)
Step 6 Next to each FMC user role you wish to assign to SSO users, enter a regular expression. (The FMC uses a
restricted version of Google's RE2 regular expression standard supported by Golang and Perl.) The FMC
compares these values against the user role mapping attribute value the IdP sends to the FMC with SSO user
information. The FMC grants users a union of all the roles for which a match is found.
What to do next
• Configure user role mapping at the service provider application; see Configure User Role Mapping at
the Okta IdP, on page 85.
Configure User Role Mapping at the Okta IdP

You can configure SSO user role mapping at the Okta Classic UI Admin Console based on individual user
permissions or based on group permissions.
• To map based on individual user permissions, see Configure a User Attribute for Role Mapping at the
Okta IdP, on page 86.
• To map based on group permissions, see Configure a Group Attribute for Role Mapping at the Okta IdP,
on page 87.
When an SSO user logs in to the FMC, Okta presents to the FMC a user or group role attribute value configured
at the Okta IdP. The FMC compares that attribute value against the regular expressions assigned to each FMC
user role in the SSO configuration, and grants the user all the roles for which a match is found. (If no match
is found, the FMC grants the user a configurable default user role.) The expression you assign to each FMC
user role must comply with the restricted version of Google's RE2 regular expression standard supported by
Golang and Perl. The FMC treats the attribute value received from Okta as a regular expression using that
same standard for purposes of comparison with the FMC user role expressions.

85
Your User Account
Configure a User Attribute for Role Mapping at the Okta IdP
Note A single FMC cannot support role mapping for both groups and individual users; you must choose one mapping
method for the FMC service provider application and use it consistently. Furthermore, the FMC can support
group role mapping using only one group attribute statement per FMC service provider application configured
in Okta. Generally group-based roll mapping is more efficient for an FMC with many users. You should take
into account user and group definitions established throughout your Okta org.
Configure a User Attribute for Role Mapping at the Okta IdP

Use these instructions at the Okta Classic UI Admin Console to add a custom role mapping attribute to the
Okta default user profile.
Okta service provider applications may use one of two types of user profiles:
• Okta user profiles, which can be extended with any custom attribute.
• App user profiles, which can be extended only with attributes from a predefined list that Okta generates
by querying a third-party application or directory (such as Active directory, LDAP, or Radius) for
supported attributes.
You may use either type of user profile in your Okta org; consult Okta documentation for information on how
to configure them. Whichever type of user profile you use, to support user role mapping with the FMC you
must configure a custom attribute in the profile to convey each user's role mapping expression to the FMC.
This documentation describes role mapping using Okta user profiles; mapping with App profiles requires
familiarity with the third-party user management application in use at your organization to set up custom
attributes. See the Okta documentation for details.
Before you begin

• Configure an FMC service provider application at the Okta IdP as described in Configure an FMC Service
Provider Application for Okta, on page 82.
• Configure SSO user role mapping at the FMC as described in Configure User Role Mapping for Okta
at the FMC, on page 84.
Procedure
Step 1 Add a new attribute to the default Okta user profile:

• For Data type choose string.
• Provide the Variable name the Okta IdP will send to the FMC, containing an expression to match for
user role mapping. This variable name must match the string you entered at the FMC SSO configuration
for Group Member Attribute. (See Step 5 in Configure User Role Mapping for Okta at the FMC, on
page 84.)
Step 2 For each user assigned to the FMC service provider application using this profile, assign a value to the user
role attribute you have just created.
Use an expression to represent the role or roles the FMC will assign to the user. The FMC compares this string
against the expressions you assigned to each FMC user role in Step 6 of Configure User Role Mapping for

86
Your User Account
Configure a Group Attribute for Role Mapping at the Okta IdP
Okta at the FMC, on page 84. (For purposes of comparison with the FMC user role expressions, the FMC
treats the attribute value received from Okta as an expression complying with the restricted version of Google's
RE2 regular expression standard supported by Golang and Perl.)
Configure a Group Attribute for Role Mapping at the Okta IdP

Use these instructions at the Okta Classic UI Admin Console to add a custom role mapping group attribute
to the FMC service provider application. The FMC can support group role mapping using only one group
attribute statement per Okta FMC service provider application.
Okta service provider applications may use one of two types of groups:
• Okta groups, which can be extended with any custom attribute.
• Application groups, which can be extended only with attributes from a predefined list that Okta generates
by querying a third-party application or directory (such as Active directory, LDAP, or Radius) for
supported attributes.
You may use either type of group in your Okta org; consult Okta documentation for information on how to
configure them. Whichever type of group you use, to support user role mapping with the FMC you must
configure a custom attribute for the group to convey its role mapping expression to the FMC.
This documentation describes role mapping using Okta groups; mapping with application groups requires
familiarity with the third-party user management application in use at your organization to set up custom
attributes. See the Okta documentation for details.
Before you begin

• Configure an FMC service provider application at the Okta IdP; see Configure an FMC Service Provider
• Configure user role mapping at the FMC; Configure User Role Mapping for Okta at the FMC, on page
84.
Procedure
Create a new SAML group attribute for the FMC service provider application:
• For Name, use the same string you entered at the FMC SSO configuration for Group Member Attribute.
(See Step 5 in Configure User Role Mapping for Okta at the FMC, on page 84.)
• For Filter, specify an expression to represent the role or roles the FMC will assign to the members of
the group. Okta compares this value against the names of the group(s) of which a user is a member, and
sends the FMC the group names that match. The FMC in turn compares those group names against the
regular expressions you assigned to each FMC user role in Step 6 of Configure User Role Mapping for
Okta at the FMC, on page 84.

87
Your User Account
Okta User Role Mapping Examples
Okta User Role Mapping Examples

As the following examples demonstrate, the SSO configurations at the FMC to support user role mapping are
the same for both individual users and for groups. The difference lies in the settings at the FMC service
provider application in Okta.
Note You can configure FMC roles to be mapped based on individual user permissions or based on group permissions,
but a single FMC application cannot support role mapping for both groups and individual users. Furthermore,
the FMC can support group role mapping using only one group attribute statement per FMC service provider
application configured in Okta.
Okta Role Mapping Example for Individual User Accounts

In role mapping for individual users, the Okta FMC service application has a custom attribute whose name
matches the name of the Group Member Attribute on the FMC. (In this example, UserRole). The user profile
in Okta also has a custom attribute (in this example, a variable named FMCrole.) The definition for the
application custom attribute UserRole establishes that when Okta passes user role mapping information to
the FMC, it will use the custom attribute value assigned for the user in question.
The following diagrams illustrate how the relevant fields and values in the FMC and Okta configurations
correspond to each other in user role mapping for individual accounts. Each diagram uses the same SSO
configurations at the FMC and at the Okta UI Admin Console, but the configuration for each user at the Okta
UI Admin Console differs to assign each user different roles at the FMC.
• In this diagram sue@example.com uses the FMCrole value FMCAdmin and the FMC assigns her the
Administrator role.

88
Your User Account
Okta Role Mapping Example for Groups
• In this diagram fred@example.com uses the FMCrole value PolicyAdmin, and the FMC assigns him the
roles Access Admin, Discovery Admin, and Intrusion Admin.
• Other users assigned to the Okta service application for this FMC are assigned the default user role
Security Analyst (Read Only) for one of the following reasons:
• They have no value assigned to the FMCrole variable in their Okta user profile.
• The value assigned to the FMCrole variable in their Okta user profile does not match any expression
configured for a user role in the SSO configuration at the FMC.

In role mapping for groups, the Okta FMC service application has a custom group attribute whose name
matches the name of the Group Member Attribute on the FMC (in this example, UserRole). When Okta
processes a request for FMC SSO login, it compares the user's group membership against the expression
assigned to the FMC service application group attribute (in this case ^(.*)Admin$ ). Okta sends to the FMC
the user's group membership(s) that match the group attribute. The FMC compares the group names it receives
against the regular expressions it has configured for each user role, and assigns user roles accordingly.
The following diagrams illustrate how the relevant fields and values in the FMC and Okta configurations
correspond to each other in user role mapping for groups. Each diagram uses the same SSO configurations
at the FMC and at the Okta UI Admin Console, but the configuration for each user at the Okta UI Admin
Console differs to assign each user different roles at the FMC.
• In this diagram fred@example.com is a member of the Okta IdP group Admin, which matches the
expression ^(.*)Admin$. Okta sends the FMC Fred's Admin group membership, and the FMC assigns
him the Administrator role.

89
Your User Account
• In this diagram sue@example.com is a member of the Okta IdP group PolicyAdmin, which matches the
expression ^(.*)Admin$. Okta sends the FMC Sue's PolicyAdmin group membership, and the FMC
assigns her the roles Access Admin, Discovery Admin, and Intrusion Admin.
Sue is also a member of the Okta group Maint, but because this group name does not match the expression
assigned to the group membership attribute in the Okta FMC service application, Okta does not send
information about Sue's Maint group membership to the FMC, and her membership in the Maint group
plays no part in the roles the FMC assigns to her.

90
Your User Account
• In this diagram sean@example.com is a member of the Okta IdP group Maint. This group name does
not match the expression ^(.*)Admin$, so, when sean@example.com logs into the FMC, Okta does not
send information about Sean's Maint group membership to the FMC and Sean is assigned the default
user role (Security Analyst (Read Only)) rather than the Maintenance User role.

91
Your User Account
Configure Single Sign-On with OneLogin
These diagrams illustrate the importance of advance planning when establishing a role mapping strategy. In
this example, any Okta user with access to this FMC who is a member of only the Maint group can be assigned
only the default user role. The FMC supports using only one custom group attribute in its Okta Service
Application configuration. The expression you assign to that attribute and the group names you establish to
match against it must be carefully crafted. You can add more flexibility to role mapping by using regular
expressions in the user role assignment strings in the FMC SSO configuration. (The expression you assign to
each FMC user role must comply with the restricted version of Google's RE2 regular expression standard
supported by Golang and Perl.)
Configure Single Sign-On with OneLogin

See the following tasks to configure SSO using OneLogin:

92
Your User Account
Review the OneLogin Subdomain
FMC Review the OneLogin Subdomain, on page 93
FMC Configure an FMC Service Provider Application for OneLogin, on page 93
OneLogin Admin Enable Single Sign-On at the FMC, on page 80

Portal
OneLogin Admin Configure the FMC for OneLogin SSO, on page 95

Portal
OneLogin Admin Configure User Role Mapping for OneLogin at the FMC, on page 96
Portal
FMC Configure User Role Mapping at the OneLogin IdP, on page 97
Review the OneLogin Subdomain

In OneLogin, the entity that encompasses all the federated devices and applications that a user can access
with the same SSO account is called a subdomain. Before adding the FMC to a OneLogin subdomain, be
familiar with its configuration; consider the following questions:
• Are users within the OneLogin subdomain members of groups?
• Are users and groups from a third-party directory such as Active Directory, Google Apps, or LDAP
synchronized with the OneLogin subdomain?
• Do you need to add more users or groups to the OneLogin subdomain to support SSO on the FMC?
• What kind of FMC user role assignments do you want to make? (If you choose not to assign user roles,
the FMC automatically assigns a configurable default user role to all SSO users.)
• How must users and groups within the OneLogin subdomain be organized to support the required user
role mapping?
Keep in mind that you can configure FMC roles to be mapped based on individual users or based on groups,
but a single FMC application cannot support role mapping for both groups and individual users.
This documentation assumes you are already familiar with the OneLogin Admin Portal, and have an account
with Super User privilege. To configure user role mapping, you will also need a subscription to the OneLogin
Unlimited plan, which supports Custom User Fields. If you need more information, see the OneLogin
documentation available online.
Configure an FMC Service Provider Application for OneLogin

Use these instructions at the OneLogin Admin Portal to create an FMC service provider application within
OneLogin and assign users or groups to that application. You should be familiar with SAML SSO concepts
and the OneLogin Admin Portal. This documentation does not describe all the OneLogin functions you need
to establish a fully functional SSO org; for instance, to create users and groups, or to import user and group
definitions from another user management application, see the OneLogin documentation.

93
Your User Account
Configure an FMC Service Provider Application for OneLogin
individuals.
or grup role mapping and configure a single attribute to convey user role information from OneLogin to the
FMC.
Before you begin

• Familiarize yourself with the OneLogin subdomain and its users and groups; see Review the OneLogin
Subdomain, on page 93.
• Create user accounts in your OneLogin subdomain if necessary.
an FMC.
• Confirm the login URL for the target FMC (https://ipaddress_or_hostname/).
Note If your FMC web interface can be reached with multiple URLs. (for instance, a
Procedure
Step 1 Create the FMC service provider application using the SAML Test Connector (Advanced) as its basis.
Step 2 Configure the application with the following settings:
• For the Audience (Entity ID), append the string /saml/metadata to the FMC login URL. For example:
• For Recipient, append the string /saml/acs to the FMC login URL. For example:
https://ExampleFMC/saml/acs.
• For ACS (Consumer) URL Validator, enter an expression that OneLogin uses to confirm it is using
the correct FMC URL. You can create a simple validator by using the ACS URL and altering it as follows:

94
Your User Account
Configure the FMC for OneLogin SSO
• Append a ^ to the beginning of the ACS URL.

• Append a $ to the end of the ACS URL.
• Insert a \ preceding every / and ? within the ACS URL.
For example, for the ACS URL https://ExampleFMC/saml/acs, an appropriate URL validator would be
^https:\/\/ExampleFMC\/saml\/acs$.
• For ACS (Consumer) URL, append the string /saml/acs to the FMC login URL. For example:
• For Login URL, append the string /saml/acs to the FMC login URL. For example:
• For the SAML Initiator, choose Service Provider.
Step 3 Assign OneLogin users to the FMC service provider application.

Step 4 (Optional) To make SSO setup at the FMC easier, you can download the SAML XML metadata for the FMC
service provider application from OneLogin to your local computer.
What to do next
Configure the FMC for OneLogin SSO

Before you begin

• Create an FMC service provider application at the OneLogin Admin Portal; see Configure an FMC
Service Provider Application for OneLogin, on page 93.
Procedure
Step 1 (This step continues directly from Enable Single Sign-On at the FMC, on page 80.) At the Configure OneLogin
b. Enter the following SSO configuration values from the OneLogin service provide application:
• Identity Provider Single Sign-On URL: Enter the SAML 2.0 Endpoint (HTTP) from
OneLogin.
• Identity Provider Issuer: Enter the Issuer URL from OneLogin.
• X.509 Certificate: Enter the X.509 Certificate from OneLogin.

95
Your User Account
Configure User Role Mapping for OneLogin at the FMC
• If you saved the XML metadata file generated by OneLogin to your local computer (Step 4 in Configure
an FMC Service Provider Application for OneLogin, on page 93), you can upload the file to the FMC:
computer.
Step 2 Click Next.

FMC as well as the OneLogin service provider application configuration, correct any errors, and try again.
What to do next
You may optionally configure user role mapping for SSO users; see Configure User Role Mapping for
OneLogin at the FMC, on page 96. If you choose not to configure role mapping, by default all SSO users
that log into the FMC are assigned the user role you configure in Step 4 of Configure User Role Mapping for
OneLogin at the FMC, on page 96.
Configure User Role Mapping for OneLogin at the FMC

Before you begin

• Review the OneLogin users and groups, see Review the OneLogin Subdomain, on page 93.
Application for OneLogin, on page 93.
and Configure an FMC Service Provider Application for OneLogin, on page 93.
Procedure
Step 1 Choose System > Users > Single Sign-OnSystem > Users.
Step 3 Select an FMC user role to assign to users as a default value from the Default User Role drop-down.
Step 4 Enter a Group Member Attribute. This string must match the field name for a custom parameter you define
for role mapping at the FMC service provider application in OneLogin. (See Step 1 of Configure User Role
Mapping for Individual Users at the OneLogin IdP, on page 97 or Step 1 of Configure User Role Mapping
for Groups at the OneLogin IdP, on page 98.)

96
Your User Account
Configure User Role Mapping at the OneLogin IdP
Step 5 Next to each FMC user roll you wish to assign to SSO users, enter a regular expression. The FMC compares
these values against the user role mapping attribute the IdP sends to the FMC with SSO user information. The
FMC grants users a union of all the roles for which a match is found.
What to do next
Configure user role mapping at the service provider application; see Configure User Role Mapping at the
OneLogin IdP, on page 97.
Configure User Role Mapping at the OneLogin IdP

You can configure SSO user role mapping at the Onelogin Admin Portal based on individual permissions or
based on group permissions.
• To map based on individual user permissions, see Configure User Role Mapping for Individual Users at
the OneLogin IdP, on page 97.
• To map based on group permissions, see Configure User Role Mapping for Groups at the OneLogin IdP,
on page 98.
When an SSO user logs into the FMC, OneLogin presents to the FMC a user or group role attribute value that
gets its value from a custom user field configured at the OneLogin IdP. The FMC compares that attribute
value against the regular expression assigned to each FMC user role in the SSO configuration, and grants the
user all the roles for which a match is found. (If no match is found, the FMC grants the user a configurable
default user role.) The expression you assign to each FMC user role must comply with the restricted version
of Google's RE2 regular expression standard supported by Golang and Perl. The FMC treats the attribute
value received from OneLogin as a regular expression using that same standard for purposes of comparison
with the FMC user role expressions.
method for the FMC service provider application and use it consistently. The FMC can support role mapping
using only one custom user field configured in OneLogin. Generally group-based role mapping is more
efficient for an FMC with many users. You should take into account user and group definitions established
throughout your OneLogin subdomain.
Configure User Role Mapping for Individual Users at the OneLogin IdP
Use the OneLogin Admin Portal to create a custom parameter for the FMC service provider application and
a custom user field. These provide the means for OneLogin to pass user role information to the FMC during
the SSO login process.
Before you begin

• Review the OneLogin subdomain and its users and groups; see Review the OneLogin Subdomain, on
page 93.
• Create and configure an FMC service provider application in OneLogin; see Configure an FMC Service

97
Your User Account
Configure User Role Mapping for Groups at the OneLogin IdP
• Configure SSO user role mapping as described in Configure User Role Mapping for OneLogin at the
FMC, on page 96.
Procedure
Step 1 Create a custom parameter for the FMC service provider application.
• For the Field Name, use the same name you used for the Group Member Attribute in the FMC SSO
configuration. (See Step 4 in Configure User Role Mapping for OneLogin at the FMC, on page 96.)
• For the Value, provide a mnemonic name such as FMCUserRole. This must match the name of the customer
user field you will configure in Step 2 of this procedure.
Step 2 Create a custom user field to contain user role information for each OneLogin user with access the FMC.
• For the field Name, provide a mnemonic name such as FMCUserRole. This must match the value provided
for the application custom parameter described in Step 1 of this procedure.
• For the Short name, provide an abbreviated alternate name for the field. (This is used for OneLogin
programmatic interfaces.)
Step 3 For each user with access to the FMC service provider application, assign a value to the custom user field
you created in Step 2 of this procedure.
When a user logs into the FMC using SSO, the value you assign to this field for that user is the value the FMC
compares against the expressions you assigned to FMC user roles in the SSO configuration. (See Step 5 in
Configure User Role Mapping for OneLogin at the FMC, on page 96.)
What to do next
• Test your role mapping scheme by logging into the FMC using SSO from various accounts and confirming
that users are assigned FMC user roles as you expect.

Use the OneLogin Admin Portal to create a custom parameter for the FMC service provider application and
a custom user field. Assign OneLogin users to groups. Then create one or more mappings between the custom
user field and the user group so OneLogin assigns a value to the custom user field based on the user's group
membership. These provide the means for OneLogin to pass group-based user role information to the FMC
during the SSO login process.
OneLogin service provider applications may use one of two types of groups:
• Groups native to OneLogin.
• Groups synchronized from third-party applications such as Active Directory, Google Apps, or LDAP.
You may user either type of group for FMC group role mapping. This documentation describes role mapping
using OneLogin groups; using third-party application groups requires familiarity with the third-party user
management application in use at your organization. See the OneLogin documentation for details.

98
Your User Account
Before you begin

• Review the OneLogin subdomain and its users and groups; see Review the OneLogin Subdomain, on
page 93.
• Create and configure an FMC service provider application in OneLogin; see Configure an FMC Service
• Configure SSO user role mapping as described in Configure User Role Mapping for OneLogin at the
FMC, on page 96.
Procedure
Step 1 Create a custom parameter for the FMC service provider application.
• For the Field Name, use the same name you used for the Group Member Attribute in the FMC SSO
configuration. (See Step 4 in Configure User Role Mapping for OneLogin at the FMC, on page 96.)
• For the Value, provide a mnemonic name such as FMCUserRole. This must match the name of the customer
user field you will configure in Step 2 of this procedure.
Step 2 Create a custom user field to contain user role information for each OneLogin user with access the FMC.
• For the field Name, provide a mnemonic name such as FMCUserRole. This must match the value provided
for the application custom parameter described in Step 1 of this procedure.
• For the Short name, provide an abbreviated alternate name for the field. (This is used for OneLogin
programmatic interfaces.)
Step 3 Create one or more user field mappings to assign group-based values to the custom user field you created in
Step 2 of this procedure. Create as many mappings as you need to assign the correct FMC user role to each
OneLogin user group.
• Create one or more Conditions for the mapping, comparing the user Group field against group names.
• If you create multiple Conditions, choose whether a user's group must match any or all of the conditions
for the mapping to take place.
• Create an Action for the mapping, to assign a value to the custom user field you created in Step 2 of this
procedure. Provide the field Name, and the string that OneLogin assigns to this custom user field for all
users that meet the Conditions you specified.
The FMC compares this string against the expressions you assign to each FMC user role in Step 5 of
Configure User Role Mapping for OneLogin at the FMC, on page 96.
• Reapply All Mappings when you have completed your changes.
What to do next

99
Your User Account
OneLogin User Role Mapping Examples
OneLogin User Role Mapping Examples

provider application in OneLogin.
using only one custom user field configured in OneLogin. Generally group-based role mapping is more
efficient for an FMC with many users. You should take into account user and group definitions established
throughout your OneLogin subdomain.
OneLogin Role Mapping Example for Individual User Accounts

In role mapping for individual users, the OneLogin FMC service application has a custom parameter whose
name matches the name of the Group Member attribute on the FMC (in this example, UserRole). OneLogin
also has a custom user field defined (in this example, FMCUserRole). The definition for the application custom
parameter UserRole establishes that when OneLogin passes user role mapping information to the FMC, it
will use the value of the custom user field FMCUserRole for the user in question.
The following diagrams illustrate how the relevant fields and values in the FMC and OneLogin configurations
configurations at the FMC and at the OneLogin Admin portal, but the configuration for each user at the
OneLogin Admin portal differs to assign each user different roles at the FMC.
• In this diagram fred@example.com uses the FMCUserRole value PolicyAdmin and the FMC assigns him
the roles Access Admin, Discovery Admin, and Intrusion Admin.

100
Your User Account
OneLogin Role Mapping Example for Groups
• In this diagram sue@example.com uses the FMCUserRole value FMCAdmin, and the FMC assigns her the
Administrator role.
• Other users assigned to the OneLogin service application for this FMC are assigned the default user role
• They have no value assigned to the FMCUserRole custom user field.
• The value assigned to the FMCUserRole custom user field does not match any expression configured
for a user role in the SSO configuration at the FMC.

In role mapping for groups, the OneLogin FMC service application has a has a custom parameter whose name
matches the name of the Group Member attribute on the FMC (in this example, UserRole). OneLogin also
has a custom user field defined (in this example, FMCUserRole). The definition for the application custom
parameter UserRole establishes that when OneLogin passes user role mapping information to the FMC, it
will use the value of the custom user field FMCUserRole for the user in question. To support user group mapping,
you must establish a mapping within OneLogin to assign a value for each user's FMCUserRole field based on
that user's OneLogin group membership.
The following diagrams illustrate how the relevant fields and values in the FMC and OneLogin configurations
at the FMC and at the OneLogin Admin portal, but the configuration for each user at the OneLogin Admin
portal differs to assign each user different roles at the FMC.
• In this diagram fred@example.com is a member of the OneLogin IdP group FMCPolicyAdminGroup. A
OneLogin mapping assigns the value PolicyAdmin to the custom user field FMCUserRole for members
of the FMCPolicyAdminGroup. The FMC assigns Fred and other members of the FMCPolicyAdminGroup
the roles Access Admin, Discovery Admin, and Intrusion Admin.

101
Your User Account
• In this diagram sue@example.com is a member of the OneLogin IdP group FMCAdminGroup. A OneLogin
mapping assigns the value FMCAdmin to the custom user field FMCUserRole for members of the
FMCAdminGroup. The FMC assigns Sue and other members of the FMCAdminGroup the Administrator role.

102
Your User Account
• In this diagram sean@example.com is a member of the Idp group FMCMaintGroup. There is no OneLogin
mapping associated with this group, so OneLogin does not assign a value to the custom user field
FMCUserRole for Sean. The FMC assigns Sean the default user role (Security Analyst (Read Only)) rather
than the Maintenance User role.

103
Your User Account
Configure Single Sign-On with Azure AD
Configure Single Sign-On with Azure AD

See the following tasks to configure SSO using Azure:
Azure AD Portal Review the Azure Tenant, on page 105
Azure AD Portal Configure an FMC Service Provider Application for Azure, on page 105

104
Your User Account
Review the Azure Tenant
FMC Enable Single Sign-On at the FMC, on page 80
FMC Configure the FMC for Azure SSO, on page 107
FMC Configure User Role Mapping for Azure at the FMC, on page 108
Azure AD Portal Configure User Role Mapping at the Azure IdP, on page 109
Review the Azure Tenant

Azure AD is Microsoft's multitenant cloud based identity and access management service. In Azure, the entity
that encompasses all the federated devices that a user can access with the same SSO account is called a tenant.
Before adding the FMC to an Azure tenant, be familiar with its organization; consider the following questions:
• Are users within the Azure tenant members of groups?
• Are users and groups from another directory product?
• Do you need to add more users or groups to the Azure tenant to support SSO on the FMC?
• What kind of FMC user role assignments do you want to make? (If you choose not to assign user roles,
the FMC automatically assigns a configurable default user role to all SSO users.)
• How must users and groups within the Azure tenant be organized to support the required user role
mapping?
• Keep in mind that you can configure FMC roles to be mapped based on individual users or based on
groups, but a single FMC application cannot support role mapping for both groups and individual users.
This documentation assumes you are already familiar with the Azure Active Directory Portal and have an
account with application admin privileges for the Azure AD tenant. Keep in mind that the FMC supports
Azure SSO only with tenant-specific single sign-on and single sign-out endpoints. You must have an Azure
AD Premium P1 or above license and Global Administrator permissions; see Azure documentation for more
information.
Configure an FMC Service Provider Application for Azure

Use the Azure Active Directory Portal to create an FMC service provider application within your Azure Active
Directory tenant and establish basic configuration settings.
individuals.

105
Your User Account
Configure an FMC Service Provider Application for Azure
or grup role mapping and configure a single attribute to convey user role information from OneLogin to the
FMC.
Before you begin

• Familiarize yourself with your Azure tenant and its users and groups; see Review the Azure Tenant, on
page 105.
• Create user accounts and/or groups in your Azure tenant if necessary.
an FMC.
• Confirm the login URL for the target FMC (https://ipaddress_or_hostname)
Procedure
Step 1 Create the FMC service provider application using the Azure AD SAML Toolkit as its basis.
Step 2 Configure the application with the following setttings for Basic SAML Configuration:
• For the Identifier (Entity ID) append the string /saml/metadata to the FMC login URL. For example:
• For the Reply URL (Assertion Consumer Service URL) append the string /saml/acs to the FMC login
URL. For example: https://ExampleFMC/saml/acs.
• For the Sign on URL append the string /saml/acs to the FMC login URL. For example:
Step 3 Edit the Unique User Identifier Name (Name ID) claim for the application to force the username for sign-on
at the FMC to be the email address associated with the user account:
• For Source choose Attribute.
• For Source attribute: Choose user.mail.

106
Your User Account
Configure the FMC for Azure SSO
Step 4 Generate a certificate to secure SSO on the FMC. Use the following options for the certificate:
• Select Sign SAML Response and Assertion for the Signing Option.
• Select SHA-256 for the Signing Algorithm.
Step 5 Download the Base-64 version of the certificate to your local computer; you will need it when you configure
Azure SSO at the FMC web interface
Step 6 In the SAML-based Sign-on information for the application, note the following values:
• Login URL
• Azure AD Identifier
You will need these values when you configure Azure SSO at the FMC web interface.
Step 7 (Optional) to make SSO setup at the FMC easier, you can download the SAML XML metadata file for the
FMC service provider application (called the Federation Metadata XML in the Azure Portal) to your local
computer.
Step 8 Assign existing Azure users and groups to the FMC service application.
Note If you plan to assign user groups to the FMC Application, do not also assign users within those
groups as individuals.
Note If you plan to configure user role mapping, you can configure roles to be mapped based on individual
user permissions or based on group permissions, but a single FMC application cannot support role
mapping for both groups and individual users.
What to do next
Configure the FMC for Azure SSO

Before you begin

• Create an FMC service provider application at the Azure AD Portal; see Configure an FMC Service
Provider Application for Azure, on page 105.
Procedure
Step 1 (This step continues directly from Enable Single Sign-On at the FMC, on page 80.) At the Configure Azure

107
Your User Account
Configure User Role Mapping for Azure at the FMC
b. Enter the values you retrieved from the Azure SSO Service Provider application:
• For Identity Provider Single Sign-On URL enter the Login URL you noted in Step 6 of Configure
an FMC Service Provider Application for Azure, on page 105.
• For Identity Provider Issuer enter the Azure AD Identifier you noted in Step 6 of Configure an
FMC Service Provider Application for Azure, on page 105.
• For the X.509 Certificate, use the certificate you downloaded from Azure in Step 5 of Configure
an FMC Service Provider Application for Azure, on page 105. (Use a text editor to open the certificate
file, copy the contents, and paste it into the X.509 Certificate field.)
• If you saved the XML metadata file generated by Azure to your local computer (Step 7 of Configure an
FMC Service Provider Application for Azure, on page 105), you can upload the file the FMC:
computer.
Step 2 Click Next.

Step 4 Click Test Configuration. If the System displays an error message, review the SSO configuration for the
FMC as well as the Azure service provider application, correct any errors, and try again.
What to do next
You may optionally configure role mapping for SSO users; see Configure User Role Mapping for Azure at
the FMC, on page 108. If you choose not to configure role mapping, by default all SSO users that log into the
FMC are assigned the default user role you configure in Step 4 of Configure User Role Mapping for Azure
at the FMC, on page 108.
Configure User Role Mapping for Azure at the FMC

Before you begin

• Review the existing Azure users and groups; see Review the Azure Tenant, on page 105.
Application for Azure, on page 105.
and Configure the FMC for Azure SSO, on page 107.

108
Your User Account
Configure User Role Mapping at the Azure IdP
Procedure

Step 5 Enter a Group Member Attribute. This string must match the name of the user claim you create for the FMC
service provider application in Azure; see Step 1 of Configure User Role Mapping for Individual Users at the
Azure IdP, on page 110 or Step 1 of Configure User Role Mapping for Groups at the Azure IdP, on page 111.
What to do next
Configure user role mapping at the service provider application; see Configure User Role Mapping at the
Azure IdP, on page 109.
Configure User Role Mapping at the Azure IdP

You can configure SSO user role mapping at the Azure AD Portal based on individual user permissions or
based on group permissions.
• To map based on individual user permissions, see Configure User Role Mapping for Individual Users at
the Azure IdP.
• To map based on group permissions, see Configure User Role Mapping for Groups at the Azure IdP.
When an SSO user logs into the FMC, Azure presents to the FMC a user or group role attribute value that
gets its value from an application role configured at the Azure AD Portal. The FMC compares that attribute
value against the regular expression assigned to each FMC user role in the SSO configuration, and grants the
user all the roles for which a match is found. (If no match is found, the FMC grants the user a configurable
default user role.) The expression you assign to each FMC user role must comply with the restricted version
of Google's RE2 regular expression standard supported by Golang and Perl. The FMC treats the attribute
value received from Azure as a regular expression using that same standard for purposes of comparison with
the FMC user role expressions.
using only one claim configured in Azure. Generally group-based role mapping is more efficient for an FMC
with many users. You should take into account user and group definitions established throughout your Azure
tenant.

109
Your User Account
Configure User Role Mapping for Individual Users at the Azure IdP
Configure User Role Mapping for Individual Users at the Azure IdP
To establish role mapping for individual users of the FMC service application in Azure, use the Azure AD
Portal to add a claim to the application, add roles to the application's registration manifest, and assign roles
to users.
Before you begin

• Review the Azure tenant; see Review the Azure Tenant, on page 105.
• Create and configure an FMC service provider application in Azure; see Configure an FMC Service
• Configure SSO user role mapping as described in Configure User Role Mapping for Azure at the FMC,
on page 108.
Procedure
Step 1 Add a user claim to the SSO configuration for the FMC service application with the following characteristics:
• Name: Use the same string you entered for the Group Member Attribute in the FMC SSO configuration.
(See Step 5 in Configure User Role Mapping for Azure at the FMC, on page 108.)
• Source: Choose Attribute.
• Source attribute: Choose user.assignedroles.
Step 2 Edit the manifest for the FMC service application (in JSON format) and add application roles to represent
FMC user roles you wish to assign to SSO users. The simplest approach is to copy an existing application
role definition and change the following properties:
• displayName: The name for the role that will appear in the AD Azure Portal.
• description: A brief description of the role.
• Id: An alphanumeric string that must be unique among ID properties within the manifest.
• value: A string to represent one or more FMC user roles. (Note: Azure does not permit spaces in this
string.)
Step 3 For each user assigned to the FMC Service application, assign one of the application roles you have added to
the manifest for that application. When a user logs in to the FMC using SSO, the application role you assign
to that user is the value Azure sends to the FMC in the claim for the service application. The FMC compares
the claim against the expressions you assigned to FMC user roles in the SSO configuration (See Step 6 of
Configure User Role Mapping for Azure at the FMC, on page 108.), and assigns the user all the FMC user
roles for which there is a match.
What to do next

110
Your User Account
Configure User Role Mapping for Groups at the Azure IdP
Configure User Role Mapping for Groups at the Azure IdP

To establish role mapping for user groups for the FMC service application in Azure, use the Azure AD Portal
to add a claim to the application, add roles to the application's registration manifest, and assign roles to groups.
Before you begin

• Review the Azure tenant; see Review the Azure Tenant, on page 105.
• Create and configure an FMC service provider application in Azure; see Configure an FMC Service
• Configure SSO user role mapping as described in Configure User Role Mapping for Azure at the FMC,
on page 108.
Procedure
Step 1 Add a user claim to the SSO configuration for the FMC service application with the following characteristics:
• Name: Use the same string you entered for the Group Member Attribute in the FMC SSO configuration.
(See Step 5 in Configure User Role Mapping for Azure at the FMC, on page 108.)
• Source: Choose Attribute.
• Source attribute: Choose user.assignedroles.
Step 2 Edit the manifest for the FMC service application (in JSON format) and add application roles to represent
FMC user roles you wish to assign to SSO users. The simplest approach is to copy an existing application
role definition and change the following properties:
• displayName: The name for the role that will appear in the Ad Azure Portal.
• description: A brief description of the role.
• Id: An alphanumeric string that must be unique among id properties within the manifest.
• value: A string to represent one or more FMC user roles. (Azure does not permit spaces in this string.)
Step 3 For each group assigned to the FMC Service application, assign one of the application roles you have added
to the manifest for that application. When a user logs in to the FMC using SSO, the application role you assign
to that user's group is the value Azure sends to the FMC in the claim for the service application. The FMC
compares the claim against the expressions you assigned to FMC user roles in the SSO configuration (see
Step 6 of Configure User Role Mapping for Azure at the FMC, on page 108), and assigns the user all the FMC
user roles for which there is a match.
What to do next
Test your role mapping scheme by logging into the FMC using SSO from various accounts and confirming

111
Your User Account
Azure User Role Mapping Examples
Azure User Role Mapping Examples

provider application in Azure.
Note You can configure FMC roles to be mapped based on individual permissions or based on group permissions,
but a single FMC application cannot support role mapping for both groups and individual users. The FMC
can support role mapping using only one claim configured in Azure.
Azure Role Mapping Example for Individual User Accounts

In role mapping for individual users, the Azure FMC service application has custom roles defined within its
manifest. (In this case, FMCAdmin and PolicyAdmin.) These roles can be assigned to users; Azure stores
role assignments for each user in that user's assignedroles attribute. The application also has a custom user
claim defined, and this claim is configured to get its value from the assigned user role for a user logging into
the FMC using SSO. Azure passes the claim value to the FMC during the SSO login process, and the FMC
compares the claim value against strings assigned to each FMC user role in the FMC SSO configuration.
The following diagrams illustrate how the relevant fields and values in the FMC and Azure configurations
configurations at the FMC and at the Azure AD portal, but the configuration for each user at the Azure AD
portal differs to assign each user different roles at the FMC.
• In this diagram sue@ example.com uses the assignedroles attribute value FMCAdmin, and the FMC assigns
her the FMC Administrator role.

112
Your User Account
Azure Role Mapping Example for Groups
• In this diagram fred @ example .com uses the assignedroles attribute value PolicyAdmin, and the FMC
assigns him the roles Access Admin, Discovery Admin, and Intrusion Admin.
• Other users assigned to the Azure service application for this FMC are assigned the default user role
• They have no value assigned to their assignedroles attribute.
• The value assigned to their assignedroles attribute does not match any expression configured for a
user role in the SSO configuration at the FMC.

In role mapping for groups, the Azure FMC service application has custom roles defined within its manifest.
(In this case, FMCAdmin, AccessAdmin, Discovery Admin, and Maint.) These roles can be assigned to
groups; Azure passes role assignments for each group to group members' assignedroles attribute. The application
also has a custom user claim defined, and this claim is configured to get its value from the assigned user role
for a user logging into the FMC using SSO. Azure passes the claim value to the FMC during the SSO login
process, and the FMC compares the claim value against strings assigned to each FMC user role in the FMC
SSO configuration.
The following diagrams illustrate how the relevant fields and values in the FMC and Azure configurations
at the FMC and at the Azure AD portal, but the configuration for each user at the Azure AD portal differs to
assign each user different roles at the FMC.
• In this diagram sue@example.com is a member of the groups FMCAccessAdmins and FMCDiscoveryAdmins.
From these groups she inherits the custom roles AccessAdmin and DiscoveryAdmin. When Sue logs into
the FMC using SSO the FMC assigns her the roles Access Admin and Discovery Admin.

113
Your User Account
• In this diagram fred@example.com is a member of the FMCAdmins group, from which he inherits the
custom role FMCAdmin. When Fred logs into the FMC using SSO the FMC assigns him the Administrator
role.

114
Your User Account
• In this diagram sean@example.com is a member of the FMCMaintUsers group, but because no custom
role has been assigned to FMCMaintUsers within the Azure FMC service provider application, Sean has
no roles assigned to him, and when he logs into the FMC using SSO, the FMC assigns him the default
role Security Analyst (Read Only).

115
Your User Account
Configure Single Sign-On with PingID
Configure Single Sign-On with PingID

See the following tasks to configure SSO using PingID's PingOne for Customers product:

116
Your User Account
Review the PingID PingOne for Customers Environment
PingOne for Review the PingID PingOne for Customers Environment, on page 117.
Customers
Administrator's
Console
PingOne for Configure an FMC Service Provider Application for PingID PingOne for
Customers Customers, on page 117.
Administrator's
Console
FMC Enable Single Sign-On at the FMC, on page 80.
FMC Configure the FMC for SSO with PingID PingOne for Customers, on page 119.
Review the PingID PingOne for Customers Environment

PingOne for Customers is PingID's cloud-hosted identity-as-a-service (IDaaS) product. In PingOne for
Customers, the entity that encompasses all the federated devices that a user can access with the same SSO
account is called an environment. Before adding the FMC to a PingOne environment, be familiar with its
organization; consider the following questions:
• Do you need to add more users to support SSO access to the FMC?
This documentation assumes you are already familiar with the PingOne for Customers Administrator Console
and have an account with the Organization Admin role.
Configure an FMC Service Provider Application for PingID PingOne for Customers
Use the PingOne for Customers Administrator Console to create an FMC service provider application within
your PingOne for Customers environment and establish basic configuration settings. This documentation does
not describe all the PingOne for Customers functions you need to establish a fully functional SSO environment;
for instance, to create users see the PingOne for Customers documentation.
Before you begin

• Familiarize yourself with your PingOne for Customers environment and its users.
• Create additional users if necessary.
an FMC.

117
Your User Account
Configure an FMC Service Provider Application for PingID PingOne for Customers
Procedure
Step 1 Use the PingOne for Customer Administrator Console to create the application in your environment using
these settings:
• Choose the Web App application type.
• Choose the SAML connection type.
Step 2 Configure the application with the following settings for the SAML Connection:
• For the ACS URL, append the string /sam/acs to the FMC login URL. For example:
• For the Signing Certificate, choose Sign Assertion & Response.

• For the Signing Algorithm choose RSA_SHA256.
• For the Entity ID, append the string /saml/metadata to the FMC login URL. For example:
• For the SLO Binding select HTTP POST.

• For the Assertion Validity Duration enter 300.
Step 3 In the SAMLConnection information for the application, note the following values:
• Single Sign-On Service
• Issuer ID
You will need these values when you configure SSO using PingID's PingOne for Customers product at the
FMC web interface.
Step 4 For SAML ATTRIBUTES, make the following selections for a single required attribute:
• PINGONE USER ATTRIBUTE: Email Address
• APPLICATION ATTRIBUTE: saml_subject
Step 5 Download the signing certificate in X509 PEM (.crt) format and save it to your local computer.
Step 6 (Optional) to make SSO setup at the FMC easier, you can download the SAML XML metadata file for the
FMC service provider application to your local computer.
Step 7 Enable the application.

118
Your User Account
Configure the FMC for SSO with PingID PingOne for Customers
What to do next
Configure the FMC for SSO with PingID PingOne for Customers
Before you begin

• Create an FMC service provider application at the PingOne for Customers Administrator Console; see
Configure an FMC Service Provider Application for PingID PingOne for Customers, on page 117.
Procedure
Step 1 (This step continues directly from Enable Single Sign-On at the FMC, on page 80.) At the Configure PingID
b. Enter the values you retrieved from the PingOne for Customers Administrator Console:
• For Identity Provider Single Sign-On URL enter the Single Signon Service you noted in Step
3 of Configure an FMC Service Provider Application for PingID PingOne for Customers, on
page 117.
• For Identity Provider Issuer enter the Issuer ID you noted in Step 3 of Configure an FMC
Service Provider Application for PingID PingOne for Customers, on page 117.
• For the X.509 Certificate, use the certificate you downloaded from PingOne for Customers in
Step 5 of Configure an FMC Service Provider Application for PingID PingOne for Customers,
on page 117. (Use a text editor to open the certificate file, copy the contents, and paste it into
the X.509 Certificate field.)
• If you saved the XML metadata file generated by PingOne for Customers to your local computer (Step
6 of Configure an FMC Service Provider Application for PingID PingOne for Customers, on page 117),
you can upload the file to the FMC:
computer.
Step 2 Click Next.


119
Your User Account
Configure Single Sign-On with Any SAML 2.0-Compliant SSO Provider
Step 6 Click Test Configuration. If the System displays an error message, review the SSO configuration for the
FMC as well as the PingOne for Customers service provider application, correct any errors, and try again.
Configure Single Sign-On with Any SAML 2.0-Compliant SSO Provider

The FMC supports single sign-on with any SSO identity provider (IdP) compliant with the SAML 2.0 SSO
protocol. Generic instructions to use a wide range of SSO providers must address the tasks to be performed
at a high level; establishing SSO using a provider not specifically addressed in this documentation requires
that you be proficient with the IdP of your choice. These tasks help you determine the steps to configure the
FMC for single sign-on using any SAML 2.0-compliant SSO provider:
IdP Administration Application Familiarize Yourself with the SSO

Identity Provider and the SSO
Federation, on page 121.
IdP Administration Application Configure an FMC Service

Provider Application for Any
SAML 2.0-Compliant SSO
Provider, on page 121.
FMC Enable Single Sign-On at the FMC,

on page 80.
FMC Configure the FMC for SSO Using

Any SAML 2.0-Compliant SSO
Provider, on page 123.
FMC Configure User Role Mapping at

the FMC for SAML 2.0-Compliant
SSO Providers, on page 124.
IdP Administration Application Configure FMC User Role

Mapping at the IdP for SAML
2.0-Compliant SSO Providers, on
page 125.

120
Your User Account
Familiarize Yourself with the SSO Identity Provider and the SSO Federation
Familiarize Yourself with the SSO Identity Provider and the SSO Federation
Read the IdP vendor documentation with the following considerations in mind:
• Does the SSO provider require that users subscribe to or register with any services before using the IdP?
• What terminology does the SSO provider use for common SSO concepts? For instance, to refer to a
group of federated service provider applications, Okta uses "org" where Azure uses "tenant."
• Does the SSO provider support SSO exclusively, or a suite of functions—for instance, multifactor
authentication or domain management? (This can affect configuration of some elements shared between
features—especially users and groups.)
• What permissions does an IdP user account need to configure SSO?
• What configurations does the SSO provider require you to establish for a service provider application?
For instance, Okta automatically generates an X509 Certificate to secure its communications with the
FMC, while Azure requires that you generate that certificate using the Azure portal interface.
• How are users and groups created and configured? How are users assigned to groups? How are users
and groups granted access to service provider applications?
• Does the SSO provider require that at least one user be assigned to a service provider application before
the SSO connection can be tested?
• Does the SSO provider support user groups? How are user and group attributes configured? How can
you map attributes to FMC user roles in the SSO configuration?
• Do you need to add more users or groups to the federation to support SSO on the FMC?
• Are users within the federation members of groups?
• Are user and group definition native to the IdP or imported from a user management application such as
Active Directory, RADIUS, or LDAP?
• What kind of user role assignments do you want to make? (If you choose not to assign user roles, the
FMC automatically assigns the user a configurable default user role role to all SSO users.)
• How must users and groups within the federation be organized to support your plan for user role mapping?
Generally SSO providers require that you configure a service provider application at the IdP for each federated
application. All IdPs that support SAML 2.0 SSO need the same configuration information for service provider
applications, but some IdP's automatically generate some configuration settings for you, while others require
that you configure all settings yourself.
Note If you plan to assign user groups to the FMC Application, do not also assign users within those groups as
individuals.

121
Your User Account
or group role mapping and configure a single attribute to convey user role information from the IdP to the
FMC.
Before you begin

• Familiarize yourself with the SSO federation and its users and groups; see Familiarize Yourself with the
SSO Identity Provider and the SSO Federation, on page 121.
• Confirm your IdP account has the necessary permissions to perform this task.
• Create user accounts and/or groups in your SSO federation if necessary.
an FMC.
Note If your FMC web interface can be reached with multiple URLs. (for instance, a
full-qualified domain name as well as an IP address), SSO users must consistently
Procedure
Step 1 Create a new service provider application at the IdP.

Step 2 Configure values required by the IdP. Be sure to include the fields listed below, required to support SAML
2.0 SSO functionality with the FMC. (Because different SSO service providers use different terminology for
SAML concepts, this list provides alternate names for these fields to help you find the right settings in the
IdP application.):
• Service Provider Entity ID, Service Provider Identifier, Audience URI: A globally unique name for the
service provider (the FMC), formatted as a URL. To create this, append the string /saml/metadata to
the FMC login URL, such as https://ExampleFMC/saml/metadata.
• Single Sign on URL, Recipient URL, Assertion Consumer Service URL: The service provider (FMC)
address to which the browser sends information on behalf of the IdP. To create this, append the string
saml/acs to the FMC login URL, such as https://ExampleFMC/saml/acs.

122
Your User Account
Configure the FMC for SSO Using Any SAML 2.0-Compliant SSO Provider
• X.509 Certificate: Certificate to secure communications between the FMC and the IdP. Some IdP's may
automatically generate the certificate, and some may require that you explicitly generate it using the IDP
interface.
Step 3 (Optional if you are assigning groups to the application) Assign individual users to the FMC application. (If
you plan to assign groups to the FMC application, do not assign members of those groups as individuals.)
Step 4 (Optional if you are assigning individual users to the application.) Assign user groups to the FMC application.
Step 5 (Optional) Some IdP's provide the ability to generate a SAML XML metadata file containing the information
you have configured in this task formatted to comply with SAML 2.0 standards. If your IdP provides this
ability, you can download the file to your local computer to ease the SSO configuration process at the FMC.
What to do next
Configure the FMC for SSO Using Any SAML 2.0-Compliant SSO Provider
Use these instructions at the FMC web interface. To configure the FMC for SSO using any SAML 2.0-compliant
SSO provider, you need information from the IdP.
Before you begin

• Review the organization of your SSO federation, and its users and groups.
• Configure an FMC service provider application at the IdP; see Configure the FMC for SSO Using Any
SAML 2.0-Compliant SSO Provider, on page 123.
• Gather the following SSO configuration information for the service provider application from the IdP.
Because different SSO service providers use different terminology for SAML concepts, this list provides
alternate names for these fields to help you find the right values in the IdP application:
• Identity Provider Single Sign-On URL, Login URL: The IdP URL where the browser sends
information on behalf of the FMC.
• Identity Provider Issuer, Identity Provider Issuer URL, Issuer URL: A globally unique name for the
IdP, often formatted as a URL.
• An X.509 digital certificate to secure communications between the FMC and the IdP.
Procedure
Step 1 (This step continues directly from Enable Single Sign-On at the FMC, on page 80.) At the Configure SAML
b. Enter the following values previously obtained from the SSO Service Provider application:

123
Your User Account
Configure User Role Mapping at the FMC for SAML 2.0-Compliant SSO Providers
• Identity Provider Single Sign-On URL

• Identity Provider Issuer
• X.509 Certificate
• If you saved an the XML metadata file generated at the IdP (Step 5 in Configure an FMC Service Provider
Application for Any SAML 2.0-Compliant SSO Provider, on page 121), you can upload the file to the
FMC:
computer.
Step 2 Click Next.

FMC as well as the service provider application configuration at the IdP, correct any errors, and try again.
What to do next
You may optionally configure user role mapping for SSO users; see Configure User Role Mapping at the
FMC for SAML 2.0-Compliant SSO Providers, on page 124. If you choose not to configure role mapping, by
default all SSO users that log into the FMC are assigned the default user role you configure in Step 4 of
Configure User Role Mapping at the FMC for SAML 2.0-Compliant SSO Providers, on page 124.
Configure User Role Mapping at the FMC for SAML 2.0-Compliant SSO Providers
To implement SAML SSO user role mapping you must establish coordinating configurations at the IdP and
at the FMC.
• At the IdP, establish user or group attributes to convey user role information and assign values to them;
the IdP sends these to the FMC once it has authenticated and authorized an SSO user.
• At the FMC, associate values with each of the FMC user roles you want to assign to users.
When the IdP sends the FMC the user or group attribute associated with an authorized user, the FMC compares
the attribute value against values associated with each FMC user role, and assigns the user all the roles that
produce a match. The FMC performs this comparison treating both values as regular expressions complying
with the restricted version of Google's RE2 regular expression standard supported by Golang and Perl.
implements user role mapping. Your IdP may enforce syntactical limitations on user or group attributes; if
so, you must devise a user role mapping scheme using role names and regular expressions compatible with
those requirements.

124
Your User Account
Configure FMC User Role Mapping at the IdP for SAML 2.0-Compliant SSO Providers
Before you begin

Application for Any SAML 2.0-Compliant SSO Provider, on page 121.
• Enable and configure single sign-on at the FMC, see Enable Single Sign-On at the FMC, on page 80,
and Configure the FMC for SSO Using Any SAML 2.0-Compliant SSO Provider, on page 123.
Procedure

Step 5 Enter a Group Member Attribute. This string must match an attribute name configured at the IdP FMC
service provider application for user role mapping using either users or groups. (See Step 1 of Configure FMC
User Role Mapping at the IdP for SAML 2.0-Compliant SSO Providers, on page 125.)
What to do next
Configure user role mapping at the service provider application; see Configure FMC User Role Mapping at
the IdP for SAML 2.0-Compliant SSO Providers, on page 125.
Configure FMC User Role Mapping at the IdP for SAML 2.0-Compliant SSO Providers
The detailed steps for configuring user role mapping are different for each IdP. You must determine how to
create a custom user or group attribute for the service provider application, and assign values to the attribute
for each user or group at the IdP to convey user or group privileges to the FMC. Keep in mind the following:
• If your IdP imports user or group profiles from a third-party user management application (such as Active
directory, LDAP, or Radius), this may affect how you can use attributes for role mapping.
• Take into account user and group role definitions throughout your SSO federation.
• The FMC cannot support role mapping using multiple SSO attributes; you must select either user role
mapping or group role mapping and configure a single attribute to convey user role information from
the IdP to the FMC.
• Group role mapping is generally more efficient for an FMC with many users.
• If you assign user groups to an FMC application, do not also assign users within those groups as
individuals.
• For the purpose of determining a match with FMC user roles, the FMC treats user and group role attribute
values received from the IdP as regular expressions complying with the restricted version of Google's
RE2 regular expression standard supported by Golang and Perl. Your IdP may enforce certain syntactical

125
Your User Account
Customize User Roles for the Web Interface
limitations on user or group attributes. if so, you must devise a user role mapping scheme using role
names and regular expressions compatible with those requirements.
Before you begin

• Confirm your IdP account has the necessary permissions to perform this task.
• Configure an FMC service provider application at the IdP (see Configure an FMC Service Provider
Application for Any SAML 2.0-Compliant SSO Provider, on page 121).
Procedure
Step 1 At the IdP, create or designate an attribute to be sent to the FMC to contain role mapping information for each
user sign-in. This may be a user attribute, a group attribute, or a different attribute that obtains its value from
a source such as user or group definitions maintained by the IdP or a third party user management application.
Step 2 Configure how the attribute gets its value. Coordinate the possible values with the values associated with the
user roles in the FMC SSO configuration.
Customize User Roles for the Web Interface

Each user account must be defined with a user role. This section describes how to manage user roles and how
to configure a custom user role for web interface access. For default user roles, see User Roles, on page 54.
Create Custom User Roles

Custom user roles can have any set of menu-based and system permissions, and may be completely original,
copied from a predefined or another custom user role, or imported from another device.
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 1393.
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.

126
Your User Account
Create Custom User Roles
Procedure

Step 2 Click User Roles.
Step 3 Add a new user role with one of the following methods:
• Click Create User Role.
• 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 128.
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

127
Your User Account
Deactivate User Roles
can view (but not modify) access control and intrusion policies. They can also deploy configuration
changes to devices.
Table 1: Sample Access Control Custom Roles
Custom Role Permission Example: Access Control Editor Example: Intrusion & Network Example: Policy Approver
Analysis Editor
Access Control yes no yes
Access Control Policy yes no yes
Modify Access Control Policy yes no no
Intrusion Policy no yes yes
Modify Intrusion Policy no yes no
Deploy Configuration to no no yes

Devices
Deactivate User Roles

Deactivating a role removes that role and all associated permissions from any user who is assigned that role.
You cannot delete predefined user roles, but you can deactivate them.
In a multidomain deployment, the system displays custom user roles created in the current domain, which
you can edit. It also displays custom user roles created in ancestor domains, which you cannot edit. To view
and edit custom user roles in a lower domain, switch to that domain.
Procedure

Step 3 Click the slider next to the user role you want to activate or deactivate.
If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission
to modify the configuration.
If you deactivate, then reactivate, a role with Lights-Out Management 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.
Enable User Role Escalation

You can give custom user roles the permission, with a password, to temporarily gain the privileges of another,
targeted user role in addition to those of the base role. This feature allows you to easily substitute one user

128
Your User Account
Set the Escalation Target Role
for another during an absence, or to more closely track the use of advanced user privileges. Default user roles
do not support escalation.
For example, a user whose base role has very limited privileges can escalate to the Administrator role to
perform administrative actions. You can configure this feature so that users can use their own passwords, or
so they use the password of another user that you specify. The second option allows you to easily manage
one escalation password for all applicable users.
To configure user role escalation, see the following workflow.
Procedure
Step 1 Set the Escalation Target Role, on page 129. Only one user role at a time can be the escalation target role.
Step 2 Configure a Custom User Role for Escalation, on page 129.
Step 3 (For the logged in user) Escalate Your User Role, on page 130.
Set the Escalation Target Role

You can assign any of your user roles, predefined or custom, to act as the system-wide escalation target role.
This is the role to which a custom role can escalate, if it has the ability. Only one user role at a time can be
the escalation target role. Each escalation lasts for the duration of a login session and is recorded in the audit
log.
Procedure

Step 3 Click Configure Permission Escalation.
Step 4 Choose a user role from the Escalation Target drop-down list.
Step 5 Click OK to save your changes.
Changing the escalation target role is effective immediately. Users in escalated sessions now have the
permissions of the new escalation target.
Configure a Custom User Role for Escalation

Users for whom you want to enable escalation must belong to a custom user role with escalation enabled.
This procedure describes how to enable escaltion for a custom user role.
Consider the needs of your organization when you configure the escalation password for a custom role. If
you want to easily manage many escalating users, you might want to choose another user whose password
serves as the escalation password. If you change that user’s password or deactivate that user, all escalating
users who require that password are affected. This action allows you to manage user role escalation more
efficiently, especially if you choose an externally-authenticated user that you can manage centrally.

129
Your User Account
Escalate Your User Role
Before you begin

Set a target user role according to Set the Escalation Target Role, on page 129.
Procedure
Step 1 Begin configuring your custom user role as described in Create Custom User Roles, on page 126.
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 4 Click Save.
Escalate Your User Role

When a user has an assigned custom user role with permission to escalate, that user can escalate to the target
role’s permissions at any time. Note that escalation has no effect on user preferences.
Procedure
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.
Step 2 Enter the authentication password.

Step 3 Click Escalate. You now have all permissions of the escalation target role in addition to your current role.
Escalation lasts for the remainder of your login session. To return to the privileges of your base role only, you
must log out, then begin a new session.
Troubleshooting LDAP Authentication Connections

If you create an LDAP authentication object and it either does not succeed in connecting to the server you
select, or does not retrieve the list of users you want, you can tune the settings in the object.

130
Your User Account
If the connection fails when you test it, try the following suggestions to troubleshoot your configuration:
• Use the messages displayed at the top of the web interface screen and in the test output to determine
which areas of the object are causing the issue.
• Check that the user name and password you used for the object are valid:
• Check that the user has the rights to browse to the directory indicated in your base distinguished
name by connecting to the LDAP server using a third-party LDAP browser.
• Check that the user name is unique to the directory information tree for the LDAP server.
• If you see an LDAP bind error 49 in the test output, the user binding for the user failed. Try
authenticating to the server through a third-party application to see if the binding fails through that
connection as well.
• Check that you have correctly identified the server:

• Check that the server IP address or host name is correct.
• Check that you have TCP/IP access from your local appliance to the authentication server where
you want to connect.
• 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 CLI 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.

131
Your User Account
History for User Accounts for FMC
• 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
domainadmin@myrtle.example.com 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
'domainadmin@myrtle.example.com' -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 CLI access filter or use a more restrictive or less restrictive base DN.

Added new field for assigning 7.0 Provision to specify a template for CLI access attributes for LDAP external
Shell user name template authentication—Shell User Name Template was introduced. Thus, CLI attribute would
have its own template to identify the LDAP CLI users.
New/Modified screens:
System > Users > External Authentication
Added support of Single 6.7 Added the ability to support Single Sign-On for external users configured at any
Sign-On using any SAML third-party SAML 2.0-compliant identity provider (IdP). This includes the abillity to
2.0-compliant SSO provider. map user or group roles from the IdP to FMC user roles.
Only users with the Admin role authenticated internally or by LDAP or RADIUS can
configure SSO.
System > Users > Single Sign-On
Added a new field for name in 6.6 Added a field that can identify the user or department responsible for an internal user
user accounts account.
System > Users > Users> Real Name field

132
Your User Account
Cisco Security Manager Single 6.5 Single Sign-on between the FMC and Cisco Security Manager is no longer supported
Sign-on no longer supported as of Firepower 6.5.
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

133
Your User Account

134
CHAPTER 5
User Accounts for Devices
Managed devices include a default admin account for CLI access. This chapter discusses how to create custom
user accounts. See Logging into the Firepower System, on page 29 for detailed information about logging
into the managed device with a user account.
• About User Accounts for Devices, on page 135
• Requirements and Prerequisites for User Accounts for Devices, on page 136
• Guidelines and Limitations for User Accounts for Devices, on page 137
• Add an Internal User at the CLI, on page 137
• Configure External Authentication for the FTD, on page 139
• Troubleshooting LDAP Authentication Connections, on page 151
• History for User Accounts for Devices, on page 153
About User Accounts for Devices

You can add custom user accounts on managed devices, either as internal users or, for the FTD, as external
users on a LDAP or RADIUS server. Each managed device maintains separate user accounts. For example,
when you add a user to the FMC, that user only has access to the FMC; you cannot then use that username
to log directly into a managed device. You must separately add a user on the managed device.
Internal and External Users

Managed devices support two types of users:
• Internal user—The device checks a local database for user authentication. For more information about
internal users, see Add an Internal User at the CLI, on page 137. The FTD, NGIPSv, and ASA FirePOWER
support internal users.
• External user (FTD only)—If the user is not present in the local database, the system queries an external
LDAP or RADIUS authentication server. For more information about external users, see Configure
External Authentication for the FTD, on page 139. Only the FTD supports external users.

135
Your User Account
CLI Access
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 31.
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.
CLI User Roles

On managed devices, user access to commands in the CLI depends on the role you assign.
None
The user cannot log into the device on the command line.
Config
The user can access all commands, including configuration commands. Exercise caution in assigning
this level of access to users.
Basic
The user can access non-configuration commands only. Only internal users and FTD external RADIUS
users support the Basic role.
Requirements and Prerequisites for User Accounts for Devices

Model Support
• FTD—Internal and external users
• ASA FirePOWER—Internal users
• NGIPSv—Internal users

136
Your User Account
Guidelines and Limitations for User Accounts for Devices
Supported Domains
Any
User Roles
Configure external users—Admin FMC user
Configure internal users—Config CLI user
Guidelines and Limitations for User Accounts for Devices

Defaults
All devices include an admin user as a local user account; you cannot delete the admin user. The default
initial password is Admin123; the system forces you to change this during the initialization process. See the
getting started guide for your model for more information about system initialization.
Add an Internal User at the CLI

Use the CLI to create internal users on the FTD, ASA FirePOWER, and NGIPSv devices.
Procedure
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.
Step 2 Create the user account.

configure user add username {basic | config}
• username—Sets the username. The username must be Linux-valid:
• All lowercase
• Cannot start with hyphen (-); cannot be all numbers; cannot include a period (.), at sign (@), or
slash (/)
• 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:

137
Your User Account
Add an Internal User at the CLI
The following example adds a user account named johncrichton with Config access rights. The password is
not shown as you type it.
> configure user add johncrichton config

Enter new password for user johncrichton: newpassword
Confirm new password for user johncrichton: newpassword
> show user
Login UID Auth Access Enabled Reset Exp Warn Str Lock Max
admin 1000 Local Config Enabled No Never N/A Dis No N/A
johncrichton 1001 Local Config Enabled No Never N/A Dis No 5
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.
Step 4 Manage user accounts as necessary.

Users can get locked out of their accounts, or you might need to remove accounts or fix other issues. Use the
following commands to manage the user accounts on the system.
• configure user access username {basic | config}
Changes the privileges for a user account.
• configure user delete username
Deletes the specified account.
• configure user disable username
Disables the specified account without deleting it. The user cannot log in until you enable the account.

138
Your User Account
Configure External Authentication for the FTD
• configure user enable username

Enables the specified account.
• configure user password username
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.
Configure External Authentication for the FTD

To enable external authentication for FTD devices, you need to add one or more external authentication
objects.
About External Authentication for the FTD

When you enable external authentication for FTD users, the FTD verifies the user credentials with an LDAP
or RADIUS server as specified in an external authentication object.
between the different appliance/device types, or create separate objects. For the FTD, you can only activate
one external authentication object in the platform settings that you deploy to the devices.
to a higher value, the FTD external authentication configuration will not work.
Note External authentication is not supported on FTD virtual devices.
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.

139
Your User Account
About LDAP
Note Users with CLI access can gain Linux shell access with the expert command. Linux shell users 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 Microsoft 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.
Add an LDAP External Authentication Object for FTD

Add an LDAP server to support external users for FTD management.
are created.
Sharing External Authentication Objects
External LDAP objects can be used by the FMC and FTD devices. You can share the same object between
the FMC and devices, or create separate objects.
Note For LDAP, the timeout range is different for the FTD and the FMC, so if you share an object, be sure not to
exceed the FTD's smaller timeout range (1-30 seconds). If you set the timeout to a higher value, the deployment
to the FTD will fail.

140
Your User Account
FTD Supported Fields

Only a subset of fields in the LDAP 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 Add an LDAP External Authentication Object for FMC,
on page 63.
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 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.
Privilege Level
LDAP users always have Config privileges.
Before you begin

You must specify DNS server(s) for domain name lookup on your device. Even if you specify an IP address
and not a hostname for the LDAP server on this procedure, the LDAP server may return a URI for authentication
that can include a hostname. A DNS lookup is required to resolve the hostname. See Modify Device
Management Interfaces at the CLI, on page 370 to add DNS servers.
Procedure

Step 2 Click the External Authentication tab.
Step 4 Set the Authentication Method to LDAP.
Step 6 Choose a Server Type from the drop-down list.
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.

Step 10 Enter LDAP-Specific Parameters.
a) Enter the Base DN for the LDAP directory you want to access. For example, to authenticate names in the
Security organization at the Example company, enter ou=security,dc=example,dc=com. Alternatively
click Fetch DNs, and choose the appropriate base distinguished name from the drop-down list.
b) (Optional) Enter the Base Filter. For example, if the user objects in a directory tree have a

141
Your User Account
c) Enter a User Name for a user who has sufficient credentials to browse the LDAP server. For example, if
you are connecting to an OpenLDAP server where user objects have a uid attribute, and the object for
the administrator in the Security division at your example company has a uid value of NetworkAdmin,
you might enter uid=NetworkAdmin,ou=security,dc=example,dc=com.
d) Enter the user password in the Password and the Confirm Password fields.
e) (Optional) Click Show Advanced Options to configure the following advanced options.
If you change the encryption method after specifying a port, you reset the port to the default value
for that method. For None or TLS, the port resets to the default value of 389. If you choose SSL
encryption, the port resets to 636.
• SSL Certificate Upload Path—For SSL or TLS encryption, you must choose a certificate by clicking
Choose File.
If you previously uploaded a certificate and want to replace it, upload the new certificate and redeploy
the configuration to your devices to copy over the new certificate.
Note TLS encryption requires a certificate on all platforms. For SSL, the FTD also requires a
certificate. For other platforms, SSL does not require a certificate. However, we recommend
that you always upload a certificate for SSL to prevent man-in-the-middle attacks.
• (Not Used) User Name Template—Not used by the FTD.

• Timeout—Enter the number of seconds before rolling over to the backup connection, between 1 and
Note The timeout range is different for the FTD and the FMC, so if you share an object, be sure
not to exceed the FTD's smaller timeout range (1-30 seconds). If you set the timeout to a
higher value, the FTD LDAP configuration will not work.
Step 11 (Optional) Set the CLI Access Attribute if you want to use a CLI access attribute other than the user
distinguished type. For example, on a Microsoft Active Directory Server, use the sAMAccountName CLI access
attribute to retrieve CLI access users by typing sAMAccountName in the CLI Access Attribute field.
Step 12 Set the CLI Access Filter.

Choose one of the following methods:
Filter.
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).
The usernames must be Linux-valid:

142
Your User Account

• All lowercase
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.
Step 13 Click Save.

Step 14 Enable use of this server. See Configure External Authentication for SSH, on page 1429.
Step 15 If you later add or delete users on the LDAP server, you must refresh the user list and redeploy the Platform
Settings on managed devices.
a) Click the Refresh ( ) next to each LDAP server.

If the user list changed, you will see a message advising you to deploy configuration changes for your
device.
b) Deploy configuration changes; see Deploy Configuration Changes, on page 535.
Examples
Basic Example
The following figures illustrate a basic configuration of an LDAP login authentication object for a

143
Your User Account

domain of the Example company.

144
Your User Account
A CLI 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.
Note that because no base filter is applied to this server, the FTD checks attributes for all objects in
the directory indicated by the base distinguished name. Connections to the server time out after the
default time period (or the timeout period set on the LDAP server).
Advanced Example
This example illustrates an advanced configuration of an LDAP login authentication object for a

domain of the Example company. However, note that this server has a base filter of (cn=*smith).
The filter restricts the users retrieved from the server to those with a common name ending in smith.

145
Your User Account
Add a RADIUS External Authentication Object for FTD
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 CLI Access Atrribute 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 CLI access filter is set to be the same as the base filter.

Add a RADIUS server to support external users for the FTD.
are created.
You can share the same object between the FMC and devices, or create separate objects. Note that the FTD
supports defining users on the RADIUS server, while the FMC requires you to predefine the user list in the

146
Your User Account
external authentication object. You can choose to use the predefined list method for the FTD, but if you want
to define users on the RADIUS server, you must create separate objects for the FTD and the FMC.
FTD's smaller timeout range (1-300 seconds). If you set the timeout to a higher value, the FTD RADIUS
configuration will not work.

Only a subset of fields in the RADIUS 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 Add a RADIUS External Authentication Object for
FMC, on page 70.
Usernames
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.
the FTD first checks the password against the internal user, and if that fails, it checks the RADIUS 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.
Procedure
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.
The names must be Linux-valid usernames:

• All lowercase
Alternatively, you can predefine users in the external authentication object (see Step Step 12, on page 148).
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 CLI Access Filter users (for use with the FMC), and the other object leaves the CLI Access
Filter empty (for use with FTDs).
Step 2 In FMC, choose System > Users.

147
Your User Account

Step 5 Set the Authentication Method to RADIUS.
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.

Step 9 Enter the RADIUS Secret Key.
Step 11 (Optional) Enter RADIUS-Specific Parameters.
a) Enter the Timeout in seconds before retrying the primary server, between 1 and 300. The default is 30.
Note The timeout range is different for the FTD and the FMC, so if you share an object, be sure not
to exceed the FTD's smaller timeout range (1-300 seconds). If you set the timeout to a higher
value, the FTD RADIUS configuration will not work.
b) Enter the Retries before rolling over to the backup server. The default is 3.
Step 12 (Optional) Instead of using RADIUS-defined users (see Step Step 1, on page 147), in the CLI Access Filter
area Administrator CLI Access User List field, enter the user names that should have CLI access, separated
by commas. For example, enter jchrichton, aerynsun, rygel.
You may want to use the CLI Access Filter method for FTD so you can use the same external authentication
object with FTD and other platform types.
Note If you want to use RADIUS-defined users, you must leave the CLI Access Filter empty.
usernames:
• All lowercase
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.
able to authenticate: enter a User Name and Password, and then click Test.

148
Your User Account
Example:
password.
Step 15 Click Save.

Step 16 Enable use of this server. See Configure External Authentication for SSH, on page 1429
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.

149
Your User 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.

150
Your User Account
Enable External Authentication for Users on FTD Devices
Enable External Authentication for Users on FTD Devices

Enable External Authentication in the Firepower Threat Defense Platform Settings, and then deploy the settings
to the managed devices. See Configure External Authentication for SSH, on page 1429 for more information.

If you create an LDAP authentication object and it either does not succeed in connecting to the server you
select, or does not retrieve the list of users you want, you can tune the settings in the object.
If the connection fails when you test it, try the following suggestions to troubleshoot your configuration:
• Use the messages displayed at the top of the web interface screen and in the test output to determine
which areas of the object are causing the issue.
• Check that the user name and password you used for the object are valid:
• Check that the user has the rights to browse to the directory indicated in your base distinguished
name by connecting to the LDAP server using a third-party LDAP browser.
• Check that the user name is unique to the directory information tree for the LDAP server.
• If you see an LDAP bind error 49 in the test output, the user binding for the user failed. Try
authenticating to the server through a third-party application to see if the binding fails through that
connection as well.
• Check that you have correctly identified the server:

• Check that the server IP address or host name is correct.
• Check that you have TCP/IP access from your local appliance to the authentication server where
you want to connect.

151
Your User Account
• 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 CLI 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
domainadmin@myrtle.example.com 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
'domainadmin@myrtle.example.com' -W '(cn=*)'

152
Your User Account
History for User Accounts for Devices
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 CLI 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.
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.
Devices > Platform Settings > External
Authentication

153
Your User Account

154
PA R T II
Firepower System Management
• Licensing the Firepower System, on page 157
• System Updates, on page 231
• Backup and Restore, on page 257
• Configuration Import and Export, on page 287
• Task Scheduling, on page 293
• Data Storage, on page 315
• Firepower Management Center High Availability, on page 321
• Device Management Basics, on page 341
CHAPTER 6
Licensing the Firepower System
The Licensing chapter of the Firepower Management Center Configuration Guide provides in-depth information
about the different license types, service subscriptions, licensing requirements and more. The chapter also
provides procedures and requirements for deploying Smart and Classic licenses and licensing for air-gapped
solutions.
The following topics explain how to license Firepower.
• About Firepower Licenses, on page 157
• Requirements and Prerequisites for Licensing, on page 158
• License Requirements for Firepower Management Center, on page 158
• Evaluation License Caveats, on page 159
• Smart vs. Classic Licenses, on page 159
• License Firepower Threat Defense Devices (FTD), on page 160
• FTDv Licensing, on page 197
• License Classic Devices (ASA FirePOWER and NGIPSv), on page 199
• How to Convert a Classic License for Use on an FTD Device, on page 205
• Assign Licenses to Managed Devices from the Device Management Page, on page 207
• License Expiration, on page 208
• Other Licensing Information in This Guide, on page 211
• Additional Information about Firepower Licensing, on page 213
• Cisco Success Network, on page 213
• Cisco Support Diagnostics, on page 227
• End-User License Agreement, on page 228
• History for Licensing, on page 228
About Firepower Licenses

Your Firepower products (Firepower Management Center and managed devices) include licenses for basic
operation, but some features require separate licensing or service subscriptions, as described in this chapter.
A "right-to-use" license does not expire, but service subscriptions require periodic renewal.
The type of license your products require (Smart or Classic) depends on the software you use, not on the
hardware it runs on.

157
Requirements and Prerequisites for Licensing
Note "NGFW" means different things to different people, so this documentation does not use this term.
Requirements and Prerequisites for Licensing

Model Support
Any, but the specific licenses requires per model differ as indicated in the procedures.
Supported Domains
Global, except where indicated.
User Roles
• Admin
License Requirements for Firepower Management Center

Firepower Management Center allows you to assign licenses to managed devices and manage licenses for the
system.
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 158.
Firepower Management Center Virtual Licenses

Generally, Firepower Management Center Virtual (FMCv) requires a license entitlement for each FTD device
that it will manage.
FMCv does not require Smart licenses (Firepower MCv) to manage Classic devices. Classic devices need
PAK licenses to be installed via FMCv. However, when you purchase an FMCv25, 25 MCv Entitlements are
deposited in your Smart Account. If your FMCv manages both Classic (7K/8K/FP Services and Smart FTDs)
and your device limit reaches 25, you see an error in FMC but your Smart License will still comply with the
additional MCv Entitlements.
In case of an FTDv high availability configuration, you require two MCv licenses for every FTDv device.
If a single FMCv manages Firepower Threat Defense devices that are configured in a high availability pair,
you still need one entitlement for each device (not one entitlement for the pair of FTDs.)

158
Evaluation License Caveats
For FMCv in high availability configurations, see License Requirements for FMC High Availability
Configurations, on page 328.
In multi-instance deployments, you need one entitlement for each security module.
In standard, connected Smart Licensing, these licenses are perpetual.
In Specific License Reservation, these licenses are term-based.
This entitlement appears in Cisco Smart Software Manager as Firepower MCv Device License with different
numbers of entitlements.
Evaluation License Caveats

Not all functionality is available with an evaluation license, functionality under an evaluation license may be
partial, and transition from evaluation licensing to standard licensing may not be seamless.
For example, if you have Firepower Threat Defense devices configured in a cluster, and you switch from an
evaluation license to Smart Licensing, service will be interrupted when you deploy the change.
Review information about evaluation license caveats in information about particular features in this Licensing
chapter and in the chapters related to deploying each feature.
Smart vs. Classic Licenses

For managed devices, the licenses you need (Smart or Classic) depend on the software that runs on the device.
Any FMC can simultaneously manage devices with Smart and Classic licenses. You must configure each
type of licensing separately.
Software License Type More Information
Firepower Management None FMC hardware models themselves require no license.

Center (hardware)
Firepower Management Device See Firepower Management Center Virtual Licenses, on page
Center Virtual entitlements 158.
Firepower Threat Defense Smart See the topics under License Firepower Threat Defense
Devices (FTD), on page 160.
Virtual
NGIPS software: Classic See License Classic Devices (ASA FirePOWER and NGIPSv),
on page 199.
• ASA FirePOWER
• NGIPSv
All other software products, See licensing information for your software product.
including those that run on
Firepower hardware

159
License Firepower Threat Defense Devices (FTD)
License Firepower Threat Defense Devices (FTD)

Firepower Threat Defense devices require Smart Licensing.
Cisco Smart Licensing lets you purchase and manage a pool of licenses centrally. Unlike product authorization
key (PAK) licenses, Smart Licenses are not tied to a specific serial number or license key. Smart Licensing
lets you assess your license usage and needs at a glance.
In addition, Smart Licensing does not prevent you from using product features that you have not yet purchased.
You can start using a license immediately, as long as you are registered with the Cisco Smart Software
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.
How to License Firepower Threat Defense Devices

Firepower Threat Defense devices require Smart Licensing.
Follow the steps outlined in this overview to license FTD devices managed by a hardware or virtual Firepower
Management Center.
If your FMC also manages Classic devices (ASA FirePOWER, NGIPSv), you can follow this procedure for
FTD devices, then follow the instructions under License Classic Devices (ASA FirePOWER and NGIPSv),
on page 199 for devices that use Classic licensing.
Procedure
Step 1 If you do not already have a Smart Account, create one.

We recommend you have a Smart Account before you purchase licenses. To create a new Smart Account,
see Create a Smart Account to Hold Your Licenses, on page 171.
Note Your account representative may have created a Smart Account on your behalf. If so, make sure
you can access the account in the Cisco Smart Software Manager (CSSM) at
https://software.cisco.com/#module/SmartLicensing.
Step 2 Understand the platform licenses your organization needs:

• Firepower Management Center physical hardware:
This appliance comes with the licensing it needs; you do not need to do anything to activate this.
• Firepower Management Center Virtual:
You need additional licenses. For details, see Firepower Management Center Virtual Licenses, on page
158.

160
(If your FMCv will also manage devices that use Classic licenses, those devices will also require these
entitlements when you configure Classic licensing.)
• Firepower Threat Defense devices:
Each device automatically includes a license for basic functionality. For details, see Base Licenses, on
page 166.
You do not need to do anything to activate a base license, but many features require separate licensing,
which is discussed below.
Step 3 Understand the feature licenses (sometimes called service subscriptions) that your organization needs.
See FTD License Types and Restrictions, on page 165 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 for FMC High Availability Configurations, on page 328.
• 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 908.
• For inter- or intra-chassis clustered Firepower Threat Defense devices:
See Licenses for Clustering, on page 940.
• For a multi-instance deployment:
See Licensing for Multi-Instance Deployments, on page 170.
Step 5 If you have existing licenses that you need to move:

• To convert a Classic license to a license that can be used for Firepower Threat Defense:
See How to Convert a Classic License for Use on an FTD Device, on page 205.
• To transfer Smart Licenses that are currently registered to another Firepower Management Center:
See Transfer FTD Licenses to a Different Firepower Management Center, on page 195 and Deregister a
Firepower Management Center from the Cisco Smart Software Manager, on page 196.
• To move Smart Licenses that are currently registered to another Firepower Threat Defense device:
See Move or Remove Licenses from FTD Devices, on page 195.
Step 6 If your Firepower appliances have restricted internet access:

Determine which solution is best for your situation:
• If your Firepower Management Center is not connected to the internet, but it can connect to an internal
server that can connect to Cisco's licensing authority, or can receive manual license updates:

161
Deploy Smart Software Manager On-Prem (formerly known as a Smart Software Satellite Server.) For
information, see Smart Software Manager On-Prem Overview, on page 177 and How to Deploy Smart
Software Manager On-Prem, on page 178.
• If your deployment is completely air-gapped and cannot connect to the licensing authority or to Smart
Software Manager On-Prem (which connects to the licensing authority), or receive manual license
updates:
See the options at Specific License Reservation (SLR), on page 179 and skip the rest of this procedure.
• For a comparison, see Licensing Options for Air-Gapped Deployments, on page 177.
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 Smart Software Manager On-Prem (formerly known as a Smart Software Satellite Server.) For
information, see Smart Software Manager On-Prem Overview, on page 177.
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 169.
Step 9 Purchase the licenses you need:

Contact your Cisco sales representative or authorized reseller.
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 173 and
• Register Smart Licenses, on page 174
• If your Firepower Management Center connects to Smart Software Manager On-Prem:

See Configure the Connection to Smart Software Manager On-Prem, on page 178.
Step 12 Verify that registration was successful:

In the Firepower Management Center web interface, go to System > Licenses > Smart Licenses. Product
Registration should show a green checkmark.

162
Smart Software Manager (CSSM)
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 355
Step 14 Assign licenses to your managed Firepower Threat Defense devices:

See Assign Licenses to Multiple Managed Devices, on page 192
Step 15 Verify that licenses have successfully been added to your devices.
See View FTD Licenses and License Status, on page 193.
Step 16 As applicable, set up licensing for high-availability and clustered deployments:

• For Firepower Management Centers in a high availability pair:
See the prerequisites to Establishing Firepower Management Center High Availability, on page 329.
After you configure FMC high-availability pairs, device licenses are automatically transferred from the
active to the standby management center. You do not need to configure anything specific for licensing.
• For Firepower Threat Defense devices in a high availability pair:
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 940. Licensing steps are included in FMC: Add a Cluster, on page
960.
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 199.
• Understand validity periods and expiration. See License Expiration, on page 208.
Smart Software Manager (CSSM)

When you purchase one or more Smart Licenses for Firepower features, you manage them in the Cisco Smart
Software Manager: http://www.cisco.com/web/ordering/smart-software-manager/index.html. The Smart
Software Manager lets you create a master account for your organization.
By default, your licenses are assigned to the Default Virtual Account under your master account. As the
account administrator, you can create additional virtual accounts; for example, for regions, departments, or
subsidiaries. Multiple virtual accounts help you manage large numbers of licenses and appliances.
You manage licenses and appliances by virtual account. Only that virtual account’s appliances can use the
licenses assigned to the account. If you need additional licenses, you can transfer an unused license from
another virtual account. You can also transfer appliances between virtual accounts.

163
Periodic Communication with the License Authority
For each virtual account, you can create a Product Instance Registration Token. Enter this token ID when you
deploy each Firepower Management Center, or when you register an existing FMC. You can create a new
token if an existing token expires. An expired token does not affect a registered FMC that used this token for
registration, but you cannot use an expired token to register a FMC. Also, a registered FMC becomes associated
with a virtual account based on the token you use.
For more information about the Cisco Smart Software Manager, see Cisco Smart Software Manager User
Guide or https://www.cisco.com/c/en/us/buy/smart-accounts/software-manager.html or the online help in
CSSM, also available from: https://www.cisco.com/web/fw/softwareworkspace/smartlicensing/
SSMCompiledHelps/.
Periodic Communication with the License Authority

In order to maintain your product license entitlement, your product must communicate periodically with the
Cisco License Authority.
When you use a Product Instance Registration Token to register a Firepower Management Center, the appliance
registers with the Cisco License Authority. The License Authority issues an ID certificate for communication
between the Firepower Management Center and the License Authority. This certificate is valid for one year,
although it will be renewed every six months. If an ID certificate expires (usually in nine months or a year
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 either have direct Internet access to the License Authority through
the Cisco Smart Software Manager, or use one of the options described in Licensing Options for Air-Gapped
Deployments, on page 177. In non-airgapped deployments, 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.
Service Subscriptions for FTD Features

Some features require a service subscription.
A service subscription enables a specific Firepower feature on a managed device for a set length of time.
Service subscriptions can be purchased in one-, three-, or five-year terms. If a subscription expires, Cisco
notifies you that you must renew the subscription. If a subscription expires for a Firepower Threat Defense
device, you can continue to use the related features.
Table 2: Service Subscriptions and Corresponding Smart Licenses
Subscription You Purchase Smart Licenses You Assign in Firepower System
T Threat
TC Threat + URL Filtering
TM Threat + Malware
TMC Threat + URL Filtering + Malware

164
FTD License Types and Restrictions
Subscription You Purchase Smart Licenses You Assign in Firepower System
URL URL Filtering (can be added to Threat or used without Threat)
AMP Malware (can be added to Threat or used without Threat)
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.
FTD License Types and Restrictions

This section describes the types of Smart Licenses available in a Firepower System deployment. The Firepower
Management Center requires Smart Licenses to manage Firepower Threat Defense devices.
The following table summarizes Firepower System Smart Licenses.
Table 3: Firepower System Smart Licenses
License You Assign in Subscription You Duration Granted Capabilities

Firepower System Purchase
Base No subscription required Perpetual User and application control

(license is included with
(Except for Specific License Switching and routing
device)
Reservation, Base licenses are
NAT
automatically assigned with all
Firepower Threat Defense For details, see Base Licenses,
devices) on page 166.
Threat •T Term-based Intrusion detection and

prevention
• TC (Threat + URL)
File control
• TMC (Threat +
Malware + URL) Security Intelligence filtering
For details, see Threat Licenses,
on page 167
Malware • TM (Threat + Term-based AMP for Networks

Malware) (network-based Advanced
Malware Protection)
• TMC (Threat +
Malware + URL) Cisco Threat Grid
• AMP File storage

For details, see Malware
Licenses for Firepower Threat
Defense Devices, on page 167
and License Requirements for
File and Malware Policies, on
page 1843.

165
Base Licenses
License You Assign in Subscription You Duration Granted Capabilities

Firepower System Purchase
URL Filtering • TC (Threat + URL) Term-based Category and reputation-based

URL filtering
• TMC (Threat +
Malware + URL) For details, see URL Filtering
Licenses for Firepower Threat
• URL Defense Devices, on page 168.
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 158.
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 169.
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
168 and VPN Licensing, on page
1126.
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)

166
Malware Licenses for Firepower Threat Defense Devices
• 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 170.
Malware Licenses for Firepower Threat Defense Devices

A Malware license for Firepower Threat Defense devices allows you to perform Cisco Advanced Malware
Protection (AMP) with AMP for Networks and Cisco Threat Grid. With this feature, you can use Firepower
Threat Defense devices to detect and block malware in files transmitted over your network. To support this
feature license, you can purchase the Malware (AMP) service subscription as a stand-alone subscription or
in combination with Threat (TM) or Threat and URL Filtering (TMC) subscriptions.
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 1843.
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.

167
URL Filtering Licenses for Firepower Threat Defense Devices
• 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.
URL Filtering Licenses for Firepower Threat Defense Devices

The URL Filtering license allows you to write access control rules that determine the traffic that can traverse
your network based on URLs requested by monitored hosts, correlated with information about those URLs.
To support this feature license, you can purchase the URL Filtering (URL) service subscription as a stand-alone
subscription or in combination with Threat (TC) or Threat and Malware (TMC) subscriptions.
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.

168
Licensing for Export-Controlled Functionality
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 165.
You cannot deploy Remote Access VPN if the following are true:
• Smart Licensing on the Firepower Management Center is running in evaluation mode.
• Your Smart Account is not configured to use export-controlled features (strong encryption). Note that
you need to reboot FTD devices after applying a base license that has export-controlled functionality.
Licensing for Export-Controlled Functionality
Features that require export-controlled functionality

Certain software features are subject to national security, foreign policy, and anti-terrorism laws and regulations.
These export-controlled features include:
• Security certifications compliance
• Firepower Threat Defense Remote Access VPN
• Site to Site VPN with strong encryption
• SSH platform policy with strong encryption
• SSL policy with strong encryption
• Functionality such as SNMPv3 with strong encryption
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.
About enabling export-controlled functionality

If Export-Controlled Features shows Disabled and you want to use features that require strong encryption:
There are two ways to enable strong cryptographic features. Your organization may be eligible for one or the
other (or neither), but not both.
• If there is no option to enable export-controlled functionality when you generate a new Product Instance
Registration Token in Cisco Smart Software Manager (CSSM):
Contact your account representative.
The Firepower Management Center allows you to use export-controlled features if your Smart Account
is eligible for export-controlled functionality. When approved by Cisco, an export control license is added
to your virtual account and you can use the export-controlled features. For more information, see Enabling
the Export Control Feature (for Accounts Without Global Permission), on page 175

169
Licensing for High-Availability Configurations
• If the option to use export-controlled functionality appears when you generate a new Product Instance
Registration Token in Cisco Smart Software Manager:
• The entitlement is perpetual and does not require a subscription.
• In order to use export-controlled functionality, your Smart Account must be enabled for this
functionality before you license your Firepower Management Center.
• After export-controlled functionality is enabled for your Smart Account in Cisco Smart Software
Manager (CSSM), you must re-register your Firepower Management Center using a new Product
Instance Registration Token.
• 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.
Licensing for High-Availability Configurations

See:
• For Firepower Management Center appliances in a high-availability pair:
License Requirements for FMC High Availability Configurations, on page 328
• For Firepower Threat Defense devices in a high-availability pair:
License Requirements for FTD Devices in a High Availability Pair, on page 908
See also the topics for specific license types under the FTD License Types and Restrictions, on page 165 topic.
Licensing for FTD Clusters

In addition to information in this Licensing chapter, see:
• Licenses for Clustering, on page 940
• FMC: Add a Cluster, on page 960.
Licensing for Multi-Instance Deployments

All licenses apply per security engine/chassis (for the Firepower 4100) or per security module (for the Firepower
9300), not per container instance.

170
Create a Smart Account to Hold Your Licenses
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.
Firepower Management Center Virtual

One entitlement is required for each security engine/module managed by a Firepower Management Center
virtual appliance.
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
780.
Create a Smart Account to Hold Your Licenses

A Smart Account is required for Smart Licenses and can also hold Classic licenses.
You should set up this account before you purchase Smart Licenses.
Before you begin

Your account representative or reseller may have set up a Smart Account on your behalf. If so, obtain the
necessary information to access the account from that person instead of using this procedure, then verify that
you can access the account.
For general information about Smart Accounts, see http://www.cisco.com/go/smartaccounts.
Procedure
Step 1 Request a Smart Account:

For instructions, see https://community.cisco.com/t5/licensing-enterprise-agreements/
request-a-smart-account-for-customers/ta-p/3636515?attachment-id=150577 .
For additional information, see https://communities.cisco.com/docs/DOC-57261.
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:

171
How to Configure Smart Licensing with Direct Internet Access
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 160
How to Configure Smart Licensing with Direct Internet Access

Before you begin
If your deployment is complex or you have questions about the licenses you need, see How to License
Firepower Threat Defense Devices, on page 160.
Procedure
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 173.
Step 2 Register your Firepower Management Center with the Smart licensing portal.
See Register Smart Licenses, on page 174. 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 355.
Step 5 Assign licenses to the devices that are managed by your FMC.
See Assign Licenses to Multiple Managed Devices, on page 192.
Step 6 Verify that licenses are successfully installed.


172
Obtain a Product License Registration Token for Smart Licensing
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 160.
Obtain a Product License Registration Token for Smart Licensing
Before you begin

• Create a Smart Account, if you have not already done so: Visit https://software.cisco.com/smartaccounts/
setup#accountcreation-account. For information, see https://www.cisco.com/c/en/us/buy/
smart-accounts.html.
• Ensure that you have purchased the type and number of licenses you require.
• 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 174 to ensure that your registration
process goes smoothly.
• Make sure you have your credentials to sign in to the Cisco Smart Software Manager.
Procedure
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 175.

173
Register Smart Licenses
Step 10 Click Create Token.

Step 11 Locate your new token in the list and click Actions, then choose Copy or Download.
Step 12 If necessary, save your token in a safe place until you are ready to enter it into your Firepower Management
Center.
What to do next
Continue with the steps in Register Smart Licenses, on page 174.
Register Smart Licenses

Register the Firepower Management Center with the Cisco Smart Software Manager.
Before you begin

• If your deployment is air-gapped, do not use this procedure. Instead, see Configure the Connection to
Smart Software Manager On-Prem, on page 178 or How to Implement Specific License Reservation, on
page 180, respectively.
• Ensure that the Firepower Management Center can reach the Cisco Smart Software Manager (CSSM)
server at tools.cisco.com:443.
• Make sure the NTP daemon is running on your Firepower Management Center. During registration, a
key exchange occurs between the NTP server and the Cisco Smart Software Manager, so time must be
in sync for proper registration.
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.
• If your organization has multiple Firepower Management Center appliances, make sure each FMC has
a unique name that clearly identifies and distinguishes it from other Firepower Management Center
appliances that may be registered to the same virtual account. This name is critical for managing your
Smart License entitlements and ambiguous names will lead to problems later.
• Generate the necessary product license registration token from the Cisco Smart Software Manager. See
Obtain a Product License Registration Token for Smart Licensing, on page 173, including all prerequisites.
Make sure the token is accessible from the machine from which you will access your Firepower
Management Center.
Procedure
Step 1 Choose System > Licenses > Smart Licenses.

Step 2 Click Register.
Step 3 Paste the token you generated from Cisco Smart Software Manager into the Product Instance Registration
Token field.
Make sure there are no empty spaces or blank lines at the beginning or end of the text.
Step 4 Decide whether to send usage data to Cisco.

174
Enabling the Export Control Feature (for Accounts Without Global Permission)
• Enable Cisco Success Network is enabled by default. You can click sample data to see the kind of
data Cisco collects. To help you make your decision, read the Cisco Success Network information block.
• Enable Cisco Proactive Support is enabled by default. You can review the kind of data Cisco collects
in the link provided above the check box. To help you make your decision, read the Cisco Support
Diagnostics information block.
Note • When enabled, Cisco Support Diagnostics is enabled in the Firepower Threat Defense
(FTD) devices in the next sync cycle. The FMC sync with the FTD runs once every 30
minutes.
• When enabled, any new FTD registered in this FMC in the future will have Cisco Support
Diagnostics enabled on it automatically.
Step 5 Click Apply Changes.
What to do next
• Add your Firepower Threat Defense devices to the Firepower Management Center; see Add a Device to
the FMC, on page 355.
• Assign licenses to your Firepower Threat Defense devices; see Assign Licenses to Multiple Managed
Devices, on page 192.
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 169.
Before you begin

• Make sure that your deployment does not already support the export-controlled functionality.
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.
• Make sure your deployment is not using an evaluation license.

• In Cisco Smart Software Manager, on the Inventory > Licenses page, verify that you have the license
that corresponds to your Firepower Management Center:

175
Disabling the Export Control Feature (for Accounts without Global Permission)
Export Control License Firepower Management Center Model
Cisco Virtual FMC Series Strong Encryption All virtual Firepower Management Centers
(3DES/AES)
Cisco FMC 1K Series Strong Encryption 1000, 1600

(3DES/AES)

(3DES/AES)

(3DES/AES)
Procedure
Step 1 Choose System > Licenses > Smart Licenses .

Note If you see the Request Export Key, your account is approved for the export-controlled functionality
and you can proceed to use the required feature.
Step 2 Click Request Export Key to generate an export key.

Tip If the export control key request fails, make sure that your virtual account has a valid Export Control
license.
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 175, you can disable this functionality using this
procedure.

176
Licensing Options for Air-Gapped Deployments
Procedure
Step 1 Choose System > Licenses > Smart Licenses .

This releases the license back into the pool of available licenses in your virtual account, where it is now
available for reuse.
Step 2 Disable the export control license by clicking Return Export Key.
Licensing Options for Air-Gapped Deployments

The following table compares the available licensing options for environments without internet access. Your
sales representative may have additional advice for your specific situation.
Table 4: Comparison of Licensing Options for Air-Gapped Networks
Smart Software Manager On-Prem Specific License Reservation
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 Manager For more information, see Specific License
On-Prem Overview, on page 177 Reservation (SLR), on page 179
Smart Software Manager On-Prem Overview

As described in Periodic Communication with the License Authority, on page 164, your system must
communicate regularly with Cisco to maintain your license entitlement. If you have one of the following
situations, you might want to use a Smart Software Manager On-Prem (also known as SSM On-Prem, and
formerly known as "Smart Software Satellite Server") as a proxy for connections to the License Authority:
• Your Firepower Management Center is offline or otherwise has limited or no connectivity (in other
words, is deployed in an air-gapped network.)
(For an alternate solution for air-gapped networks, see Licensing Options for Air-Gapped Deployments,
on page 177.)
• Your Firepower Management Center has permanent connectivity, but you want to manage your Smart
Licenses via a single connection from your network.

177
How to Deploy Smart Software Manager On-Prem
Cisco Smart Software Manager On-Prem allows you to schedule synchronization or manually synchronize
Smart License authorization with the Smart Software Manager.
For more information about Smart Software Manager On-Prem, see https://www.cisco.com/c/en/us/buy/
smart-accounts/software-manager.html#~on-prem
How to Deploy Smart Software Manager On-Prem
Before you begin

If your network is air-gapped, determine the best solution for license management for your deployment. See
Licensing Options for Air-Gapped Deployments, on page 177.
Procedure
Step 1 Deploy and set up Smart Software Manager On-Prem.

See the documentation for the Smart Software Manager On-Prem, available from https://www.cisco.com/c/
en/us/buy/smart-accounts/software-manager.html#~on-prem.
Step 2 Connect the Firepower Management Center to Smart Software Manager On-Prem, obtain a registration token,
and register the FMC to SSM On-Prem.
See Configure the Connection to Smart Software Manager On-Prem, on page 178.
Step 3 Add devices to be managed.

See Add a Device to the FMC, on page 355.
Step 4 Assign licenses to managed devices

See Assign Licenses to Multiple Managed Devices, on page 192
Step 5 Synchronize Smart Software Manager On-Prem to the Cisco Smart Software Management Server (CSSM).
See the Smart Software Manager On-Prem documentation, above.
Step 6 Schedule ongoing synchronization times.
Configure the Connection to Smart Software Manager On-Prem
Before you begin

• Set up Smart Software Manager On-Prem (SSM On-Prem). For information, see How to Deploy Smart
Software Manager On-Prem, on page 178.
• Make a note of the CN of the TLS/SSL certificate on your SSM On-Prem.
• Verify that your FMC can reach your SSM On-Prem. For example, verify that the FQDN configured as
the SSM On-Prem call-home URL can be resolved by your internal DNS server.
• Go to http://www.cisco.com/security/pki/certs/clrca.cer and copy the entire body of the TLS/SSL certificate
(from "-----BEGIN CERTIFICATE-----" to "-----END CERTIFICATE-----") into a place you can access
during configuration.

178
Specific License Reservation (SLR)
Procedure
Step 1 Choose System > Integration.

Step 2 Click Smart Software Satellite.
Step 3 Select Connect to Cisco Smart Software Satellite Server.
Step 4 Enter the URL of your Smart Software Manager On-Prem, using the CN value you collected in the prerequisites
of this procedure, in the following format:
https://FQDN_or_hostname_of_your_SSM_On-Prem/Transportgateway/services/DeviceRequestHandler
The FQDN or hostname must match the CN value of the certificate presented by your SSM On-Prem.
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 Smart Software Manager On-Prem.
Step 9 Copy the token.
Step 10 Paste the token into the form on the management center page.
The management center is now registered to Smart Software Manager On-Prem.
What to do next
Complete remaining steps in How to Deploy Smart Software Manager On-Prem, on page 178.
Specific License Reservation (SLR)

You can use the Specific License Reservation feature to deploy Smart Licensing in an air-gapped network.
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 using
Smart Software Manager On-Prem.
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:

179
Best Practices for Specific License Reservation
• Best Practices for Specific License Reservation, on page 180

• Requirements for Specific License Reservation, on page 180
• How to Implement Specific License Reservation, on page 180
• Specific License Reservation Status, on page 187
• Update a Specific License Reservation, on page 185
• Deactivate and Return the Specific License Reservation, on page 189
• Troubleshoot Specific License Reservation, on page 191
Best Practices for Specific License Reservation

You will not be able to successfully implement Specific License Reservation without reading this
documentation.
An unsuccessful attempt is likely to result in the need to contact TAC.
To avoid problems, follow the instructions carefully, including the prerequisites and verification procedures.
Requirements for Specific License Reservation

Usage of Specific License Reservation requires approval and authorization from Cisco.
See also Prerequisites for Specific License Reservation, on page 181.
How to Implement Specific License Reservation

Do This More Information
Step 1 Complete the prerequisites for this feature. Prerequisites for Specific License Reservation, on
page 181
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 182
Step 3 Enable Specific License Reservation using the Enable the Specific Licensing Menu Option, on
Firepower Management Center page 182
Step 4 Generate a Reservation Request Code from the Generate a Reservation Request Code from the
Firepower Management Center Firepower Management Center, on page 183
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 183
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 184
Step 7 Assign Specific Licenses to managed Firepower Assign Specific Licenses to Managed Devices, on
Threat Defence devices page 185

180
Prerequisites for Specific License Reservation
Do This More Information
Step 9 (Outside of your Firepower Management Maintain Your Air-Gapped Deployment, on page
Center) Schedule reminders for ongoing 250
maintenance tasks
Prerequisites for Specific License Reservation

• Set up your Smart Account.
See Create a Smart Account to Hold Your Licenses, on page 171.
• If you are currently using standard Smart Licensing on your Firepower Management Center, de-register
the Firepower Management Center before you implement Specific License Reservation. For information,
see Deregister a Firepower Management Center from the Cisco Smart Software Manager, on page 196.
All Smart Licenses that are currently deployed to your Firepower Management Center will be returned
to the pool of available licenses in your account, and you can re-use them when you implement Specific
License Reservation.
• Specific License Reservation requires the same number and types of licenses as standard Smart Licensing.
Determine how many standard licenses and service subscriptions you need for the devices and features
you will deploy. Be sure to include entitlements for Firepower Management Center Virtual if applicable.
For descriptions of Firepower licenses and service subscriptions, see FTD License Types and Restrictions,
on page 165 and its subtopics, especially Firepower Management Center Virtual Licenses, on page 158.
• Purchase the licenses you need.
• 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 169.
• 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 355. (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.

181
Verify that your Smart Account is Ready to Deploy Specific License Reservation
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.
Before you begin

• Ensure that you have met the requirements described in Prerequisites for Specific License Reservation,
on page 181.
• Make sure you have your Cisco Smart Software Manager credentials.
Procedure
Step 1 Sign in to the Cisco Smart Software Manager:

https://software.cisco.com/#SmartLicensing-Inventory
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.
Enable the Specific Licensing Menu Option

This procedure changes the "Smart Licenses" menu option to "Specific Licenses" in Firepower Management
Center.
Procedure
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:

182
Generate a Reservation Request Code from the Firepower Management Center
admin@fmc63betaslr: ~$ sudo manage_slr.pl

Password:
**************** Configuration Utility **************
1 Show SLR Status

2 Enable SLR
3 Disable SLR
0 Exit
**************************************************************
Enter choice:
Step 5 Enable Specific License Reservation by selecting option 2.

Step 6 Select option 0 to exit the manage_slr utility.
Step 7 Type exit to exit the Linux shell.
Step 8 Enter exit to exit the command line interface.
Step 9 Verify that you can access the Specific License Reservation page in the Firepower Management Center web
interface:
• If the System > Licenses > Smart Licenses page is currently displayed, refresh the page.
• Otherwise, choose System > Licenses > Specific Licenses.
Generate a Reservation Request Code from the Firepower Management Center
Procedure
Step 1 If you are not already viewing the Specific License Reservation page, choose System > Licenses > Specific
Licenses.
Step 2 Click Generate.
Step 3 Make a note of the Reservation Request Code.
Generate a Reservation Authorization Code from Cisco Smart Software Manager
Procedure
Step 1 Go to the Cisco Smart Software Manager:

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 4 Click Licenses.

183
Enter the Specific License Reservation Authorization Code into the Firepower Management Center
Step 5 Click License Reservation.

Step 6 Enter the code that you generated from Firepower Management Center into the Reservation Request Code
box.
Step 7 Click Next.
Step 8 Select Reserve a specific license.
Step 9 Scroll down to display the entire License grid.
Step 10 Under Quantity To Reserve, enter the number of each platform and feature license needed for your deployment.
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 175.
Step 11 Click Next.

Step 12 Click Generate Authorization Code.
At this point, the license is now in use according to the Smart Software Manager.
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
Procedure
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.

184
Assign Specific Licenses to Managed Devices
Assign Specific Licenses to Managed Devices

Use this procedure to quickly assign licenses to multiple managed devices at one time.
You can also use this procedure to disable or move licenses from one Firepower Threat Defense device to
another. If you disable a license for a device, you cannot use the features associated with that license on that
device.
Procedure
Step 1 Choose System > Licenses > Specific Licenses.

Step 2 Click Edit Licenses.
Step 3 Click each tab and assign licenses to devices as needed.
Step 4 Click Apply.
Step 5 Click the Assigned Licenses tab and verify that your licenses are correctly installed on each device.
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 535.
Update a Specific License Reservation

After you have successfully deployed Specific Licenses on your Firepower Management Center, you can add
or remove entitlements at any time using this procedure.
Procedure
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:
a) Go to the Cisco Smart Software Manager:
b) If necessary, click Inventory.
c) Click Product Instances.
d) Look for a product instance that has FP in the Type column and a generic SKU (not a hostname) in the
Name column. You may also be able to use the values in other table columns to help determine which
Firepower Management Center is the correct Firepower Management Center. Click the name.

185
Update a Specific License Reservation
e) Look at the UUID and see if it is the UUID of the Firepower Management Center that you are trying to
modify.
If not, you must repeat these steps until you find the correct Firepower Management Center.
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 175.
c) Click Next and verify the details.

d) Click Generate Authorization Code.
e) Download the Authorization Code in preparation for entering it into the Firepower Management Center.
f) Leave the Update Reservation page open. You will return to it later in this procedure.
Step 4 Update the Specific Licenses in Firepower Management Center:
a) Choose System > Licenses > Specific Licenses.
b) Click Edit SLR.
c) Click Browse to upload the newly generated authorization code.
d) Click Install to update the licenses.
After successful installation of the authorization code, ensure that the licenses shown in the Reserved
column of Firepower Management Center, matches with the licenses that you have reserved in Cisco
Smart Software Manager.
e) Make a note of the Confirmation Code.
Step 5 Enter the confirmation code in Cisco Smart Software Manager:
a) Return to the Cisco Smart Software Manager page that you left open earlier in this procedure.
b) Choose Actions > Enter Confirmation Code:

186
Important! Maintain Your SLR Deployment
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 187 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 535.
Important! Maintain Your SLR Deployment

To update the threat data and software that keep your deployment effective, see Maintain Your Air-Gapped
Deployment, on page 250.
To ensure that all functionality continues to work without interruption, monitor your license expiration dates
(on the Reserved Licenses tab).
Specific License Reservation Status

The System > Licenses > Specific Licenses page provides an overview of license usage on the Firepower
Management Center, as described below.

187
Expired Specific License Reservation
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 169.
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.
Assigned Licenses Tab

Shows the licenses assigned to each device and the status of each.
Reserved Licenses Tab

Shows the number of licenses used and available to be assigned, and license expiration dates.
Expired Specific License Reservation

If required licenses are unavailable or expired, the following actions are restricted:
• Device registration
• Policy deployment
To renew your Specific License Reservation entitlements, purchase the necessary licenses, then follow the
procedure in Update a Specific License Reservation, on page 185.
Renew Specific License Reservation Entitlements

When it is time to renew your Specific License Reservation entitlements, purchase the necessary licenses,
then follow the procedure in Update a Specific License Reservation, on page 185.

188
Deactivate and Return the Specific License Reservation

If you no longer need a specific license, you must return it to your Smart Account.
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.
Procedure
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:
b) If necessary, click Inventory.
c) Click Product Instances.

189
d) Look for a product instance that has FP in the Type column and a generic SKU (not a hostname) in the
Name column. You may also be able to use the values in other table columns to help determine which
Firepower Management Center is the correct Firepower Management Center. Click the name.
e) Look at the UUID and see if it is the UUID of the Firepower Management Center that you are trying to
modify.
If not, you must repeat these steps until you find the correct Firepower Management Center.
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:
**************** Configuration Utility **************
1 Show SLR Status

2 Enable SLR
3 Disable SLR
0 Exit
**************************************************************
Enter choice:
e) Select menu option 3 to disable the Specific License Reservation.

f) Select option 0 to exit the manage_slr utility.
g) Enter exit to exit the Linux shell.
h) Enter exit to exit the command line interface.

190
Troubleshoot Specific License Reservation
Troubleshoot Specific License Reservation
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
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 do not see a License Reservation button in Cisco Smart Software Manager

If you do not see the License Reservation button, then your account is not authorized for specific license
reservation. If you have already enabled Specific License Reservation in the Linux shell and generated a
request code, perform the following:
1. If you have already generated a Request Code in the Firepower Management Center web interface, cancel
the request code.
2. Disable Specific License Reservation in the Firepower Management Center Linux shell as described
within the section Deactivate and Return the Specific License Reservation, on page 189.
3. Register a Firepower Management Center with Cisco Smart Software Manager in regular mode using
smart token.
4. Contact Cisco TAC to enable Specific License for your smart account.
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 185.
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 189.
What if I do not see a Specific License page in Firepower Management Center?

You need to enable Specific License to view the Specific License page. For more information see, Enable the
Specific Licensing Menu Option, on page 182.

191
Assign Licenses to Multiple Managed Devices
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 182), then refresh the Firepower
Management Center web interface. Your Return Code will be displayed.
Assign Licenses to Multiple Managed Devices

Devices managed by a Firepower Management Center obtain their licenses via the Firepower Management
Center, not directly from the Cisco Smart Software Manager.
Use this procedure to enable licensing on multiple Firepower Threat Defense devices at once.
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.
Before you begin

• If you have not yet done so, register your devices with the Firepower Management Center. See Add a
Device to the FMC, on page 355.
• Prepare licenses for distribution to managed devices: See Register Smart Licenses, on page 174
Procedure
Step 1 Choose System > Licenses > Smart Licenses or Specific 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.

192
View FTD Licenses and License Status
What to do next
• Verify that your licenses are correctly installed. Follow the procedure in View FTD Licenses and License
Status, on page 193.
• 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.
View FTD Licenses and License Status

To view the license status for a Firepower Management Center and its managed Firepower Threat Defense
devices, use the Smart Licenses page in FMC.
For each type of license in your deployment, the page lists the total number of licenses consumed, whether
the license is in compliance or out of compliance, the device type, and the domain and group where the device
is deployed. You can also view the Firepower Management Center's Smart License Status. Container instances
on the same security module/engine only consume one license per security module/engine. Therefore, even
though the FMC lists each container instance separately under each license type, the number of licenses
consumed for feature license types will only be one.
Other than the Smart Licenses page, there are a few other ways you can view licenses:
• The Product Licensing dashboard widget provides an at-a-glance overview of your licenses.
See Adding Widgets to a Dashboard, on page 417 and Dashboard Widget Availability by User Role, on
page 405 and The Product Licensing Widget, on page 414.
• The Device Management page (Devices > Device Management) lists the licenses applied to each of
your managed devices.
• The Smart License Monitor health module communicates license status when used in a health policy.
Procedure

Step 2 In the Smart Licenses table, click the arrow at the left side of each License Type folder to expand that folder.
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.

193
FTD License Status
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.
FTD License Status
Permanent License Reservation

See Specific License Reservation Status, on page 187
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.
Assigned Virtual Account

Specifies the Virtual Account under the Smart Account that you used to generate the Product Instance
Registration Token and register the Firepower Management Center. If this deployment is not associated with
a particular virtual account within your Smart Account, this information is not displayed.
Export-Controlled Features
If this option is enabled, you can deploy restricted features. For details, see Licensing for Export-Controlled
Functionality, on page 169.
Cisco Success Network

Specifies whether you have enabled Cisco Success Network for the Firepower Management Center. If this
option is enabled, you provide usage information and statistics to Cisco which are essential to provide you
with technical support. This information also allows Cisco to improve the product and make you aware of
unused available features so that you can maximize the value of the product in your network. See Cisco
Success Network, on page 213 for more information.

194
Move or Remove Licenses from FTD Devices
Move or Remove Licenses from FTD Devices

Use this procedure to manage licenses for Firepower Threat Defense devices managed by an Firepower
Management Center.
For example, you can move a license from one FTD device to another device registered to the same FMC, or
to remove a license from a device.
If you remove (disable) a license for a device, you cannot use the features associated with that license on that
device.
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 195.
Procedure

Step 3 Click either the Malware, Threat, URL Filtering, AnyConnect Plus, AnyConnect Apex, or AnyConnect
VPN Only.
Step 4 Choose the devices you want to license, then click Add, and/or click each device form which you want to
remove a license and click the Delete ( ).
Step 5 Click Apply.
What to do next
Deploy the changes to the managed devices.
Transfer FTD Licenses to a Different Firepower Management Center

When you register a Smart License to a Firepower Management Center, your virtual account allocates the
license to the FMC. If you need to transfer your Smart Licenses to another Firepower Management Center,
you must deregister the currently licensed FMC. This removes it from your virtual account and frees your
existing licenses, so you can register the licenses to the new FMC. Otherwise, you cannot reuse these licenses,
and you may receive an Out-of-Compliance notification because your virtual account does not have enough
free licenses. For instructions, see Deregister a Firepower Management Center from the Cisco Smart Software
Manager, on page 196.
Then you can register the licenses to the destination Firepower Management Center.
If FTD License Status is Out of Compliance

If the Usage Authorization status on the Smart Licenses page (System > Licenses > Smart Licenses) shows
Out of Compliance, you must take action.

195
Deregister a Firepower Management Center from the Cisco Smart Software Manager
Procedure
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 197.
Step 4 In Firepower Management Center, select System > Licenses > Smart Licenses.
Step 5 Click Re-Authorize.
Deregister a Firepower Management Center from the Cisco Smart Software

Manager
Deregister (unregister) your Firepower Management Center from the Cisco Smart Software Manager before
you reinstall (reimage) the appliance, or if you need to release all of the license entitlements back to your
Smart Account for any reason.
Deregistering removes the FMC 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.
If you need to remove the licenses from a subset of managed Firepower Threat Defense devices, see Assign
Licenses to Multiple Managed Devices, on page 192 or Assign Licenses to Managed Devices from the Device
Management Page, on page 207.
Procedure
Step 2 Click Deregister ( ).
Synchronize a Firepower Management Center with the Cisco Smart Software

Manager
If you make changes in the Cisco Smart Software Manager, you can refresh the authorization on the Firepower
Management Center so the changes immediately take effect.
Procedure

196
Troubleshoot FTD Licensing
Step 2 Click Refresh ( ).
Troubleshoot FTD Licensing

Expected Licenses Do Not Appear in My Smart Account
If the licenses you expect to see are not in your Smart Account, try the following:
• 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.
Unable to Connect to Smart License Server

Check the obvious causes first. For example, make sure your Firepower system has outside connectivity. See
Internet Access Requirements, on page 3032.
Unexpected Out-of-Compliance Notification or Other Error

• If a device is already registered to a different FMC, you need to deregister the original FMC before you
can license the device under a new FMC. See Deregister a Firepower Management Center from the Cisco
Smart Software Manager, on page 196.
• Try synchronizing: Synchronize a Firepower Management Center with the Cisco Smart Software Manager,
on page 196.
Troubleshoot Other Issues

For solutions to other common issues, see https://www.cisco.com/c/en/us/support/docs/security/
firepower-management-center/215838-fmc-and-ftd-smart-license-registration-a.html
FTDv Licensing
This section describes the performance-tiered license entitlements available for the FTDv.
Any FTDv license can be used on any supported FTDv vCPU/memory configuration. This allows FTDv
customers to run on a wide variety of VM resource footprints. This also increases the number of supported
AWS and Azure instances types. When configuring the FTDv VM, the maximum supported number of cores
(vCPUs) is 16 ; and the maximum supported memory is 32 GB RAM .
Performance Tiers for FTDv Smart Licensing

Session limits for RA VPNs are determined by the installed FTDv platform entitlement tier, and enforced via
a rate limiter. The following table summarizes the session limits based on the entitlement tier and rate limiter.

197
FTDv Performance Tier Licensing Guidelines and Limitations
Table 5: FTDv Licensed Feature Limits Based on Entitlement
Performance Tier Device Specifications Rate Limit RA VPN Session Limit

(Core/RAM)
FTDv5, 100Mbps 4 core/8 GB 100Mbps 50
FTDv10, 1Gbps 4 core/8 GB 1Gbps 250
FTDv100, 16Gbps 16 core/32 GB 16Gbps 10,000
Note For a set of guidelines and limitations that you must keep in mind when licensing your FTDv device, see
FTDv Performance Tier Licensing Guidelines and Limitations, on page 198.
FTDv Performance Tier Licensing Guidelines and Limitations

Please keep the following guidelines and limitations in mind when licensing your FTDv device.
• The FTDv supports performance-tiered licensing that provides different throughput levels and VPN
connection limits based on deployment requirements.
• Any FTDv license can be used on any supported FTDv core/memory configuration. This allows FTDv
customers to run on a wide variety of VM resource footprints; see the "Performance Tiers for FTDv
Smart Licensing" table in the FTDv Licensing section.
• You can select a performance tier when you deploy a FTDv, whether your device is in evaluation mode
or is already registered with Cisco Smart Software Manager.
Note Make sure your Smart Licensing account contains the available licenses you need.
It’s important to choose the tier that matches the license you have in your account.
If you are upgrading your FTDv to Version 7.0, you can choose FTDv - Variable
to maintain your current license compliance. Your FTDv continues to perform
with session limits based on your device capabilities (number of cores/RAM).
• The default performance tier is FTDv50 when deploying a new FTDv device, or when provisioning the
FTDv using the REST API.
• You cannot update the performance tier when the FTDv is in Universal PLR mode. You need to unregister
the device and then register it with a new tier.
• Base licenses are subscription-based and mapped to performance tiers. Your virtual account needs to
have the Base license entitlements for the FTDv devices, as well as for Threat, Malware, and URL
Filtering licenses.

198
License Classic Devices (ASA FirePOWER and NGIPSv)
• Each HA peer consumes one entitlement, and the entitlements on each HA peer must match, including
Base license.
• A change in performance tier for an HA pair should be applied to the primary peer.
• Universal PLR licensing is applied to each device in an HA pair separately. The secondary device will
not automatically mirror the performance tier of the primary device. It must be updated manually.
License Classic Devices (ASA FirePOWER and NGIPSv)

NGIPSv devices and ASA FirePOWER modules require Classic licenses. These devices are frequently referred
to in this documentation as Classic devices.
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."
Product License Registration Portal

When you purchase one or more Classic licenses for Firepower features, you manage them in the Cisco Product
License Registration Portal:
https://cisco.com/go/license
For more information on using this portal, see:
https://slexui.cloudapps.cisco.com/SWIFT/LicensingUI/Quickstart
You will need your account credentials in order to access these links.
Service Subscriptions for Firepower Features (Classic Licensing)

Some features require a service subscription.
A service subscription enables a specific Firepower feature on a managed device for a set length of time.
Service subscriptions can be purchased in one-, three-, or five-year terms. If a subscription expires, Cisco
notifies you that you must renew the subscription. If a subscription expires for a Classic device, you might
not be able to use the related features, depending on the feature type.
Table 6: Service Subscriptions and Corresponding Classic Licenses
Subscription You Purchase Classic Licenses You Assign in Firepower System
TA Control + Protection (a.k.a. "Threat & Apps," required for system

updates)
TAC Control + Protection + URL Filtering

199
Classic License Types and Restrictions
Subscription You Purchase Classic Licenses You Assign in Firepower System
TAM Control + Protection + Malware
TAMC Control + Protection + URL Filtering + Malware
URL URL Filtering (add-on where TA is already present)
AMP Malware (add-on where TA is already present)
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.
Classic License Types and Restrictions

This section describes the types of Classic licenses available in a Firepower System deployment. The licenses
you can enable on a device depend on its model, version, and the other licenses enabled.
Licenses are model-specific for NGIPSv devices and for ASA FirePOWER modules. You cannot enable a
license on a managed device unless the license exactly matches the device’s model.
There are a few ways you may lose access to licensed features in the Firepower System:
• You can remove Classic licenses from the Firepower Management Center, which affects all of its managed
devices.
• You can disable licensed capabilities on specific managed devices.
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.
Table 7: Firepower System Classic Licenses
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
Protection TA (included with ASA FirePOWER intrusion detection and none no

device) prevention
NGIPSv
file control
Security Intelligence
filtering
Control none (included with ASA FirePOWER user and application control Protection no
device)
NGIPSv

200
Protection Licenses
License You Assign Service Subscription Platforms Granted Capabilities Also Expire
in Firepower System You Purchase Requires Capable?
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,
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

201
URL Filtering Licenses for Classic Devices
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.
URL Filtering Licenses for Classic Devices

URL filtering allows you to write access control rules that determine the traffic that can traverse your network
based on URLs requested by monitored hosts, correlated with information about those URLs. To enable a
URL Filtering license, you must also enable a Protection license. You can purchase a URL Filtering license
for Classic devices as a services subscription combined with Threat & Apps (TAC) or Threat & Apps and
Malware (TAMC) subscriptions, or as an add-on subscription (URL) for a system where Threat & Apps (TA)
is already enabled.
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,
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.
Malware Licenses for Classic Devices

A Malware license allows you to perform Cisco Advanced Malware Protection (AMP) with AMP for Networks
and Cisco Threat Grid. You can use managed devices to detect and block malware in files transmitted over
your network. To enable a Malware license, you must also enable Protection. You can purchase a Malware
license as a subscription combined with Threat & Apps (TAM) or Threat & Apps and URL Filtering (TAMC)
subscriptions, or as an add-on subscription (AMP) for a system where Threat & Apps (TA) is already enabled.
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.

202
View Your Classic Licenses
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.
Before you can deploy an access control policy that includes AMP for Networks configurations, you must
add a Malware license, then enable it on the devices targeted by the policy. If you later disable the license on
the devices, you cannot re-deploy the existing access control policy to those devices.
If you delete all your Malware licenses or they all expire, 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 expires or is deleted, the system can use existing cached file dispositions. After the time
window expires, the system assigns a disposition of Unavailable to those files.
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 1843.
View Your Classic Licenses

Procedure
Do one of the following, depending on your needs:
To View Do This
The Classic licenses that you have added to the Choose System > Licenses > Classic Licenses.
Firepower Management Center and details including
The summary shows the number of licenses you have
their type, status, usage, expiration dates, and the
purchased, followed by the number of licenses that
managed devices to which they are applied.
are in used in parentheses.
The licenses applied to each of your managed devices Choose Devices > Device Management.
License status in the Health Monitor Use the Classic License Monitor health module in a
health policy. For information, see Health Monitoring,
on page 425, including #unique_320 and Creating
Health Policies, on page 437.
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 414 and Adding Widgets
to a Dashboard, on page 417 and Dashboard Widget
Availability by User Role, on page 405.

203
Identify the License Key
Identify the License Key

The license key uniquely identifies the Firepower Management Center in the Cisco License Registration
Portal. It is composed of a product code (for example, 66) and the MAC address of the management port
(eth0) of the Firepower Management Center; for example, 66:00:00:77:FF:CC:88.
You will use the license key in the Cisco License Registration Portal to obtain the license text required to add
licenses to the Firepower Management Center.
Procedure
Step 1 Choose System > Licenses > Classic Licenses.

Step 2 Click Add New License.
Step 3 Note the value in the License Key field at the top of the Add Feature License dialog.
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 204.
This procedure includes the process of generating the actual license text using the license key.
Generate a Classic License and Add It to the Firepower Management Center
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.
Before you begin

• Make sure you have the product activation key (PAK) from the Software Claim Certificate that Cisco
provided when you purchased the license. If you have a legacy, pre-Cisco license, contact Support.
• Identify the license key for the Firepower Management Center; see Identify the License Key, on page
204.
• You will need your account credentials to complete this procedure.

204
How to Convert a Classic License for Use on an FTD Device
Procedure
Step 1 Choose System > Licenses > Classic Licenses.

Step 2 Click Add New License.
Step 3 Continue as appropriate:
• If you have already obtained the license text, skip to Step 8.
• If you still need to obtain the license text, go to the next step.
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
For information, see Product License Registration Portal, on page 199.
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.
Step 10 Click Submit License.
What to do next
• Assign the license to a managed device; see Assign Licenses to Managed Devices from the Device
Management Page, on page 207. You must assign licenses to your managed devices before you can use
licensed features on those devices.

You can convert licenses using either the License Registration Portal (LRP) or the Cisco Smart Software
Manager (CSSM), and you can convert an unused Product Authorization Key (PAK) or a Classic license that
has already been assigned to a device.

205
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.
In documentation on Cisco.com, Classic licenses may also be referred to as "traditional" licenses.
Before you begin

• It is easiest to convert a Classic license to a Smart License when it is still an unused PAK that has not
yet been assigned to a product instance.
• Your hardware must be able to run Firepower Threat Defense. See the Cisco Firepower Compatibility
Guide at https://www.cisco.com/c/en/us/support/security/defense-center/
products-device-support-tables-list.html.
• You must have a Smart Account. If you do not have one, create one. See Create a Smart Account to Hold
Your Licenses, on page 171.
• The PAKs or licenses that you want to convert must appear in your Smart Account.
• If you convert using the License Registration Portal instead of the Cisco Smart Software Manager, you
must have your Smart Account credentials in order to initiate the conversion process.
Procedure
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.
• To convert PAKs or licenses using CSSM:

• Converting Hybrid Licenses to Smart Software Licenses QRG:

206
Assign Licenses to Managed Devices from the Device Management Page
https://community.cisco.com/t5/licensing-enterprise-agreements/
converting-hybrid-licenses-to-smart-software-licenses-qrg/ta-p/3628609?attachment-id=134907
• Sign in to CSSM at https://software.cisco.com/#SmartLicensing-LicenseConversion and follow the
instructions for your type of conversion (PAK or installed Classic license) in the documentation
above.
Step 3 Freshly install Firepower Threat Defense on your hardware.

See the instructions for your hardware at https://www.cisco.com/c/en/us/support/security/firepower-ngfw/
products-installation-guides-list.html.
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 192.
b) Verify that the new Smart License has been successfully applied to the device.
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 160. (Skip any steps that do not apply or that
you have already completed.)
Assign Licenses to Managed Devices from the Device

Management Page
Although there are some exceptions, you cannot use the features associated with a license if you disable it on
a managed device.
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.

207
License Expiration
Before you begin

• Add your devices to the Firepower Management Center. See Add a Device to the FMC, on page 355.
• You must have Admin or Network Admin privileges to perform this task. When operating with multiple
domains, you must do this task in leaf domains.
• If you will assign Smart Licenses:
• If you need to apply Smart Licenses to many devices at one time, use the Smart Licenses page
instead of following this procedure. See Assign Licenses to Multiple Managed Devices, on page
192
• Prepare Smart Licenses for distribution to managed devices: See Register Smart Licenses, on page
174
Procedure
Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to assign or disable a license, click Edit ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.
Step 3 Click Device.

Step 4 Next to the License section, click Edit ( ).
Step 5 Check or clear the appropriate check boxes to assign or disable licenses for the device.
Step 6 Click Save.
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.
• 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

208
License Expiration
• Specific License Reservation

• Classic Licensing
• Subscription Renewals
License Expiration vs. Service Subscription Expiration

Q. Do Firepower feature licenses expire?
A. Strictly speaking, Firepower feature licenses do not expire. Instead, the service subscriptions that support
those licenses expire. For details about service subscriptions, see "Service Subscriptions for Firepower
Features" in the Firepower Management Center Configuration Guide available from
https://www.cisco.com/c/en/us/support/security/defense-center/
products-installation-and-configuration-guides-list.html.
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.

209
License Expiration
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.
Specific License Reservation

Q. What happens if my Specific License Reservation expires?
A. SLR licenses are term-based.
If required licenses are unavailable or expired, the following actions are restricted:
• Device registration
• Policy deployment
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:
Table 8: Expiration Impact for Classic Licenses/Subscriptions
Classic License Possible Supporting Expiration Impact

Subscriptions
Control TA, TAC, TAM, TAMC You can continue to use existing Firepower
functionality, but you cannot download VDB updates,
including application signature updates.

210
Other Licensing Information in This Guide
Classic License Possible Supporting Expiration Impact

Subscriptions
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.
• The system stops querying the AMP cloud, and

stops acknowledging retrospective events sent from
the AMP cloud.
• You cannot re-deploy existing access control
policies if they include AMP for Firepower
configurations.
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.

For See
Information about the interface for FMC About Device Management Interfaces, on page 343
communications with the Smart Licensing authority and subtopics
Firewall requirements for licensing Internet Access Requirements, on page 3032

211
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. 24
Important licensing considerations when restoring Backup and Restore, on page 257
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 1639
• Access Control Rule Components, on page 1640,
information about Conditions
• TLS/SSL Rule Guidelines and Limitations, on
page 1783
• TLS/SSL Rule Components, on page 1759
• Rate Limiting with QoS Policies, on page 898
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 596
Licensing requirements for SSL Prerequisites in Configure SSL Settings , on page 1437
for Firepower Threat Defense
Licensing requirements for SSL preprocessor The SSL Preprocessor, on page 2247
functionality
Licensing for AMP for Endpoints integrations Comparison of Malware Protection: Firepower vs.
AMP for Endpoints, on page 1875
Licensing and stream reassembly on client and server TCP Stream Preprocessing Options, on page 2289
services
Licensing and Cisco Threat Intelligence Director Platform, Element, and License Requirements, on
(TID) page 1890
Licensing impacts on connection events Requirements for Populating Connection Event Fields,
on page 2835
Information about the Licensing and other dashboard Dashboard Widget Availability by User Role, on page
widgets 405
The Custom Analysis Widget, on page 408
Information about the Health Monitor for licensing. Information about the Smart License Monitor and the
Classic License Monitor in #unique_320

212
Additional Information about Firepower Licensing
Additional Information about Firepower Licensing

For additional information to help resolve common licensing questions, see the following documents:
• The Frequently Asked Questions (FAQ) about Firepower Licensing document at:
https://www.cisco.com/c/en/us/td/docs/security/firepower/licensing/faq/firepower-license-FAQ.html
• The Cisco Firepower System Feature Licenses document at:
https://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/firepower-licenseroadmap.html
Cisco Success Network

Cisco Success Network is a user-enabled cloud service. When you enable Cisco Success Network, a secure
connection is established between the Firepower Management Center and the Cisco cloud to stream usage
information and statistics. Streaming telemetry provides a mechanism to select data of interest from the
Firepower System and to transmit it in a structured format to remote management stations for the following
benefits:
• To inform you of available unused features that can improve the effectiveness of the product in your
network.
• To inform you of additional technical support services and monitoring that might be available for your
product.
• (If you integrate with SecureX) To summarize appliance and device status in SecureX tiles. This lets
you see at a glance, for example, whether all of your devices are running optimal software versions.
For more information about SecureX, see Integrate with Cisco SecureX, on page 2695.
• To help Cisco improve our products.
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.
Enabling Cisco Success Network

You enable Cisco Success Network when you register the Firepower Management Center with the Cisco
Smart Software Manager. See Register Smart Licenses, on page 174.
You can view your current Cisco Success Network enrollment status on the Licences > Smart Licenses page,
and you can change your enrollment status. See Changing Cisco Success Network Enrollment, on page 227.

213
Cisco Success Network Telemetry Data
Note The Cisco Success Network feature is disabled if the Firepower Management Center has a valid Smart Software
Manager On-Prem (formerly known as Smart Software Satellite Server) configuration, or uses Specific License
Reservation.
Cisco Success Network Telemetry Data

Cisco Success Network allows enrolled Firepower Management Centers to continuously stream real time
configuration and operating state information to the Cisco Success Network cloud. Collected and monitored
data include the following:
• Enrolled device information—This includes the Firepower Management Center device name, model,
serial number, UUID, system uptime, and Smart Licensing information; see Enrolled Device Data, on
page 214.
• Software information—This includes software information about the enrolled Firepower Management
Center, such as version number, rule update version, geolocation database version, and vulnerability
database (VDB) version information; see Software Version Data, on page 215.
• Managed device information—This includes information about all the managed devices associated
with the enrolled Firepower Management Center, including device names, device models, serial numbers,
software versions, and licenses in use per device; see Managed Device Data, on page 215.
• Deployment information—This includes information about policy deploymnents. After you configure
your deployment, and any time you change that configuration, you must deploy the changes to affected
devices; see Deployment Information, on page 216.
• Feature usage—This includes feature-specific policy and licensing information:
• URL filtering—This includes how many URL filtering licenses are configured and deployed to
devices, and how many devices have policies deployed that are using the URL filtering capability.
• Intrusion prevention—This includes how many managed devices are configured for intrusion
prevention,and whether a device has been enabled for Threat Intelligence Director (TID).
• Malware detection— This includes how many malware licenses are configured and deployed to
devices, and how many devices have policies deployed that are using the malware detection capability.
Enrolled Device Data

Once you enroll the Firepower Management Center in Cisco Success Network, select telemetry data about
the enrolled Firepower Management Center device is streamed to the Cisco cloud. The following table describes
the collected and monitored data about the enrolled device. This includes feature-specific information about
instrusion policies (both system-provided and custom) and malware detection for enrolled Firepower
Management Centers.
Table 9: Enrolled Device Telemetry Data
Data Point Example Value

Device Name Management Center East

214
Software Version Data

Device UUID 24fd0ccf-1464- 491f-a503- d241317bb327
HA Peer UUID 24fe0ccd-1564- 491h-b802- d321317cc827
Device Model Cisco Firepower Management Center for VMWare
Serial Number 9AMDESQP6UN
System Uptime 99700000
Product Identifier FS-VMW-SW-K9
Smart License PIID 24fd0ccf-1464- 491f-a503- d241317bb327
Virtual Account Identifier CiscoSVStemp
Software Version Data

Cisco Success Network collects software information that pertains to the enrolled Firepower Management
Center device, including software version, rule update version, geolocation database version, and vulnerability
database version information. The following table describes the collected and monitored software information
about the enrolled device.
Table 10: Software Version Telemetry Data

Firepower Management Center Software Version { type: "SOFTWARE", version: "6.2.3-10517" }
Rule Update Version { type: "SNORT_RULES_DB", version:

"2016-11-29-001-vrt", lastUpdated: 1468606837000
}
Vulnerability Database (VDB) Version { type: "VULNERABILITY_DB", version: "271",

lastUpdated: 1468606837000 }
Geolocation Database Version { type: "GEOLOCATION_DB", version: "850" }
Managed Device Data

Cisco Success Network collects information about all the managed devices associated with an enrolled
Firepower Management Center. The following table describes the collected and monitored information about
managed devices. This includes feature-specific policy and licensing information, such as URL filtering,
intrusion prevention, and malware detection for managed devices.
Table 11: Managed Device Telemetry Data

Managed Device Name firepower
Managed Device Version 6.2.3-10616

215
Deployment Information

Managed Device Manager FMC
Managed Device Model Cisco Firepower 2130 NGFW Appliance

Cisco Firepower Threat Defense VMware
Managed Device Serial Number 9AMDESQP6UN
Managed Device PID FPR2130-NGFW-K9

NGFWv
Is URL Filtering License Used for Device? True
AC Rules with URL Filtering Per Device 10
Number of AC Rules with URL Filtering That Use 3

URL Filtering License
Number of AC Rules with URL Filtering That Use 3

Threat License
Is Threat License Used for Device? True
Does AC Policy Have Intrusion Rule Attached? True
Number of AC Rules with Intrusion Policies 10
Is Malware License Used for Device? True
Number of AC Rules with Malware Policy 10
Number of AC Rules with Malware Policy That Use 5

Malware License
Is Threat Intelligence Director (TID) Used for Device? True
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.
Table 12: Deployment Information

Job ID 8589936079
Number of Devices Selected for Deployment 3
Number of Devices with Deployment Failure 1

216
TLS/SSL Inspection Event Data

Number of Devices with Deployment Success 2
End Time 1523993913001
Start Time 1523993840445
Status SUCCEEDED
Target Device UUID 4f14f644-41e0 -11e8-9354- cf32315d7095
Policy Types Deployed NetworkDiscovery

NGFWPolicy
DeviceConfiguration
Last Deployment Job ID Collected in Current Run 8589936079
Container Type (Standalone or HA Pair) STANDALONE

HAPAIR
Container UUID 5e006633-30fe-11e9-8a70-cd88086eeac0
Device Model Cisco Firepower Threat Defense for VMWare
Device Version 6.4.0
Policy Bundle Size 3588153

By default, the Firepower System cannot inspect traffic encrypted with the Secure Socket Layer (SSL) protocol
or its successor, the Transport Layer Security (TLS) protocol. TLS/SSL inspection enables you to either block
encrypted traffic without inspecting it, or inspect encrypted or decrypted traffic with access control. The
following tables describe statistics.shared with Cisco Success Network about encrypted traffic.
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.
Table 13: TLS/SSL Inspection - Handshake Telemetry Data

The system reports the following applied actions when
the traffic cannot be decrypted and is:
• Blocked
An integer value of 0 or greater
• Blocked with a TCP reset
• Not decrypted

217

The system reports the following applied actions when
the traffic can be decrypted:
• With a known private key
• With a replacement key only An integer value of 0 or greater
• By resigning a self-signed certificate

• By resigning the server certificate
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.
Table 14: TLS/SSL Inspection - Cache Telemetry Data

The system caches encrypted session data and server
certificate data, and reports on the cache per SSL
connections, specifically:
• The number of times SSL session information
was cached
• The number of times the SSL certificate
validation cache was hit
• The number of times the SSL certificate
validation cache lookup missed
• The number of times the SSL original certificate
cache was hit
• The number of times the SSL original certificate
cache lookup missed
• The number of times the SSL resigned certificate
cache was hit
• The number of times the SSL resigned certificate
cache lookup missed
Certificate Status
The system evaluates encrypted traffic and reports the certificate status of the encrypting server.

218
Table 15: TLS/SSL Inspection - Certificate Status Telemetry Data

The system evaluates encrypted traffic based on the
certificate status of the encrypting server, and reports
the number of connections where the SSL Certificate:
• Is valid
• Is expired
• Has an invalid issuer
• Has an invalid signature An integer value of 0 or greater
• Is not checked
• Is not yet valid
• Is revoked
• Is self signed
• Is unknown
Failure Reason
The system evaluates encrypted traffic and reports the failure reason when the system fails to decrypt traffic.
Table 16: TLS/SSL Inspection - Failure Telemetry Data

The system evaluates encrypted traffic and reports
the failure reason when the system fails to decrypt
traffic due to:
• A decryption error
• Making a policy verdict during the handshake
• Making a policy verdict before the handshake
• Compression being negotiated
• An uncached session
• An interface in passive mode
• An unknown cipher suite
• An unsupported cipher suite
Version
The system evaluates encrypted traffic and reports the negotiated TLS/SSL version per connection.

219
Snort Restart Data
Table 17: TLS/SSL Inspection - Version Telemetry Data

The system evaluates encrypted traffic and reports
the negotiated version per SSL connections where:
• SSLv2 was negotiated
• SSLv3 was negotiated
• An unknown version was negotiated
• TLSv1.0 was negotiated
Snort Restart Data

When the traffic inspection engine referred to as the Snort process on a managed device restarts, inspection
is interrupted until the process resumes. Creating or deleting a user-defined application, or activating or
deactivating a system or custom application detector immediately restarts the Snort process without going
through the deploy process. The system 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.
Table 18: Snort Restart Telemetry Data

Count of snort restarts when you enable or disable a An integer value of 0 or greater
custom application detector
Count of snort restarts when you create or modify a An integer value of 0 or greater
custom application detector
Snort3 Data
The following table describes the collected and monitored data about the Snort3 process. This includes
session-specific information about packet performance monitoring with respect to TCP/IP and other network
protocols.
Table 19: Snort3 Telemetry Data

Count of the number of sessions pruned due to a full An integer value of 0 or greater
cache or flow memory capacity was reached.
Count of the number of sessions for which Snort did An integer value of 0 or greater
not see the start of the flow.

220
Snort3 Data

The system reports the following counts related to
packet performance monitoring used to determine the
basic level of latency:
• The number of packets that exceeded the total
detection time threshold
• The number of packets that exceeded the rule
threshold
• The total time spent in detection
• The maximum time that a packet spent in
detection
• The number of rule trees that exceeded the rule
threshold
• The total number of rules evaluated
• The number of rules that are re-enabled post
suspension
The maximum number of TCP sessions An integer value of 0 or greater
The number of TCP data bytes processed An integer value of 0 or greater
The maximum number of UDP sessions An integer value of 0 or greater
The number of UDP data bytes processed An integer value of 0 or greater
The maximum number of IP sessions (non An integer value of 0 or greater

ICMP/UDP/TCP)
The number of IP data bytes processed (non An integer value of 0 or greater

ICMP/UDP/TCP)
The maximum number of FTP sessions An integer value of 0 or greater
The number of FTP data bytes processed An integer value of 0 or greater
The maximum number of HTTP sessions An integer value of 0 or greater
The maximum number of SMTP sessions An integer value of 0 or greater
The number of SMTP data bytes processed An integer value of 0 or greater
The maximum number of POP sessions An integer value of 0 or greater
The number of POP data bytes processed An integer value of 0 or greater
The maximum number of SSH sessions An integer value of 0 or greater
The number of SSH data bytes processed An integer value of 0 or greater

221
Contextual Cross-Launch Data

The number of SSL packets processed An integer value of 0 or greater
The number of SSL packets ignored An integer value of 0 or greater
The maximum number of SSL sessions An integer value of 0 or greater
The maximum number of HTTP/2 sessions An integer value of 0 or greater
The maximum number of HTTP/2 data bytes An integer value of 0 or greater

processed (total_bytes)
The maximum number of HTTP data bytes processed An integer value of 0 or greater
(total_bytes)
The data collection start time (in Unix Epoch format) An integer string
Contextual Cross-Launch Data

The contextual cross-launch feature allows you to quickly find more information about potential threats in
web-based resources outside of the Firepower Management Center. You can click directly from an event in
the event viewer or dashboard in the FMC to the relevant information in an external resource. This lets you
quickly gather context around a specific event based on its IP addresses, ports, protocol, domain, and/or SHA
256 hash.
Table 20: Contextual Cross-Launch Telemetry Data

The count of the Contextual Cross-Launch resources An integer value of 0 or greater
configured on the FMC
The count of the Contextual Cross-Launch resources An integer value of 0 or greater

enabled on the FMC
The count of Contextual Cross-Launch instances An integer value of 0 or greater

containing a domain variable

containing an IP variable

containing a SHA 256 variable
Telemetry Example File

The following is an example of a Cisco Success Network telemetry file for streaming policy and deployment
information about a Firepower Management Center and its managed devices:
{
"recordType" : "CST_FMC",
"recordVersion" : "6.4.0",

222
"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" : {

223

"deviceName" : "10.10.17.221",
"serialNumber" : "9A0NMB3VAL7"
},
"malware" : {
"malwareLicenseUsed" : false,
},
"sslUsage" : {
},
"threat" : {
"acPolicyHasIntrusion" : false,
"isTIDEnabled" : false,
"threatLicenseUsed" : false
},
"urlFiltering" : {
"urlFilteringLicenseUsed" : false
}
}, {
"deviceInfo" : {
"deviceName" : "10.10.17.222",
"serialNumber" : "9ATSKTCFNXA"
},
"malware" : {
"malwareLicenseUsed" : true,
},
"sslUsage" : {
},
"threat" : {
},
"urlFiltering" : {
}
}, {
"deviceInfo" : {
"deviceName" : "10.10.17.223",
"serialNumber" : "9AP4B2J9BC1"
},
"malware" : {
"malwareLicenseUsed" : true,
},
"sslUsage" : {

224
},
"threat" : {
},
"urlFiltering" : {
}
} ]
},
"deploymentData" : {
"deployJobInfoList" : [ {
"jobDeviceList" : [ {
"containerType" : "STANDALONE",
"deployEndTime" : "1550466953538",
"deployStartTime" : "1550466890057",
"deployStatus" : "SUCCEEDED",
"deviceOSVersion" : "6.4.0",
"deviceUuid" : "8918db92-30de-11e9-a576-92cc6a3b249d",
"pgTypes" : "[PG.FIREWALL.NGFWAccessControlPolicy]",
"policyBundleSize" : 3588153
}, {
"containerType" : "STANDALONE",
"deployEndTime" : "1550466953634",
"deviceUuid" : "87cf54e6-30de-11e9-8fdb-ce9d0fc91a42",
}, {
"containerID" : "5f009744-30fe-11e9-8a70-cd88086eeac0",
"containerType" : "HAPAIR",
"deployEndTime" : "1550467052791",
"deviceUuid" : "c8df3b96-30ce-11e9-b5e5-d6beeb6498f5",
} ],
"jobId" : "12884903350",
"numberOfDevices" : 3,
"numberOfFailedDevices" : 0,
"numberOfSuccessDevices" : 3
} ],
"lastJobId" : "12884903350"
},
"cspa" : {
"cspaCount" : 0,
"queryCount" : 0,
"queryGroupCount" : 0
},
"analysis" : {
"crossLaunchInfo" : {
"count" : 28,
"enabledCount" : 28,
"iocInfo" : [ {

225
"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
}
}

226
Changing Cisco Success Network Enrollment
Changing Cisco Success Network Enrollment

You enable Cisco Success Network when you register the Firepower Management Center with the Cisco
Smart Software Manager. After that, use the following procedure to view or change enrollment status.
Note Cisco Success Network does not work in evaluation mode.
Procedure
Step 1 Click System > Licenses > Smart Licenses.

Step 2 Under Smart License Status, next to Cisco Success Network, click Enabled/Disabled control for the Cisco
Success Network feature to change the setting as appropriate.
Step 3 Read the information provided by Cisco, choose whether you want to Enable Cisco Success Network, and
click Apply Changes.
What to do next
(Optional) See (Optional) Opt Out of Web Analytics Tracking, on page 1405.
Cisco Support Diagnostics

Cisco Support Diagnostics is a user-enabled cloud-based TAC support service. When enabled, a secure
connection is established between the Firepower Management Center (FMC), and Firepower Threat Defense
(FTD) on one side and the Cisco cloud on the other side, to stream system health related information.
Cisco Support Diagnostics provides an enhanced user experience during troubleshooting by allowing Cisco
TAC to securely collect essential data from your device during a TAC case. Moreover, operational health
data is periodically collected and processed through Cisco's automated problem detection system to proactively
notify you of any issues. While the data collection service during a TAC case is available for all users with
support contracts, the proactive notification service is only available to users with specific service contracts.
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 these features from the Cisco cloud. However,
when Cisco Support Diagnostics is enabled, a secure connection is established and maintained between the
FTD and the Cisco cloud along with the FMC and Cisco cloud. Therefore, when the Cisco Support Diagnostics
is disabled both these secure connections are turned off.
Administrators can view a sample data set which is collected from the FMC by following the steps in Producing
Troubleshooting Files for Specific System Functions, on page 505 to generate a troubleshooting file, and then
by opening the file to view it.
The FMC sends the collected data to the regional cloud specified on the System > Integration > Cloud
Services page. Note that this setting is also used for Cisco Support Network, described at Cisco Success

227
Changing Cisco Support Diagnostics Enrollment
Network, on page 213, and the Cisco Threat Response integration described at Event Analysis with Cisco
SecureX threat response, on page 2696.
Enabling Cisco Support Diagnostics

You enable Cisco Support Diagnostics when you register the Firepower Management Center with the Cisco
Smart Software Manager. See Register Smart Licenses, on page 174.
You can view your current Cisco Support Diagnostics enrollment status on the Licenses > Smart Licenses
page, and you can change your enrollment status. SeeChanging Cisco Support Diagnostics Enrollment, on
page 228.
Changing Cisco Support Diagnostics Enrollment

You enable Cisco Support Diagnostics when you register the Firepower Management Center with the Cisco
Smart Software Manager. After that, use the following procedure to view or change enrollment status.
Procedure
Step 1 Click System > Licenses > Smart Licenses.

Step 2 Under Smart License Status, next to Cisco Support Diagnostics, click Enabled/Disabled control to change
the setting as appropriate.
Note Read the information provided next to the Enabled/Disabled control before you proceed.
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.
End-User License Agreement

The Cisco end-user license agreement (EULA) and any applicable supplemental agreement (SEULA) that
governs your use of this product are available from http://www.cisco.com/go/softwareterms.
History for Licensing

Performance tier licensing 7.0 Performance-tiered licensing provides different throughput levels and VPN connection
for the FTDv limits based on deployment requirements. License tiers map to new FTDv models; see
FTDv Licensing, on page 197.

228
Snort3 telemetry data for 7.0 Packet performance monitoring data with respect to TCP/IP and other network protocols;
Cisco Success Network see Snort3 Data, on page 220.
Virtual FMC (FMCv) in a 6.7 See License Requirements for FMC High Availability Configurations, on page 328.
high availability pair
Cisco Support Diagnostics 6.6. Cisco Support Diagnostics is now fully supported on all FMCs and FTD devices.
on additional FTD platforms Previously, support was limited to FMCs, Firepower 4100/9300 with FTD, and FTDv
for Azure.
Supported platforms: FMC, FTD
Cisco Support Diagnostics 6.5 Cisco Support Diagnostics (sometimes called Cisco Proactive Support) sends
configuration and operational health data to Cisco, and processes that data through our
automated problem detection system, allowing us to proactively notify you of issues.
This feature also allows Cisco TAC to collect essential information from your devices
during the course of a TAC case.
During upgrades and reimages, you may be asked to enroll. You can also change your
enrollment at any time. For details, see Cisco Support Diagnostics, on page 227.
In Version 6.5.0, Cisco Support Diagnostics support is limited to select platforms.
New/Modified screens: System > Licenses > Smart Licenses
Supported platforms: FMC, Firepower 4100/9300, FTDv for Azure
Enabling Cisco Success 6.4 For general information about the SecureX integration, see Integrate with Cisco SecureX,
Network allows SecureX to on page 2695 and the information linked from that topic.
display appliance and device
status information
Licensing for multi-instance 6.3 You can now deploy multiple FTD container instances on a Firepower 4100/9300. You
capability for the FTD on only need a single license per feature per security module/engine. The base license is
the Firepower 4100/9300 automatically assigned to each instance.
New/Modified screens: System > Licenses > Smart Licenses
Supported platforms: FTD on the Firepower 4100/9300
Specific License 6.3 Customers whose deployments cannot connect to the internet to communicate with the
Reservation for air-gapped Cisco License Authority can use a Specific License Reservation. For details, see: Specific
deployments License Reservation (SLR), on page 179.
New/Modified screens: System > Licenses > Specific Licenses (This option is not
available by default.)
Export-controlled 6.3 Certain customers whose Smart Accounts are not otherwise eligible to use restricted
functionality for restricted functionality can purchase term-based licenses, with approval. For details, see: Enabling
customers the Export Control Feature (for Accounts Without Global Permission), on page 175.

229

230
CHAPTER 7
System Updates
The following topics explain how to update Firepower deployments:
• About System Updates, on page 231
• Requirements and Prerequisites for System Updates, on page 233
• Guidelines and Limitations for System Updates, on page 233
• Upgrade System Software, on page 234
• Update the Vulnerability Database (VDB), on page 237
• Update the Geolocation Database (GeoDB), on page 239
• Update Intrusion Rules, on page 241
• Maintain Your Air-Gapped Deployment, on page 250
• History for System Updates, on page 250
About System Updates

You can use the FMC to upgrade the system software for itself and the devices it manages. You can also
update various databases and feeds that provide advanced services.
For FMCs with internet access, the system can often obtain updates directly from Cisco. We recommend you
schedule or enable automatic updates whenever possible. Some updates are auto-enabled by the initial setup
process or when you enable the related feature. Other updates you must schedule yourself. After initial setup,
we recommend you review all auto-updates and adjust them if necessary.

231
About System Updates
Table 21: Upgrades and Updates in FMC Deployments
Component Description Details
Firepower software Major software releases contain new Direct Download: Select releases only, usually some time after
features, functionality, and enhancements. the release is available for manual download. The length of the
They may include infrastructure or delay depends on release type, release adoption, and other
architectural changes. factors.
Maintenance releases contain general bug Schedule: Patches only, on System > Tools > Scheduling.
and security related fixes. Behavior changes
Uninstall: Patches only.
are rare, and are related to those fixes.
Reimage: Major and maintenance releases only.
Patches are on-demand updates limited to
critical fixes with time urgency. See: Upgrade System Software, on page 234
Hotfixes can address specific customer
issues.
Vulnerability database The Cisco vulnerability database (VDB) is Direct Download: Yes.
(VDB) a database of known vulnerabilities to
Schedule: Yes, on System > Tools > Scheduling.
which hosts may be susceptible, as well as
fingerprints for operating systems, clients, Uninstall: No.
and applications. The system uses the VDB
See: Update the Vulnerability Database (VDB), on page 237
to help determine whether a particular host
increases your risk of compromise.
Geolocation database The Cisco geolocation database (GeoDB) Direct Download: Yes.
(GeoDB) is a database of geographical and
Schedule: Yes, on System > Updates.
connection-related data associated with
routable IP addresses. Uninstall: No.
See: Update the Geolocation Database (GeoDB), on page 239
Intrusion rules Intrusion rule updates provide new and Direct Download: Yes.
(SRU/LSP) updated intrusion rules and preprocessor
Schedule: Yes, on System > Updates.
rules, modified states for existing rules, and
modified default intrusion policy settings. Uninstall: No.
Rule updates may also delete rules, provide See: Update Intrusion Rules, on page 241
new rule categories and default variables,
and modify default variable values.
Security Intelligence Security Intelligence feeds are collections Direct Download: Yes.
feeds of IP addresses, domain names, and URLs
Schedule: Yes, on Objects > Object Management.
that you can use to quickly filter traffic that
matches an entry. Uninstall: No.
See: List and Feed Updates for Security Intelligence, on page
644

232
Requirements and Prerequisites for System Updates
Component Description Details
URL categories and URL filtering allows you to control access Direct Download: Yes.
reputations to websites based on the URL’s general
Schedule: Yes, on System > Integration > Cloud Services
classification (category) and risk level
or System > Tools > Scheduling, depending on your
(reputation).
requirements.
Uninstall: No.
See: Enable URL Filtering Using Category and Reputation, on
page 1662
Requirements and Prerequisites for System Updates

Model Support
Any
Supported Domains
Global unless indicated otherwise.
User Roles
Admin
Guidelines and Limitations for System Updates

Before You Update
Before you update any component of your Firepower deployment (including intrusion rules, VDB, or GeoDB)
read the release notes or advisory text that accompanies the update. These provide critical and release-specific
information, including compatibility, prerequisites, new capabilities, behavior changes, and warnings.
Scheduled Updates
The system schedules tasks — including updates — in UTC. This means that when they occur locally depends
on the date and your specific location. Also, because updates 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 updates occur one hour "later" in the summer than in the winter, according to
local time.
Important We strongly recommend you review scheduled updates to be sure they occur when you intend.

233
Upgrade System Software
Bandwidth Guidelines
To upgrade a Firepower appliance (or perform a readiness check), the upgrade package must be on the
appliance. Firepower upgrade package sizes vary. Make sure you have the bandwidth to perform a large data
transfer to your managed devices. See Guidelines for Downloading Data from the Firepower Management
Center to Managed Devices (Troubleshooting TechNote).
Upgrade System Software

Upgrading a Firepower deployment can be a complex process. Careful planning and preparation can help you
avoid missteps. These are as much a part of the upgrade process as actually performing the mechanical steps
that invoke the upgrade scripts.
This guide does not contain detailed upgrade instructions for either system software or companion operating
systems. Instead, see the Cisco Firepower Management Center Upgrade Guide.
This guide does currently contain:
• An overview of the Firepower Threat Defense upgrade process: Upgrade Firepower Threat Defense, on
page 234.
• Information on scheduling downloads and installations for system software patches: Software Update
Automation, on page 303.
Note that the initial setup process automatically schedules a weekly patch download. After setup, you
should review the auto-scheduled configurations and adjust them if necessary.
Upgrade Firepower Threat Defense

Use the Device Upgrade page (Devices > Device Upgrade) to upgrade Firepower Threat Defense devices.
Note You must still use the System Updates page (System > Updates) page to upload or specify the location of
Firepower Threat Defense upgrade packages. You must also use the System Updates page to upgrade the
Firepower Management Center itself, as well as all non-Firepower Threat Defense managed devices: ASA
FirePOWER, and NGIPSv.
The Device Upgrade page has two panes: Device Selection on the left, and Device Details on the right. Click
a device link in the Device Selection (such as '4 devices') to show the Device Details for those devices.
As you proceed through the upgrade workflow, the Device Details pane displays basic information about your
selected devices, as well as the current upgrade-related status. This includes any reasons why you cannot
upgrade. If a device does not "pass" a stage in the workflow, it does not appear in the next stage.

234
Note The Device Upgrade page does not correctly display devices in clusters or high availability pairs. Even though
you must select and upgrade these devices as a unit, the workflow displays them as standalone devices. Device
status and upgrade readiness are evaluated and reported on an individual basis. This means it is possible for
one unit to appear to "pass" to the next stage while the other unit or units do not. However, these devices are
still grouped. Running a readiness check on one, runs it on all. Starting the upgrade on one, starts it on all.
To avoid possible time-consuming upgrade failures, manually ensure all group members are ready to move
on to the next step of the workflow before you click Next.
If you navigate away from the Device Upgrade page, your progress is preserved, although other users with
Administrator access can reset, modify, or continue the workflow (unless you logged in with a CAC, in which
case the upgrade workflow resets 24 hours after you log out). Upgrade workflow status is also synchronized
between high availability FMCs.
Before you begin

Complete the pre-upgrade checklist. Make sure the appliances in your deployment are healthy and successfully
communicating.
Tip You can find detailed upgrade instructions — including the pre-upgrade checklist — in the Cisco Firepower
Management Center Upgrade Guide.
Procedure
Select devices to upgrade.

Step 2 Select the devices you want to upgrade.
You can upgrade multiple devices at once. You must upgrade the members of device clusters and high
availability pairs at the same time.
Important Due to performance issues, if you are upgrading FTD to (not from) Version 6.4.0.x through 6.6.x,
we strongly recommend upgrading no more than five devices simultaneously.
Step 3 From the Select Action or Select Bulk Action menu, select Upgrade Firepower Software.
The Device Upgrade page appears, indicating how many devices you selected and prompting you to select a
target version.
Note that if there is already an upgrade workflow in process, you must first either Merge Devices (add the
newly selected devices to the previously selected devices and continue) or Reset (discard the previous selections
and use only the newly selected devices).
Step 4 Verify your device selection.

To select additional devices, go back to the Device Management page—your progress will not be lost. To
remove devices, click Reset to clear your device selection and start over.
Copy upgrade packages to devices.

235
Step 5 From the Upgrade to menu, select your target version.

The system determines which of your selected devices can be upgraded to that version. If any devices are
ineligible, you can click the device link to see why. You do not have to remove ineligible devices if you don't
want to; they will just not be included in the next step.
Note that the choices in the Upgrade to menu correspond to the device upgrade packages available to the
system. If your target version is not listed, go back to System > Updates and upload or specify the location
of the correct upgrade package.
Step 6 For all devices that still need an upgrade package, click Copy Upgrade Packages, then confirm your choice.
To upgrade Firepower software, the software upgrade package must be on the appliance. Copying the upgrade
package before upgrade reduces the length of your upgrade maintenance window.
Run compatibility and readiness checks.

Step 7 Click Next.
Compatibility checks are automatic. For example, the system alerts you immediately if you need to upgrade
FXOS on the Firepower 4100/9300, or if you need to deploy to managed devices. However, you must manually
run readiness checks.
Although you can skip checks by disabling the Require passing compatibility and readiness checks option,
we recommend against it. Passing all checks greatly reduces the chance of upgrade failure.
Step 8 For all devices that still need to pass the readiness check, click Run Readiness Check, then confirm your
choice.
Do not manually reboot, or shut down an appliance running readiness checks. If your appliance fails the
readiness check, correct the issues and run the readiness check again. If the readiness check exposes issues
that you cannot resolve, do not begin the upgrade. Instead, contact Cisco TAC.
Perform other final checks and pre-upgrade actions.

Step 9 (Optional, high availability only) Switch the active/standby roles of your high availability device pairs.
The standby device in a high availability pair upgrades first. The devices switch roles, then the new standby
upgrades. When the upgrade completes, the devices' roles remain switched. If you want to preserve the
active/standby roles, manually switch the roles before you upgrade. That way, the upgrade process switches
them back.
Choose Devices > Device Management, click the Switch Active Peer icon next to the pair, and confirm your
choice.
Step 10 Perform final pre-upgrade checks.

Revisit the pre-upgrade checklist. Make sure you have completed all relevant tasks, especially the final checks.
Upgrade.
Step 11 If necessary, return to the Device Upgrade page.
Your progress should have been preserved. If it was not, someone else with Administrator access may have
reset, modified, or completed the workflow.
Step 12 Click Next.

Step 13 Verify your device selection and target version.
Step 14 Click Start Upgrade, and confirm your choice.

236
Update the Vulnerability Database (VDB)
Do not deploy configurations to the device while it is upgrading. Even if the system shows no progress for
several minutes or indicates that the upgrade has failed, do not restart the upgrade or reboot the device. Instead,
contact Cisco TAC.
Some devices may reboot twice during the upgrade; this is expected behavior.
Traffic either drops throughout the upgrade or traverses the network without inspection depending on how
your devices are configured and deployed..
Step 15 Monitor upgrade progress.

Do not deploy configurations to the device while it is upgrading.
Verify success and complete post-upgrade tasks.

Step 16 Verify upgrade success.
After the upgrade completes, choose Devices > Device Management and confirm that the devices you
upgraded have the correct software version.
Step 17 Update intrusion rules (SRU/LSP) and the vulnerability database (VDB).
If the component available on the Cisco Support & Download site is newer than the version currently running,
install the newer version. Note that when you update intrusion rules, you do not need to automatically reapply
policies. You will do that later.
Step 18 Complete any post-upgrade configuration changes described in the release notes.
Step 19 Redeploy configurations to the devices you just upgraded.
Update the Vulnerability Database (VDB)

The Cisco vulnerability database (VDB) is a database of known vulnerabilities to which hosts may be
susceptible, as well as fingerprints for operating systems, clients, and applications. The system uses the VDB
to help determine whether a particular host increases your risk of compromise.
Cisco issues periodic updates to the VDB. The time it takes to update the VDB and its associated mappings
on the Firepower Management Center depends on the number of hosts in your network map. As a rule of
thumb, divide the number of hosts by 1000 to determine the approximate number of minutes to perform the
update.
When you set up a new or reimaged FMC, the system automatically attempts to update the vulnerability
database (VDB). This is a one-time operation. If the FMC has internet access, we recommend you schedule
tasks to perform automatic recurring VDB update downloads and installations.
Caution In most cases, the first deploy after updating the VDB restarts the Snort process on managed devices. The
system warns you that this can happen — warnings can appear after manual VDB updates, when you schedule
VDB updates, during background VDB updates, when you deploy, and so on. Snort restarts cause an interruption
in traffic inspection and, depending on how the managed device handles traffic, possibly interrupts traffic
flow. For more information, see Snort® Restart Traffic Behavior, on page 546.

237
Manually Update the VDB
Manually Update the VDB

To update the VDB, the VDB update package must be on the FMC.
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 306.
Before you begin

• Download the update from https://www.cisco.com/go/firepower-software.
• Consider the update's effect on traffic flow and inspection due to Snort restarts. We recommend performing
updates in a maintenance window.
Procedure
Step 1 Choose System > Updates, then click Product Updates.

Step 2 Choose how you want to upload the VDB update to the FMC.
• Download directly from Cisco.com: Click Download Updates. If it can access the Cisco Support &
Download site, the Firepower Management Center downloads the latest VDB. Note that the Firepower
Management Center also downloads a package for each patch and hotfix (but not major release) associated
with the version your appliances are currently running.
• Upload manually: Click Upload Update, then Choose File. Browse to the update you downloaded
earlier, and click Upload.
VDB updates appear on the same page as Firepower software upgrade and uninstaller packages.
Step 3 Install the update.
a) Click Install next to the Vulnerability and Fingerprint Database update.
b) Choose the Firepower Management Center.
c) Click Install.
Step 4 (Optional) Monitor update progress in the Message Center.
Do not perform tasks related to mapped vulnerabilities until the update completes. Even if the Message Center
shows no progress for several minutes or indicates that the update has failed, do not restart the update. Instead,
contact Cisco TAC.
After the update completes, the system uses the new vulnerability information. However, you must deploy
before updated application detectors and operating system fingerprints can take effect.
Step 5 Verify update success.
Choose Help > About to view the current VDB version.
What to do next

238
Schedule VDB Updates
Schedule VDB Updates

If your FMC has internet access, we recommend you schedule regular VDB updates. See Vulnerability
Database Update Automation, on page 306.
Update the Geolocation Database (GeoDB)

The Cisco Geolocation Database (GeoDB) is a database of geographical data (such as country, city, coordinates)
and connection-related data (such as Internet service provider, domain name, connection type) associated with
routable IP addresses. When your system detects GeoDB information that matches a detected IP address, you
can view the geolocation information associated with that IP address. The system comes with an initial GeoDB,
so country and continent information should always be available. However, Cisco issues periodic updates to
the GeoDB, and you must regularly update the GeoDB to have accurate geolocation 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 240.
To update the GeoDB, use the Geolocation Updates page (System > Updates > Geolocation Updates) on
the Firepower Management Center. When you upload GeoDB updates you obtained from Support or from
your appliance, they appear on this page.
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.
Manually Update the GeoDB (Internet Connection)

You can import a new GeoDB update by automatically connecting to the Support Site only if the appliance
has Internet access.
Procedure
Step 1 Choose System > Updates.

Step 2 Click Geolocation Updates.
Step 3 Choose Download and install geolocation update from the Support Site.

239
Manually Update the GeoDB (No Internet Connection)
Step 4 Click Import.

The system queues a Geolocation Update task, which checks for the latest updates on the Cisco Support Site
(http://www.cisco.com/cisco/web/support/index.html).
Step 5 Optionally, monitor the task status; see Viewing Task Messages, on page 498.
Step 6 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.
Manually Update the GeoDB (No Internet Connection)

If your Firepower Management Center does not have Internet access, you can download the GeoDB update
from the Cisco Support Site to a local machine on your network, then manually upload it to your Firepower
Management Center.
Procedure
Step 1 Manually download the update from the Cisco Support Site
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 7 Optionally, monitor the task status; see Viewing Task Messages, on page 498.
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.
Schedule GeoDB Updates

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 this topic.
Before you begin

Make sure the FMC can access the internet.
Procedure
Step 1 Choose System > Updates, then click Geolocation Updates.

Step 2 Under Recurring Geolocation Updates, check Enable Recurring Weekly Updates...
Step 3 Specify the Update Start Time.

240
Update Intrusion Rules
Step 4 Click Save.
Update Intrusion Rules

As new vulnerabilities become known, the Cisco Talos Intelligence Group (Talos) releases intrusion rule
updates that you can import onto your Firepower Management Center, and then implement by deploying the
changed configuration to your managed devices. These updates affect intrusion rules, preprocessor rules, and
the policies that use the rules.
Intrusion rule updates are cumulative, and Cisco recommends you always import the latest update. You cannot
import an intrusion rule update that either matches or predates the version of the currently installed rules.
An intrusion rule update may provide the following:
• New and modified rules and rule states—Rule updates provide new and updated intrusion and
preprocessor rules. For new rules, the rule state may be different in each system-provided intrusion policy.
For example, a new rule may be enabled in the Security over Connectivity intrusion policy and disabled
in the Connectivity over Security intrusion policy. Rule updates may also change the default state of
existing rules, or delete existing rules entirely.
• New rule categories—Rule updates may include new rule categories, which are always added.
• Modified preprocessor and advanced settings—Rule updates may change the advanced settings in
the system-provided intrusion policies and the preprocessor settings in system-provided network analysis
policies. They can also update default values for the advanced preprocessing and performance options
in your access control policies.
• New and modified variables—Rule updates may modify default values for existing default variables,
but do not override your changes. New variables are always added.
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.
Understanding When Intrusion Rule Updates Modify Policies

Intrusion rule updates can affect both system-provided and custom network analysis policies, as well as all
access control policies:
• system provided—Changes to system-provided network analysis and intrusion policies, as well as any
changes to advanced access control settings, automatically take effect when you re-deploy the policies
after the update.
• custom—Because every custom network analysis and intrusion policy uses a system-provided policy as
its base, or as the eventual base in a policy chain, rule updates can affect custom network analysis and
intrusion policies. However, you can prevent rule updates from automatically making those changes.
This allows you to update system-provided base policies manually, on a schedule independent of rule
update imports. Regardless of your choice (implemented on a per-custom-policy basis), updates to
system-provided policies do not override any settings you customized.
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.

241
Update Intrusion Rules One-Time Manually
Deploying Intrusion Rule Updates

For changes made by an intrusion rule update to take effect, you must redeploy configurations. When importing
a rule update, you can configure the system to automatically redeploy to affected devices. This approach is
especially useful if you allow the intrusion rule update to modify system-provided base intrusion policies.
Recurring Intrusion Rule Updates

You can import rule updates on a daily, weekly, or monthly basis, using the Rule Updates page.
If your deployment includes a high availability pair of Firepower Management Centers, import the update on
the primary only. The secondary Firepower Management Center receives the rule update as part of the regular
synchronization process.
Applicable subtasks in the intrusion rule update import occur in the following order: download, install, base
policy update, and configuration deploy. When one subtask completes, the next subtask begins.
At the scheduled time, the system installs the rule update and deploys the changed configuration as you
specified in the previous step. You can log off or use the web interface to perform other tasks before or during
the import. When accessed during an import, the Rule Update Log displays a Red Status ( ), and you can
view messages as they occur in the Rule Update Log detailed view. Depending on the rule update size and
content, several minutes may pass before status messages appear.
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 Schedule Intrusion Rule Updates, on page 243.
Importing Local Intrusion Rules

A local intrusion rule is a custom standard text rule that you import from a local machine as a plain text file
with ASCII or UTF-8 encoding. You can create local rules using the instructions in the Snort users manual,
which is available at http://www.snort.org.
In a multidomain deployment, you can import local intrusion rules in any domain. You can view local intrusion
rules imported in the current domain and ancestor domains.
Update Intrusion Rules One-Time Manually

Import a new intrusion rule update manually if your Firepower Management Center does not have Internet
access.
Procedure
Step 1 Manually download the update from the Cisco Support Site
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.

242
Update Intrusion Rules One-Time Automatically
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.
Update Intrusion Rules One-Time Automatically

To import a new intrusion rule update automatically, your appliance must have Internet access to connect to
the Support Site.
Before you begin

• Ensure the Firepower Management Center has internet access; see Security, Internet Access, and
Communication Ports, on page 3031.
Procedure

Tip You can also click Import Rules on the Rule Editor page, which you access by choosing Policies >
Intrusion > Intrusion Rules.
Step 2 Click Rule Updates.

Step 3 If you want to move all user-defined rules that you have created or imported to the deleted folder, click Delete
All Local Rules in the toolbar, then click OK.
Step 4 Choose Download new Rule Update from the Support Site.
Step 5 If you want to automatically re-deploy the changed configuration to managed devices after the update completes,
check the Reapply all policies after the rule update import completes check box.
The system installs the rule update and displays the Rule Update Log detailed view.
Caution Contact Support if you receive an error message while installing the rule update.
Schedule Intrusion Rule Updates

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 this section.

243
Best Practices for Importing Local Intrusion Rules
Procedure


Step 3 If you want to move all user-defined rules that you have created or imported to the deleted folder, click Delete
All Local Rules in the toolbar, then click OK.
Step 4 Check Enable Recurring Rule Update Imports from the Support Site check box.
Import status messages appear beneath the Recurring Rule Update Imports section heading.
Step 5 In the Import Frequency field, specify:

• The frequency of the update (Daily, Weekly, or Monthly)
• The day of the week or month you want the update to occur
• The time you want the update to start
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.
Best Practices for Importing Local Intrusion Rules

Observe the following guidelines when importing a local rule file:
• The rules importer requires that all custom rules are imported in a plain text file encoded in ASCII or
UTF-8.
• The text file name can include alphanumeric characters, spaces, and no special characters other than
underscore (_), period (.), and dash (-).
• The system imports local rules preceded with a single pound character (#), but they are flagged as deleted.
• The system imports local rules preceded with a single pound character (#), and does not import local
rules preceded with two pound characters (##).
• Rules cannot contain any escape characters.
• In a multidomain deployment, the system assigns a GID of 1 to a rule imported into or created in the
Global domain, and a domain-specific GID between 1000 and 2000 for all other domains.
• You do not have to specify a Generator ID (GID) when importing a local rule. If you do, specify only
GID 1 for a standard text rule.

244
Import Local Intrusion Rules
• When importing a rule for the first time, do not specify a Snort ID (SID) or revision number. This avoids
collisions with SIDs of other rules, including deleted rules. The system will automatically assign the rule
the next available custom rule SID of 1000000 or greater, and a revision number of 1.
If you must import rules with SIDs, a SID can be any unique number 1,000,000 or greater.
In a multidomain deployment, if multiple administrators are importing local rules at the same time, SIDs
within an individual domain might appear to be non-sequential because the system assigned the intervening
numbers in the sequence to another domain.
• 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.
Import Local Intrusion Rules

• Make sure your local rule file follows the guidelines described in Best Practices for Importing Local
Intrusion Rules, on page 244.
• Make sure your process for importing local intrusion rules complies with your security policies.
• Consider the import's effect on traffic flow and inspection due to bandwidth constraints and Snort restarts.
We recommend scheduling rule updates during maintenance windows.
• You can perform this task in any domain.
Use this procedure to import local intrusion rules. Imported intrusion rules appear in the local rule category
in a disabled state.

245
Rule Update Log
Procedure
Step 1 Choose System > Updates, then click Rule Updates.

Step 2 (Optional) Delete existing local rules.
Click Delete All Local Rules, then confirm that you want to move all created and imported intrusion rules
to the deleted folder.
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 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.
Rule Update Log

The Firepower Management Center generates a record for each rule update and local rule file that you import.
Each record includes a time stamp, the name of the user who imported the file, and a status icon indicating
whether the import succeeded or failed. You can maintain a list of all rule updates and local rule files that you
import, delete any record from the list, and access detailed records for all imported rules and rule update
components.
The Rule Update Import Log detailed view lists a detailed record for each object imported in a rule update or
local rule file. You can also create a custom workflow or report from the records listed that includes only the
information that matches your specific needs.
Intrusion Rule Update Log Table

Table 22: Intrusion Rule Update Log Fields
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.
Time The time and date that the import started.
User ID The user name of the user that triggered the import.

246
Viewing the Intrusion Rule Update Log
Field Description
Status Whether the import:
• Succeeded ( )
• failed or is currently in progress Red Status ( )
The red status icon indicating an unsuccessful or incomplete import appears on the
Rule Update Log page during the import and is replaced by the green icon only when
the import has successfully completed.
Tip You can view import details as they appear while an intrusion rule update import is in progress.
Viewing the Intrusion Rule Update Log

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.
Procedure

Tip You can also click Import Rules on the intrusion rules editor page (Objects > Intrusion Rules).

Step 3 Click Rule Update Log.
Step 4 You have two options:
• 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 249.
• 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.
Fields in an Intrusion Rule Update Log
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.

247
Fields in an Intrusion Rule Update Log
Table 23: Rule Update Import Log Detailed View Fields
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.
Rev The revision number for a rule.
Rule Update The rule update file name.
SID The SID for a rule.
Time The time and date the import began.

248
Viewing Details of the Intrusion Rule Update Import Log
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.
Viewing Details of the Intrusion Rule Update Import Log

Procedure


Step 3 Click Rule Update Log.
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
2744 for more information.
• Switch workflows—To temporarily use a different workflow, click (switch workflows).

249
Maintain Your Air-Gapped Deployment
Maintain Your Air-Gapped Deployment

If your Firepower system is not connected to the internet, essential updates will not occur automatically.
You must manually obtain and install these updates. See the following information:
• Manually Update the VDB, on page 238
• Update Intrusion Rules One-Time Manually, on page 242
• Manually Update the GeoDB (No Internet Connection), on page 240
• The Firepower Management Center Software Upgrade Guide at
https://www.cisco.com/c/en/us/td/docs/security/firepower/upgrade/fpmc-upgrade-guide.html
History for System Updates

Improved FTD upgrade 7.0.0 Firepower Threat Defense upgrades are now easier faster, more reliable, and take up
performance and status less disk space. A new Upgrades tab in the Message Center provides further
reporting enhancements to upgrade status and error reporting.
Supported platforms: Firepower Threat Defense

250
Easy-to-follow FTD upgrade 7.0.0 A new device upgrade page (Devices > Upgrade) on the Version 7.0.0 Firepower
workflow Management Center provides an easy-to-follow workflow for upgrading Version 6.4.0+
The system walks you through important pre-upgrade stages, including:
• Selecting devices to upgrade.
• Copying the upgrade package to the devices.
• Compatibility and readiness checks.
To begin, use the new Upgrade Firepower Software action on the Device Management
page (Devices > Device Management > Select Action).
Note You must still use the System Updates page (System > Updates) page to
upload or specify the location of Firepower Threat Defense upgrade packages.
You must also use the System Updates page to upgrade the Firepower
Management Center itself, as well as all non-Firepower Threat Defense
managed devices.
As you proceed with the upgrade workflow, the system displays basic information about
your selected devices, as well as the current upgrade-related status. This includes any
reasons why you cannot upgrade. If a device does not "pass" a stage in the workflow,
it does not appear in the next stage.
If you navigate away from workflow, your progress is preserved, although other users
with Administrator access can reset, modify, or continue the workflow.
Note In Version 7.0.0/7.0.x, the Device Upgrade page does not correctly display
devices in clusters or high availability pairs. Even though you must select
and upgrade these devices as a unit, the workflow displays them as standalone
devices. Device status and upgrade readiness are evaluated and reported on
an individual basis. This means it is possible for one unit to appear to "pass"
to the next stage while the other unit or units do not. However, these devices
are still grouped. Running a readiness check on one, runs it on all. Starting
the upgrade on one, starts it on all.
To avoid possible time-consuming upgrade failures, manually ensure all
group members are ready to move on to the next step of the workflow before
you click Next.

251
Upgrade more FTD devices 7.0.0 The Firepower Threat Defense upgrade workflow lifts the following restrictions:
at once
• Simultaneous device upgrades.
The number of devices you can upgrade at once is now limited by your management
network bandwidth—not the system's ability to manage simultaneous upgrades.
Previously, we recommended against upgrading more than five devices at a time.
Important Only upgrades to FTD Version 6.7.0+ see this improvement. If you are
upgrading devices to an older FTD release—even if you are using the
new upgrade workflow—we still recommend you limit to five devices
at a time.
• Grouping upgrades by device model.

You can now queue and invoke upgrades for all Firepower Threat Defense models
at the same time, as long as the system has access to the appropriate upgrade
packages.
Previously, you would choose an upgrade package, then choose the devices to
upgrade using that package. That meant that you could upgrade multiple devices
at the same time only if they shared an upgrade package. For example, you could
upgrade two Firepower 2100 series devices at the same time, but not a Firepower
2100 series and a Firepower 1000 series.

252
Improved FTD upgrade 6.7.0 You can now view the status of FTD device upgrades and readiness checks in progress
status reporting and on the Device Management page, as well as a 7-day history of upgrade success/failures.
cancel/retry options The Message Center also provides enhanced status and error messages.
A new Upgrade Status pop-up, accessible from both Device Management and the
Message Center with a single click, shows detailed upgrade information, including
percentage/time remaining, specific upgrade stage, success/failure data, upgrade logs,
and so on.
Also on this pop-up, you can manually cancel failed or in-progress upgrades (Cancel
Upgrade), or retry failed upgrades (Retry Upgrade). Canceling an upgrade reverts the
device to its pre-upgrade state.
Note To be able to manually cancel or retry a failed upgrade, you must disable the
new auto-cancel option, which appears when you use the FMC to upgrade
an FTD device: Automatically cancel on upgrade failure and roll back
to the previous version. With the option enabled, the device automatically
reverts to its pre-upgrade state upon upgrade failure.
Auto-cancel is not supported for patches. In an HA or clustered deployment,
auto-cancel applies to each device individually. That is, if the upgrade fails
on one device, only that device is reverted.
New/modified screens:
• System > Update > Product Updates > Available Updates > Install icon for the
FTD upgrade package
• Devices > Device Management > Upgrade
• Message Center > Tasks
New FTD CLI commands:

• show upgrade status detail
• show upgrade status continuous
• show upgrade status
• upgrade cancel
• upgrade retry
Upgrades remove PCAP 6.7.0 To upgrade a Firepower appliance, you must have enough free disk space or the upgrade
files to save disk space fails. Upgrades now remove locally stored PCAP files.

253
Custom intrusion rule 6.7.0 The FMC now warns you of rule collisions when you import custom (local) intrusion
import warns when rules rules. Previously, the system would silently skip the rules that cause collisions—with
collide the exception of Version 6.6.0.1, where a rule import with collisions would fail entirely.
On the Rule Updates page, if a rule import had collisions, a warning icon is displayed
in the Status column. For more information, hover your pointer over the warning icon
and read the tooltip.
Note that a collision occurs when you try to import an intrusion rule that has the same
SID/revision number as an existing rule. You should always make sure that updated
versions of custom rules have new revision numbers; for more best practices, see Best
Practices for Importing Local Intrusion Rules, on page 244.
New/modified screens: We added a warning icon to System > Updates > Rule Updates.
Get FTD upgrade packages 6.6.0 FTD devices can now get upgrade packages from your own internal web server, rather
from an internal web server than from the FMC. This is especially useful if you have limited bandwidth between
the FMC and its devices. It also saves space on the FMC.
Note This feature is supported only for FTD devices running Version 6.6.0+. It is
not supported for upgrades to Version 6.6.0, nor is it supported for the FMC
or Classic devices.
New/modified screens: System > Updates > Upload Update button > Specify software
update source option
FMC downloads and installs 6.6.0 When you set up a new or reimaged FMC, the system automatically attempts to update
the latest VDB during initial the vulnerability database (VDB).
setup
This is a one-time operation. If the FMC has internet access, we recommend you schedule
tasks to perform automatic recurring VDB update downloads and installations.
FMC schedules software 6.5.0 When you set up a new or reimaged FMC, the system automatically schedules:
downloads and GeoDB
• A weekly task to download software updates for the FMC and its managed devices.
updates during initial setup
• Weekly updates for the GeoDB.
The tasks are scheduled in UTC, which means that 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. We recommend
you review the auto-scheduled configurations and adjust them if necessary.

254
FMC upgrades postpone 6.7.0 FMC upgrades now postpone scheduled tasks. Any task scheduled to begin during the
scheduled tasks upgrade will begin five minutes after the post-upgrade reboot.
6.6.3
Note Before you begin any upgrade, you must still make sure running tasks are
6.4.0.10
complete. Tasks running when the upgrade begins are stopped, become failed
tasks, and cannot be resumed.
Note that this feature is supported for all upgrades from a supported version. This includes
Version 6.4.0.10 and later patches, Version 6.6.3 and later maintenance releases, and
Version 6.7.0+. This feature is not supported for upgrades to a supported version from
an unsupported version.
Signed SRU, VDB, and 6.4.0 So Firepower can verify that you are using the correct update files, the system now uses
GeoDB updates signed updates for intrusion rules (SRU), the vulnerability database (VDB), and the
geolocation database (GeoDB). Earlier versions continue to use unsigned updates.
Unless you manually download updates from the Cisco Support & Download site—for
example, in an air-gapped deployment—you should not notice any difference in
functionality.
If, however, you do manually download and install SRU, VDB, and GeoDB updates,
make sure you download the correct package for your current version. Signed update
files begin with 'Cisco' instead of 'Sourcefire,' and terminate in .sh.REL.tar instead of
.sh:
• SRU: Cisco_Firepower_SRU-date-build-vrt.sh.REL.tar
• VDB: Cisco_VDB_Fingerprint_Database-4.5.0-version.sh.REL.tar
• GeoDB: Cisco_GEODB_Update-date-build.sh.REL.tar
Do not untar signed (.tar) packages.
Faster upgrade 6.4.0 Improvements to the event database mean that upgrading Firepower appliances is now
faster.
Copy upgrade packages to 6.2.3 You can now copy (or push) an upgrade package from the FMC to a managed device
managed devices before the before you run the actual upgrade. This is useful because you can push during times of
upgrade low bandwidth use, outside of the upgrade maintenance window.
When you push to high availability, clustered, or stacked devices, the system sends the
upgrade package to the active/control/primary first, then to the standby/data/secondary.
New/modified screens: System > Updates

255
FMC warns of Snort restart 6.2.3 The FMC now warns you that Vulnerability Database (VDB) updates restart the Snort
before VDB updates process. This interrupts traffic inspection and, depending on how the managed device
handles traffic, possibly interrupts traffic flow. You can cancel the install until a more
convenient time, such as during a maintenance window.
These warnings can appear:
• After you download and manually install a VDB.
• When you create a scheduled task to install the VDB.
• When the VDB installs in the background, such as during a previously scheduled
task or as part of a Firepower software upgrade.

256
CHAPTER 8
Backup and Restore
• About Backup and Restore, on page 257
• Requirements for Backup and Restore, on page 259
• Guidelines and Limitations for Backup and Restore, on page 260
• Best Practices for Backup and Restore, on page 261
• Backing Up FMCs or Managed Devices, on page 265
• Restoring FMCs and Managed Devices, on page 269
• Manage Backups and Remote Storage, on page 282
• History for Backup and Restore, on page 285
About Backup and Restore

The ability to recover from a disaster is an essential part of any system maintenance plan. As part of your
disaster recovery plan, we recommend that you perform periodic backups to a secure remote location.
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 FMCs or Managed Devices, on page 265.
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 295.
Storing Backup Files

You can store backups locally. However, we recommend you back up FMCs and managed devices to a secure
remote location by mounting 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.

257
About Backup and Restore
For more information, see Remote Storage Management, on page 1370 and Manage Backups and Remote
Storage, on page 282.
Restoring the FMC and Managed Devices

You restore the FMC from the Backup Management page. You must use the FTD CLI to restore an FTD
device, except for the ISA 3000 zero-touch restore, which uses an SD card and the reset button.
For more information, see Restoring FMCs and Managed Devices, on page 269.
What Is Backed Up?

FMC backups can include:
• Configurations.
All configurations you can set on the FMC web interface are included in a configuration backup, with
the exception of remote storage and audit log server certificate settings. In a multidomain deployment,
you must back up configurations. You cannot back up events or TID data only.
• Events.
Event backups include all events in the FMC database. However, FMC event backups do not include
intrusion event review status. Restored intrusion events do not appear on Reviewed Events pages.
• Threat Intelligence Director (TID) data.
For more information, see About Backing Up and Restoring TID Data, on page 1900.
Device backups are always configuration-only.
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.

258
Requirements for Backup and Restore
Requirements for Backup and Restore

Backup and restore has the following requirements.
Model Requirements: Backup

You can back up:
• FMCs
• FTD standalone devices, native instances, container instances, and HA pairs
• FTDv for VMware devices, either standalone or HA pairs
Backup is not supported for:

• FTD clusters
• FTDv implementations other than FTDv for VMware
• NGIPSv
• ASA FirePOWER
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.
Model Requirements: Restore

A replacement managed device must be the same model as the one you are replacing, with the same number
of network modules and same type and number of physical interfaces.
For FMCs, you can use backup and restore not only in an RMA scenario, but also to migrate configurations
and events between FMCs. For details, including supported target and destination models, see the Firepower
Management Center Model Migration Guide.
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.

259
Guidelines and Limitations for Backup and Restore
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.
Guidelines and Limitations for Backup and Restore

Backup and restore has the following guidelines and limitations.
Backup and Restore is for Disaster Recovery/RMA

Backup and restore is primarily intended for RMA scenarios. Before you begin the restore process of a faulty
or failed physical appliance, contact Cisco TAC for replacement hardware.
You can also use backup and restore to migrate configurations and events between FMCs. This makes it easier
to replace FMCs due to technical or business reasons such as a growing organization, migration from a physical
to a virtual implementation, hardware refresh, and so on.
Backup and Restore is not Configuration Import/Export

A backup file contains information that uniquely identifies an appliance, and cannot be shared. Do not use
the backup and restore process to copy configurations between appliances or devices, or as a way to save
configurations while testing new ones. Instead, use the import/export feature.
For example, FTD device backups include the device's management IP address and all information the device
needs to connect to its managing FMC. Do not restore an FTD backup to a device being managed by a different
FMC; the restored device will attempt to connect to the FMC specified in the backup.
Restore is Individual and Local

You restore to FMCs and manageed devices individually and locally. This means:
• You cannot batch-restore to high availability (HA) FMCs or devices. The restore procedures in this guide
explain how to restore in an HA environment.
• You cannot use the FMC to restore a device. For the FMC, you can use the web interface to restore. For
FTD devices, you must use the FTD CLI, except for the ISA 3000 zero-touch restore, which uses an SD
card and the reset button.
• You cannot use an FMC user account to log into and restore one of its managed devices. FMCs and
devices maintain their own user accounts.
Configuration Import/Export Guidelines for Firepower 4100/9300

You can use the configuration export feature to export an XML file containing logical device and platform
configuration settings for your Firepower 4100/9300 chassis to a remote server or your local computer. You

260
Best Practices for Backup and Restore
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.
Guidelines and Restrictions

• Do not modify the contents of the configuration file. If a configuration file is modified, configuration
import using that file might fail.
• Application-specific configuration settings are not contained in the configuration file. You must use the
configuration backup tools provided by the application to manage application-specific settings and
configurations.
• When you import a configuration to the Firepower 4100/9300 chassis, all existing configuration on the
Firepower 4100/9300 chassis (including any logical devices) are deleted and completely replaced by the
configuration contained in the import file.
• Except in an RMA scenario, we recommend you only import a configuration file to the same Firepower
4100/9300 chassis where the configuration was exported.
• The platform software version of the Firepower 4100/9300 chassis where you are importing should be
the same version as when the export was taken. If not, the import operation is not guaranteed to be
successful. We recommend you export a backup configuration whenever the Firepower 4100/9300 chassis
is upgraded or downgraded.
• The Firepower 4100/9300 chassis where you are importing must have the same Network Modules installed
in the same slots as when the export was taken.
• The Firepower 4100/9300 chassis where you are importing must have the correct software application
images installed for any logical devices defined in the export file that you are importing.
• To avoid overwriting existing backup files, change the file name in the backup operation or copy the
existing file to another location.

Backup and restore has the following best practices.
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. If you include event data,
event-related features such as eStreamer are not available.
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 295.

261
• After SLR changes.

Back up the FMC after you make changes to Specific Licensing Reservations (SLRs). If you make
changes and then restore an older backup, you will have issues with your Specific Licensing return code
and can accrue orphan entitlements.
• Before upgrade or reimage.
If an upgrade fails catastrophically, you may have to reimage and restore. Reimaging returns most settings
to factory defaults, including the system password. If you have a recent backup, you can return to normal
operations more quickly.
• After upgrade.
Back up after you upgrade, so you have a snapshot of your freshly upgraded deployment. We recommend
you back up the FMC after you upgrade its managed devices, so your new FMC backup file 'knows' that
its devices have been upgraded.
Maintaining Backup File Security

Backups are stored as unencrypted archive (.tar) files.
Private keys in PKI objects—which represent the public key certificates and paired private keys required to
support your deployment—are decrypted before they are backed up. The keys are reencrypted with a randomly
generated key when you restore the backup.
Caution We recommend you back up FMCs and devices to a secure remote location and verify transfer success.
Backups left locally 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 1370 and Manage Backups
and Remote Storage, on page 282.
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).
Backup and Restore in FMC High Availability Deployments

In an FMC high availability deployment, backing up one FMC does not back up the other. You should regularly
back up both peers. Do not restore one HA peer with the backup file from the other. A backup file contains
information that uniquely identifies an appliance, and cannot be shared.
Note that you can replace an HA FMC without a successful backup. For more information on replacing HA
FMCs, both with and without successful backups, see Replacing FMCs in a High Availability Pair, on page
336.

262
Backup and Restore in FTD High Availability Deployments

In an FTD HA deployment, you should:
• Back up the device pair from the FMC, but restore individually and locally from the FTD CLI.
The backup process produces unique backup files for FTD HA devices. Do not restore one HA peer with
the backup file from the other. A backup file contains information that uniquely identifies an appliance,
and cannot be shared.
An FTD HA device's role is noted in its backup file name. When you restore, make sure you choose the
appropriate backup file: primary vs secondary.
• Do not suspend or break HA before you restore.
Maintaining the HA configuration ensures replacement devices can easily reconnect after restore. Note
that you will have to resume HA synchronization to make this happen.
• Do not run the restore CLI command on both peers at the same time.
Assuming you have successful backups, you can replace either or both peers in an HA pair. Any physical
replacement tasks you can perform simultaneously: unracking, reracking, and so on. However, do not
run the restore command on the second device until the restore process completes for the first device,
including the reboot.
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 929.
Backup and Restore for Firepower 4100/9300 Chassis

To restore Firepower software on a Firepower 4100/9300 chassis, the chassis must be running a compatible
FXOS version.
When you back up a Firepower 4100/9300 chassis, we strongly recommend you also back up FXOS
configurations. For additional best practices, see Configuration Import/Export Guidelines for Firepower
4100/9300 , on page 260.
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.

263
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 538.

264
Backing Up FMCs or Managed Devices
Backing Up FMCs or Managed Devices

You can perform on-demand or scheduled backups for supported appliances.
You do not need a backup profile to back up devices from the FMC. However, FMC backups require backup
profiles. The on-demand backup process allows you to create a new backup profile.
For more information, see:
• Back up the FMC, on page 265
• Back up a Device from the FMC, on page 266
• Create a Backup Profile, on page 268
• Scheduled Backups, on page 295
Back up the FMC

Use this procedure to perform an on-demand FMC backup.
Before you begin

You must read and understand the requirements, guidelines, limitations, and best practices. You do not want
to skip any steps or ignore security concerns. Careful planning and preparation can help you avoid missteps.
Procedure
Step 1 Select System > Tools > Backup/Restore.

The Backup Management page lists all locally and remotely stored backups. It also lists how much disk space
you have available to store backups. Backups can fail if there is not enough space.
Step 2 Choose whether to use an existing backup profile or start fresh.

FMC backups require that you use or create a backup profile.
• Click Backup Profiles to use an existing backup profile.
Next to the profile you want to use, click the edit icon. You can then click Start Backup to begin the
backup right now. Or, if you want to edit the profile, go on to the next step.
• Click Firepower Management Backup to start fresh and create a new backup profile.
Enter a Name for the backup profile.
Step 3 Choose what to back up:

265
Back up a Device from the FMC
• 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 257.
Step 4 Note the Storage Location for FMC backup files.

This will either be local storage in /var/sf/backup/, or a remote network volume. For more information,
see Manage Backups and Remote Storage, on page 282.
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 1386.
Step 7 Click Start Backup to start the on-demand backup.

If you are not using an existing backup profile, the system automatically creates one and uses it. If you decide
not to run the backup now, you can click Save or Save As New to save the profile. In either case, you can use
the newly created profile to configure scheduled backups.
Step 8 Monitor progress in the Message Center.

While the system collects backup data, there may be a temporary pause in data correlation, and you may be
prevented from changing configurations related to the backup. If you configured remote storage or enabled
Copy when complete, the FMC may write temporary files to the remote server. These files are cleaned up
at the end of the backup process.
What to do next
If you configured remote storage or enabled Copy when complete, verify transfer success of the backup file.
Back up a Device from the FMC

Use this procedure to perform an on-demand backup of any of the following devices:
• FTD: Physical devices, standalone or HA
• FTDv: VMware, standalone or HA

266
Exporting an FXOS Configuration File
Backup and restore is not supported for any other platforms or configurations, including clustered devices.
Before you begin

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 267.
Procedure
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 the
ISA 3000, if you have an SD card installed, a copy of the backup will also be made on the SD card at
/mnt/disk3/backup. For more information, see Manage Backups and Remote Storage, on page 282.
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.
Step 5 Click Start Backup to start the on-demand backup.

What to do next
If you configured remote storage, verify transfer success of the backup file.
Exporting an FXOS Configuration File

Use the configuration export feature to export an XML file containing logical device and platform configuration
settings for your Firepower 4100/9300 chassis to a remote server or your local computer.
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.

267
Create a Backup Profile
Before you begin

Review the Configuration Import/Export Guidelines for Firepower 4100/9300 .
Procedure
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.
Create a Backup Profile

A backup profile is a saved set of preferences—what to back up, where to store the backup file, and so on.
FMC backups require backup profiles. Backup profiles are not required to back up a device from the FMC.
When you perform an on-demand FMC backup, if you do not pick an existing backup profile, the system
automatically creates one and uses it. You can then use the newly created profile to configure scheduled
backups.
The following procedure explains how to create a backup profile without performing an on-demand backup.
Procedure
Step 1 Select System > Tools > Backup/Restore, then click Backup Profiles.
Step 2 Click Create Profile and enter a Name.

268
Restoring FMCs and Managed Devices
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 257.
Step 4 Note the Storage Location for backup files.

This will either be local storage in /var/sf/backup/, or a remote network volume. For the ISA 3000, if
you have an SD card installed, a copy of the backup will also be made on the SD card at
/mnt/disk3/backup. For more information, see Manage Backups and Remote Storage, on page 282.
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 1386.
Step 7 Click Save.
Restoring FMCs and Managed Devices

For the FMC, you use the web interface to restore from backup. For FTD devices, you must use the FTD CLI.
You cannot use the FMC to restore a device.
The following sections explain how to restore FMCs and managed devices.
• Restore an FMC from Backup, on page 270
• Replacing FMCs in a High Availability Pair, on page 336
• Restore FTD from Backup: Firepower 1000/2100, ASA-5500-X, ISA 3000 (Non-Zero-Touch), on page
271 (includes high availability examples)
• Zero-Touch Restore FTD from Backup: ISA 3000, on page 274
• Restore FTD from Backup: Firepower 4100/9300 Chassis, on page 276
• Restore FTD from Backup: FTDv, on page 280

269
Restore an FMC from Backup
Restore an FMC from Backup

When you restore an FMC backup, you can choose to restore any or all of the components included in the
backup file (events, configurations, TID data).
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 336.
Before you begin

Procedure
Step 1 Log into the FMC you want to restore.

The Backup Management page lists all locally and remotely stored backup files. You can click a backup file
to view its contents.
If the backup file is not in the list and you have it saved on your local computer, click Upload Backup; see
Manage Backups and Remote Storage, on page 282.
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.
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.

270
Restore FTD from Backup: Firepower 1000/2100, ASA-5500-X, ISA 3000 (Non-Zero-Touch)
• (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.
Restore FTD from Backup: Firepower 1000/2100, ASA-5500-X, ISA 3000

(Non-Zero-Touch)
FTD backup and restore is intended for RMA. Restoring configurations overwrites all configurations on the
device, including the management IP address. It also reboots the device.
In case of hardware failure, this procedure outlines how to replace a Firepower 1000/2100, ASA-5500-X, or
ISA 3000 FTD device, either standalone or in an HA pair. It assumes you have access to a successful backup
of the device or devices you are replacing; see Back up a Device from the FMC, on page 266. For zero-touch
restore on the ISA 3000 using an SD card, see Zero-Touch Restore FTD from Backup: ISA 3000, on page
274.
In an FTD HA deployment, you can use this procedure to replace either or both peers. To replace both, perform
all steps on both devices simultaneously, except the restore CLI command itself. 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 929.
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.
Before you begin

Procedure
Step 1 Contact Cisco TAC for replacement hardware.

Obtain an identical model, with the same number of network modules and same type and number of physical
interfaces. You can begin the RMA process from the Cisco Returns Portal.
Step 2 Locate a successful backup of the faulty device.
Depending on your backup configuration, device backups may be stored:
• On the faulty device itself in /var/sf/backup.
• On the FMC in /var/sf/remote-backup.

271
• In a remote storage location.
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 282.
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 3 Remove (unrack) the faulty device.

Disconnect all interfaces. In FTD HA deployments, this includes the failover link.
See the hardware installation and getting started guides for your model: Cisco Firepower NGFW: Install and
Upgrade Guides.
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.
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 5 (Optional) Reimage the replacement device.

In an RMA scenario, the replacement device will arrive configured with factory defaults. If the replacement
device is not running the same major version as the faulty device, we recommend you reimage.
See the Cisco ASA and Firepower Threat Defense Reimage Guide.
Step 6 Perform initial configuration on the replacement device.

Access the FTD CLI as the admin user. You can use the console or you can SSH to the factory-default
management interface IP address (192.168.45.45). A setup wizard prompts you to configure the management
IP address, gateway, and other basic network settings.
Do not set the same management IP address as the faulty device. This can cause problems if you need to
register the device in order to patch it. The restore process will correctly reset the management IP address.
See the initial configuration topics in the getting started guide for your model: Cisco Firepower NGFW: Install
and Upgrade Guides.
Note If you need to patch the replacement device, start the FMC registration process as described in the
getting started guide. If you do not need to patch, do not register.
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:

272
a) From the FMC web interface, complete the device registration process: Add a Device to the FMC, on
page 355.
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 358.
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.
Step 9 From the FTD CLI, restore the 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
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 928.
• 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 718.
Step 12 Deploy configurations.

You must deploy. If a restored device is not marked out of date, force deploy from the Device Management
page: Redeploy Existing Configurations to a Device, on page 538.
Step 13 Connect the device's data interfaces.

273
Zero-Touch Restore FTD from Backup: ISA 3000
What to do next
Verify that the restore succeeded and the replacement device is passing traffic as expected.

In case of hardware failure, this procedure outlines how to replace an ISA 3000 FTD device, either standalone
or in an HA pair. It assumes you have a backup of the failed unit on an SD card; see Back up a Device from
the FMC, on page 266.
In an FTD HA deployment, you can use this procedure to replace either or both peers. To replace both, perform
all steps on both devices simultaneously, except the restore CLI command itself. 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 929.
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.
Before you begin

Procedure

Step 2 Remove the SD card from the faulty device, and unrack the device.
Disconnect all interfaces. In FTD HA deployments, this includes the failover link.
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.

274
Step 3 Rerack the replacement device, and connect it to the management network. In an FTD HA deployment, connect
the failover link. However, do not connect the data interfaces.
If you need to reimage the device or apply a software patch, connect the power connector.
Step 4 (May be required) Reimage the replacement device.

device is not running the same major version as the faulty device, you need to reimage. Obtain the installer
from https://www.cisco.com/go/isa3000-software.
See the Cisco ASA and Firepower Threat Defense Reimage Guide to reimage.
Step 5 (May be required) Make sure the replacement device is running the same Firepower software version, including
the same patch version, as the faulty device. If you need to patch the device, you can connect to Firepower
Device Manager (FDM) to install the patch.
The following procedure assumes you have a factory default configuration. If you already configured the
device, you can log into FDM and go directly to the Device > Upgrades page to install the patch.
In either case, obtain the patch package from https://www.cisco.com/go/isa3000-software.
a) Connect your computer directly to the inside (Ethernet 1/2) interface, and access FDM on the default IP
address: https://192.168.95.1.
b) Enter the admin username and the default password Admin123, then click Login.
c) Complete the setup wizard. Keep in mind that you are not going to retain anything you configure in FDM;
you only want to get past any initial configuration so you can apply the patches, so it doesn't matter what
you enter in the setup wizard.
d) Go to the Device > Upgrades page.
The System Upgrade section shows the currently running software version.
e) Upload the patch file by clicking Browse.
f) Click Install to start the installation process.
Information next to the icon indicates whether the device will reboot during installation. You are
automatically logged out of the system. Installation might take 30 minutes or more.
Wait before logging into the system again. The Device Summary, or System monitoring dashboard, should
show the new version.
Note Do not simply refresh the browser window. Instead, delete any path from the URL, and reconnect
to the home page. This ensures that cached information gets refreshed with the latest code.
Step 6 Insert the SD card in the replacement device.

Step 7 Power on or reboot the device and shortly after it starts the bootup, depress and hold the Reset button for no
fewer than 3 seconds and no longer than 15 seconds.
If you used FDM to install a patch, you can reboot from the Device > System Settings > Reboot/Shutdown
page. From the FTD CLI, use the reboot command. If you have not yet attached power, attach it now.
Use a standard size #1 paper clip with wire gauge 0.033 inch or smaller to depress the Reset button. The
restoration process is triggered during bootup. The device restores the configuration, and then reboots. The
device will then register with the FMC automatically.
If you are restoring both devices in an HA pair, do this sequentially. Do not restore the second device until
the restore process completes for the first device, including the reboot.

275
Restore FTD from Backup: Firepower 4100/9300 Chassis
• Resume HA synchronization. From the FTD CLI, enter configure high-availability resume. See
Suspend and Resume High Availability, on page 928.


What to do next

In case of hardware failure, this procedure outlines how to replace a Firepower 4100/9300 chassis. It assumes
you have access to a successful backups of:
• The logical device or devices you are replacing; see Back up a Device from the FMC, on page 266.
• FXOS configurations; see Exporting an FXOS Configuration File, on page 267.
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.
Before you begin


276
Procedure

Step 3 Locate a successful backup of your FXOS configurations.

Step 4 Remove (unrack) the faulty device.
Disconnect all interfaces.
See the hardware installation and getting started guides for your model: Cisco Firepower NGFW: Install and
Upgrade Guides.
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.
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.
Step 6 (Optional) Reimage the replacement device.

device is not running the same major version as the faulty device, we recommend you reimage.
See the instructions on restoring the factory default configuration in the appropriate Cisco Firepower 4100/9300
FXOS Firepower Chassis Manager Configuration Guide.
Step 7 Make sure FXOS is running a compatible version.

You must be running a compatible FXOS version before you re-add logical devices. You can use Firepower
Chassis Manager to import your backed-up FXOS configurations: Importing a Configuration File, on page
279.
Step 8 Use Firepower Chassis Manager to add logical devices and perform initial configurations.

277
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.
faulty device.
page 355.

address.
To restore:

278
Importing a Configuration File


What to do next
Importing a Configuration File

You can use the configuration import feature to apply configuration settings that were previously exported
from your Firepower 4100/9300 chassis. This feature allows you to return to a known good configuration or
to recover from a system failure.
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.
Before you begin

Review the Configuration Import/Export Guidelines for Firepower 4100/9300 .
Procedure
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.
Step 3 To import from a configuration file on a remote server:
a) Click Remote.

279
Restore FTD from Backup: FTDv
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) If you are using a non-default port, enter the port number in the Port field.
d) Enter the hostname or IP address of the location where the backup file is 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.
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 File Path field, enter the full path to the configuration file including the file name.
h) 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.
i) 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.

Use this procedure to replace a faulty or failed Firepower Threat Defense Virtual device for VMware.
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.
Before you begin

Procedure


280
Step 2 Remove the faulty device.

Shut down, power off, and delete the virtual machine. For procedures, see the documentation for your virtual
environment.
Step 3 Deploy a replacement device.

See the Cisco Firepower Threat Defense Virtual for VMware Getting Started Guide.
Step 4 Perform initial configuration on the replacement device.

Use the VMware console to access the FTD CLI as the admin user. A setup wizard prompts you to configure
the management IP address, gateway, and other basic network settings.
Do not set the same management IP address as the faulty device. This can cause problems if you need to
register the device in order to patch it. The restore process will correctly reset the management IP address.
See the CLI setup topics in the getting started guide: Cisco Firepower Threat Defense Virtual for VMware
Getting Started Guide.
Note If you need to patch the replacement device, start the FMC registration process as described in the
getting started guide. If you do not need to patch, do not register.
faulty device.
page 355.

281
Manage Backups and Remote Storage

address.
To restore:

Step 11 Add and configure data interfaces.

See the Cisco Firepower Threat Defense Virtual for VMware Getting Started Guide and the documentation
for your virtual environment.
What to do next

Backups are stored as unencrypted archive (.tar) files. The file name includes identifying information that can
include:
• The name of the backup profile or scheduled task associated with the backup.
• The display name or IP address of the backed-up appliance.
• The appliance's role, such as a member of an HA pair.
We recommend you back up 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 284.

282
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.
The following procedure describes how to manage backup files.
Procedure

The Backup Management page lists available backups. It also lists how much disk space you have available
to store backups. Backups can fail if there is not enough space.
Step 2 Do one of the following:
Table 24: Remote Storage and Backup File Management
To Do This
Enable or disable remote storage Click Enable Remote Storage for Backups.
for backups without having to edit
This option appears only after you configure remote storage. Toggling
the FMC system configuration.
it here 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.
Move a file between the FMC and Click Move.

the remote storage location.
You can move a file back and forth as many times as you want. This
will delete—not copy—the file from the current location.
When you move a backup file from remote storage to the FMC, where
it is stored on the FMC depends on the kind of backup:
• FMC backups: /var/sf/backup
• Device backups: /var/sf/remote-backup
View the contents of the backup. Click the backup file.
Delete a backup file. Choose a backup file and click Delete.

You can delete both locally and remotely stored backup files.
Upload a backup file from your Click Upload Backup, choose a backup file, and click Upload Backup
computer. again.

283
Backup Storage Locations
To Do This
Download a backup to your Choose a backup file and click Download.
computer.
Unlike moving a backup file, this does not delete the backup from the
FMC.
Backup Storage Locations

The following table describes backup storage options for FMCs and managed devices.
Table 25: Backup Storage Locations
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 1370.)
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.

284
History for Backup and Restore
Location Details
Local, on the device internal Device backup files are saved to /var/sf/backup on the device if you:
flash memory.
• Do not configure remote storage by mounting a network volume.
• Do not enable Retrieve to Management Center.
Local, on the device SD card. For the ISA 3000, when you back up the device to the local
/var/sf/backup internal flash memory location, if you have an SD card
installed, the backup is automatically copied to the SD card at
/mnt/disk3/backup/ for use with zero-touch restore.

Zero-touch restore for 7.0 When you perform a local backup, the backup file is copied to the SD
the ISA 3000 using the card if present. To restore the configuration on a replacement device,
SD card simply install the SD card in the new device, and depress the Reset
button for 3 to 15 seconds during the device bootup.
Support for backup and 6.7 You can now use the FMC to perform on-demand remote backups of
restore of FTD FTD container instances on the Firepower 4100/9300.
container instances
VDB requirements for 6.6 Restoring an FMC from backup now replaces the existing VDB with
restore the VDB in the backup file. You no longer need to match VDB versions
before you restore.
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.
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
For supported platforms, see Requirements for Backup and Restore, on
page 259.
New/modified screens: System > Tools > Backup/Restore > Managed
Device Backup
New/modified FTD CLI commands: restore

285

286
CHAPTER 9
Configuration Import and Export
The following topics explain how to use the Import/Export feature:
• About Configuration Import/Export, on page 287
• Requirements and Prerequisites for Configuration Import/Export, on page 289
• Exporting Configurations, on page 289
• Importing Configurations, on page 290
About Configuration Import/Export

You can use the Import/Export feature to copy configurations between appliances. Import/Export is not a
backup tool, but can simplify the process of adding new appliances to your deployment.
You can export a single configuration, or you can export a set of configurations (of the same type or of different
types) with a single action. When you later import the package onto another appliance, you can choose which
configurations in the package to import.
An exported package contains revision information for that configuration, which determines whether you can
import that configuration onto another appliance. When the appliances are compatible but the package includes
a duplicate configuration, the system offers resolution options.
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.
Configurations that Support Import/Export

Import/Export is supported for the following configurations:
• Access control policies and the policies they invoke: prefilter, network analysis, intrusion, SSL, file,
Threat Defense Service Policy
• Intrusion policies, independently of access control
• NAT policies (Firepower Threat Defense only)

287
Special Considerations for Configuration Import/Export
• 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
Special Considerations for Configuration Import/Export

When you export a configuration, the system also exports other required configurations. For example, exporting
an access control policy also exports any subpolicies it invokes, objects and object groups it uses, ancestor
policies (in a multidomain deployment), and so on. As another example, if you export a platform settings
policy with external authentication enabled, the authentication object is exported as well. There are some
exceptions, however:
• System-provided databases and feeds—The system does not export URL filtering category and reputation
data, Cisco Intelligence Feed data, or the geolocation database (GeoDB). Make sure all the appliances
in your deployment obtain up-to-date information from Cisco.
• Global Security Intelligence lists—The system exports Global Security Intelligence Block and Do Not
Block lists associated with exported configurations. (In a multidomain deployment, this occurs regardless
of your current domain. The system does not export descendant domain lists.) The import process converts
these lists to user-created lists, then uses those new lists in the imported configurations. This ensures that
imported lists do not conflict with existing Global Block and Do Not Block lists. To use Global lists on
the importing Firepower Management Center in your imported configurations, add them manually.
• Intrusion policy shared layers—The export process breaks intrusion policy shared layers. The previously
shared layer is included in the package, and imported intrusion policies do not contain shared layers.
• Intrusion policy default variable set—The export package includes a default variable set with custom
variables and system-provided variables with user-defined values. The import process updates the default
variable set on the importing Firepower Management Center with the imported values. However, the
import process does not delete custom variables not present in the export package. The import process
also does not revert user-defined values on the importing Firepower Management Center, for values not
set in the export package. Therefore, an imported intrusion policy may behave differently than expected
if the importing Firepower Management Center has differently configured default variables.

288
Requirements and Prerequisites for Configuration Import/Export
• 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.
When you import objects and object groups:

• Generally, the import process imports objects and groups as new, and you cannot replace existing objects
and groups. However, if network and port objects or groups in an imported configuration match existing
objects or groups, the imported configuration reuses the existing objects/groups, rather than creating new
objects/groups. The system determines a match by comparing the name (minus any autogenerated number)
and content of each network and port object/group.
• If the names of imported objects match existing objects on the importing Firepower Management Center,
the system appends autogenerated numbers to the imported object and group names to make them unique.
• You must map any security zones and interface groups used in the imported configurations to
matching-type zones and groups managed by the importing Firepower Management Center.
• If you export a configuration that uses PKI objects containing private keys, the system decrypts the
private keys before export. On import, the system encrypts the keys with a randomly generated key.
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.

289
Importing Configurations
Before you begin

• Confirm that the importing and exporting appliances are 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.
Procedure
Step 1 Choose System > Tools > Import/Export.
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.
Before you begin

• Confirm that the importing and exporting appliances are 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.
Procedure
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.

290
Import Conflict Resolution
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 620.
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.
Note For individual access control policies, you have the option of replacing an existing policy with the
imported ones. However, for nested access control policies, you can only import them as new
policies.

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 291.
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 498.

When you attempt to import a configuration, the system determines whether a configuration of the same name
and type already exists on the appliance. In a multidomain deployment, the system also determines whether
a configuration is a duplicate of a configuration defined in the current domain or any of its ancestor or
descendant domains. (You cannot view configurations in descendant domains, but if a configuration with a
duplicate name exists in a descendant domain, the system notifies you of the conflict.) When an import includes
a duplicate configuration, the system offers resolution options suitable to your deployment from among the
following:
• Keep existing
The system does not import that configuration.
• Replace existing
The system overwrites the current configuration with the configuration selected for import.
• Keep newest
The system imports the selected configuration only if its timestamp is more recent than the timestamp
on the current configuration on the appliance.
• Import as new

291
The system imports the selected duplicate configuration, appending a system-generated number to the
name to make it unique. (You can change this name before completing the import process.) The original
configuration on the appliance remains unchanged.
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.
Resolution Option Firepower Management Center Managed Device
Duplicate in current Duplicate in ancestor or

domain descendant domain
Keep existing Yes Yes Yes
Replace existing Yes No Yes
Keep newest Yes No Yes
Import as new Yes Yes Yes
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:
Resolution Option System Action
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
Keep existing No Yes
Replace existing Yes No
Import as new Yes No
Keep newest and access Yes No

control policy being imported
is the newest
Keep newest and existing No Yes

access control policy is the
newest
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.

292
CHAPTER 10
Task Scheduling
The following topics explain how to schedule tasks:
• About Task Scheduling, on page 293
• Requirements and Prerequisites for Task Scheduling, on page 294
• Configuring a Recurring Task, on page 294
• Scheduled Task Review, on page 310
• History for Scheduled Tasks, on page 312
About Task Scheduling

You can schedule many different types of administrative tasks to run at designated times, either once or on a
recurring basis.
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 304. 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 296.
• As a part of initial configuration the FMC downloads and installs the latest vulnerability database (VDB)
as described in Vulnerability Database Update Automation, on page 306.

293
Requirements and Prerequisites for Task Scheduling
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.
Requirements and Prerequisites for Task Scheduling

Model Support
Any.
Supported Domains
Any
User Roles
• Admin
• Maintenace User
Configuring a Recurring Task

You set the frequency for a recurring task using the same process for all types of tasks.
Note that the time displayed on most pages on the web interface is the local time, which is determined by
using the time zone you specify in your local configuration. Further, the Firepower Management Center
automatically adjusts its local time display for daylight saving time (DST), where appropriate. However,
recurring tasks that span the transition dates from DST to standard time and back do not adjust for the transition.
That is, if you create a task scheduled for 2:00 AM during standard time, it will run at 3:00 AM during DST.
Similarly, if you create a task scheduled for 2:00 AM during DST, it will run at 1:00 AM during standard
time.
Procedure
Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.

294
Scheduled Backups
Step 3 From the Job Type drop-down list, select the type of task that you want to schedule.
Step 4 Click Recurring next to the Schedule task to run option.
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 296.
• Download CRL - Schedule certificate revocation list downloads as described in Configuring Certificate
Revocation List Downloads, on page 297.
• Deploy Policies - Schedule policy deployment as described in Automating Policy Deployment, on page
298.
• Nmap Scan - Schedule Nmap scans as described in Scheduling an Nmap Scan, on page 299.
• Report - Schedule report generation as described in Automating Report Generation, on page 300
• Firepower Recommended Rules - Schedule automatic update of Firepower recommended rules as
described in Automating Firepower Recommendations, on page 302
• Download Latest Update - Schedule software or VDB update downloads as described in Automating
Software Downloads, on page 304 or Automating VDB Update Downloads, on page 307.
• 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 306 or Automating VDB
Update Installs, on page 308
• Push Latest Update - Schedule push of software updates to managed devices as described in Automating
Software Pushes, on page 305.
• Update URL Filtering Database - Scheduling automatic update of URL filtering data as described in
Automating URL Filtering Updates Using a Scheduled Task, on page 309
Step 10 Click Save
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 257.
Note that not all devices support remote backups.

295
Schedule FMC Backups
Schedule FMC Backups

You can use the scheduler on the Firepower Management Center to automate both FMC and device backups.
Note that not all devices support remote backups. For more information, see Backup and Restore, on page
257.
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.
Before you begin

Create a backup profile that specifies your backup preferences: Create a Backup Profile, on page 268.
You must be in the global domain to perform this task.
Procedure
Step 1 Choose System > Tools > Scheduling.

Step 2 From the Job Type list, select Backup.
Step 3 Specify whether you want to back up Once or Recurring.
• 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 294.
Step 4 Enter a Job Name.

Step 5 For the Backup Type, click Management Center.
Step 6 Choose a Backup Profile.
Step 7 (Optional) Enter a Comment.
Keep comments brief. They will appear in the Task Details section of the schedule calendar page.
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 1386.
Step 9 Click Save.
Schedule Remote Device Backups

You can use the scheduler on the Firepower Management Center to automate both FMC and device backups.
Note that not all devices support remote backups. For more information, see Backup and Restore, on page
257.

296
Configuring Certificate Revocation List Downloads
Procedure

Step 2 From the Job Type list, select Backup.
Step 3 Specify whether you want to back up Once or Recurring.
• For recurring tasks, see Configuring a Recurring Task, on page 294.
Step 4 Enter a Job Name.

Step 5 For the Backup Type, click Device.
Step 6 Select one or more devices.
If your device is not listed, it does not support remote backup.
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 282.
Step 8 (Optional) Enter a Comment.

Keep comments brief. They will appear in the Task Details section of the schedule calendar page.
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 1386.
Step 10 Click Save.
Configuring Certificate Revocation List Downloads

You must perform this procedure using the local web interface for the Firepower Management Center. In a
multidomain deployment, this task is only supported in the Global domain for the Firepower Management
Center.
The system automatically creates the Download CRL task when you enable downloading a certificate revocation
list (CRL) in the local configuration on an appliance where you enable user certificates or audit log certificates
for the appliance. You can use the scheduler to edit the task to set the frequency of the update.

297
Automating Policy Deployment
Before you begin

• Enable and configure user certificates or audit log certificates and set one or more CRL download URLs.
See Requiring Valid HTTPS Client Certificates, on page 1355 and Require Valid Audit Log Server
Certificates, on page 1382 for more information.
Procedure

Step 3 From Job Type, select Download CRL.
Step 4 Specify how you want to schedule the CRL download, Once or Recurring:
• For recurring tasks, see Configuring a Recurring Task, on page 294 for details.
Step 5 Type a name in the Job Name field.

Step 6 If you want to comment on the task, type a comment in the Comment field.
The comment field appears in the Task Details section of the schedule calendar page; keep comments brief.
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 1386
Automating Policy Deployment

After modifying configuration settings in the FMC, you must deploy those changes to the affected devices.
In a multidomain deployment, you can schedule policy deployments only for your current domain.
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 546 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 548.
Procedure


298
Nmap Scan Automation
Step 3 From Job Type, select Deploy Policies.

Step 4 Specify how you want to schedule the task, Once or Recurring:

Step 6 In the Device field, select a device where you want to deploy policies.
Step 7 Select or deselect the Skip deployment for up-to-date devices check box, as required.
By default, the Skip deployment for up-to-date devices option is enabled to improve performance during
the policy deployment process.
Note The system does not perform a scheduled policy deployment task if a policy deployment initiated
from the Firepower Management Center web interface is in progress. Correspondingly, the system
does not permit you to initiate a policy deployment from the web interface if a scheduled policy
deployment task is in-progress.
The comment field displays in the Tasks Details section of the schedule calendar page; keep comments brief.
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
Out-of-Date Policies, on page 552
Nmap Scan Automation

You can schedule regular Nmap scans of targets on your network. Automated scans allow you to refresh
information previously supplied by an Nmap scan. Because the Firepower System cannot update Nmap-supplied
data, you need to rescan periodically to keep that data up to date. You can also schedule scans to automatically
test for unidentified applications or servers on hosts in your network.
Note that a Discovery Administrator can also use an Nmap scan as a remediation. For example, when an
operating system conflict occurs on a host, that conflict may trigger an Nmap scan. Running the scan obtains
updated operating system information for the host, which resolves the conflict.
If you have not used the Nmap scanning capability before, you configure Nmap scanning before defining a
scheduled scan.
Related Topics
Nmap Scanning, on page 2368
Scheduling an Nmap Scan

After Nmap replaces a host’s operating system, applications, or servers detected by the system with the results
from an Nmap scan, the system no longer updates the information replaced by Nmap for the host.

299
Automating Report Generation
Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan
to scan a host using Nmap, you may want to set up regularly scheduled scans to keep Nmap-supplied operating
systems, applications, or servers up to date. If the host is deleted from the network map and re-added, any
Nmap scan results are discarded and the system resumes monitoring of all operating system and service data
for the host.
In a multidomain deployment:
• You can schedule scans only for your current domain
• The remediation and Nmap targets you select must exist at your current domain or an ancestor domain.
• Choosing to perform an Nmap scan on a non-leaf domain scans the same targets in each descendant of
that domain.
Procedure

Step 3 From Job Type, select Nmap Scan.

Step 6 In the Nmap Remediation field, select an Nmap remediation.
Step 7 In the Nmap Target field, select the scan target.
Step 8 In the Domain field, select the domain whose network map you want to augment.
Tip The comment field appears in the Task Details section of the calendar schedule page; keep comments
brief.
messages.
Step 11 Click Save.
Related Topics
Automating Report Generation

You can automate reports so that they run at regular intervals.
In a multidomain deployment, you can schedule reports only for your current domain.

300
Specify Report Generation Settings for a Scheduled Report
Before you begin

• For reports other than risk reports: Create a report template. See Report Templates, on page 2605 for more
information.
• If you want to distribute email reports using the scheduler, configure a mail relay host and specify report
recipients and message information. See Configuring a Mail Relay Host and Notification Address, on
page 1386 and (for reports other than risk reports) Distributing Reports by Email at Generation Time, on
page 2625 or (for risk reports) Generating, Viewing, and Printing Risk Reports, on page 2604.
• (Optional) Set or change the file name, output format, time window, or email distribution settings of the
scheduled report. See Specify Report Generation Settings for a Scheduled Report, on page 301.
• If you will choose PDF as the report output format, look at the report template and verify that the number
of results in each section of the template does not exceed the limit for PDFs. For information, see Report
Template Fields, on page 2606.
Procedure

Step 3 From the Job Type list, select Report.

Step 6 In the Report Template field, select a risk report or report template.
The comment field appears in the Tasks Details section of the schedule calendar page; keep comments brief.
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.
Specify Report Generation Settings for a Scheduled Report

You must have Admin or Security Analyst privileges to perform this task.

301
Automating Firepower Recommendations
To specify or change the file name, output format, time window, or email distribution settings of a scheduled
report:
Procedure
Step 1 Select Overview > Reporting > Report Templates.

Step 2 Click Edit for the report template to change.
Step 3 If you will select PDF output:
a) Look to see whether any of the sections in the report shows a yellow triangle beside the number of results.
b) If you see any yellow triangles, mouse over the triangle to view the maximum number of results allowable
for that section for PDF output.
c) For each section with a yellow triangle, reduce the number of results to a number below the limit.
d) When there are no more yellow triangles, click Save.
Note If you want to change report generation settings without generating the report now, you must click
Generate from the template configuration page. Changes will not be saved if you click Generate
from the template list view unless you generate the report.
Step 5 Modify settings.

Step 6 To save the new settings without generating the report, click Cancel.
To save the new settings and generate the report, click Generate and skip the rest of the steps in this procedure.
Step 7 Click Save.

Step 8 If you see a prompt to save even though you haven't made changes, click OK.
Automating Firepower Recommendations

You can automatically generate rule state recommendations based on network discovery data for your network
using the most recently saved configuration settings in a custom intrusion policy.
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.

302
Software Update Automation
Before you begin

• Configure Firepower recommended rules in an intrusion policy as described in Generating and Applying
Firepower Recommendations, on page 2008
• If you want to email task status messages, configure a valid email relay server.
• You must have the Threat Smart License or Protection Classic License to generate recommendations.
Procedure

Step 3 From Job Type, choose Firepower Recommended Rules.
Step 5 Enter a name in the Job Name field.

Step 6 Next to Policies, choose one or more intrusion policies where you want to generate recommendations. Check
All Policies check box to choose all intrusion policies.
Step 7 (Optional) Enter a comment in the Comment field.
Keep comments brief. Comments appear in the Task Details section of the schedule calendar page.
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 1949
About Firepower Recommended Rules, on page 2005
Software Update Automation

You can automatically download and apply most patches and feature releases to the Firepower System.
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 304. 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.

303
Automating Software Downloads
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
System Updates, on page 231
Automating Software Downloads

You can create a scheduled task that automatically downloads the latest software updates from Cisco. You
can use this task to schedule download of updates you plan to install manually.
Procedure


304
Automating Software Pushes
Step 3 From the Job Type list, select Download Latest Update.

Step 6 Next to Update Items, check Software check box.
messages.
Step 9 Click Save.
Related Topics
Automating Software Pushes

If you want to automate the installation of software updates on managed devices, you must push the updates
to the devices before installing.
When you create the task to push software updates to managed devices, make sure you allow enough time
between the push task and a scheduled install task for the updates to be copied to the device.
Procedure

Step 3 From the Job Type list, select Push Latest Update.

Step 6 From the Device drop-down list, select the device that you want to update.
messages.

305
Automating Software Installs
Step 9 Click Save.
Related Topics
Automating Software Installs

Make sure you allow enough time between the task that pushes the update to a managed device and the task
that installs the update.
Caution Depending on the update being installed, the appliance may reboot after the software is installed.
Procedure

Step 3 From the Job Type list, select Install Latest Update.

Step 6 From the Device drop-down list, select the appliance (including the Firepower Management Center) where
you want to install the update.
Step 7 Next to Update Items, check the Software check box.
messages.
Step 10 Click Save.
Related Topics
Vulnerability Database Update Automation

Cisco uses vulnerability database (VDB) updates to expand the list of network assets, traffic, and vulnerabilities
that the Firepower System recognizes. You can use the scheduling feature to update the VDB, thereby ensuring
that you are using the most up-to-date information to evaluate the hosts on your network.

306
Automating VDB Update Downloads
When automating VDB updates, you must automate two separate steps:
• Downloading the VDB update.
• Installing the VDB update.
As a part of initial configuration the FMC downloads and installs the latest vulnerability database (VDB)
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 546 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
Automating VDB Update Downloads

Procedure

Step 3 From the Job Type list, select Download Latest Update.

307
Automating VDB Update Installs

Step 6 Next to Update Items, check the Vulnerability Database check box.
The comment field appears in the Task Details section of the calendar schedule page; keep comments brief.
messages.
Step 9 Click Save.
Related Topics
Automating VDB Update Installs

Allow enough time between the task that downloads the VDB update and the task that installs the update.
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 546 for more information.
Procedure

Step 3 From the Job Type list, select Install Latest Update.

Step 6 From the Device drop-down list, select the FMC.
Step 7 Next to Update Items, check the Vulnerability Database check box.
Tip The comment field appears in the View Tasks section of the page, so you should try to keep it
relatively short.

308
Automating URL Filtering Updates Using a Scheduled Task
messages.
Step 10 Click Save.
Related Topics
Automating URL Filtering Updates Using a Scheduled Task

In order to ensure that threat data for URL filtering is current, the system must obtain data updates from the
Cisco Collective Security Intelligence (CSI) cloud.
By default, when you enable URL filtering, automatic updates are enabled. However, if you need to control
when these updates occur, use the procedure described in this topic instead of the default update mechanism.
Although daily updates tend to be small, if it has been more than five days since your last update, new URL
filtering 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.
Before you begin

• Ensure the Firepower Management Center has internet access; see Security, Internet Access, and
Communication Ports, on page 3031.
• Ensure that URL filtering is enabled. See Enable URL Filtering Using Category and Reputation, on page
• Verify that Enable Automatic Updates is not selected on the Cloud Services under the System >
Integration menu.
• You must be in the global domain to perform this task. You must also have the URL Filtering license.
Procedure

Step 3 From the Job Type list, select Update URL Filtering Database.
Step 4 Specify how you want to schedule the update, Once or Recurring:


309
Scheduled Task Review
messages.
Step 8 Click Save.
Related Topics
Scheduled Task Review

After adding scheduled tasks, you can view them and evaluate their status. The View Options section of the
page allows you to view scheduled tasks using a calendar and a list of scheduled tasks.
The Calendar view option allows you to view which scheduled tasks occur on which day.
The Task List shows a list of tasks along with their status. The task list appears below the calendar when you
open the calendar. In addition, you can view it by selecting a date or task from the calendar.
You can edit a scheduled task that you previously created. This feature is especially useful if you want to test
a scheduled task once to make sure that the parameters are correct. Later, after the task completes successfully,
you can change it to a recurring task.
There are two types of deletions you can perform from the Schedule View page. You can delete a specific
one-time task that has not yet run or you can delete every instance of a recurring task. If you delete an instance
of a recurring task, all instances of the task are deleted. If you delete a task that is scheduled to run once, only
that task is deleted.
Task List Details

Table 26: Task List Columns
Column Description
Name Displays the name of the scheduled task and the

comment associated with it.
Type Displays the type of scheduled task.
Start Time Displays the scheduled start date and time.
Frequency Displays how often the task is run.
Last Run Time Displays the actual start date and time.
For a recurring task, this applies to the most recent
execution.

310
Viewing Scheduled Tasks on the Calendar
Column Description
Last Run Status Describes the current status for a scheduled task:
• A Check Mark ( ) indicates that the task ran

successfully.
• A question mark icon (Question Mark ( ) )

indicates that the task is in an unknown state.
• An exclamation mark icon ( ) indicates that

the task failed.
For a recurring task, this applies to the most recent

execution.
Next Run Time Displays the next execution time for a recurring task.
Displays N/A for a one-time task.
Creator Displays the name of the user that created the

scheduled task.
Edit Edits the scheduled task.
Delete Deletes the scheduled task.
Viewing Scheduled Tasks on the Calendar

In a multidomain deployment, you can view scheduled tasks only for your current domain.
Procedure

Step 2 You can perform the following tasks using the calendar view:
• Click Double Left Arrow ( ) to move back one year.
• Click Single Left Arrow ( ) to move back one month.
• Click Single Right Arrow ( ) to move forward one month.
• Click Double Right Arrow ( ) to move forward one year.

• Click Today to return to the current month and year.
• Click Add Task to schedule a new task.
• Click a date to view all scheduled tasks for the specific date in a task list table below the calendar.

311
Editing Scheduled Tasks
• Click a specific task on a date to view the task in a task list table below the calendar.
Editing Scheduled Tasks

In a multidomain deployment, you can edit scheduled tasks only for your current domain.
Procedure

Step 2 On the calendar, click either the task that you want to edit or the day on which the task appears.
Step 3 In the Task Details table, click Edit ( ) next to the task you want to edit.
Step 4 Edit the task.
Step 5 Click Save.
Deleting Scheduled Tasks

In a multidomain deployment, you can delete scheduled tasks only for your current domain.
Procedure

Step 2 In the calendar, click the task you want to delete. For a recurring task, click an instance of the task.
Step 3 In the Task Details table, click Delete ( ), then confirm your choice.
History for Scheduled Tasks

Automatically 6.6 For a new or newly-restored-to-factory-defaults FMC the Initial
scheduled updates Configuration Wizard automatically schedules a daily intrusion rule
update from the Cisco support site. The FMC deploys automatic intrusion
rule updates when it next deploys affected polices.
No modified screens

312

Automatically 6.5 For a new or newly-restored-to-factory-defaults FMC the Initial
scheduled updates Configuration Wizard automatically schedules the following:
• a weekly task to download software updates for the FMC and its
managed devices.
• a weekly task to perform a locally-stored configuration-only backup.
No modified screens
Scheduled remote 6.4 You can now use the FMC to schedule remote backups of certain
backups of managed managed devices.
devices
New/modified screens: System > Tools > Scheduling > add/edit task
> choose Job Type: Backup > choose a Backup Type
Supported platforms: FTD physical platforms, FTDv for VMware
Exceptions: No support for FTD clustered devices or container instances

313

314
CHAPTER 11
Data Storage
• Data Stored on the FMC, on page 315
• External Data Storage, on page 317
• History for Data Storage, on page 319
Data Stored on the FMC

For See
General information about data storage on the FMC The Disk Usage Widget, on page 412
Purging old data Purging Data from the FMC Database, on page 316
Allowing external access to the data on the FMC (this External Database Access Settings, on page 1356
is an advanced feature)
Backups Manage Backups and Remote Storage, on page 282

and subtopics
Reports Configuring Local Storage, on page 1370
Events Connection Logging, on page 2801

Database Event Limits, on page 1358 and subtopics
Network discovery data Network Discovery Data Storage Settings, on page

2514 and subsequent topics
Files Information about storing files in File Policies and

Malware Protection, on page 1841, including best
practices.
File and Malware Inspection Performance and Storage
Tuning, on page 1881
Packet data Edit General Settings, on page 385
Users and user activity The Users Database, on page 2345

The User Activity Database, on page 2345

315
Purging Data from the FMC Database
Purging Data from the FMC Database

You can use the database purge page to purge discovery, identity, connection, and Security Intelligence data
files from the FMC databases. Note that when you purge a database, the appropriate process is restarted.
Caution Purging a database removes the data you specify from the Firepower Management Center. After the data is
deleted, it cannot be recovered.
Before you begin

You must have Admin or Security Analyst privileges to purge data. You can be in the global domain only.
Procedure
Step 1 Choose System > Tools > Data Purge.

Step 2 Under Discovery and Identity, perform any or all of the following:
• Check the Network Discovery Events check box to remove all network discovery events from the
database.
• Check the Hosts check box to remove all hosts and Host Indications of Compromise flags from the
database.
• Check the User Activity check box to remove all user activity events from the database.
• Check the User Identities check box to remove all user login and user history data from the database,
as well as User Indications of Compromise flags.
Step 3 Under Connections, perform any or all of the following:

• Check the Connection Events check box to remove all connection data from the database.
• Check the Connection Summary Events check box to remove all connection summary data from the
database.
• Check the Security Intelligence Events check box to remove all Security Intelligence data from the
database.
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.
Step 4 Click Purge Selected Events.

The items are purged and the appropriate processes are restarted.

316
External Data Storage
External Data Storage

You can optionally use remote data storage for store certain types of data.
For See
Backups Manage Backups and Remote Storage, on page 282 and subtopics
Remote Storage Management, on page 1370 and subtopics
Reports Remote Storage Management, on page 1370 and subtopics

Moving Reports to Remote Storage, on page 2628
Events Information about syslog and other resources in Event Analysis Using External Tools,
on page 2695
Remote Data Storage in the Stealthwatch Cloud, on page 318
Remote Data Storage on a Stealthwatch Appliance, on page 318
If you store connection events remotely, consider disabling storage of connection
events on your FMC. For information, see Database Event Limits, on page 1358 and
subtopics.
Important If you will use syslog or store events externally, avoid special characters in object names such as policy and
rule names. Object names should not contain special characters, such as commas, that the receiving application
may use as separators.
Comparison of Cisco Security Analytics and Logging Remote Event Storage

Options
Similar but different options for storing event data externally to your Firepower Management Center:
On Premises SaaS
You purchase, license, and set up the storage system You purchase licenses and a data storage plan and
behind your firewall. send your data to the Cisco cloud.
Supported event types: Supported event types:

• Connection • Connection
• Security Intelligence • Security Intelligence
• Intrusion • Intrusion
• File and Malware • File and Malware
• LINA

317
Remote Data Storage in the Stealthwatch Cloud
On Premises SaaS
Supports both syslog and direct integration. Supports both syslog and direct integration.
• View all events on the Stealthwatch Management View events in CDO or Stealthwatch, depending on
Console. your license. Cross-launch from FMC event viewer.
• Cross-launch from FMC event viewer to view
events on the Stealthwatch Management Console.
• View remotely stored connection and Security
Intelligence events in FMC
For more information, see the links in Remote Data For more information, see the links in Remote Data
Storage on a Stealthwatch Appliance, on page 318. Storage in the Stealthwatch Cloud, on page 318.
Remote Data Storage in the Stealthwatch Cloud

Send select Firepower event data to the Stealthwatch 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.
You can send events either directly or via syslog.
Remote Data Storage on a Stealthwatch Appliance

If you require more data storage than your Firepower appliance can provide, you can use Cisco Security
Analytics and Logging (On Premises) to store Firepower data on a Stealthwatch appliance. For complete
information, see the documentation available from https://cisco.com/go/sal-on-prem-docs.
You can view connection events in FMC even if they are stored on a Stealthwatch appliance. See Work in
Firepower Management Center with Connection Events Stored on a Stealthwatch Appliance, on page 2745.

318
History for Data Storage

Exempt low priority connection events from 7.0 If you choose not to store connection events
event rate limits on the FMC because you are storing them
on a remote volume, those events do not
count towards the flow rate limits for your
FMC hardware device.
If you send events to Cisco Security
Analytics and Logging (On Premises) using
the new 7.0 configurations, you configure
this setting as part of that integration.
Otherwise, see information about the
Connection Database in Database Event
Limits, on page 1358.
New/Modified pages: None. Behavior
change only.
Improved process for sending events to a 7.0 A new wizard streamlines sending events
Stealthwatch appliance directly to a Stealthwatch appliance using
Cisco Security Analytics and Logging (On
Premises).
The wizard also allows you to see remotely
stored connection events while viewing
event pages on your FMC, and to
cross-launch from FMC to view events on
your Stealthwatch appliance.
If you have already configured your system
to send events using syslog, events will
continue to be sent using syslog unless you
disable those configurations.
For details, see the documentation
referenced in Remote Data Storage on a
Stealthwatch Appliance, on page 318.
New/Modified pages: The System >
Logging > Security Analytics & Logging
page now displays the wizard instead of the
configuration for creating cross-launch
options.

319
Remote data storage on a Stealthwatch 6.7 You can now store large volumes of
appliance Firepower event data remotely, using Cisco
Security Analytics and Logging (On
Premises). When viewing events in FMC,
you can quickly cross-launch to view events
in your remote data storage location.
Supported events: Connection, Security
Intelligence, intrusion, file, and malware.
Events are sent using syslog.
This solution depends on availability of
Stealthwatch Management Console (SMC)
Virtual Edition running Stealthwatch
Enterprise (SWE) version 7.3.
See Remote Data Storage on a Stealthwatch
Appliance, on page 318.
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.

320
CHAPTER 12
Firepower Management Center High Availability
The following topics describe how to configure Active/Standby high availability of Cisco Firepower
Management Centers:
• About Firepower Management Center High Availability, on page 321
• Requirements for Firepower Management Center High Availability, on page 326
• Prerequisites for Firepower Management Center High Availability, on page 329
• Establishing Firepower Management Center High Availability, on page 329
• Viewing Firepower Management Center High Availability Status, on page 331
• Configurations Synced on Firepower Management Center High Availability Pairs, on page 332
• Configuring External Access to the FMC Database in a High Availability Pair, on page 332
• Using CLI to Resolve Device Registration in Firepower Management Center High Availability, on page
333
• Switching Peers in a Firepower Management Center High Availability Pair, on page 333
• Pausing Communication Between Paired Firepower Management Centers, on page 334
• Restarting Communication Between Paired Firepower Management Centers, on page 334
• Changing the IP address of a Firepower Management Center in a High Availability Pair, on page 335
• Disabling Firepower Management Center High Availability, on page 335
• Replacing FMCs in a High Availability Pair, on page 336
• History for FMC High Availability, on page 340
About Firepower Management Center High Availability

To ensure the continuity of operations, the high availability feature allows you to designate redundant Firepower
Management Centers to manage devices. Firepower Management Centers support Active/Standby high
availability where one appliance is the active unit and manages devices. The standby unit does not actively
manage devices. The active unit writes configuration data into a data store and replicates data for both units,
using synchronization where necessary to share some information with the standby unit.
Active/Standby high availability lets you configure a secondary Firepower Management Center to take over
the functionality of a primary Firepower Management Center if the primary fails. When the primary Firepower
Management Center fails, you must promote the secondary Firepower Management Center to become the
active unit.
Event data streams from managed devices to both Firepower Management Centers in the high availability
pair. If one Firepower Management Center fails, you can monitor your network without interruption using
the other Firepower Management Center.

321
Roles v. Status in Firepower Management Center High Availability
Note that Firepower Management Centers configured as a high availability pair do not need to be on the same
trusted management network, nor do they have to be in the same geographic location.
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.
About Remote Access VPN High Availability

If the primary device has Remote Access VPN configuration with an identity certificate enrolled using a
CertEnrollment object, the secondary device must have an identity certificate enrolled using the same
CertEnrollment object. The CertEnrollment object can have different values for the primary and secondary
devices due to device-specific overriddes. The limitation is only to have the same CertEnrollment object
enrolled on the two devices before the high availability formation.
Roles v. Status in Firepower Management Center High Availability

Primary/Secondary Roles
When setting up Firepower Management Centers in a high availability pair, you configure one Firepower
Management Center to be primary and the other as secondary. During configuration, the primary unit's policies
are synchronized to the secondary unit. After this synchronization, the primary Firepower Management Center
becomes the active peer, while the secondary Firepower Management Center becomes the standby peer, and
the two units act as a single appliance for managed device and policy configuration.
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.
Event Processing on Firepower Management Center High Availability Pairs

Since both Firepower Management Centers in a high availability pair receive events from managed devices,
the management IP addresses for the appliances are not shared. This means that you do not need to intervene
to ensure continuous processing of events if a Firepower Management Center fails.
AMP Cloud Connections and Malware Information

Although they share file policies and related configurations, Firepower Management Centers in a high
availability pair share neither Cisco AMP cloud connections nor malware dispositions. To ensure continuity
of operations, and to ensure that detected files’ malware dispositions are the same on both Firepower
Management Centers, both primary and secondary Firepower Management Centers must have access to the
AMP cloud.

322
URL Filtering and Security Intelligence
URL Filtering and Security Intelligence

URL filtering and Security Intelligence configurations and information are synchronized between Firepower
Management Centers in a high availability deployment. However, only the primary Firepower Management
Center downloads URL category and reputation data for updates to Security Intelligence feeds.
If the primary Firepower Management Center fails, not only must you make sure that the secondary Firepower
Management Center can access the internet to update threat intelligence data, but you must also use the web
interface on the secondary Firepower Management Center to promote it to active.
User Data Processing During Firepower Management Center Failover

If the primary Firepower Management Center fails, the Secondary Firepower Management Center propagates
to managed devices user-to-IP mappings from the TS Agent identity source; and propagates SGT mappings
from the ISE/ISE-PIC identity source. Users not yet seen by identity sources are identified as Unknown.
After the downtime, the Unknown users are re identified and processed according to the rules in your identity
policy.
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.
Cisco Threat Intelligence Director (TID) and High Availability Configurations

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.
For details, see About Backing Up and Restoring TID Data, on page 1900.
Single Sign-On and High Availability Pairs

FMCs in a high availability configuration can support Single Sign-On, but you must keep the following
considerations in mind:
• SSO configuration is not synchronized between the members of the high availability pair; you must
configure SSO separately on each member of the pair.
• Both FMCs in a high availability pari must use the same identity provider (IdP) for SSO. You must
configure a service provider application at the IdP for each FMC configured for SSO.
• In a high availabilty pair of FMCs where both are configured to support SSO, before a user can use SSO
to access the secondary FMC for the first time, that user must first use SSO to log into the primary FMC
at least once.

323
Firepower Management Center High Availability Behavior During a Backup
• When configuring SSO for FMCs in a high availability pair:

• If you configure SSO on the primary FMC, you are not required to configure SSO on the secondary
FMC.
• If you configure SSO on the secondary FMC, you are required to configure SSO on the primary
FMC as well. (This is because SSO users must log in to the primary FMC at least once before
logging into the secondary FMC.)
Related Topics
Firepower Management Center High Availability Behavior During a Backup

When you perform a Backup on a Firepower Management Center high availability pair, the Backup operation
pauses synchronization between the peers. During this operation, you may continue using the active Firepower
Management Center, but not the standby peer.
After Backup is completed, synchronization resumes, which briefly disables processes on the active peer.
During this pause, the High Availability page briefly displays a holding page until all processes resume.
Firepower Management Center High Availability Split-Brain

If the active Firepower Management Center in a high-availability pair goes down (due to power issues,
network/connectivity issues), you can promote the standby Firepower Management Center to an active state.
When the original active peer comes up, both peers can assume they are active. This state is defined as
'split-brain'. When this situation occurs, the system prompts you to choose an active appliance, which demotes
the other appliance to standby.
If the active Firepower Management Center goes down (or disconnects due to a network failure), you may
either break high availability or switch roles. The standby Firepower Management Center enters a degraded
state.
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.
Upgrading Firepower Management Centers in a High Availability Pair

Cisco electronically distributes several different types of updates periodically. These include major and minor
upgrades to the system software. You may need to install these updates on Firepower Management Centers
in a high availability setup.

324
Troubleshooting Firepower Management Center High Availability
Warning Make sure that there is at least one operational Firepower Management Center during an upgrade.
Before you begin

Read the release notes or advisory text that accompanies the upgrade. The release notes provide important
information, including supported platforms, compatibility, prerequisites, warnings, and specific installation
and uninstallation instructions.
Procedure
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 334.
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.
Troubleshooting Firepower Management Center High Availability

This section lists troubleshooting information for some common Firepower Management Center high availability
operation errors.
Error Description Solution
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

325
Requirements for Firepower Management Center High Availability
Error Description Solution
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.
2. Pause mirroring operations by using

option 5.
Reload the Firepower Management
Center web interface.
3. Use the web interface to resume
synchronization. Choose System >
Integration, then click the High
Availability tab and choose Resume
Synchronization.
Requirements for Firepower Management Center High

Availability
Model Support
See Hardware Requirements, on page 327.
Virtual Model Support

See Virtual Platform Requirements, on page 327.
Supported Domains
Global
User Roles
Admin

326
Hardware Requirements
• Supported hardware models:
MC1000, MC1600, MC2500, MC2600, MC4500, MC4600
• 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.
• See also License Requirements for FMC High Availability Configurations, on page 328.
Virtual Platform Requirements

Requirements for establishing high availability (HA) using two FMCv virtual appliances:
• FMCv must be running on VMware ESXi.
• FMCv-HA is supported on FMCv 10, 25, and 300.
• The two FMCv virtual appliances in a high availability configuration must have the same device
management capacity. For example, you cannot pair an FMCv 25 with an FMCv 300.
• High availability licensing requirements are different for virtual vs hardware FMC. See License
Requirements for FMC High Availability Configurations, on page 328.
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 406
• 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.
of the vulnerability database update installed.
of the LSP (Lightweight Security Package) installed.

327
License Requirements for FMC High Availability Configurations
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 for FMC High Availability Configurations

Hardware Firepower Management Center: All Licensing Types
No special license is required for Firepower Management Center hardware appliances in a high availability
pair.
A device managed with Firepower Management Center hardware appliances in a high availability configuration
requires the same number of feature licenses and subscriptions as a device managed by a single Firepower
Management Center hardware appliance.
In Specific License Reservation deployments, only the primary FMC requires a Specific License Reservation.
The system automatically replicates all feature licenses from active to standby Firepower Management Center
when the high-availability pair is formed, and updates license changes during ongoing data synchronization,
so the licenses are available on failover.
Virtual Firepower Management Center (FMCv): All Licensing Types

You will need two identically licensed FMCv's (with entitlements for 10, 25, or 300 managed devices.)
Example: For an FMCv high availability pair managing 10 FTD devices and 3 NGIPS devices, you need:
• Two (2) FMCv25 entitlements
• 10 FTD entitlements, as described below under Smart Licensing
• 3 NGIPS entitlements, as described below under Classic Licensing
If you break the high availability pair, the FMCv entitlements associated with the secondary FMCv are released.
(In the example, you would then have two standalone FMCv25’s.)
Smart Licensing
Each FTD device requires the same licenses whether managed by a single FMC or by FMCs in a high
availability pair (hardware or virtual).
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

328
Prerequisites for Firepower Management Center High Availability
Classic Licensing
Each device requires the same licenses whether managed by a single FMC or by FMCs in a high availability
pair (hardware or virtual).
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.
Prerequisites for Firepower Management Center High

Availability
Before establishing a Firepower Management Center high availability pair:
• Export required policies from the intended secondary Firepower Management Center to the intended
primary Firepower Management Center. For more information, see Exporting Configurations, on page
289.
• Make sure that the intended secondary Firepower Management Center does not have any devices added
to it. Delete devices from the intended secondary Firepower Management Center and register these
devices to the intended primary Firepower Management Center. For more information see Delete a
Device from the FMC, on page 358 and Add a Device to the FMC, on page 355.
• Import the policies into the intended primary Firepower Management Center. For more information, see
Importing Configurations, on page 290.
• On the intended primary Firepower Management Center, verify the imported policies, edit them as needed
and deploy them to the appropriate device. For more information, see Deploy Configuration Changes,
on page 535.
• On the intended primary Firepower Management Center, associate the appropriate licenses to the newly
added devices. For more information see Assign Licenses to Managed Devices from the Device
Management Page, on page 207.
You can now proceed to establish high availability. For more information, see Establishing Firepower
Management Center High Availability, on page 329.
Establishing Firepower Management Center High Availability

Establishing high availability can take a significant amount of time, even several hours, depending on the
bandwidth between the peers and the number of policies. It also depends on the number of devices registered
to the active Firepower Management Center, which need to be synced to the standby Firepower Management
Center. You can view the High Availability page to check the status of the high availability peers.
Before you begin

• Confirm that both the Firepower Management Centers adhere to the high availability system requirements.
For more information , see Requirements for Firepower Management Center High Availability, on page
326.

329
Establishing Firepower Management Center High Availability
• Confirm that you completed the prerequisites for establishing high availability. For more information,
see Prerequisites for Firepower Management Center High Availability, on page 329.
Procedure
Step 1 Log into the Firepower Management Center that you want to designate as the secondary.
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 1363 for more information.
Step 9 Using an account with Admin access, log into the Firepower Management Center that you want to designate
as the primary.
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.
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.

330
Viewing Firepower Management Center High Availability Status
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 333.
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.
Procedure
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
You can view:
Summary Information
• The health status of the high availability pair. The status of a correctly functioning system will oscillate
between "Healthy" and "Synchronization task is in progress" as the standby unit receives configuration
changes from the active unit.
• 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

331
Configurations Synced on Firepower Management Center High Availability Pairs
Configurations Synced on Firepower Management Center High

Availability Pairs
When you establish high availability between two Firepower Management Centers, the following configuration
data is synced between them:
• License entitlements
• Access control policies
• Intrusion rules
• Malware and file policies
• DNS policies
• Identity policies
• SSL policies
• 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 2597.
Configuring External Access to the FMC Database in a High

Availability Pair
In a high availability setup, we recommend you to use only the active peer to configure the external access
to the database. When you configure the standby peer for external database access, it leads to frequent
disconnections. To restore the connectivity, you must Pausing Communication Between Paired Firepower
Management Centers and Restarting Communication Between Paired Firepower Management Centers the
synchronization of the standby peer. For information on how to enable external database access to Firepower
Management Centers, see Enabling External Access to the Database, on page 1357 .

332
Using CLI to Resolve Device Registration in Firepower Management Center High Availability
Using CLI to Resolve Device Registration in Firepower

Management Center High Availability
If automatic device registration fails on the standby Firepower Management Center, but appears to be registered
to the active Firepower Management Center, complete the following steps:
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.
Procedure
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 4 Run the CLI command: configure manager add.

This command configures the device to initiate a connection to a Firepower Management Center.
Tip Configure remote management on the device, only for the active Firepower Management Center.
When high availability is established, devices are automatically added to be managed by the standby
Step 5 Log into the active Firepower Management Center and register the device.
Switching Peers in a Firepower Management Center High

Availability Pair
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:
Procedure

333
Pausing Communication Between Paired Firepower Management Centers
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.
Pausing Communication Between Paired Firepower

Management Centers
If you want to temporarily disable high availability, you can disable the communications channel between
the Firepower Management Centers. If you pause synchronization on the active peer, you can resume
synchronization on either the standby or active peer. However, if you pause synchronization on the standby
peer, you only can resume synchronization on the standby peer.
Procedure
Step 4 Choose Pause Synchronization.
Restarting Communication Between Paired Firepower

Management Centers
If you temporarily disable high availability, you can restart high availability by enabling the communications
channel between the Firepower Management Centers. If you paused synchronization on the active unit, you
can resume synchronization on either the standby or active unit. However, if you paused synchronization on
the standby unit, you only can resume synchronization on the standby unit.
Procedure
Step 4 Choose Resume Synchronization.

334
Changing the IP address of a Firepower Management Center in a High Availability Pair
Changing the IP address of a Firepower Management Center in

a High Availability Pair
If the IP address for one of the high availability peers changes, high availability enters a degraded state. To
recover high availability, you must manually change the IP address.
Procedure
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.
Disabling Firepower Management Center High Availability

Procedure
Step 1 Log into one of the Firepower Management Centers in the high availability pair.
Step 4 Choose Break High Availability.
Step 5 Choose one of the following options for handling managed devices:
• To control all managed devices with this Firepower Management Center, choose Manage registered
devices from this console. All devices will be unregistered from the peer.
• To control all managed devices with the other Firepower Management Center, choose Manage registered
devices from peer console. All devices will be unregistered from this Firepower Management Center.
• To stop managing devices altogether, choose Stop managing registered devices from both consoles.
All devices will be unregistered from both Firepower Management Centers.

335
Replacing FMCs in a High Availability Pair
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 195.
Step 6 Click OK.
Replacing FMCs in a High Availability Pair

If you need to replace a failed unit in a Firepower Management Center high availability pair, you must follow
one of the procedures listed below. The table lists four possible failure scenarios and their corresponding
replacement procedures.
Failure Status Data Backup Status Replacement Procedure
Primary FMC Data backup successful Replace a Failed Primary FMC (Successful Backup), on
failed page 336
Data backup not successful Replace a Failed Primary FMC (Unsuccessful Backup),
on page 337
Secondary FMC Data backup successful Replace a Failed Secondary FMC (Successful Backup),
failed on page 338
Data backup not successful Replace a Failed Secondary FMC (Unsuccessful Backup),
on page 339
Replace a Failed Primary FMC (Successful Backup)

Two Firepower Management Centers, FMC1 and FMC2, are part of a high availability pair. FMC1 is the
primary and FMC2 is the secondary. This task describes the steps to replace a failed primary Firepower
Management Center, FMC1, when data backup from the primary is successful.
Before you begin

Verify that the data backup from the failed primary Firepower Management Center is successful.
Procedure
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 333.

336
Replace a Failed Primary FMC (Unsuccessful Backup)
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 333.
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 204.
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.
Replace a Failed Primary FMC (Unsuccessful Backup)

Two Firepower Management Centers - FMC1 and FMC2 are part of a high availability pair. FMC1 is the
primary and FMC2 is the secondary. This task describes the steps to replace a failed primary Firepower
Management Center -FMC1 when data backup from the primary is unsuccessful.
Procedure
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 333.
This promotes the secondary Firepower Management Center - FMC2 to active.

337
Replace a Failed Secondary FMC (Successful Backup)
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 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 196.
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 335. 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 329.
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 204.
Step 9 Register a Smart License to the primary Firepower Management Center - FMC2. For more information see
Register Smart Licenses, on page 174.
What to do next
Replace a Failed Secondary FMC (Successful Backup)

primary and FMC2 is the secondary. This task describes the steps to replace a failed secondary Firepower
Management Center -FMC2 when data backup from the secondary is successful.
Before you begin

Verify that the data backup from the failed secondary Firepower Management Center is successful.

338
Replace a Failed Secondary FMC (Unsuccessful Backup)
Procedure
Step 2 Continue to use the primary Firepower Management Center - FMC1 as the active Firepower Management
Center.
Step 4 Restore the data backup from FMC2 to the new Firepower Management Center.
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 334.
Classic and Smart Licenses work seamlessly.
What to do next
Replace a Failed Secondary FMC (Unsuccessful Backup)

primary and FMC2 is the secondary. This task describes the steps to replace a failed secondary Firepower
Management Center -FMC2 when data backup from the secondary is unsuccessful.
Procedure
Step 2 Continue to use the primary Firepower Management Center - FMC1 as the active Firepower Management
Center.
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 335. 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 329.
• 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.

339
History for FMC High Availability
• Classic and Smart Licenses work seamlessly.
What to do next
History for FMC High Availability

FMC high availability 6.7 You can now achieve FMC high availability using FMCv running on
with FMCv on VMWare.
VMWare
See requirements at Virtual Platform Requirements, on page 327.
Supported platforms: FMCv 10, 25, and 300 for VMWare
Single Sign-On 6.7 When configuring one or both members of a high-availability pair for
single sign-on, you must take into account special considerations.
Supported platforms: FMC.

340
CHAPTER 13
Device Management Basics
The following topics describe how to manage devices in the Firepower System:
• About Device Management, on page 341
• Requirements and Prerequisites for Device Management, on page 349
• Complete the FTD Initial Configuration, on page 349
• Add a Device to the FMC, on page 355
• Delete a Device from the FMC, on page 358
• Add a Device Group, on page 359
• Configure Device Settings, on page 360
• Change the Manager for the Device, on page 390
• Viewing Device Information, on page 395
• History for Device Management Basics, on page 399
About Device Management

Use the Firepower Management Center to manage your devices.
About the Firepower Management Center and Device Management

When the Firepower Management Center manages a device, it sets up a two-way, SSL-encrypted communication
channel between itself and the device. The Firepower Management Center uses this channel to send information
to the device about how you want to analyze and manage your network traffic to the device. As the device
evaluates the traffic, it generates events and sends them to the Firepower Management Center using the same
channel.
By using the Firepower Management Center to manage devices, you can:
• configure policies for all your devices from a single location, making it easier to change configurations
• install various types of software updates on devices
• push health policies to your managed devices and monitor their health status from the Firepower
Management Center
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.

341
What Can Be Managed by a Firepower Management Center?
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.
What Can Be Managed by a Firepower Management Center?

You can use the Firepower Management Center as a central management point in a Firepower System
deployment to manage the following devices:
• ASA FirePOWER modules
• NGIPSv devices
• Firepower Threat Defense (physical hardware and virtual)
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.
Beyond Policies and Events

In addition to deploying policies to devices and receiving events from them, you can also perform other
device-related tasks on the Firepower Management Center.
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.

342
About Device Management Interfaces
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.
About Device Management Interfaces

Each device includes a single dedicated Management interface for communicating with the FMC. You can
optionally configure the device to use a data interface for management instead of the dedicated Management
interface.
You can perform initial setup on the management interface, or on the console port.
Management interfaces are also used to communicate with the Smart Licensing server, to download updates,
and to perform other management functions.
Management Interfaces on Managed Devices

When you set up your device, you specify the FMC IP address that you want to connect to. Both management
and event traffic go to this address at initial registration. Note: In some situations, the FMC might establish
the initial connection on a different management interface; subsequent connections should use the management
interface with the specified IP address.
If the FMC has a separate event-only interface, the managed device sends subsequent event traffic is sent to
the FMC event-only interface if the network allows. In addition, some managed-device models include an
additional management interface that you can configure for event-only traffic. Note that if you configure a
data interface for management, you cannot use separate management and event interfaces. If the event network
goes down, then event traffic reverts to the regular management interfaces on the FMC and/or on the managed
device.
About Using an FTD Data interface for Management

You can use either the dedicated Management interface or a regular data interface for communication with
the FMC. FMC access on a data interface is useful if you want to manage the FTD remotely from the outside
interface, or you do not have a separate management network.
FMC access from a data interface has the following limitations:
• You can only enable FMC access on one physical, data interface. You cannot use a subinterface or
EtherChannel.
• This interface cannot be management-only.
• Routed firewall mode only, using a routed interface.
• High Availability is not supported. You must use the Management interface in this case.

343
Management Interface Support Per Device Model
• PPPoE is not supported. If your ISP requires PPPoE, you will have to put a router with PPPoE support
between the FTD and the WAN modem.
• The interface must be in the global VRF only.
• You cannot use separate management and event-only interfaces.
• SSH is not enabled by default for data interfaces, so you will have to enable SSH later using FMC.
Because the Management interface gateway will be changed to be the data interfaces, you also cannot
SSH to the Management interface from a remote network unless you add a static route for the Management
interface using the configure network static-routes command.
Management Interface Support Per Device Model

See the hardware installation guide for your model for the management interface locations.
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 811
for more information.
See the following table for supported management interfaces on each managed device model.
Table 27: Management Interface Support on Managed Devices
Model Management Interface Optional Event Interface
NGIPSv eth0 No support
ASA FirePOWER services module eth0 No support

on the ASA 5508-X, or 5516-X
Note eth0 is the internal name
of the Management 1/1
interface.
ASA FirePOWER services module eth0 No support

on the ISA 3000
Note eth0 is the internal name
interface.

344
Network Routes on Device Management Interfaces
Model Management Interface Optional Event Interface
Firepower Threat Defense on the management0 No Support

Firepower 1000
Note management0 is the
internal name of the
Management 1/1
interface.
Firepower Threat Defense on the management0 No Support

Firepower 2100
Note management0 is the
internal name of the
Management 1/1
interface.
Firepower Threat Defense on the management0 management1

Firepower 4100 and 9300
Note management0 is the Note management1 is the
internal name of this internal name of this
interface, regardless of interface, regardless of
the physical interface the physical interface
ID. ID.
Firepower Threat Defense on the br1 No support

ASA 5508-X, or 5516-X
Note br1 is the internal name
interface.
Firepower Threat Defense on the br1 No support

ISA 3000
Note br1 is the internal name
interface.
Firepower Threat Defense Virtual eth0 No support
Network Routes on Device Management Interfaces

Management interfaces (including event-only interfaces) support only static routes to reach remote networks.
When you set up your managed device, the setup process creates a default route to the gateway IP address
that you specify. You cannot delete this route; you can only modify the gateway address.
Note The routing for management interfaces is completely separate from routing that you configure for data
interfaces. If you configure a data interface for management instead of using the dedicated Management
interface, traffic is routed over the backplane to use the data routing table. The information in this section
does not apply.

345
NAT Environments
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 one static route is recommended per management interface to access remote networks. We recommend
placing each interface on a separate network to avoid potential routing problems, including routing problems
from other devices to the FTD. If you do not experience problems with interfaces on the same network, then
be sure to configure static routes correctly. 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.

346
NAT Environments
Figure 1: 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 2: NAT ID for FMC Behind PAT

347
Management and Event Traffic Channel Examples
Note If you use a data interface for management on an FTD, you cannot use separate management and event
interfaces for that device.
The following example shows the Firepower Management Center and managed devices using only the default
management interfaces.
Figure 3: Single Management Interface on the Firepower Management Center
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

348
Requirements and Prerequisites for Device Management
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.
Figure 6: Mixed Management and Event Interface Usage
Requirements and Prerequisites for Device Management

Model Support
Any managed device; unless noted in the procedure.
Supported Domains
The domain in which the device resides.
User Roles
• Admin
• Network Admin
Complete the FTD Initial Configuration

Connect to the FTD CLI to perform initial setup, including setting the Management IP address, gateway, and
other basic networking settings using the setup wizard. The dedicated Management interface is a special
interface with its own network settings. If you do not want to use the Management interface for FMC access,
you can use the CLI to configure a data interface instead. You will also configure FMC communication
settings.
Before you begin

This procedure applies to all FTD devices except for the Firepower 4100/9300.

349
Procedure
Step 1 Connect to the FTD CLI, either from the console port or using SSH to the Management interface, which
obtains an IP address from a DHCP server by default. 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.
Note If the password was already changed, and you do not know it, you must reimage the device to reset
the password to the default. See the FXOS troubleshooting guide for the reimage procedure.
Example:
firepower login: admin

Password: Admin123
Successful login attempts for user 'admin' : 1
[...]
Hello admin. You must change your password.

Enter new password: ********
Confirm new password: ********
Your password was updated successfully.
[...]
firepower#
Step 3 (Firepower 1000/2100) If you connected to FXOS on the console port, connect to the FTD CLI.
connect ftd
Example:
firepower# connect ftd

>
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.
Note The Management interface settings are used even when you enable FMC access on a data interface.
For example, the management traffic that is routed over the backplane through the data interface
will resolve FQDNs using the Management interface DNS servers, and not the data interface DNS
servers.

350
See the following guidelines:

• Configure IPv4 via DHCP or manually?—If you want to use a data interface for FMC access instead
of the management interface, choose manual. Although you do not plan to use the Management interface,
you must set an IP address, for example, a private address. This IP address is NATted when the traffic
is forwarded to the data interface. You cannot configure a data interface for management if the management
interface is set to DHCP, because the default route, which must be data-interfaces (see the next bullet),
might be overwritten with one received from the DHCP server.
• Enter the IPv4 default gateway for the management interface—If you want to use a data interface
for FMC access instead of the management interface, set the gateway to be data-interfaces. This setting
forwards management traffic over the backplane so it can be routed through the FMC access data interface.
If you want to use the Management interface for FMC access, you should set a gateway IP address on
the Management 1/1 network.
• 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.Note that data interface
FMC access is only supported in routed firewall mode.
Example:
You must accept the EULA to continue.

Press <ENTER> to display the EULA:
End User License Agreement
[...]
Please enter 'YES' or press <ENTER> to AGREE to the EULA:
System initialization in progress. Please stand by.

You must change the password for 'admin' to continue.
Enter new password: ********
Confirm new password: ********
You must configure the network to continue.
You must configure at least one of IPv4 or IPv6.
Do you want to configure IPv4? (y/n) [y]:
Do you want to configure IPv6? (y/n) [n]:
Configure IPv4 via DHCP or manually? (dhcp/manual) [manual]:
Enter an IPv4 address for the management interface [192.168.45.45]: 10.10.10.15
Enter an IPv4 netmask for the management interface [255.255.255.0]: 255.255.255.192
Enter the IPv4 default gateway for the management interface [data-interfaces]: 10.10.10.1
Enter a fully qualified hostname for this system [firepower]: ftd-1.cisco.com
Enter a comma-separated list of DNS servers or 'none' [208.67.222.222,208.67.220.220]:
Enter a comma-separated list of search domains or 'none' []:
If your networking information has changed, you will need to reconnect.
For HTTP Proxy configuration, run 'configure network http-proxy'
Manage the device locally? (yes/no) [yes]: no

Configure firewall mode? (routed/transparent) [routed]:
Configuring firewall mode ...
Update policy deployment information

- add device configuration

351
- add network discovery

- add system policy
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.
When registering the sensor to a Firepower Management Center, a unique

alphanumeric registration key is always required. In most cases, to register
a sensor to a Firepower Management Center, you must provide the hostname or
the IP address along with the registration key.
'configure manager add [hostname | ip address ] [registration key ]'
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.
>
Step 5 Identify the FMC that will manage this FTD.

configure manager add {hostname | IPv4_address | IPv6_address | DONTRESOLVE} reg_key [nat_id]
• {hostname | IPv4_address | IPv6_address | DONTRESOLVE}—Specifies either the FQDN or IP address
of the FMC. If the FMC is not directly addressable, use DONTRESOLVE and also specify the nat_id.
At least one of the devices, either the FMC or the FTD, must have a reachable IP address to establish
the two-way, SSL-encrypted communication channel between the two devices. If you specify
DONTRESOLVE in this command, then the FTD must have a reachable IP address or hostname.
• 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.
Note If you use a data interface for management, then you must specify the NAT ID on both the
FTD and FMC for registration.
Example:
> configure manager add MC.example.com 123456

Manager successfully configured.
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:
> configure manager add DONTRESOLVE regk3y78 natid90


352
If the FTD is behind a NAT device, enter a unique NAT ID along with the FMC IP address or hostname, for
example:
Example:
> configure manager add 10.70.45.5 regk3y78 natid56

Step 6 (Optional) Configure a data interface for FMC access.

configure network management-data-interface
You are then prompted to configure basic network settings for the data interface.
Note You should use the console port when using this command. If you use SSH to the Management
interface, you might get disconnected and have to reconnect to the console port. See below for more
information about SSH usage.
See the following details for using this command:

• The original Management interface cannot use DHCP if you want to use a data interface for management.
If you did not set the IP address manually during initial setup, you can set it now using the configure
network {ipv4 | ipv6} manual command. If you did not already set the Management interface gateway
to data-interfaces, this command will set it now.
• FMC access from a data interface has the following limitations:
EtherChannel.
• PPPoE is not supported. If your ISP requires PPPoE, you will have to put a router with PPPoE
support between the FTD and the WAN modem.
Because the Management interface gateway will be changed to be the data interfaces, you also
cannot SSH to the Management interface from a remote network unless you add a static route for
the Management interface using the configure network static-routes command.
• When you add the FTD to the FMC, the FMC discovers and maintains the interface configuration,
including the following settings: interface name and IP address, static route to the gateway, DNS servers,
and DDNS server. For more information about the DNS server configuration, see below. In FMC, you
can later make changes to the FMC access interface configuration, but make sure you don't make changes
that can prevent the FTD or FMC from re-establishing the management connection. If the management
connection is disrupted, the FTD includes the configure policy rollback command to restore the previous
deployment.
• If you configure a DDNS server update URL, the FTD automatically adds certificates for all of the major
CAs from the Cisco Trusted Root CA bundle so that the FTD can validate the DDNS server certificate

353
for the HTTPS connection. The FTD supports any DDNS server that uses the DynDNS Remote API
specification (https://help.dyn.com/remote-access-api/).
• This command sets the data interface DNS server. The Management DNS server that you set with the
setup script (or using the configure network dns servers command) is used for management traffic.
The data DNS server is used for DDNS (if configured) or for security policies applied to this interface.
On the FMC, the data interface DNS servers are configured in the Platform Settings policy that you
assign to this FTD. When you add the FTD to the FMC, the local setting is maintained, and the DNS
servers are not added to a Platform Settings policy. However, if you later assign a Platform Settings
policy to the FTD that includes a DNS configuration, then that configuration will overwrite the local
setting. We suggest that you actively configure the DNS Platform Settings to match this setting to bring
the FMC and the FTD into sync.
Also, local DNS servers are only retained by FMC if the DNS servers were discovered at initial registration.
For example, if you registered the device using the Management interface, but then later configure a data
interface using the configure network management-data-interface command, then you must manually
configure all of these settings in FMC, including the DNS servers, to match the FTD configuration.
• You can change the management interface after you register the FTD to the FMC, to either the
Management interface or another data interface.
• The FQDN that you set in the setup wizard will be used for this interface.
• You can clear the entire device configuration as part of the command; you might use this option in a
recovery scenario, but we do not suggest you use it for initial setup or normal operation.
• To disable data managemement, enter the configure network management-data-interface disable
command.
Example:
> configure network management-data-interface

Data interface to use for management: ethernet1/1
Specify a name for the interface [outside]:
IP address (manual / dhcp) [dhcp]:
DDNS server update URL [none]:
https://jcrichton:pa$$w0rd17@domains.example.com/nic/update?hostname=<h>&myip=<a>
Do you wish to clear all the device configuration before applying ? (y/n) [n]:
Configuration done with option to allow FMC access from any network, if you wish to change
the FMC access network
use the 'client' option in the command 'configure network management-data-interface'.
Setting IPv4 network configuration.

Network settings changed.
>
Example:

Specify a name for the interface [outside]: internet
IP address (manual / dhcp) [dhcp]: manual
IPv4/IPv6 address: 10.10.6.7
Netmask/IPv6 Prefix: 255.255.255.0
Default Gateway: 10.10.6.1
Comma-separated list of DNS servers [none]: 208.67.222.222,208.67.220.220

354
Add a Device to the FMC

Do you wish to clear all the device configuration before applying ? (y/n) [n]:

>
Step 7 (Optional) Limit data interface access to an FMC on a specific network.

configure network management-data-interface client ip_address netmask
By default, all networks are allowed.
What to do next
Register your device to a FMC.

Use this procedure to add a single device to the FMC. If you plan to link devices for redundancy or performance,
you must still use this procedure, keeping in mind the following points:
• FTD high availability—Use this procedure to add each device to the Firepower Management Center,
then establish high availability; see Add a Firepower Threat Defense High Availability Pair, on page 923.
• FTD clusters—For detailed information about adding clusters, see FMC: Add a Cluster, on page 960.
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.
Before you begin

• Set up the device to be managed by the FMC. See:
• FTD devices: Complete the FTD Initial Configuration, on page 349
• Other device types: The getting started guide for your model
• If you are adding an FTD device, the FMC must be registered to the Smart Licensing server (CSSM). A
valid evaluation license is sufficient, but if it expires, you will not be able to add new devices until you
successfully register.
• If you registered a FMC and a device using IPv4 and want to convert them to IPv6, you must delete and
reregister the device.

355
Procedure

Step 2 From the Add drop-down menu, choose Device.
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.

356
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 346.
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. The key can include
alphanumeric characters and hyphens (-).
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.
Step 7 (Optional) Add the device to a device Group.

Step 8 Choose an initial Access Control Policy to deploy to the device upon registration, or create a new policy.
If the device is incompatible with the policy you choose, deploying will fail. This incompatibility could occur
for multiple reasons, including licensing mismatches, model restrictions, passive vs inline issues, and other
misconfigurations. After you resolve the issue that caused the failure, manually deploy configurations to the
device.
Step 9 Choose licenses to apply to the device.

Performance Tier (FTDv only)
Note Starting with Version 7.0, virtual FTDs require a performance tier license. Make sure your Smart
Licensing account contains the available licenses you need. If you are upgrading your FTDv to
Version 7.0, you can choose FTDv - Variable to maintain your current license compliance.
From the Performance Tier drop-down list, select the performance-tiered license entitlement for the FTDv
device to be managed by the FMC:
• FTDv5 - Tiered (Core 4 / 8 GB) (100Mbps)
• FTDv10 - Tiered (Core 4 / 8 GB) (1Gbps)
• FTDv - Variable
Note It’s important to choose the tier that matches the license you have in your account. Until you choose
a tier, your FTDv defaults to the FTDv50 selection. For more information about the
performance-tiered license entitlements available for the FTDv, see FTDv Licensing, on page 197.
Smart Licensing
Assign the Smart Licenses you need for the features you want to deploy:
• Malware (if you intend to use AMP malware inspection)

357
Delete a Device from the FMC
• Threat (if you intend to use intrusion prevention)

• URL (if you intend to implement category-based URL filtering)
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. The NAT ID can include alphanumeric characters and hyphens (-).
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.

It may take up to two minutes for the FMC to verify the device’s heartbeat and establish communication. If
the registration succeeds, the device is added to the list. If it fails, you will see an error message. If the device
fails to register, check the following items:
• Ping—Access the device CLI, and ping the FMC IP address using the following command:
ping system ip_address
If the ping is not successful, check your network settings using the show network command. If you need
to change the device IP address, use the configure network {ipv4 | ipv6} manual command.
• Registration key, NAT ID, and FMC IP address—Make sure you are using the same registration key,
and if used, NAT ID, on both devices. You can set the registration key and NAT ID on the device using
the configure manager add command.
For more troubleshooting information, see https://cisco.com/go/fmc-reg-error.
Delete a Device from the FMC

If you no longer want to manage a device, you can delete it from the FMC. Deleting a device:
• Severs all communication between the Firepower Management Center and the device.
• Removes the device from the Device Management page.
• Returns the device to local time management if the device is configured via the platform settings policy
to receive time from the FMC via NTP.
To manage the device later, re-add it to the FMC.

358
Add a Device Group
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.
Procedure
Step 2 Next to the device you want to delete, click Delete ( ).

Step 3 Confirm that you want to delete the device.
Add a Device Group

The Firepower Management Center allows you to group devices so you can easily deploy policies and install
updates on multiple devices. You can expand and collapse the list of devices in the group.
In a multidomain deployment, you can create device groups within a leaf domain only. When you configure
a Firepower Management Center for multitenancy, existing device groups are removed; you can re-add them
at the leaf domain level.
If you add the primary device in a high-availability pair to a group, both devices are added to the group. If
you break the high-availability pair, both devices remain in that group.
Procedure

Step 2 From the Add drop-down menu, choose Add Group.
To edit an existing group, click Edit ( ) for the group you want to edit.
Step 3 Enter a Name.

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.

359
Configure Device Settings
Configure Device Settings

After you add a device, you can configure some settings on the device's Device page.
Managing System Shut Down

Smart License Classic License Supported Devices Supported Domains Access
Any Any Any except ASA Leaf only Admin/Network

FirePOWER Admin
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.
Procedure

Step 2 Next to the device that you want to restart, click Edit ( ).
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.
Step 6 To restart the device, click Restart Device ( ).

Step 7 When prompted, confirm that you want to restart the device.
Edit Management Settings

You can edit management settings in the Management area.
Update the Hostname or IP Address in FMC

If you edit the hostname or IP address of a device after you added it to the FMC (using the device’s CLI, for
example), you need to use the procedure below to manually update the hostname or IP address on the managing
FMC.
To change the device management IP address on the device, see Modify Device Management Interfaces at
the CLI, on page 370.

360
Change the FMC Access Interface from Management to Data
Procedure

Step 2 Next to the device where you want to modify management options, click Edit ( ).
Step 3 Click Device, and view the Management area.
Step 4 Disable management temporarily by clicking the slider so it is disabled ( ).
You are prompted to proceed with disabling management; click Yes.
Disabling management blocks the connection between the Firepower Management Center and the device, but
does not delete the device from the Firepower Management Center.
Step 5 Edit the Host IP address or hostname by clicking Edit ( ).
In the Management dialog box, modify the name or IP address in the Host field, and click Save.
What to do next

You can manage the FTD from either the dedicated Management interface, or from a data interface. If you
want to change the FMC access interface after you added the device to FMC, follow these steps to migrate

361
from the Management interface to a data interface. To migrate the other direction, see Change the FMC Access
Interface from Data to Management, on page 364.
Initiating the FMC access migration from Management to data causes the FMC to apply a block on deployment
to the FTD. To remove the block, enable FMC access on the data interface.
See the following steps to enable FMC access on a data interface, and also configure other required settings.
Before you begin

Model Support—FTD
Procedure
Step 1 Initiate the interface migration.

a) On the Devices > Device Management page, click Edit ( ) for the device.
b) Go to the Device > Management section, and click the link for FMC Access Interface.
The FMC Access Interface field shows the current management interface. When you click the link,
choose the new interface type, Data Interface, in the Manage device by drop-down list.
c) Click Save.
You must now complete the remaining steps in this procedure to enable FMC access on the data interface.
On the Devices page, you will see a yellow banner in the top right showing that you are migrating the
management interface.
If you click View Details, the Devices > Device Management > Device > Management > FMC Access
Details dialog box opens. The FMC Access Mode shows an In Process migration.

362
Step 2 Enable FMC access on a data interface on the Devices > Device Management > Interfaces > Edit Physical
Interface > FMC Access page.
See Configure Routed Mode Interfaces, on page 844. You can enable FMC access on one routed data interface.
Make sure this interface is fully configured with a name and IP address and that it is enabled.
Step 3 (Optional) If you use DHCP for the interface, enable the web type DDNS method on the Devices > Device
Management > DHCP > DDNS page.
See Configure Dynamic DNS, on page 886. DDNS ensures the FMC can reach the FTD at its Fully-Qualified
Domain Name (FQDN) if the FTD's IP address changes.
Step 4 Make sure the FTD can route to the FMC through the data interface; add a static route if necessary on Devices >
Device Management > Routing > Static Route.
See Add a Static Route, on page 1050.
Step 5 (Optional) Configure DNS in a Platform Settings policy, and apply it to this device at Devices > Platform
Settings > DNS.
See Configure DNS, on page 1427. DNS is required if you use DDNS. You may also use DNS for FQDNs in
your security policies.
Step 6 (Optional) Enable SSH for the data interface in a Platform Settings policy, and apply it to this device at
Devices > Platform Settings > Secure Shell.
See Configure Secure Shell, on page 1441. SSH is not enabled by default on the data interfaces, so if you want
to manage the FTD using SSH, you need to explicitly allow it.
The FMC will deploy the configuration changes over the current Management interface. After the deployment,
the data interface is now ready for use, but the original management connection to Management is still active.
Step 8 At the FTD CLI (preferably from the console port), set the Management interface to use a static IP address
and set the gateway to use the data interfaces.
configure network {ipv4 | ipv6} manual ip_address netmask data-interfaces
• ip_address netmask—Although you do not plan to use the Management interface, you must set a static
IP address, for example, a private address. You cannot use DHCP because the default route, which must
be data-interfaces (see the next bullet), might be overwritten with one received from the DHCP server.
• data-interfaces—This setting forwards management traffic over the backplane so it can be routed through
the FMC access data interface.
We recommend that you use the console port instead of an SSH connection because when you change the
Management interface network settings, your SSH session will be disconnected.
Step 9 If necessary, re-cable the FTD so it can reach the FMC on the data interface.
Step 10 In FMC, disable the management connection, update the Host IP address for the FTD in the Devices > Device
Management > Device > Management section, and reenable the connection.
See Update the Hostname or IP Address in FMC, on page 360. If you used the FTD hostname or just the NAT
ID when you added the FTD to the FMC, you do not need to update the value; however, you need to disable
and reenable the management connection to restart the connection.
Step 11 Ensure the management connection is reestablished.

363
Change the FMC Access Interface from Data to Management
In FMC, check the management connection status on the Devices > Device Management > Device >
Management > FMC Access Details > Connection Status page.
At the FTD CLI, enter the sftunnel-status-brief command to view the management connection status.
The following status shows a successful connection for a data interface, showing the internal "tap_nlp"
interface.
If it takes more than 10 minutes to reestablish the connection, you should troubleshoot the connection. See
Troubleshoot Management Connectivity on a Data Interface, on page 380.

You can manage the FTD from either the dedicated Management interface, or from a data interface. If you
want to change the FMC access interface after you added the device to FMC, follow these steps to migrate
from a Data interface to the Management interface. To migrate the other direction, see Change the FMC
Access Interface from Management to Data, on page 361.
Initiating the FMC access migration from data to Management causes the FMC to apply a block on deployment
to the FTD. You must disable FMC access on the data interface to remove the block.
See the following steps to disable FMC access on a data interface, and also configure other required settings.
Before you begin

Model Support—FTD
Procedure
Step 1 Initiate the interface migration.

a) On the Devices > Device Management page, click Edit ( ) for the device.
b) Go to the Device > Management section, and click the link for FMC Access Interface.
The FMC Access Interface field shows the current management interface. When you click the link,
choose the new interface type, Management Interface, in the Manage device by drop-down list.

364
c) Click Save.
You must now complete the remaining steps in this procedure to enable FMC access on the Management
interface. On the Devices page, you will see a yellow banner in the top right showing that you are migrating
the management interface.
If you click View Details, the Devices > Device Management > Device > Management > FMC Access
Details dialog box opens. The FMC Access Mode shows an In Process migration.
Step 2 Disable FMC access on a data interface on the Devices > Device Management > Interfaces > Edit Physical
Interface > FMC Access page.
See Configure Routed Mode Interfaces, on page 844. This step removes the block on deployment.
Step 3 If you have not already done so, configure DNS settings for the data interface in a Platform Setting policy,
and apply it to this device at Devices > Platform Settings > DNS.
See Configure DNS, on page 1427. The FMC deployment that disables FMC access on the data interface will
remove any local DNS configuration. If that DNS server is used in any security policy, such as an FQDN in
an Access Rule, then you must re-apply the DNS configuration using FMC.
The FMC will deploy the configuration changes over the current data interface.
Step 5 If necessary, re-cable the FTD so it can reach the FMC on the Management interface.
Step 6 At the FTD CLI, configure the Management interface IP address and gateway using a static IP address or
DHCP.

365
View FMC Access Details for Data Interface Management
When you originally configured the data interface for FMC access, the Management gateway was set to
data-interfaces, which forwarded management traffic over the backplane so it could be routed through the
FMC access data interface. You now need to set an IP address for the gateway on the management network.
Static IP address:
configure network {ipv4 | ipv6} manual ip_address netmask gateway_ip
DHCP:
configure network{ipv4 | ipv6} dhcp
Step 7 In FMC, disable the management connection, update the Host IP address for the FTD in the Devices > Device
Management > Device > Management section, and reenable the connection.
See Update the Hostname or IP Address in FMC, on page 360. If you used the FTD hostname or just the NAT
ID when you added the FTD to the FMC, you do not need to update the value; however, you need to disable
and reenable the management connection to restart the connection.
Step 8 Ensure the management connection is reestablished.

Management > Status field or view notifications in FMC.

Model Support—FTD
When you use a data interface for FMC management instead of using the dedicated Management interface,
you must be careful about changing the interface and network settings for the device in FMC so you do not
disrupt the connection. You can also change the data interface settings locally on the device, which requires
you to reconcile those changes in FMC manually. The Devices > Device Management > Device >
Management > FMC Access Details dialog box helps you resolve any discrepancies between the FMC and
the FTD local configuration.
Normally, you configure the FMC access data interface as part of initial FTD setup before you add the FTD
to the FMC. When you add the FTD to the FMC, the FMC discovers and maintains the interface configuration,
including the following settings: interface name and IP address, static route to the gateway, DNS servers, and
DDNS server. For the DNS server, the configuration is maintained locally if it is discovered during registration,
but it is not added to the Platform Settings policy in FMC.
After you add the FTD to the FMC, if you change the data interface settings on the FTD locally using the
configure network management-data-interface command, then the FMC detects the configuration changes,
and blocks deployment to the FTD. The FMC detects the configuration changes using one of the following
methods:
• Deploy to the FTD. Before the FMC deploys, it will detect the configuration differences and stop the
deployment.
• The Sync button in the Interfaces page.
• The Refresh button on the FMC Access Details dialog box.

366
To remove the block, you must go to the FMC Access Details dialog box and click Acknowledge. The next
time you deploy, the FMC configuration will overwrite any remaining conflicting settings on the FTD. It is
your responsibility to manually fix the configuration in the FMC before you re-deploy.
See the following pages on this dialog box.
Configuration
View the configuration comparison of the FMC access data interface on the FMC and the FTD.
The following example shows the configuration details of an FTD where the configure network
management-data-interface command was entered on the FTD. The pink highlights show that if you
Acknowledge the differences but do not match the configuration in FMC, then the FTD configuration will
be removed. The blue highlights show configurations that will be modified on the FTD. The green highlights
show configurations that will be added to the FTD.
The following example shows this page after configuring the interface in FMC; the interface settings match,
and the pink highlight was removed.

367
CLI Output
View the CLI configuration of the FMC access data interface, which is useful if you are familiar with the
underlying CLI.

368
Connection Status
View management connection status. The following example shows that the management connection is still
using the Management "br1" interface.
The following status shows a successful connection for a data interface, showing the internal "tap_nlp"
interface.
See the following sample output for a connection that is down; there is no peer channel "connected to"
information, nor heartbeat information shown:
> sftunnel-status-brief
PEER:10.10.17.202
Registration: Completed.
Connection to peer '10.10.17.202' Attempted at Mon Jun 15 09:21:57 2020 UTC
Last disconnect time : Mon Jun 15 09:19:09 2020 UTC
Last disconnect reason : Both control and event channel connections with peer went down

369
Modify Device Management Interfaces at the CLI
See the following sample output for a connection that is up, with peer channel and heartbeat information
shown:
PEER:10.10.17.202
Peer channel Channel-A is valid type (CONTROL), using 'eth0', connected to '10.10.17.202'
via '10.10.17.222'
Peer channel Channel-B is valid type (EVENT), using 'eth0', connected to '10.10.17.202' via
'10.10.17.222'
IPv4 Connection to peer '10.10.17.202' Start Time: Wed Jun 10 14:27:12 2020 UTC
Heartbeat Send Time: Mon Jun 15 09:02:08 2020 UTC
Heartbeat Received Time: Mon Jun 15 09:02:16 2020 UTC

Modify the management interface settings on the managed device using the CLI. Many of these settings are
ones that you set when you performed the initial setup; this procedure lets you change those settings, and set
additional settings such as enabling an event interface if your model supports it, or adding static routes.
Note This topic applies to the dedicated Management interface. You can alternatively configure a data interface
for management. If you want to change network settings for that interface, you should do so within FMC and
not at the CLI. If you need to troubleshoot a disrupted management connection, and need to make changes
directly on the FTD, see Modify the FTD Data Interface Used for Management at the CLI, on page 376.
For information about the FTD CLI, see the FTD command reference.
For information about the classic device CLI, see Classic Device Command Line Reference, on page 3039 in
this guide.
The FTD and classic devices use the same commands for management interface configuration. Other commands
may differ between the platforms.
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.

370
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 391):
• 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 360. 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 360.
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.
Before you begin

• For Firepower Threat Defense devices, you can create user accounts that can log into the CLI using the
configure user add command; see Add an Internal User at the CLI, on page 137. You can also configure
AAA users according to Configure External Authentication for SSH, on page 1429.
Procedure
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 38 or Logging Into the CLI on ASA
FirePOWER and NGIPSv Devices, on page 37.
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:
> configure network management-interface enable management1

Configuration updated successfully
> configure network management-interface disable-management-channel management1


371
>
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:
> configure network ipv4 manual 10.10.10.45 255.255.255.0 10.10.10.1 management1

>
• DHCP (supported on the default management interface only):

configure network ipv4 dhcp
b) Configure the IPv6 address:

• Stateless autoconfiguration:
configure network ipv6 router [management_interface]
Example:
> configure network ipv6 router management0


372
>
• 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
Example:
> configure network ipv6 manual 2001:0DB8:BA98::3210 64 management1

>
• DHCPv6 (supported on the default management interface only):

configure network ipv6 dhcp
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:
> configure network ipv6 destination-unreachable disable

> configure network ipv6 echo-reply disable
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:
> configure network ipv4 dhcp-server-enable 10.10.10.200 10.10.10.254

DHCP Server Enabled
>

373
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:
> show network-dhcp-server

DHCP Server Enabled
10.10.10.200-10.10.10.254
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 345.
Example:
> configure network static-routes ipv4 add management1 192.168.6.0 255.255.255.0 10.10.10.1
> configure network static-routes ipv6 add management1 2001:0DB8:AA89::5110 64

2001:0DB8:BA98::3211
>
To display static routes, enter show network-static-routes (the default route is not shown):
> show network-static-routes

---------------[ IPv4 Static Routes ]---------------
Interface : management1
Destination : 192.168.6.0
Gateway : 10.10.10.1
Netmask : 255.255.255.0
[…]
Step 8 Set the hostname:

configure network hostname name
Example:
> configure network hostname farscape1.cisco.com
Syslog messages do not reflect a new hostname until after a reboot.
Step 9 Set the search domains:

configure network dns searchdomains domain_list
Example:

374
> configure network dns searchdomains example.com,cisco.com
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 10 Set up to 3 DNS servers, separated by commas:

configure network dns servers dns_ip_list
Example:
> configure network dns servers 10.10.6.5,10.20.89.2,10.80.54.3
Step 11 Set the remote management port for communication with the FMC:
configure network management-interface tcpport number
Example:
> configure network management-interface tcpport 8555
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
Interface management1 speed is set to '10000baseT/Full'

NetworkSettings::refreshNetworkConfig MTU value at end 8192
>

375
Modify the FTD Data Interface Used for Management at the CLI
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:
> configure network http-proxy

Manual proxy configuration
Enter HTTP Proxy address: 10.100.10.10
Enter HTTP Proxy Port: 80
Use Proxy Authentication? (y/n) [n]: Y
Enter Proxy Username: proxyuser
Enter Proxy Password: proxypassword
Confirm Proxy Password: proxypassword
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 391):
• 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 360. 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 360.
• 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 360.
If the management connection between the FTD and the FMC was disrupted, and you want to specify a new
data interface to replace the old interface, use the FTD CLI to configure the new interface. This procedure
assumes you want to use replace the old interface with a new interface on the same network. If the management
connection is active, then you should make any changes to an existing data interface using FMC. For initial
setup of the data management interface, see the configure network management-data-interface command
in Complete the FTD Initial Configuration, on page 349.
Note This topic applies to the data interface that you configured for Management, not the dedicated Management
interface. If you want to change network settings for the Management interface, see Modify Device Management
Interfaces at the CLI, on page 370.

376
For information about the FTD CLI, see the FTD command reference.
Before you begin

• You can create user accounts that can log into the CLI using the configure user add command; see Add
an Internal User at the CLI, on page 137. You can also configure AAA users according to Configure
External Authentication for SSH, on page 1429.
Procedure
Step 1 If you are changing the data management interface to a new interface, move the current interface cable to the
new interface.
Step 2 Connect to the device CLI.
You should use the console port when using these commands. If you are performing initial setup, then you
may be disconnected from the Management interface. If you are editing the configuration due to a disrupted
management connection, and you have SSH access to the dedicated Management interface, then you can use
that SSH connection.
See Logging Into the Command Line Interface on FTD Devices, on page 38.
Step 3 Log in with the Admin username and password.

Step 4 Configure a data interface for FMC access.
configure network management-data-interface
You are then prompted to configure basic network settings for the data interface.
When you change the data management interface to a new interface on the same network, use the same settings
as for the previous interface except the interface ID. In addition, for the Do you wish to clear all the device
configuration before applying ? (y/n) [n]: option, choose y. This choice will clear the old data management
interface configuration, so that you can successfully reuse the IP address and interface name on the new
interface.

Specify a name for the interface [outside]: internet
IP address (manual / dhcp) [dhcp]: manual
IPv4/IPv6 address: 10.10.6.7
Netmask/IPv6 Prefix: 255.255.255.0
Default Gateway: 10.10.6.1
Comma-separated list of DNS servers [none]: 208.67.222.222,208.67.220.220
Do you wish to clear all the device configuration before applying ? (y/n) [n]: y

>
Step 5 (Optional) Limit data interface access to an FMC on a specific network.

377
Roll Back the Configuration if the FMC Loses Connectivity
configure network management-data-interface client ip_address netmask

By default, all networks are allowed.
Step 6 The connection will be reestablished automatically, but disabling and reenabling the connection in FMC will
help the connection reestablish faster. See Update the Hostname or IP Address in FMC, on page 360.
Step 7 Check that the management connection was reestablished.
sftunnel-status-brief
shown:
PEER:10.10.17.202
via '10.10.17.222'
Peer channel Channel-B is valid type (EVENT), using 'eth0', connected to '10.10.17.202' via
'10.10.17.222'
Step 8 In FMC, choose Devices > Device Management > Device > Management > FMC Access Details, and click
Refresh.
The FMC detects the interface and default route configuration changes, and blocks deployment to the FTD.
When you change the data interface settings locally on the device, you must reconcile those changes in FMC
manually. You can view the discrepancies between FMC and the FTD on the Configuration tab.
Step 9 Choose Devices > Device Management > Interfaces, and make the following changes.
a) Remove the IP address and name from the old data management interface, and disable FMC Access for
this interface.
b) Configure the new data management interface with the settings of the old interface (the ones you used at
the CLI), and enable FMC Access for it.
Step 10 Choose Devices > Device Management > Routing > Static Route and change the default route from the old
data management interface to the new one.
Step 11 Return to the FMC Access Details dialog box, and click Acknowledge to remove the deployment block.
The next time you deploy, the FMC configuration will overwrite any remaining conflicting settings on the
FTD. It is your responsibility to manually fix the configuration in the FMC before you re-deploy.
You will see expected messages of "Config was cleared” and “FMC Access changed and acknowledged.”

If you use a data interface on the FTD for FMC management, and you deploy a configuration change from
the FMC that affects the network connectivity, you can roll back the configuration on the FTD to the
last-deployed configuration so you can restore management connectivity. You can then adjust the configuration
settings in FMC so that the network connectivity is maintained, and re-deploy. You can use the rollback
feature even if you do not lose connectivity; it is not limited to this troubleshooting situation.

378
See the following guidelines:

• Only the previous deployment is available locally on the FTD; you cannot roll back to any earlier
deployments.
• Rollback is not supported for High Availability or Clustering deployments.
• The rollback only affects configurations that you can set in FMC. For example, the rollback does not
affect any local configuration related to the dedicated Management interface, which you can only configure
at the FTD CLI. Note that if you changed data interface settings after the last FMC deployment using
the configure network management-data-interface command, and then you use the rollback command,
those settings will not be preserved; they will roll back to the last-deployed FMC settings.
• UCAPL/CC mode cannot be rolled back.
• Out-of-band SCEP certificate data that was updated during the previous deployment cannot be rolled
back.
• During the rollback, connections will drop because the current configuration will be cleared.
Before you begin

Model Support—FTD
Procedure
Step 1 At the FTD CLI, roll back to the previous configuration.

configure policy rollback
After the rollback, the FTD notifies the FMC that the rollback was completed successfully. In FMC, the
deployment screen will show a banner stating that the configuration was rolled back.
If the rollback failed, refer to https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw-virtual/
215258-troubleshooting-firepower-threat-defense.html for common deployment problems. In some cases, the
rollback can fail after FMC management access is restored; in this case, you can resolve the FMC configuration
issues, and redeploy from FMC.
Example:
> configure policy rollback
The last deployment to this FTD was on June 1, 2020 and its status was Successful.
Do you want to continue [Y/N]?
Rolling back complete configuration on the FTD. This will take time.
.....................
Policy rollback was successful on the FTD.
Configuration has been reverted back to transaction id:
Following is the rollback summary:
...................
....................
>
Step 2 Check that the management connection was reestablished.

379
Troubleshoot Management Connectivity on a Data Interface

Model Support—FTD
When you use a data interface for FMC management instead of using the dedicated Management interface,
you must be careful about changing the interface and network settings for the FTD in FMC so you do not
disrupt the connection. If you change the management interface type after you add the FTD to the FMC (from
data to Management, or from Management to data), if the interfaces and network settings are not configured
correctly, you can lose management connectivity.
This topic helps you troubleshoot the loss of management connectivity.
View management connection status
You can also use sftunnel-status to view more complete information.
See the following sample output for a connection that is down; there is no peer channel "connected to"
information, nor heartbeat information shown:
PEER:10.10.17.202
Connection to peer '10.10.17.202' Attempted at Mon Jun 15 09:21:57 2020 UTC
Last disconnect time : Mon Jun 15 09:19:09 2020 UTC
Last disconnect reason : Both control and event channel connections with peer went down
shown:
PEER:10.10.17.202
via '10.10.17.222'
Peer channel Channel-B is valid type (EVENT), using 'eth0', connected to '10.10.17.202'
via '10.10.17.222'
View the FTD network information

At the FTD CLI, view the Management and FMC access data interface network settings:

380
show network
> show network

===============[ System Information ]===============
Hostname : 5516X-4
DNS Servers : 208.67.220.220,208.67.222.222
Management port : 8305
IPv4 Default route
Gateway : data-interfaces
IPv6 Default route
Gateway : data-interfaces
======================[ br1 ]=======================

State : Enabled
Link : Up
Channels : Management & Events
Mode : Non-Autonegotiation
MDI/MDIX : Auto/MDIX
MTU : 1500
MAC Address : 28:6F:7F:D3:CB:8D
----------------------[ IPv4 ]----------------------
Configuration : Manual
Address : 10.99.10.4
Netmask : 255.255.255.0
Gateway : 10.99.10.1
----------------------[ IPv6 ]----------------------
Configuration : Disabled
===============[ Proxy Information ]================

State : Disabled
Authentication : Disabled
======[ System Information - Data Interfaces ]======

DNS Servers :
Interfaces : GigabitEthernet1/1
===============[ GigabitEthernet1/1 ]===============

State : Enabled
Link : Up
Name : outside
MTU : 1500
MAC Address : 28:6F:7F:D3:CB:8F
----------------------[ IPv4 ]----------------------
Configuration : Manual
Address : 10.89.5.29
Netmask : 255.255.255.192
Gateway : 10.89.5.1
----------------------[ IPv6 ]----------------------
Configuration : Disabled
Check that the FTD registered with the FMC

At the FTD CLI, check that the FMC registration was completed. Note that this command will not show
the current status of the management connection.
show managers
> show managers

Type : Manager
Host : 10.89.5.35
Registration : Completed

381
>
Ping the FMC

At the FTD CLI, use the following command to ping the FMC from the data interfaces:
ping fmc_ip
At the FTD CLI, use the following command to ping the FMC from the Management interface, which
should route over the backplane to the data interfaces:
ping system fmc_ip
Capture packets on the FTD internal interface
At the FTD CLI, capture packets on the internal backplane interface (nlp_int_tap) to see if management
packets are being sent:
capture name interface nlp_int_tap trace detail match ip any any
show capturename trace detail
Check the internal interface status, statistics, and packet count
At the FTD CLI, see information about the internal backplane interface, nlp_int_tap:
show interace detail
> show interface detail

[...]
Interface Internal-Data0/1 "nlp_int_tap", is up, line protocol is up
Hardware is en_vtun rev00, BW Unknown Speed-Capability, DLY 1000 usec
(Full-duplex), (1000 Mbps)
Input flow control is unsupported, output flow control is unsupported
MAC address 0000.0100.0001, MTU 1500
IP address 169.254.1.1, subnet mask 255.255.255.248
37 packets input, 2822 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 pause input, 0 resume input
0 L2 decode drops
5 packets output, 370 bytes, 0 underruns
0 pause output, 0 resume output
0 output errors, 0 collisions, 0 interface resets
0 late collisions, 0 deferred
0 input reset drops, 0 output reset drops
input queue (blocks free curr/low): hardware (0/0)
output queue (blocks free curr/low): hardware (0/0)
Traffic Statistics for "nlp_int_tap":
37 packets input, 2304 bytes
5 packets output, 300 bytes
37 packets dropped
1 minute input rate 0 pkts/sec, 0 bytes/sec
1 minute output rate 0 pkts/sec, 0 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 0 pkts/sec, 0 bytes/sec
5 minute output rate 0 pkts/sec, 0 bytes/sec
5 minute drop rate, 0 pkts/sec
Control Point Interface States:
Interface number is 14
Interface config status is active
Interface state is active

382
Check routing and NAT

At the FTD CLI, check that the default route (S*) was added and that internal NAT rules exist for the
Management interface (nlp_int_tap).
show route
> show route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
SI - Static InterVRF
Gateway of last resort is 10.89.5.1 to network 0.0.0.0
S* 0.0.0.0 0.0.0.0 [1/0] via 10.89.5.1, outside

C 10.89.5.0 255.255.255.192 is directly connected, outside
L 10.89.5.29 255.255.255.255 is directly connected, outside
>
show nat
> show nat
Auto NAT Policies (Section 2)

1 (nlp_int_tap) to (outside) source static nlp_server_0_sftunnel_intf3 interface service
tcp 8305 8305
translate_hits = 0, untranslate_hits = 6
2 (nlp_int_tap) to (outside) source static nlp_server_0_ssh_intf3 interface service
tcp ssh ssh
3 (nlp_int_tap) to (outside) source static nlp_server_0_sftunnel_ipv6_intf3 interface
ipv6 service tcp 8305 8305
4 (nlp_int_tap) to (outside) source dynamic nlp_client_0_intf3 interface
5 (nlp_int_tap) to (outside) source dynamic nlp_client_0_ipv6_intf3 interface ipv6
>
Check other settings

See the following commands to check that all other settings are present. You can also see many of these
commands on the FMC's Devices > Device Management > Device > Management > FMC Access
Details > CLI Output page.
show running-config sftunnel
> show running-config sftunnel

sftunnel interface outside
sftunnel port 8305
show running-config ip-client

383
> show running-config ip-client

ip-client outside
show conn address fmc_ip
> show conn address 10.89.5.35

5 in use, 16 most used
Inspect Snort:
preserve-connection: 0 enabled, 0 in effect, 0 most enabled, 0 most in effect
TCP nlp_int_tap 10.89.5.29(169.254.1.2):51231 outside 10.89.5.35:8305, idle 0:00:04,

bytes 86684, flags UxIO
TCP nlp_int_tap 10.89.5.29(169.254.1.2):8305 outside 10.89.5.35:52019, idle 0:00:02,
bytes 1630834, flags UIO
>
Check for a successful DDNS update

At the FTD CLI, check for a successful DDNS update:
debug ddns
> debug ddns

DDNS update request = /v3/update?hostname=domain.example.org&myip=209.165.200.225
Successfuly updated the DDNS sever with current IP addresses
DDNS: Another update completed, outstanding = 0
DDNS: IDB SB total = 0
If the update failed, use the debug http and debug ssl commands. For certificate validation failures,
check that the root certificates are installed on the device:
show crypto ca certificates trustpoint_name
To check the DDNS operation:
show ddns update interface fmc_access_ifc_name
> show ddns update interface outside
Dynamic DNS Update on outside:

Update Method Name Update Destination
RBD_DDNS not available
Last Update attempted on 04:11:58.083 UTC Thu Jun 11 2020

Status : Success
FQDN : domain.example.org
IP addresses : 209.165.200.225
Check FMC log files

See https://cisco.com/go/fmc-reg-error.

384
Edit General Settings
Edit General Settings

Procedure

Step 2 Next to the device you want to modify, click Edit ( ).

Step 4 In the General section, click Edit ( ).
Step 5 Enter a Name for the managed device.
Step 6 Change the Transfer Packets setting:
• Check the check box to allow packet data to be stored with events on the Firepower Management Center.
• Clear the check box to prevent the managed device from sending packet data with the events.
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.
Step 8 Click Deploy.
What to do next
Copy a Configuration to Another Device

When a new device is deployed in the network you can easily copy configurations and policies from a
pre-configured device, instead of manually reconfiguring the new device.
Before you begin

Confirm that:
• The source and destination Firepower Threat Defense devices are the same model and are running the
same version of the Firepower software.
• The source is either a standalone Firepower Threat Defense device or a Firepower Threat Defense high
availability pair.
• The destination device is a standalone Firepower Threat Defense device.
• The source and detsination Firepower Threat Defense devices have the same number of physical interfaces.
• The source and destination Firepower Threat Defense devices are in the same firewall mode - routed or
transparent.

385
Edit License Settings
• The source and destination Firepower Threat Defense devices are in the same security certifications
compliance mode.
• 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
Procedure

Step 2 Next to the device you want to modify, click Edit ( ).

Step 4 In the General section, do one of the following:
• 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.
Step 6 Click OK.

You can monitor the status of the copy device configuration task on Tasks in the Message Center.
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.
Edit License Settings

You can enable licenses on your device if you have available licenses on your Firepower Management Center.

386
Edit Advanced Settings
Procedure

Step 2 Next to the device where you want to enable or disable licenses, click Edit ( ).
Step 4 In the License section, click Edit ( ).

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
Edit Advanced Settings

The following topics explain how to edit the advanced device settings.
Note For information about the Transfer Packets setting, see Edit General Settings, on page 385.
Configure Automatic Application Bypass

Automatic Application Bypass (AAB) allows packets to bypass detection if Snort is down or, for a Classic
device, if a packet takes too long to process. AAB causes Snort to restart within ten minutes of the failure,
and generates troubleshooting data that can be analyzed to investigate the cause of the Snort failure.
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 546 for more information.
See the following behavior:

FTD Behavior: If Snort is down, then AAB is triggered after the specified timer duration. If Snort is up, then
AAB is never triggered, even if packet processing exceeds the configured timer.
Classic Device Behavior: AAB limits the time allowed to process packets through an interface. You balance
packet processing delays with your network’s tolerance for packet latency.
The feature functions with any deployment; however, it is most valuable in inline deployments.
Typically, you use Rule Latency Thresholding in the intrusion policy to fast-path packets after the latency
threshold value is exceeded. Rule Latency Thresholding does not shut down the engine or generate
troubleshooting data.

387
Configure Object Group Search
If detection is bypassed, the device generates a health monitoring alert.

By default the AAB is disabled; to enable AAB follow the steps described.
Procedure

Step 2 Next to the device where you want to edit advanced device settings, click Edit ( ).
Step 3 Click Device, then click Edit ( ) in the Advanced Settings section.
Step 4 Check Automatic Application Bypass.
Step 5 Enter a Bypass Threshold from 250 ms to 60,000 ms. The default setting is 3000 milliseconds (ms).
Step 6 Click Save.
What to do next
Configure Object Group Search

While operating, the FTD device expands access control rules into multiple access control list entries based
on the contents of any network or interface 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 or interface 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.
Enabling object group search reduces memory requirements for access control policies that include network
or interface objects. However, it is important to note that object group search might also decrease rule lookup
performance and thus increase CPU utilization. You should balance the CPU impact against the reduced
memory requirements for your specific access control policy. In most cases, enabling object group search
provides a net operational improvement.
Object group search is disabled by default. You can enable it on one device at a time; you cannot enable it
globally. We recommend that you enable it on any device to which you deploy access rules that use network
or interface objects.
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.

388
Configure Interface Object Optimization
Before you begin

• Model Support—FTD
• We recommend that you also enable transactional commit on each device. From the device CLI, enter
the asp rule-engine transactional-commit access-group command.
• Changing this setting can be disruptive to system operation while the device recompiles the ACLs. We
recommend that you change this setting during a maintenance window.
Procedure

Step 2 Next to the FTD device where you want to configure the rule, click the Edit ( ).
Step 3 Click the Device tab, then click the Edit ( ) in the Advanced Settings section.
Step 4 Check Object Group Search.
Step 5 To have object group search work on interface objects in addition to network objects, check Interface Object
Optimization.
If you do not select Interface Object Optimization, the system deploys separate rules for each source/interface
pair, rather that use the security zones and interface groups used in the rules. This means the interface groups
are not available for object group search processing.
Step 6 Click Save.
Configure Interface Object Optimization

During deployment, interface groups and security zones used in the access control and prefilter policies
generate separate rules for each source/destination interface pair. If you enable interface object optimization,
the system will instead deploy a single rule per access control/prefilter rule, which can simplify the device
configuration and improve deployment performance. If you select this option, also select the Object Group
Search option to reduce memory usage on the device.
Interface object optimization is disabled by default. You can enable it on one device at a time; you cannot
enable it globally.
Note If you disable interface object optimization, your existing access control rules will be deployed without using
interface objects, which might make deployment take longer. In addition, if object group search is enabled,
its benefits will not apply to interface objects, and you might see expansion in the access control rules 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.
Before you begin

Model Support—FTD

389
Change the Manager for the Device
Procedure

Step 2 Next to the FTD device where you want to configure the rule, click the Edit ( ).
Step 3 Click the Device tab, then click Edit ( ) in the Advanced Settings section.
Step 4 Check Interface Object Optimization.
Step 5 Click Save.
Change the Manager for the Device

You might need to change the manager on a device in the following circumstances:
• Edit the FMC IP Address or Hostname on the Device, on page 390—If you change the FMC IP address
or hostname, we recommend that you match the new IP address or hostname on the device.
• Identify a New FMC, on page 391—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 392—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 393—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.
Edit the FMC IP Address or Hostname on the Device

If you change the FMC IP address or hostname, you should also change the value at the device CLI so the
configurations match. Although in most cases, the management connection will be reestablished without
changing the FMC IP address or hostname on the device, in at least one case, you must perform this task for
the connection to be reestablished: when you added the device to the FMC and you specified the NAT ID
only. Even in other cases, we recommend keeping the FMC IP address or hostname up to date for extra network
resiliency.
Before you begin

Model Support—FTD
Procedure
Step 1 At the FMC CLI, view the unique UUID for the FMC so you can specify it in the FTD command. For
information about the FMC CLI, see Firepower Management Center Command Line Reference, on page 3089.
show version

390
Identify a New FMC
The FMC UUID definitively identifies the FMC; for example, in the case of FMC High Availability, you
need to specify the active FMC on the FTD.
Example:
> show version

-------------------[ firepower ]--------------------
Model : Cisco Firepower Management Center for VMWare (66) Version 6.7.0
(Build 1222)
UUID : f2a06484-9f7f-11ea-b9f4-541a108ebbb5
Rules update version : 2020-05-26-001-vrt
VDB version : 334
----------------------------------------------------
Step 2 At the FTD CLI, edit the FMC IP address or hostname.

configure manager edit fmc_uuid {ip_address | hostname}
If the FMC was originally identified by DONTRESOLVE and a NAT ID, you can change the value to a
hostname or IP address using this command. You cannot change an IP address or hostname to
DONTRESOLVE.
The management connection will go down, and then reestablish. You can monitor the state of the connection
using the sftunnel-status command.
Example:
> configure manager edit f2a06484-9f7f-11ea-b9f4-541a108ebbb5 10.10.5.1
Identify a New FMC

This procedure shows how to identify a new FMC for the managed device. You should perform these steps
even if the new FMC uses the old FMC's IP address.
Procedure
Step 1 On the old FMC, if present, delete the managed device. See Delete a Device from the FMC, on page 358.
You cannot change the FMC IP address if you have an active connection with an FMC.
Step 2 Connect to the device CLI, for example using SSH.

Step 3 Configure the new FMC.
configure manager add {hostname | IPv4_address | IPv6_address | DONTRESOLVE } regkey [nat_id]
• {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.

391
Switch from Firepower Device Manager to FMC
• 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:
> configure manager add DONTRESOLVE abc123 efg456

Please make note of reg_key as this will be required while adding Device in FMC.
>
Step 4 Add the device to the FMC. See Add a Device to the FMC, on page 355.
Switch from Firepower Device Manager to FMC

This procedure describes how to change your manager from Firepower Device Manager (FDM), a local device
manager, to FMC. You can switch between FDM and FMC without reinstalling the software. 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.
Caution Changing the manager resets the FTD configuration to the factory default. However, the management bootstrap
configuration is maintained.
Before you begin

Model Support—FTD
Procedure
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 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:

392
Switch from FMC to Firepower Device Manager
> configure manager delete
If you enabled any feature licenses, you must disable them in

Firepower Device Manager before deleting the local manager.
Otherwise, those licenses remain assigned to the device in
Cisco Smart Software Manager.
Do you want to continue[yes/no]:yes
DHCP Server Disabled

>

Example:

>

This procedure describes how to change your manager from FMC to Firepower Device Manager (FDM), a
local device manager. You can switch between FDM and FMC without reinstalling the software. 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.
Caution Changing the manager resets the FTD configuration to the factory default. However, the management bootstrap
configuration is maintained.

393
Before you begin

Model Support—FTD
Procedure
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 930.
Step 2 In FMC, delete the managed device. See Delete a Device from the FMC, on page 358.
You cannot change the manager if you have an active connection with an FMC.

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:
> configure manager delete
If you enabled any feature licenses, you must disable them in

Firepower Device Manager before deleting the local manager.
Otherwise, those licenses remain assigned to the device in
Cisco Smart Software Manager.
Do you want to continue[yes/no]:yes
DHCP Server Disabled

>

Example:

394
Viewing Device Information

>
Viewing Device Information

In a multidomain deployment, ancestor domains can view information about all devices in descendant domains.
You must be in a leaf domain to edit a device.
Procedure

Step 2 Click Edit ( ) next to the device you want to view.
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.

Step 4 You can view the following information:
• General — Displays general settings for the device; see General Information, on page 396.
• License — Displays license information for the device; see License Information, on page 396.
• System — Displays system information about the device; see System Information, on page 396.
• Health — Displays information about the current health status of the device; see Health Information, on
page 397.
• Management — Displays information about the communication channel between the Firepower
Management Center and the device; see Management Information, on page 397.
• Advanced — Displays information about advanced feature configuration; see Advanced Settings, on
page 398.
Device Management Page Information

The Device Management page provides you with a range of information and options that you can use to
manage Firepower devices.
Use this page to add, edit, remove, and group devices, and to view basic device properties including health
status. You can view devices grouped by various characteristics, and further filter devices by health, upgrade,
or deployment status.
This page also provides one-click access to:
• The access control policy deployed to each device.

395
General Information
• Each device's health monitoring page, where you can generate a troubleshooting file.
• 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.
Table 28: General Section Table Fields
Field Description
Name The display name of the device on the Firepower

Management Center.
Transfer Packets This displays whether or not the managed device sends
packet data with the events to the Firepower
Management Center.
Mode The displays the mode of the management interface

for the device: routed or transparent.
Note The Mode field is displayed only for
Compliance Mode This displays the security certifications compliance

for a device. Valid values are CC, UCAPL and None.
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.
Table 29: System Section Table Fields
Field Description
Model The model name and number for the managed device.
Serial The serial number of the chassis of the managed

device.
Time The current system time of the device. This is always

in UTC.
See also the Time Zone setting for time-based rules,
below.

396
Health Information
Field Description
Version The version of the software currently installed on the

managed device.
Time Zone setting for time-based rules The current system time of the device, in the time
zone specified in device platform settings.
Policy A link to the platform settings policy currently

deployed to the managed device.
Inventory A link to the inventory details for the associated

device. This field only appears for some platforms,
for example, the Firepower 2100 or a Firepower
4100/9300 container instance. To update information
for a container instance, click Update. For example,
if you change the resource profile, you can force an
update of the inventory to avoid problems with
mismatching High Availability pairs. Otherwise, this
information is updated when you deploy policy
changes.
You can also shut down or restart the device.
Health Information
The Health section of the Device page displays the information described in the table below.
Table 30: Health Section Table Fields
Field Description
Status An icon that represents the current health status of the

device. Clicking the icon displays the Health Monitor
for the appliance.
Policy A link to a read-only version of the health policy

currently deployed at the device.
Blacklist A link to the Health Blacklist page, where you can

enable and disable health blacklist modules.
Management Information
The Management section of the Device page displays the fields described in the table below.

397
Advanced Settings
Table 31: Management Section Table Fields
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 360.
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.
FMC Access Interface Shows the type of interface used for FMC management: a data interface or the
management interface. To change the interface, click the value. See Edit Management
Settings, on page 360.
FMC Access Details Click the Configuration link to view the data interface configuration on the FMC
compared to the values on the device, as well as connection status. For more
information, see View FMC Access Details for Data Interface Management, on page
366.
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.
Table 32: Advanced Section Table Fields
Field Description Supported Devices
Application Bypass The state of Automatic Application Bypass on the device. NGIPSv
Bypass Threshold The Automatic Application Bypass threshold, in ASA FirePOWER

milliseconds. Firepower Threat
Defense
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 or interface 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 or interface 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.

398
History for Device Management Basics
Field Description Supported Devices
Interface Object The state of interface object optimization on the device. Firepower Threat
Optimization During deployment, interface groups and security zones Defense
used in the access control and prefilter policies generate
separate rules for each source/destination interface pair.
If you enable interface object optimization, the system
will instead deploy a single rule per access control/prefilter
rule, which can simplify the device configuration and
improve deployment performance. If you select this
option, also select the Object Group Search option to
reduce memory usage on the device.

Filter devices by upgrade 6.7.0 The Device Management page now provides upgrade information about
status. your managed devices, including whether a device is upgrading (and
what its upgrade path is), and whether its last upgrade succeeded or
failed.
New/modified screens: Devices > Device Management
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.
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.

399

400
PA R T III
System Monitoring and Troubleshooting
• Dashboards, on page 403
• Health Monitoring, on page 425
• Monitoring the System, on page 467
• Auditing the System, on page 477
• SNMP, on page 487
• Troubleshooting the System, on page 493
CHAPTER 14
Dashboards
The following topics describe how to use dashboards in the Firepower System:
• About Dashboards, on page 403
• Firepower System Dashboard Widgets, on page 404
• Managing Dashboards, on page 416
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.

403
Firepower System Dashboard Widgets
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.
Firepower System Dashboard Widgets

A dashboard has one or more tabs, each of which can display one or more widgets in a three-column layout.
The Firepower System is delivered with many predefined dashboard widgets, each of which provides insight
into a different aspect of the Firepower System. Widgets are grouped into three categories:
• Analysis & Reporting widgets display data about the events collected and generated by the Firepower
System.
• Miscellaneous widgets display neither event data nor operations data. Currently, the only widget in this
category displays an RSS feed.
• Operations widgets display information about the status and overall health of the Firepower System.
The dashboard widgets that you can view depend on:

• the type of appliance you are using
• your user role
• your current domain (in a multidomain deployment)
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 19.

404
Dashboard Widget Availability by User Role
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.
Dashboard Widget Availability by User Role

The following table lists the user account privileges required to view each widget. Only user accounts with
Administrator, Maintenance User, Security Analyst, or Security Analyst (Read Only) access can use dashboards.
Users with custom roles may have access to any combination of widgets, or none at all, as their user roles
permit.
Table 33: User Roles and Dashboard Widget Availability
Widget Administrator Maintenance User Security Analyst Security Analyst

(RO)
Appliance yes yes yes yes

Information
Appliance Status yes yes yes no
Correlation Events yes no yes yes
Current Interface yes yes yes yes

Status
Current Sessions yes no no no
Custom Analysis yes no yes yes
Disk Usage yes yes yes yes

405
Predefined Dashboard Widgets
Widget Administrator Maintenance User Security Analyst Security Analyst

(RO)
Interface Traffic yes yes yes yes
Intrusion Events yes no yes yes
Network yes no yes yes

Compliance
Product Licensing yes yes no no
Product Updates yes yes no no
RSS Feed yes yes yes yes
System Load yes yes yes yes
System Time yes yes yes yes
Allow List Events yes no yes yes
Predefined Dashboard Widgets

The Firepower System is delivered with several predefined widgets that, when used on dashboards, can provide
you with at-a-glance views of current system status. These views include:
• data about the events collected and generated by the system
• information about the status and overall health of the appliances in your deployment
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.
The Appliance Information Widget

The Appliance Information widget provides a snapshot of the appliance. It appears by default on the Status
tabs of the Detailed Dashboard and the Summary Dashboard. The widget provides:
• the name, IPv4 address, IPv6 address, and model of the appliance
• the versions of the Firepower System software, operating system, Snort, rule update, rule pack, module
pack, vulnerability database (VDB), and geolocation update installed on the appliances with dashboards,
except for virtual Firepower Management Centers
• for managed appliances, the name and status of the communications link with the managing appliance
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.

406
The Appliance Status Widget
The Appliance Status Widget

The Appliance Status widget indicates the health of the appliance and of any appliances it is managing. Note
that because the Firepower Management Center does not automatically apply a health policy to managed
devices, you must manually apply a health policy to devices or their status appears as Disabled. This widget
appears by default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.
You can configure the widget to display appliance status as a pie chart or in a table by modifying the widget
preferences.
The preferences also control how often the widget updates.
You can click a section on the pie chart or one of the numbers on the appliance status table to go to the Health
Monitor page and view the compiled health status of the appliance and of any appliances it is managing.
The Correlation Events Widget

The Correlation Events widget shows the average number of correlation events per second, by priority, over
the dashboard time range. It appears by default on the Correlation tab of the Detailed Dashboard.
You can configure the widget to display correlation events of different priorities by modifying the widget
preferences, as well as to choose a linear (incremental) or logarithmic (factor of ten) scale.
Check one or more Priorities check boxes to display separate graphs for events of specific priorities, including
events that do not have a priority. Choose Show All to display an additional graph for all correlation events,
regardless of priority. The preferences also control how often the widget updates.
You can click a graph to view correlation events of a specific priority, or click the All graph to view all
correlation events. In either case, the events are constrained by the dashboard time range; accessing correlation
events via the dashboard changes the events (or global) time window for the appliance.
The Current Interface Status Widget

The Current Interface Status widget shows the status of all interfaces on the appliance, enabled or unused. On
a Firepower Management Center, you can display the management (eth0, eth1, and so on) interfaces. On a
managed device, you can choose to show only sensing (s1p1 and so on) interfaces or both management and
sensing interfaces. Interfaces are grouped by type: management, inline, passive, switched, routed, and unused.
For each interface, the widget provides:
• the name of the interface
• the link state of the interface
• the link mode (for example, 100Mb full duplex, or 10Mb half duplex) of the interface
• the type of interface, that is, copper or fiber
• the amount of data received (Rx) and transmitted (Tx) by the interface
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

407
The Current Sessions Widget
• blue: link state information is not available (for example, ASA)
The widget preferences control how often the widget updates.
The Current Sessions Widget

The Current Sessions widget shows which users are currently logged into the appliance, the IP address
associated with the machine where the session originated, and the last time each user accessed a page on the
appliance (based on the local time for the appliance). The user that represents you, that is, the user currently
viewing the widget, is marked with a User icon and rendered in bold type. Sessions are pruned from this
widget’s data within one hour of logoff or inactivity. This widget appears by default on the Status tabs of the
Detailed Dashboard and the Summary Dashboard.
On the Current Sessions widget, you can:
• click any user name to manage user accounts on the User Management page.
• click the Host icon or Compromised Host icon next to any IP address to view the host profile for the
associated machine.
• click any IP address or access time to view the audit log constrained by that IP address and by the time
that the user associated with that IP address logged on to the web interface.
The Custom Analysis Widget

The Custom Analysis widget is a highly customizable widget that allows you to display detailed information
on the events collected and generated by the Firepower System.
The widget is delivered with multiple presets that provide quick access to information about your deployment.
The predefined dashboards make extensive use of these presets. You can use these presets or create a custom
configuration. At a minimum, a custom configuration specifies the data you are interested in (table and field),
and an aggregation method for that data. You can also set other display-related preferences, including whether
you want to show events as relative occurences (bar graph) or over time (line graph).
The widget displays the last time it updated, based on local time. The widget updates with a frequency that
depends on the dashboard time range. For example, if you set the dashboard time range to an hour, the widget
updates every five minutes. On the other hand, if you set the dashboard time range to a year, the widget updates
once a week. To determine when the dashboard will update next, hover your pointer over the Last updated
notice in the bottom left corner of the widget.
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)
Displaying Relative Occurrences of Events (Bar Graphs)

For bar graphs in the Custom Analysis widget, the colored bars in the widget background show the relative
number of occurrences of each event. Read the bars from right to left.
The Direction icon indicates and controls the sort order of the display. A downward-pointing icon indicates
descending order; an upward-pointing icon indicates ascending order. To change the sort order, click the icon.

408
The Custom Analysis Widget
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.
Displaying Events Over Time (Line Graphs)

If you want information on events or other collected data over time, you can configure the Custom Analysis
widget to display a line graph, such as one that displays the total number of intrusion events generated in your
deployment over time.
Limitations to the Custom Analysis Widget

A Custom Analysis widget may indicate that you are unauthorized to view the data that is configured to
display. For example, Maintenance Users are not authorized to view discovery events. As another example,
the widget does not display information related to unlicensed features. However, you (and any other users
who share the dashboard) can modify the widget preferences to display data that you can see, or even delete
the widget. If you want to make sure that this does not happen, save the dashboard as private.
When viewing user data, the system displays only authoritative users.
When viewing URL category information, the system does not display uncategorized URLs.
When viewing intrusion events aggregated by Count, the count includes reviewed events for intrusion events;
if you view the count in tables on pages under the Analysis menus, the count will not include reviewed events.
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.
Example: Custom Configuration

You can configure the Custom Analysis widget to display a list of recent intrusion events by
configuring the widget to display data from the Intrusion Events table. Choosing the Classification
field and aggregating this data by Count tells you how many events of each type were generated.
On the other hand, aggregating by Unique Events tells you how many unique intrusion events of
each type have occurred (for example, how many detections of network trojans, potential violations
of corporate policy, attempted denial-of-service attacks, and so on).
You can further constrain the widget using a saved search, either one of the predefined searches
delivered with your appliance or a custom search that you created. For example, constraining the

409
Custom Analysis Widget Preferences
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 421
Custom Analysis Widget Preferences

The following table describes the preferences you can set in the Custom Analysis widget.
Different preferences appear depending on how you configure the widget. For example, a different set of
preferences appears if you configure the widget to show relative occurrences of events (a bar graph) vs a graph
over time (a line graph). Some preferences, such as Filter, only appear if you choose a specific table from
which to display data.
Table 34: Custom Analysis Widget Preferences
Preference Details
Title If you do not specify a title for the widget, the system uses the
configured event type as the title.
Preset Custom Analysis presets provide quick access to information

about your deployment. The predefined dashboards make
extensive use of these presets. You can use these presets or you
can create a custom configuration.
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.

410
Viewing Associated Events from the Custom Analysis Widget
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.
Results Choose the number of result rows to display.
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 418
Viewing Associated Events from the Custom Analysis Widget

From a Custom Analysis widget, you can invoke an event view (workflow) that provides detailed information
about the events displayed in the widget. The events appear in the default workflow for that event type,
constrained by the dashboard time range. This also changes the appropriate time window on the Firepower
Management Center, depending on how many time windows you configured and on the event type.
For example:
• If you configure multiple time windows, then access health events from a Custom Analysis widget, the
events appear in the default health events workflow, and the health monitoring time window changes to
the dashboard time range.
• If you configure a single time window and then access any type of event from the Custom Analysis
widget, the events appear in the default workflow for that event type, and the global time window changes
to the dashboard time range.

411
The Disk Usage Widget
Procedure
You have the following choices:

• 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.
The Disk Usage Widget

The Disk Usage widget displays the percentage of space used on the hard drive, based on disk usage category.
It also indicates the percentage of space used on and capacity of each partition of the appliance’s hard drive.
The Disk Usage widget displays the same information for the malware storage pack if installed in the device,
or if the Firepower Management Center manages a device containing a malware storage pack. This widget
appears by default on the Status tabs of the Default Dashboard and the Summary Dashboard.
The By Category stacked bar displays each disk usage category as a proportion of the total available disk
space used. The following table describes the available categories.
Table 35: Disk Usage Categories
Disk Usage Category Description
Events all events logged by the system
Files all files stored by the system
Backups all backup files
Updates all files related to updates, such as rule updates and

system updates
Other system troubleshooting files and other miscellaneous

files
Free free space remaining on the appliance
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.

412
The Interface Traffic Widget
The Interface Traffic Widget

The Interface Traffic widget shows the rate of traffic received (Rx) and transmitted (Tx) on the appliance’s
management interface. The widget does not appear by default on any of the predefined dashboards.
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 Intrusion Events Widget

The Intrusion Events widget shows the intrusion events that occurred over the dashboard time range, organized
by priority. This includes statistics on intrusion events with dropped packets and different impacts. This widget
appears by default on the Intrusion Events tab of the Summary Dashboard.
In the widget preferences, you can choose:
• Event Flags to display separate graphs for events with dropped packets, would have dropped packets,
or specific impacts. Choose All to display an additional graph for all intrusion events, regardless of impact
or rule state.
For explanations of the icons, see Working with Intrusion Events, on page 2849. The arrow (if any) that
appears above the impact level numbers describes the inline result and is defined as follows:
Table 36: Inline Result Field Contents in Workflow and Table Views
This Icon Indicates
The system dropped the packet that triggered the rule.
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.
IPS may have transmitted or delivered the packet to the destination, but the
connection that contained this packet is now blocked.
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.
On the widget, you can:

• Click a graph corresponding to dropped packets, to would have dropped packets, or to a specific impact
to view intrusion events of that type.
• Click the graph corresponding to dropped events to view dropped events.

413
The Network Compliance Widget
• Click the graph corresponding to would have dropped events to view would have dropped events.
• Click the All graph to view all intrusion events.
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.
The Network Compliance Widget

The Network Compliance widget summarizes your hosts’ compliance with the allow lists you configured. By
default, the widget displays a pie chart that shows the number of hosts that are compliant, non-compliant, and
that have not been evaluated, for all compliance allow lists in active correlation policies. This widget appears
by default on the Correlation tab of the Detailed Dashboard.
You can configure the widget to display network compliance either for all allow lists or for a specific allow
list by modifying the widget preferences.
If you choose to display network compliance for all allow lists, the widget considers a host to be non-compliant
if it is not compliant with any allow list in an active correlation policy.
You can also use the widget preferences to specify which of three different styles you want to use to display
network compliance.
The Network Compliance style (the default) displays a pie chart that shows the number of hosts that are
compliant, non-compliant, and that have not been evaluated. You can click the pie chart to view the host
violation count, which lists the hosts that violate at least one allow list.
The Network Compliance over Time (%) style displays a stacked area graph showing the relative proportion
of hosts that are compliant, non-compliant, and that have not yet been evaluated, over the dashboard time
range.
The Network Compliance over Time style displays a line graph that shows the number of hosts that are
compliant, non-compliant, and that have not yet been evaluated, over the dashboard time range.
The preferences control how often the widget updates. You can check the Show Not Evaluated box to hide
events which have not been evaluated.
The Product Licensing Widget

The Product Licensing widget shows the device and feature licenses currently installed on the Firepower
Management Center. It also indicates the number of items licensed and the number of remaining licensed
items allowed. It does not appear by default on any of the predefined dashboards.
The top section of the widget displays all device and feature licenses installed on the Firepower Management
Center, including temporary licenses, while the Expiring Licenses section displays only temporary and expired
licenses.
The bars in the widget background show the percentage of each type of license that is being used; you should
read the bars from right to left. Expired licenses are marked with a strikethrough.
You can configure the widget to display either the features that are currently licensed, or all the features that
you can license, by modifying the widget preferences. The preferences also control how often the widget
updates.
You can click any of the license types to go to the License page of the local configuration and add or delete
feature licenses.

414
The Product Updates Widget
The Product Updates Widget

The Product Updates widget provides you with a summary of the software currently installed on the appliance
as well as information on updates that you have downloaded, but not yet installed. This widget appears by
default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.
Because the widget uses scheduled tasks to determine the latest version, it displays Unknown until you
configure a scheduled task to download, push or install updates.
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.
The RSS Feed Widget

The RSS Feed widget adds an RSS feed to a dashboard. By default, the widget shows a feed of Cisco security
news. It appears by default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.
You can also configure the widget to display a preconfigured feed of company news, the Snort.org blog, or
the Cisco Threat Research blog, or you can create a custom connection to any other RSS feed by specifying
its URL in the widget preferences. The FMC can display encrypted RSS feeds only if they use trusted server
certificates signed by a certificate authority (CA) that the FMC recognizes. If you configure the RSS Feed
widget to display an encrypted RSS feed that uses a CA the FMC does not recognize, or that uses a self-signed
certificate, the verification fails and the widget does not display the feed.
Feeds update every 24 hours (although you can manually update the feed), and the widget displays the last
time the feed was updated based on the local time of the appliance. Keep in mind that the appliance must have
access to the web site (for the two preconfigured feeds) or to any custom feed you configure.
When you configure the widget, you can also choose how many stories from the feed you want to show in
the widget, as well as whether you want to show descriptions of the stories along with the headlines; keep in
mind that not all RSS feeds use descriptions.
On the RSS Feed widget, you can:
• click one of the stories in the feed to view the story
• click the more link to go to the feed’s web site
• click Update ( ) to manually update the feed
The System Load Widget

The System Load widget shows the CPU usage (for each CPU), memory (RAM) usage, and system load (also
called the load average, measured by the number of processes waiting to execute) on the appliance, both
currently and over the dashboard time range. It appears by default on the Status tabs of the Detailed Dashboard
and the Summary Dashboard.
You can configure the widget to show or hide the load average by modifying the widget preferences. The
preferences also control how often the widget updates.

415
The System Time Widget
The System Time Widget

The System Time widget shows the local system time, uptime, and boot time for the appliance. It appears by
default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.
You can configure the widget to hide the boot time by modifying the widget preferences. The preferences
also control how often the widget synchronizes with the appliance’s clock.
The Allow List Events Widget

The Allow List Events widget shows the average events per second by priority, over the dashboard time range.
It appears by default on the Correlation tab of the Default Dashboard.
You can configure the widget to display allow list events of different priorities by modifying the widget
preferences.
In the widget preferences, you can:
• choose one or more Priorities check boxes to display separate graphs for events of specific priorities,
including events that do not have a priority
• choose Show All to display an additional graph for all allow list events, regardless of priority
• choose Vertical Scale to choose Linear (incremental) or Logarithmic (factor of ten) scale
The preferences also control how often the widget updates.

You can click a graph to view allow list events of a specific priority, or click the All graph to view all allow
list events. In either case, the events are constrained by the dashboard time range; accessing allow list events
via the dashboard changes the events (or global) time window for the Firepower Management Center.
Managing Dashboards
Procedure
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 418.
• 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 421.
• Modify Time Constraints — Modify the time display or pause/unpause the dashboard as described in
Modifying Dashboard Time Settings, on page 421.
Step 3 Add (see Adding a Dashboard, on page 417), Delete (click Close ( )), and Rename (see Renaming a
Dashboard, on page 422) dashboards.
Note You cannot change the order of dashboards.

416
Adding a Dashboard
Step 4 Manage dashboard widgets:

• Add Widgets — Add widgets to a dashboard; see Adding Widgets to a Dashboard, on page 417.
• Configure Preferences — Configure widget preferences; see Configuring Widget Preferences, on page
418.
• Customize Display — Customize the widget display; see Customizing the Widget Display, on page 420.
• View Events — View associated events from the Custom Analysis Widget; see Viewing Associated
Events from the Custom Analysis Widget, on page 411.
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
Procedure
Step 1 View the dashboard you want to modify; see Viewing Dashboards, on page 423.
Step 2 Click Add ( ).

Step 3 Enter a name.
Step 4 Click OK.
Adding Widgets to a Dashboard

Each tab can display one or more widgets in a three-column layout. When adding a widget to a dashboard,
you choose the tab to which you want to add the widget. The system automatically adds it to the column with
the fewest widgets. If all columns have an equal number of widgets, the new widget is added to the leftmost
column. You can add a maximum of 15 widgets to a dashboard tab.
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.
Procedure
Step 1 View the dashboard where you want to add a widget; see Viewing Dashboards, on page 423.

417
Configuring Widget Preferences
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 418.
Related Topics
Widget Availability, on page 404
Configuring Widget Preferences

Each widget has a set of preferences that determines its behavior.
Procedure
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.
Creating Custom Dashboards
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.
Procedure
Step 1 Choose Overview > Dashboards > Management.

Step 2 Click Create Dashboard.
Step 3 Modify the custom dashboard options as described in Custom Dashboard Options, on page 419.

418
Custom Dashboard Options
Step 4 Click Save.
Custom Dashboard Options

The table below describes options you can use when creating or editing custom dashboards.
Table 37: Custom Dashboard Options
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.
Name A unique name for the custom dashboard.
Description A brief description of the custom dashboard.
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.

419
Customizing the Widget Display
Option Description
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.
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.
Customizing the Widget Display

You can minimize and maximize widgets, as well as rearrange the widgets on a tab.
Procedure
Step 1 View a dashboard; see Viewing Dashboards, on page 423.

Step 2 Customize the widget display:
• To rearrange a widget on a tab, click the title bar of the widget you want to move, then drag it to its new
location.

420
Editing Dashboards Options
Note You cannot move widgets from tab to tab. If you want a widget to appear on a different tab,
you must delete it from the existing tab and add it to the new tab.
• 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.
Editing Dashboards Options

Procedure
Step 1 View the dashboard you want to edit; see Viewing Dashboards, on page 423.
Step 2 Click Edit ( ).
Step 3 Change the options as described in Custom Dashboard Options, on page 419.
Step 4 Click Save.
Modifying Dashboard Time Settings

You can change the time range to reflect a period as short as the last hour (the default) or as long as the last
year. When you change the time range, the widgets that can be constrained by time automatically update to
reflect the new time range.
The maximum number of data points in any graph is 300, and the time setting determines how much time is
summarized within each data point. Following is the number of data points, and the time span covered, in the
dashboards for each time range:
• 1 hour = 12 data points, 5 minutes each
• 6 hours = 72 data points, 5 minutes each
• 1 day = 288 data points, 5 minutes each
• 1 week = 300 data points, 33.6 minutes each
• 2 weeks = 300 data points, 67.2 minutes each
• 30 days = 300 data points, 144 minutes each
• 1 year = 300 data points, 1752 minutes each
Note that not all widgets can be constrained by time. For example, the dashboard time range has no effect on
the Appliance Information widget, which provides information that includes the appliance name, model, and
current version of the Firepower System software.

421
Renaming a Dashboard
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.
Procedure
Step 1 View the dashboard where you want to add a widget; see Viewing Dashboards, on page 423.
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
Procedure
Step 1 View the dashboard you want to modify; see Viewing Dashboards, on page 423.
Step 2 Click the dasboard title you want to rename.
Step 3 Type a name.
Step 4 Click OK.

422
Viewing Dashboards
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.
Procedure
At any time, you can do one of the following:

• To view the default dashboard for your appliance, choose Overview > Dashboards.
• To view a specific dashboard, choose Overview > Dashboards, and choose the dashboard from the
menu.
• To view all available dashboards, choose Overview > Dashboards > Management. You can then choose
View ( ) next to an individual dashboard to view it.

423
Viewing Dashboards

424
CHAPTER 15
Health Monitoring
The following topics describe how to use health monitoring in the Firepower System:
• Requirements and Prerequisites for Health Monitoring, on page 425
• About Health Monitoring, on page 425
• Health Policies, on page 437
• The Health Monitor Blocklist, on page 440
• Health Monitor Alerts, on page 442
• About the Health Monitor, on page 445
• Health Event Views, on page 460
• History for Health Monitoring, on page 464
Requirements and Prerequisites for Health Monitoring

Model Support
Any
Supported Domains
Any
User Roles
Admin
Maintenace User
About Health Monitoring

The health monitor on the Firepower Management Center tracks a variety of health indicators to ensure that
the hardware and software in the Firepower System are working correctly. You can use the health monitor to
check the status of critical functionality across your Firepower System deployment.

425
About Health Monitoring
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.

426
Health Modules
Health Modules
Health modules, or health tests, test for the criteria you specify in a health policy.
Table 38: Health Modules
Module Appliances Description
Advanced Snort FMC This module monitors Snort statistics related to packet performance, flow
Statistics counters, and flow events.
AMP Connection FTD The module alerts if the FTD 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. Disabled by default.
AMP for Endpoints FMC The module alerts if the FMC cannot connect to the AMP cloud or Cisco
Status AMP 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.
AMP for Firepower FMC This module alerts if:

Status
• The FMC cannot contact the AMP cloud (public or private) or the Cisco
(AMP for Networks Threat Grid public cloud or on-premises appliance, or the AMP private
Status) cloud cannot contact the public AMP cloud.
• The encryption keys used for the connection are invalid.
• A device cannot contact the Cisco Threat Grid cloud or an Cisco Threat
Grid on-premises appliance to submit files for dynamic analysis.
• An excessive number of files are detected in network traffic based on
the file policy configuration.
If your FMC loses connectivity to the Internet, the system may take up to 30
minutes to generate a health alert.
AMP Threat Grid FTD The module alerts if the FTD cannot connect to the AMP Threat Grid cloud
Status after an initial successful connection.
Appliance Heartbeat Any This module determines if an appliance heartbeat is being heard from the
appliance and alerts based on the appliance heartbeat status.
ASP Drop FMC This module monitors the connections dropped by the data plane accelerated
security path.
Backlog Status FMC This module alerts 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.

427
Health Modules
CPU Usage (per core) FTD This module checks that the CPU usage on all of the cores is not overloaded
and alerts when CPU usage exceeds the percentages configured for the
module. The Warning Threshold % default value is 80. The Critical
Threshold % default value is 90.
CPU Usage Data Plane FTD This module checks that the average CPU usage of all data plane processes
on the device is not overloaded and alerts when CPU usage exceeds the
percentages configured for the module. The Warning Threshold % default
value is 80. The Critical Threshold % default value is 90.
CPU Usage Snort FTD This module checks that the average CPU usage of the Snort processes on
the device is not overloaded and alerts when CPU usage exceeds the
CPU Usage System FTD This module checks that the average CPU usage of all system processes on
the device is not overloaded and alerts when CPU usage exceeds the
Card Reset Any This module checks for network cards which have restarted due to hardware
failure and alerts when a reset occurs.
Chassis Status FTD Firepower 2100 series, This module monitors chassis parameters such as fan speed and chassis
Firepower 1000 series temperature, and enables you to set a warning threshold and critical threshold
for temperature. The Critical Chassis Temperature (Celsius) default value
is 85. The Warning Chassis Temperature (Celsius) default value is 75.
Classic License FMC This module determines if sufficient Classic licenses remain. It alerts based
Monitor on a warning level automatically configured for the module. You cannot
change the configuration of this module.
Cluster/Failover Status FTD 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 FMC This module checks the size of the configuration database and alerts when
Database the size exceeds the values (in gigabytes) configured for the module.
Configuration Memory Any managed device This module alerts if the size of your deployed configurations puts a device
Allocation at risk of running out of memory.
The alert shows you how much memory your configurations require, and by
how much this exceeds the available memory. If this happens, re-evaluate
your configurations. Most often you can reduce the number or complexity of
access control rules or intrusion policies.
Connection Statistics FTD This module monitors the connection statistics and NAT translation counts.

428
Health Modules
Critical Process FTD This module monitors the state of critical processes, their resource
Statistics consumption, and the restart counts.
Deployed FTD This module monitors statistics about the deployed configuration, such as the
Configuration Statistics number of ACEs and IPS rules.
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. See Disk Usage and Drain of Events Health Monitor
Alerts, on page 501 for information about troubleshooting scenarios for Disk
Usage alerts.
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.
Event Stream Status FMC This module monitors connections to third-party client applications that use
the Event Streamer on the FMC.
FMC Access FMC This module monitors access configuration changes made on the FMC directly
Configuration Changes using the configure network management-data-interface command.
FMC 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.
Note This module replaces the HA Status module, which previously
provided HA status for the FMC. In Version 7.0, we added HA
status for managed devices.
FTD HA Status FTD This module monitors and alerts on the high availability status of the FTD
and provides a health alert for a split brain scenario. If you have not established
FTD high availability, the HA Status is Not in HA.

429
Health Modules
File System Integrity FMC This module performs a file system integrity check and runs if the system
Check has CC mode or UCAPL mode enabled, or if the system runs an image signed
with a DEV key. This module is enabled by default.
Flow Offload Firepower 9300, Firepower This module monitors hardware flow offload statistics for a managed device.
4100 series
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.
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.
Hit Count FMC This module tracks the number of times a particular rule is hit on the access
control policy. Disabled by default.
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 2346.
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 except This module monitors the ports associated with inline sets and alerts if the
Alarms ASA FirePOWER two interfaces of an inline pair negotiate different speeds.
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.

430
Health Modules
Intrusion and File Any managed device This module compares the number of intrusion events per second to the limits
Event 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.
Link State Propagation ASA 5500-X series and ISA This module determines when a link in a paired inline set fails and triggers
3000 with FTD the link state propagation mode.
If a link state propagates to the pair, the status classification for that module
changes to Critical and the state reads:
Module Link State Propagation: ethx_ethy is Triggered
where x and y are the paired interface numbers.

431
Health Modules
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 500 for additional information about how thresholds are
calculated.
Beginning with Version 6.6.0, 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.
Memory Usage Data FTD This module checks the percentage of allocated memory used by the Data
Plane Plane processes and alerts when memory usage exceeds the percentages
configured for the module. The Warning Threshold % default value is 80.
The Critical Threshold % default value is 90.
Memory Usage Snort FTD This module checks the percentage of allocated memory used by the Snort
process and alerts when memory usage exceeds the percentages configured
for the module. The Warning Threshold % default value is 80. The Critical
MySQL Status FMC This module monitors the status of the MySQL database, including the
database size, number of active connections, and memory use. Disabled by
default.
NTP Status FTD FTD This module monitors the NTP clock synchronisation status of the managed
device. Disabled by default.

432
Health Modules
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.
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.
RabbitMQ Status FMC This module monitors the status of the RabbitMQ.
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 2420.
• 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 2441.
Reconfiguring Any managed device This module alerts if a device reconfiguration has failed.
Detection
Routing Statistics FMC This module monitors the current state of routing table.

433
Health Modules
SSE Connection Status Any managed device The module alerts if the FTD cannot connect to the SSE cloud after an initial
successful connection. Disabled by default.
Security Intelligence FMC This module alerts if Security Intelligence is in use and the FMC cannot
update a feed, or feed data is corrupt or contains no recognizable IP addresses.
See also the Threat Data Updates on Devices module.
Smart License Monitor FMC This module alerts if:

• There is a communication error between the Smart Licensing Agent
(Smart Agent) and the Smart Software Manager.
• The Product Instance Registration Token has expired.
• The Smart License usage is out of compliance.
• The Smart License authorization or evaluation mode has expired.
Snort Identity Memory FTD 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
Snort Statistics FTD This module monitors the Snort statistics for events, flows, and packets.
Sybase Status FMC This module monitors the status of the Sybase database on the FMC, including
the database size, number of active connections, and memory use.

434
Health Modules
Threat Data Updates Any Certain intelligence data and configurations that devices use to detect threats
on Devices are updated on the FMC from the cloud every 30 minutes.
This module alerts you if this information has not been updated on the devices
within the time period you have specified.
Monitored updates include:
• Local URL category and reputation data
• Security Intelligence URL lists and feeds, including global Block and
Do Not Block lists and URLs from Threat Intelligence Director
• Security Intelligence network lists and feeds (IP addresses), including
global Block and Do Not Block lists and IP addresses from Threat
Intelligence Director
• Security Intelligence DNS lists and feeds, including global Block and
Do Not 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.
Note Threat Intelligence Director updates are included only if TID is

configured on your system and you have feeds.
By default, this module sends a warning after 1 hour and a critical alert after
24 hours.
If this module indicates failure on the FMC or on any devices, verify that the
FMC can reach the devices.
For low-memory devices that show failure of the URL category and reputation
data type, see Troubleshooting Memory Use, on page 1696.
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.

435
Configuring Health Monitoring
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 FMC This module alerts if the FMC fails to:
• Register with the Cisco cloud.
• Download URL threat data updates from the Cisco cloud.
• Complete URL lookups.
You can configure time thresholds for these alerts.

See also the Threat Data Updates on Devices module.
Unresolved Groups FMC Monitors unresolved groups used in policies.

Monitor
VPN Statistics FMC This module monitors Site to Site and RA VPN tunnels between Firepower
devices.
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
Attention Site-to-site VPN tunnels created with Virtual Tunnel
Interfaces (VTIs) do not generate health alerts when the tunnel
goes down. If you experience packet loss over a VPN with
VTIs, check your VPN configuration.
• Remote access VPN for Firepower Threat Defense
xTLS Counters Any This module monitors xTLS/SSL flows, memory and cache effectiveness.
Disabled by default.
Configuring Health Monitoring

Procedure
Step 1 Determine which health modules you want to monitor as discussed in #unique_320.
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.

436
Health Policies
Step 2 Apply a health policy to each appliance where you want to track health status as discussed in Creating Health
Policies, on page 437.
Step 3 (Optional.) Configure health monitor alerts as discussed in Creating Health Monitor Alerts, on page 443.
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.
Default Health Policy

The Firepower Management Center setup process creates and applies an initial health policy, in which
most—but not all—available health modules are enabled. The system also applies this initial policy to devices
added to the Firepower Management Center.
This initial health policy is based on a default health policy, which you can neither view nor edit, but which
you can copy when you create a custom health policy.
Upgrades and the Default Health Policy

When you upgrade the FMC, any new health modules are added to all health policies, including the initial
health policy, default health policy, and any other custom health policies. Usually, new health modules are
added in an enabled state.
Note For a new health module to begin monitoring and alerting, reapply health policies after upgrade.
Creating Health Policies

If you want to customize a health policy to use with your appliances, you can create a new policy. The settings
in the policy initially populate with the settings from the health policy you choose as a basis for the new policy.
You can enable or disable modules within the policy and change the alerting criteria for each module as
needed.

437
Applying Health Policies
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. Administrators in ancestor domains can apply health policies to
devices in descendant domains, which descendant domains can use or replace with customized local policies.
Procedure
Step 1 Choose System > Health > Policy .

Step 2 Click New Policy.
Step 3 Choose the existing policy that you want to use as the basis for the new policy from the Copy Policy drop-down
list.
Step 4 Enter a name for the policy.
Step 5 Enter a description for the policy.
Step 6 Choose Save to save the policy information.
Step 7 Choose the module you want to use.
Step 8 Choose On for the Enabled option to enable use of the module for health status testing.
Step 9 Where appropriate, set the Critical and Warning criteria.
Step 10 Configure any additional settings for the module. Repeat steps 7-10 for each module.
Step 11 You have three choices:
• To save your changes to this module and return to the Health Policy page, click Save Policy and Exit.
• To return to the Health Policy page without saving any of your settings for this module, click Cancel.
• To temporarily save your changes to this module and switch to another module’s settings to modify,
choose the other module from the list at the left of the page. If you click Save Policy and Exit when you
are done, all changes you made will be saved; if you click Cancel, you discard all changes.
What to do next
• Apply the health policy to each appliance as described in Applying Health Policies, on page 438. This
applies your changes and updates the policy status for all affected policies.
Applying Health Policies

When you apply a health policy to an appliance, the health tests for all the modules you enabled in the policy
automatically monitor the health of the processes and hardware on the appliance. Health tests then continue
to run at the intervals you configured in the policy, collecting health data for the appliance and forwarding
that data to the Firepower Management Center.
If you enable a module in a health policy and then apply the policy to an appliance that does not require that
health test, the health monitor reports the status for that health module as disabled.
If you apply a policy with all modules disabled to an appliance, it removes all applied health policies from
the appliance so no health policy is applied.
When you apply a different policy to an appliance that already has a policy applied, expect some latency in
the display of new data based on the newly applied tests.

438
Editing Health Policies
Procedure
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 498.
Monitoring of the appliance starts as soon as the policy is successfully applied.
Editing Health Policies

Procedure

Step 2 Click Edit ( ) next to the policy you want to modify.
Step 3 Edit the Policy Name or Policy Description fields as desired.
Step 4 Click the health module you want to modify.
Step 5 Modify settings as described in #unique_320.
Step 6 You have three options:
• To save your changes to this module and return to the Health Policy page, click Save Policy and Exit.
• To return to the Health Policy page without saving any of your settings for this module, click Cancel.
• To temporarily save your changes to this module and switch to another module’s settings to modify,
choose the other module from the list at the left of the page. If you click Save Policy and Exit when you
are done, all changes you made will be saved; if you click Cancel, you discard all changes.

439
Deleting Health Policies
What to do next
• Reapply the health policy as described in Applying Health Policies, on page 438. This applies your changes
and updates the policy status for all affected policies.
Deleting Health Policies

You can delete health policies that you no longer need. If you delete a policy that is still applied to an appliance,
the policy settings remain in effect until you apply a different policy. In addition, if you delete a health policy
that is applied to a device, any health monitoring alerts in effect for the device remain active until you disable
the underlying associated alert response.
In a multidomain deployment, you can only delete health policies created in the current domain.
Tip To stop health monitoring for an appliance, create a health policy with all modules disabled and apply it to
the appliance.
Procedure
Step 2 Click Delete ( ) next to the policy you want to delete.

A message appears, indicating if the deletion was successful.
The Health Monitor Blocklist

In the course of normal network maintenance, you disable appliances or make them temporarily unavailable.
Because those outages are deliberate, you do not want the health status from those appliances to affect the
summary health status on your Firepower Management Center.
You can use the health monitor blocklist feature to disable health monitoring status reporting on an appliance
or module. For example, if you know that a segment of your network will be unavailable, you can temporarily
disable health monitoring for a managed device on that segment to prevent the health status on the Firepower
Management Center from displaying a warning or critical state because of the lapsed connection to the device.
When you disable health monitoring status, health events are still generated, but they have a disabled status
and do not affect the health status for the health monitor. If you remove the appliance or module from the
blocklist, the events that were generated during the blocklisting continue to show a status of disabled.
To temporarily disable health events from an appliance, go to the blocklist configuration page and add an
appliance to the blocklist. After the setting takes effect, the system no longer includes the blocklisted appliance
when calculating the overall health status. The Health Monitor Appliance Status Summary lists the appliance
as disabled.
You can also disable an individual health module. For example, when you reach the host limit on a Firepower
Management Center, you can disable Host Limit status messages.

440
Blacklisting Appliances
Note that on the main Health Monitor page you can distinguish between appliances that are blocklisted if you
expand to view the list of appliances with a particular status by clicking the arrow in that status row.
A Blocklist ( ) and a notation are visible after you expand the view for a blocklisted or partially blocklisted
appliance.
Note On a Firepower Management Center, Health Monitor blocklist settings are local configuration settings.
Therefore, if you blocklist a device, then delete it and later re-register it with the Firepower Management
Center, the blocklist settings remain persistent. The newly re-registered device remains blocklisted.
In a multidomain deployment, administrators in ancestor domains can blocklist an appliance or health module
in descendant domains. However, administrators in the descendant domains can override the ancestor
configuration and clear the blocklist 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.
Procedure
Step 1 Choose System > Health > Blacklist.

Step 2 Use the drop-down list on the right to sort the list by group, model, or by health policy.
Tip
The status icon next to the Health Policy column Status ( ) indicates the current health status for
the appliance. The status icon next to the System Policy column Status ( ) indicates the
communication status between the Firepower Management Center and the device.
Step 3 You have two choices:

• To blacklist all appliances in a group, model, or policy category, check the check box for the category,
then click Blacklist Selected Devices.
• To clear blacklisting from all appliances in a group, model, or policy category, check the check box for
the category, then click Clear Blacklist on Selected Devices.

441
Blacklisting Health Policy Modules
Blacklisting Health Policy Modules

You can blacklist individual health policy modules on appliances. You may want to do this to prevent events
from the module from changing the status for the appliance to warning or critical.
After the blacklist settings take effect, the appliance shows as Partially Blacklisted or All Modules Blacklisted
on the Blacklist page and in the Appliance Health Monitor Module Status Summary, but only in expanded
views on the main Appliance Status Summary page.
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.
Procedure
Step 1 Choose System > Health > Blacklist.

Step 2 Click Edit ( ) next to the appliance you want to modify.
Step 3 Check the check boxes next to the health policy modules you want to blacklist. Certain modules are applicable
to specific devices only; for more information, see #unique_320.
Step 4 Click Save.
Health Monitor Alerts

You can set up alerts to notify you through email, through SNMP, or through the system log when the status
changes for the modules in a health policy. You can associate an existing alert response with health event
levels to trigger and alert when health events of a particular level occur.
For example, if you are concerned that your appliances may run out of hard disk space, you can automatically
send an email to a system administrator when the remaining disk space reaches the warning level. If the hard
drive continues to fill, you can send a second email when the hard drive reaches the critical level.
In a multidomain deployment, you can view and modify health monitor alerts created in the current domain
only.
Health Monitor Alert Information

The alerts generated by the health monitor contain the following information:
• Severity, which indicates the severity level of the alert.
• Module, which specifies the health module whose test results triggered the alert.

442
Creating Health Monitor Alerts
• Description, which includes the health test results that triggered the alert.
The table below describes these severity levels.
Table 39: Alert Severities
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.
Error The health test did not run.
Recovered The health test results met the criteria to return to a normal alert
status, following a Critical or Warning alert status.
Creating Health Monitor Alerts

You must be an Admin user to perform this procedure.
When you create a health monitor alert, you create an association between a severity level, a health module,
and an alert response. You can use an existing alert or configure a new one specifically to report on system
health. When the severity level occurs for the selected module, the alert triggers.
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.
only.
Before you begin

• Configure an alert response that governs the Firepower Management Center's communication with the
SNMP, syslog, or email server where you send the health alert; see Firepower Management Center Alert
Responses, on page 2631.
Procedure
Step 1 Choose System > Health > Monitor Alerts.

Step 2 Enter a name for the health alert in the Health Alert Name field.
Step 3 From the Severity list, choose the severity level you want to use to trigger the alert.
Step 4 From the Module list, choose the health policy modules for which you want the alert to apply.

443
Editing Health Monitor Alerts
Step 5 From the Alert list, choose the alert response that you want to trigger when the specified severity level is
reached.
Step 6 Optionally, in the Threshold Timeout field, enter the number of minutes that should elapse before each
threshold period ends and the threshold count resets.
Even if the policy run time interval value is less than the threshold timeout value, the interval between two
reported health events from a given module is always greater. For example, if you change the threshold timeout
to 8 minutes and the policy run time interval is 5 minutes, there is a 10-minute interval (5 x 2) between reported
events.
Step 7 Click Save to save the health alert.
Editing Health Monitor Alerts

You can edit existing health monitor alerts to change the severity level, health module, or alert response
associated with the health monitor alert.
only.
Procedure

Step 2 Choose the alert you want to modify from the Active Health Alerts list.
Step 3 Click Load to load the configured settings for the alert you chose.
Step 4 Modify settings as needed.
Step 5 Click Save to save the modified health alert.
A message indicates if the alert configuration was successfully saved.
Deleting Health Monitor Alerts

only.
Procedure

Step 2 Choose the active health alerts you want to delete, then click Delete.

444
About the Health Monitor
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 2631.
About the Health Monitor

You must be an Admin, Maintenance, or Security Analyst user to perform this procedure.
The health monitor provides the compiled health status for all devices managed by the Firepower Management
Center, plus the Firepower Management Center itself. The health monitor is composed of:
• The Health Status summary page ― Provides you with an at-a-glance view of the health of the Firepower
Management Center and all of the devices that the FMC manages. Devices are listed individually, or
grouped according to their geolocation, high availability, or cluster status where applicable.
• View the health summary of the FMC and any device when you hover on the hexagon that represents
the device health.
• The dot to the left of a device indicates its health:
• Green ― No alarms.
• Orange ― At least one health warning.
• Red ― At least one critical health alarm.
• The Monitoring navigation pane ― Allows you to navigate the device hierarchy. You can view health
monitors for individual devices from the navigation pane.
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.
Procedure
Step 1 Choose System > Health > Monitor.

Step 2 View the status of the FMC and its managed devices in the Health Status landing page.
a) Hover your pointer over a hexagon to view the health summary of a device. The popup window shows a
truncated summary of the top five health alerts. Click on the popup to open a detailed view of the health
alert summary.
b) In the device list, click Expand ( ) and Collapse ( ) to expand and collapse the list of health alerts
for a device.
When you expand the row, all of the health alerts are listed, including the status, title, and details.
Note Health alerts are sorted by their severity level.
Step 3 Use the Monitoring navigation pane to access device-specific health monitors. When you use the Monitoring
navigation pane:
a) Click Home to return Health Status summary page.

445
Using the FMC Health Monitor
b) Click FMC to view the health monitor for the Firepower Management Center itself.
c) In the device list, click Expand ( ) and Collapse ( ) to expand and collapse the list of managed
devices.
When you expand the row, all of the devices are listed.
d) Click on a device to view a device-specific health monitor.
What to do next
• See Device Health Monitors, on page 448 for information about the compiled health status and metrics
for any device managed by the Firepower Management Center.
• See Using the FMC Health Monitor, on page 446 for information about the health status of the Firepower
Management Center.
To return to the Health Status landing page at any time, click Home.
Using the FMC Health Monitor

The FMC monitor provides a detailed view of the health status of the Firepower Management Center. The
health monitor is composed of:
• High Availability (if configured) ― The High Availability (HA) panel displays the current HA status,
including the status of the Active and Standby units, the last sync time, and overall device health.
• Event Rate ― The Event Rate panel shows the maximum event rate as a base line as well as the overall
event rate received by the FMC.
• Event Capacity ― The Event Capacity panel shows the current consumption by event categories, including
the retention time of events, the current vs. maximum event capacity, and a capacity overflow mechanism
where you are alerted when events are stored beyond the configured maximum capacity of the FMC.
• Process Health ― The Process Health panel has an at-a-glace view of the critical processes as well as a
tab that lets you see state of all processed, including the CPU and memory usage for each process.
• CPU ― The CPU panel lets you toggle between the average CPU usage (default) and the CPU usage of
all cores.
• Memory ― The Memory panel shows the overall memory usage on the FMC.
• Interface ― The Interface panel shows avaerage input and output rate of all interfaces.
• Disk Usage ― The Disk Usage panel shows the use of entire disk, and the use of the critical partitions
where FMC data is stored.

446
Running All Modules for an Appliance
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 1397 for more information.
Procedure

Step 2 Use the Monitoring navigation pane to access the FMC and device-specific health monitors.
• A standalone FMC is shown as a single node; a high-availability FMC is shown as a pair of nodes.
• The health monitor is available to both the active and standby FMC in an HA pair.
Step 3 Explore the FMC dashboard.

The FMC dashboard includes a summary view of the HA state of the FMC (if configured), as well as at-a-glance
views of FMC processes and device metrics such as CPU, memory, and disk usage.
Running All Modules for an Appliance

Health module tests run automatically at the policy run time interval you configure when you create a health
policy. However, you can also run all health module tests on demand to collect up-to-date health information
for the appliance.
In a multidomain deployment, you can run health module tests for appliances in the current domain and in
any descendant domains.
Procedure
Step 1 View the health monitor for the appliance.

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.
Running a Specific Health Module


447
Generating Health Module Alert Graphs
Health module tests run automatically at the policy run time interval you configure when you create a health
policy. However, you can also run a health module test on demand to collect up-to-date health information
for that module.
In a multidomain deployment, you can run health module tests for appliances in the current domain and in
any descendant domains.
Procedure

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.
Generating Health Module Alert Graphs

You can graph the results over a period of time of a particular health test for a specific appliance.
Procedure

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.
Device Health Monitors

The device health monitor provides the compiled health status for any device managed by the Firepower
Management Center. The device health monitor collects health metrics for Firepower devices in order to
predict and repond to system events. The device health monitor is comprised of the following components:
• System Details ― Displays information about the managed device, including the installed Firepower
version and other deployment details.
• Troubleshooting & Links ― Provides convenient links to frequently used troubleshooting topics and
procedures.

448
Viewing System Details and Troubleshooting
• Health alerts ― A health alert monitor provides an at-a-glance view of the health of the device.
• Time range ― An adjustable time window to constrain the information that appears in the various device
metrics windows.
• Device metrics ― An array of key Firepower device health metrics catagorized across predefined
dashboards, including:
• CPU ― CPU utilization, including the CPU usage by process and by physical cores.
• Memory ― Device memory utilization, including data plane and Snort memory usage.
• Interfaces ― Interface status and aggregate traffic statistics.
• Connections ― Connection statistics and NAT translation counts.
• Snort ― Statistics related to the Snort process.
• Disk Usage ― Device disk usage, including the disk size and disk utilization per partition.
• Critical Processes ― Statistics related to managed processes, including process restarts and other
select health monitors such as CPU and memory utilization.
Viewing System Details and Troubleshooting

The System Details section provides a general system information for a selected device. You can also launch
troubleshooting tasks for that device.
Procedure

Use the Monitoring navigation pane to access device-specific health monitors.
Step 2 In the device list, click Expand ( ) and Collapse ( ) to expand and collapse the list of managed devices.
Step 3 Click on a device to view a device-specific health monitor.
Step 4 Click the link for View System & Troubleshoot Details …
This panel is collapsed by default. Clicking on the link expands the collapsed section to see System Details
and Troubleshooting & Links for the device. The system details include:
• Version: The Firepower software version.
• Model: The device model.
• Mode: The firewall mode. The Firepower Threat Defense device supports two firewall modes for regular
firewall interfaces: Routed mode and Transparent mode.
• VDB: The Cisco vulnerability database (VDB) version.
• SRU: The intrusion rule set version.
• Snort: The Snort version.

449
Viewing the Device Health Monitor
Step 5 You have the following troubleshoot choices:

• Generate troubleshooting files; see Producing Troubleshooting Files for Specific System Functions, on
page 505
• Generate and download advanced troubleshooting files; see Downloading Advanced Troubleshooting
Files, on page 506.
• Create and modify health policies; see Creating Health Policies, on page 437.
• Create and modify health monitor alerts; see Creating Health Monitor Alerts, on page 443.
Viewing the Device Health Monitor

The device health monitor provides a detailed view of the health status of a Firepower device. The device
health monitor compiles device metrics and provides health status and trends of the device in an array of
dashboards.
Procedure

Step 3 View the Health Alerts for the device in the alert notification at the top of page, directly to the right of the
device name.
Hover your pointer over the Health Alerts to view the health summary of the device. The popup window
shows a truncated summary of the top five health alerts. Click on the popup to open a detailed view of the
health alert summary.
Step 4 You can configure the time range from the drop-down in the upper-right corner. The time range can reflect a
period as short as the last hour (the default) or as long as two weeks. Select Custom from the drop-down to
configure a custom start and end date.
Click the refresh icon to set auto refresh to 5 minutes or to toggle off auto refresh.
Step 5 Click on deployment icon for a deployment overlay on the trend graph, with respect to the selected time range.
The deployment icon indicates the number of deployments during the selected time-range. A vertical band
indicates the deployment start and end time. In the case of multiple deployments, multiple bands/lines will
appear. Click on the icon on top of the dotted line to view the deployment details.
Step 6 The device monitor reports health and performance metrics in several predefined dashboards by default. The
metrics dashboards include:
• Overview ― Highlights key metrics from the other predefined dashboards, including CPU, memory,
interfaces, connection statistics; plus disk usage and critical process information.

450
Correlating Device Metrics

You can navigate through the various metrics dashboards by clicking on the labels. See Firepower Device
Metrics, on page 452 for a comprehensive list of the supported device metrics.
Step 7 Click the plus sign (+) in the upper right corner of the device monitor to create a custom correlation dashboard
by building your own variable set from the available metric groups; see Correlating Device Metrics, on page
451.
Correlating Device Metrics

The device health monitor includes an array of key Firepower device metrics that serve to predict and repond
to system events. The health of any Firepower device can be determined by these reported metrics. The device
monitor reports these metrics in several predefined dashboards by default. These dashboards include:
• Overview ― Highlights key metrics from the other predefined dashboards, including CPU, memory,
interfaces, connection statistics; plus disk usage and critical process information.
• ASP Drops ― Statistics related to the Accelerated Security Path (ASP) performance and behavior.
You can add custom dashboards to correlate metrics that are interrelated. Select from predefined correlation
groups, such as CPU and Snort; or create a custom correlation dashboard by building your own variable set
from the available metric groups.
Procedure

Step 3 Click the plus sign (+) in the upper right corner of the device monitor to add a new dashboard.
Step 4 From the Select Correlation Group drop-down, choose a predefined correlation group or or create a custom
group.
Step 5 To create a dashboard from a predefined correlation group, select the group and click Add.
• CPU - Data Plane

451
Firepower Device Metrics
• CPU - Snort
• CPU - Others
• Memory - Data Plane
• Packet drops
Step 6 To create a custom correlation dashboard:

a) Choose Custom.
b) Optionally, enter a unique name in the Dashboard Name field or accept the default.
c) Next, select a group from the Select Metric Group drop-down, then select corresponding metrics from
the Select Metrics drop-down.
• Connections; see Connection Group Metrics, on page 454 for available metrics.
• CPU; see CPU Group Metrics, on page 452 for available metrics.
• Critical Process; see Critical Process Group Metrics, on page 458 for available metrics.
• Deployed Configuration; see Deployed Configuration Group Metrics, on page 458 for available metrics.
• Disk; see Disk Group Metrics, on page 458 for available metrics.
• Interface; see Interface Group Metrics, on page 454 for available metrics.
• Snort; see Snort Group Metrics, on page 455 for available metrics.
• ASP Drops; see ASP Drop Metrics, on page 456 for available metrics.
Step 7 Click Add Metrics to add and select metrics from another group.
Step 8 To remove an individual metric, click the x on the right side of the item. Click the delete icon (a trash can) to
remove the entire group.
Step 9 Click Add to complete the workflow and add the dashboard to the health monitor.
Step 10 You can Edit or Delete custom correlation dashboards.
Firepower Device Metrics

The following sections describe the health metrics of available from Firepower Threat Defense devices.
CPU Group Metrics

The health monitor tracks statistics related to the CPU utilization, including the CPU usage by process and
by physical cores.
Table 40: CPU Group Metrics
Metric Description Format
Control Plane The average CPU utilization for the control plane, for percent
the last one minute.
Data Plane The average CPU utilization for the data plane, for percent
Snort The average CPU utilization for the Snort process, percent
for the last one minute.
System The average CPU utilization for the system processes, percent

452
Memory Group Metrics
Physical cores The average CPU utilization for all the cores, for the percent
last one minute.
Memory Group Metrics

The health monitor tracks statistics related to the device memory utilization, including data plane and Snort
memory usage.
Table 41: Memory Group Metrics
Buffer cache The buffer cache. bytes
Free The total free memory. bytes
Maximum Data Plane The maximum memory used by the data plane. bytes
Maximum Snort The maximum memory used by the Snort process. bytes
Maximum Swap for Snort The maximum swap memory used by the Snort bytes
process.
Remaining Memory Block (1550) The free memory in a 1550 byte block. number
Remaining Memory Block (256) The free memory in a 256 byte block. number
System Used The total memory used by the system. bytes
Total The total memory available. bytes
Total Swap The total memory available for swap. bytes
Data Plane The total memory used by the data plane. bytes
Percent Used by Data Plane The percent of memory used by the data plane. percent
Percent Used by Snort The percent of memory used by the Snort process. percent
Percent Used for Swap The percent of memory used for swap. percent
Percent Used by System The percent of memory used by the system. percent
Percent Used by System and Swap The percent of memory used by the system and swap percent
combined.
Snort The total memory used by the Snort process. bytes
Used Swap The total memory used for swap. bytes
Used Swap by Snort The total swap memory used by the Snort process. bytes

453
Interface Group Metrics
Interface Group Metrics

The health monitor tracks statistics related to the device interfaces, including the interface status and aggregate
traffic statistics.
Table 42: Interface Group Metrics
Drop Packets The number of packets dropped. number
Average Input Packet Size The average size of incoming packets. bytes
Input Rate The total incoming bytes. bytes
Input Packets The total incoming packets. number
Average Output Packet Size The average size of outgoing packets. bytes
Output Rate The total outgoing bytes. bytes
Output Packets The total outgoing packets. number
Status The status of an interface; 1 for up and 0 for down. 1 or 0
Connection Group Metrics

The health monitor tracks statistics related to the connections and NAT translation counts.
Table 43: Connection Group Metrics
Connections in use Shows the number of connections in use. number
Peak Connections Shows the maximum number of simultaneous number

connections.
Total Connections per second The connections-per-second for all connection types. number
TCP Connections per second The connections-per-second for TCP connection number
types.
UDP Connections per second The connections-per-second for UDP connection number
types.
Preserve Connections Enabled Preserves existing TCP/UDP connections on routed number

and transparent interfaces in case the Snort process
goes down.
Connections Preserved Connections for which preserve-connection is number

currently enabled.
Preserve Connections Most The most number of connections ever preserved. number
Enabled

454
Snort Group Metrics
Peak Connections Preserved The most number of peak connections ever preserved. number
NAT Translations Displays the translation count. number
Peak NAT Translations Displays the historic maximum of concurrent number

translations at a time.
Snort Group Metrics

The health monitor tracks statistics related to the Snort process.
Table 44: Snort Group Metrics
Blocked list flows The number of flows from policy configuration that number
were dropped by Snort.
Blocked packets The number of blocked packets. number
Denied flows The number of denied flow events. The data plane number
sends denied flow events to Snort when it decides to
drop a flow before sending it to Snort.
End of flows The data plane sends end-of-flow events to Snort number
when a fast path flow ends.
Fast forwarded flows The number of flows that were fast forwarded by number
policy, and thus not inspected.
Dropped frames forwarded from The number of dropped frames forwarded from the number
the data plane data plane.
Injected packets dropped The number of packets that Snort added to the traffic number
stream that were dropped.
Injected packets The number of packets Snort created and added to the number
traffic stream. For example, if you configure a block
with reset action, Snort generates packets to reset the
connection.
Instances The number of snort instances (processes). number
Packet receiving queue utilization The queue utilization rate for the data plane receive percent
percentage queue.
Packets bypassed due to Snort busy The number of packets that bypassed inspection when number
Snort was too busy to handle the packets.
Packets bypassed due to Snort The number of packets that bypassed inspection when number
down Snort was down.

455
ASP Drop Metrics
Packets bypassed due to RX queue The number of packets bypassed due to a receive number
full queue full.
Packets bypassed due to TX queue The number of packets bypassed due to a transmit number
full queue full.
Passed packets The number of packets sent to Snort from the data number
plane.
Start of flows The number of start-of-flow events. These events help number
Snort keep track of the connections and report the
connection events.
ASP Drop Metrics

The health monitor tracks statistics related to the the accelerated security path (ASP) dropped packets or
connections.
Table 45: ASP Drop Metrics
Connection limit exceeded Counts the number of flows closed when the number
connection limit has been exceeded.
Connection limit reached Counts the number of dropped packets when the number
connection limit or host connection limit has been
exceeded.
L2 rule drop Counts the number of denied packets due to a Layer number
2 ACL.
L2 rule VXLAN drop Counts the number of denied packets due to a failure number
to locate a VXLAN out_tag when applying Layer 2
ACL checks.
NAT reverse path failed Counts the number of rejected attempts to connect to number
a translated host using the translated host's real
address.
NAT failed Counts the number of failed attempts to create an xlate number
to translate an IP or transport header.
No valid v4 adjacency Counts the number of dropped packets when the number
security appliance has tried to obtain an adjacency
and could not obtain mac-address for next hop (IPv4).
No valid v6 adjacency Counts the number of dropped packets when the number
security appliance has tried to obtain an adjacency
and could not obtain mac-address for next hop (IPv6).

456
ASP Drop Metrics
Packet blocklisted by Snort; Packet Counts the number of packets dropped as requested number
blocked by Snort by the Snort module.
Frame drops – Snort busy; Frame Counts the number of frames dropped as the Snort number
drops – Snort down; Frame drops module is busy and unable to handle the frame; the
– Snort drop Snort module is down; the Snort module requests the
drop.
Dispatch queue limit reached Counts the number of times a device's load balance number
ASP dispatcher reaches its queue limit. When more
packets are attempted, tail drop occurs and this counter
is incremented.
Destination MAC L2 lookup failed Counts the number of Layer 2 destination MAC number
address lookups which fail. Upon the lookup failure,
the appliance will begin the destination MAC
discovery process and attempt to find the location of
the host via ARP and/or ICMP messages.
Inspection failure Counts the number of times the appliance fails to number
enable protocol inspection carried out by the network
processor for the connection. The cause could be
memory allocation failure, or for ICMP error message,
the appliance not being able to find any established
connection related to the frame embedded in the ICMP
error message.
NAT no xlate to pat pool Counts no pre-existing xlate found for a connection number
with a destination matching a mapped address in a
PAT pool.
No routes to host Counts the number of times the security appliance number
tries to send a packet out of an interface and does not
find a route for it in routing table.
Packet dropped as number of Counts the number of packets dropped when the number
packet queued appliance receives a retransmitted data packet that is
already in the out of order packet queue.
Number of segments queued to an For a flow, the number of packets queued to the number
inspection reached limit inspector has reached the limit, thus terminating the
flow.
Blocked or blocklisted by Snort Counts the number of times a packet is dropped as number
requested by the Snort module.
Packet drop silently by Snort Counts the number of times a packet is dropped number
silently as requested by the Snort module.
Un-synced first TCP packet Counts the number of times a non SYN packet is number
received as the first packet of a non intercepted and
non nailed connection.

457
Deployed Configuration Group Metrics
Deployed Configuration Group Metrics

The health monitor tracks statistics related to the deployed configuration, such as the number of IPS rules and
the number of ACEs.
Table 46: Deployed Configuration Group Metrics
Number of ACEs The number of access control entries (ACE), or rules. number
An access control list (ACL) is composed of one or
more ACEs.
Number of rules The number of rules in an intrusion policy. number
Disk Group Metrics

The health monitor tracks statistics related to the device disk usage, including the disk size and disk utilization
per partition.
Table 47: Disk Group Metrics
Total The total size of the device disk. bytes
Used The total space used on the device disk. bytes
% Used by /ngfw The percent of disk space used by the /ngfw partition. percent
% Used by /ngfw/Volume The percent of disk space used by the /ngfw/Volume percent
partition.
% Used by /dev/cgroups The percent of disk space used by the /dev/cgroups percent
partition.
% Used by /mnt/disk0 The percent of disk space used by the /mnt/disk0 percent
partition.
% Used by /var/volatile The percent of disk space used by the /var/volatile percent
partition.
Critical Process Group Metrics

The health monitor tracks statistics related to process restarts for managed processes. In addition, for each
critical process the health monitor tracks CPU utilization, memory utilization, uptime, and status.
Table 48: Critical Process Group Metrics
CPU utilization The average CPU utilization for the control plane and percent
data plane combined, for the last one minute.

458
Health Monitor Status Categories
Restart count The average CPU utilization for the control plane, for percent
Status The average CPU utilization for the data plane, for percent
Uptime The average CPU utilization for the Snort process, percent
Memory used The average CPU utilization for the system processes, percent
Health Monitor Status Categories

Available status categories are listed by severity in the table below.
Table 49: Health Status Indicator
Status Level Status Icon Status Color in Pie Chart Description
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.
Warning Yellow Indicates that warning limits have been exceeded

Warning ( )
for at least one health module on the appliance and
the problem has not been corrected.
Normal Green Indicates that all health modules on the appliance

Normal ( )
are running within the limits configured in the health
policy applied to the appliance.
Recovered Green Indicates that all health modules on the appliance

Recovered ( )
are running within the limits configured in the health
policy applied to the appliance, including modules
that were in a Critical or Warning state.
Disabled Blue Indicates that an appliance is disabled or blacklisted,

Disabled ( )
that the appliance does not have a health policy
applied to it, or that the appliance is currently
unreachable.

459
Health Event Views
Health Event Views

The Health Event View page allows you to view health events logged by the health monitor on the Firepower
Management Center logs health events. The fully customizable event views allow you to quickly and easily
analyze the health status events gathered by the health monitor. You can search event data to easily access
other information that may be related to the events you are investigating. If you understand what conditions
each health module tests for, you can more effectively configure alerting for health events.
You can perform many of the standard event view functions on the health event view pages.
Viewing Health Events

The Table View of Health Events page provides a list of all health events on the specified appliance.
When you access health events from the Health Monitor page on your Firepower Management Center, you
retrieve all health events for all managed appliances.
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.
Procedure
Choose System > Health > Events.

Tip If you are using a custom workflow that does not include the table view of health events, click
(switch workflow). On the Select Workflow page, click Health Events.
Note If no events appear, you may need to adjust the time range.
Viewing Health Events by Module and Appliance

Procedure
Step 1 View the health monitor for the appliance; see Viewing the Device Health Monitor, on page 450.
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.

460
Viewing the Health Events Table
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.
Viewing the Health Events Table

Procedure
Step 1 Choose System > Health > Events.

Step 2 You have the following choices:
• Bookmark — To bookmark the current page so that you can quickly return to it, click Bookmark This
Page, provide a name for the bookmark, and click Save.
• Change Workflow — To choose another health events workflow, click (switch workflow).
• Delete Events — To delete health events, check the check box next to the events you want to delete, and
click Delete. To delete all the events in the current constrained view, click Delete All, then confirm you
want to delete all the events.
• Generate Reports — Generate a report based on data in the table view — click Report Designer.
• Modify — Modify the time and date range for events listed in the Health table view. Note that 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.
• Navigate — Navigate through event view pages.
• Navigate Bookmark — To navigate to the bookmark management page, click View Bookmarks from
any event view.
• Navigate Other — Navigate to other event tables to view associated events.
• Sort — Sort the events that appear, change what columns display in the table of events, or constrain the
events that appear
• View All — To view event details for all events in the view, click View All.
• View Details — To view the details associated with a single health event, click the down arrow link on
the left side of the event.
• View Multiple — To view event details for multiple health events, choose the check box next to the rows
that correspond with the events you want to view details for and then click View.
• View Status — To view all events of a particular status, click status in the Status column for an event
with that status.

461
The Health Events Table

The Health Monitor modules you choose to enable in your health policy run various tests to determine appliance
health status. When the health status meets criteria that you specify, a health event is generated.
The table below describes the fields that can be viewed and searched in the health events table.
Table 50: Health Event Fields
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)
Time The timestamp for the health event.

(Search only)
Description The description of the health module that generated

the event. For example, health events generated when
a process was unable to execute are labeled Unable
to Execute.
Value The value (number of units) of the result obtained by

the health test that generated the event.
For example, if the Firepower Management Center
generates a health event whenever a device it is
monitoring is using 80 percent or more of its CPU
resources, the value could be a number from 80 to
100.
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 (%).
Status The status (Critical, Yellow, Green, or Disabled)

reported for the appliance.
Domain For health events reported by managed devices, the

domain of the device that reported the health event.
For health events reported by the Firepower
Management Center, Global. This field is only present
in a multidomain deployment.

462
Field Description
Device The appliance where the health event was reported.

463
History for Health Monitoring

New health modules 7.0.0 We added the following health modules:

• AMP Connection Status: Monitors AMP cloud connectivity from the FTD.
• AMP Threat Grid Status: Monitors AMP Threat Grid cloud connectivity from the FTD.
• ASP Drop: Monitors the connections dropped by the data plane accelerated security path.
• Advanced Snort Statistics: Monitors Snort statistics related to packet performance, flow
counters, and flow events.
• Chassis Status FTD: Monitors chassis environmental metrics on the Firepower 2100 and
1000 platforms.
• Event Stream Status: Monitors connections to third-party client applications that use the
Event Streamer.
• FMC Access Configuration Changes: Monitors access configuration changes made
directly on the FMC.
• FMC HA Status: Monitors the active and standby FMC and the sync status between the
devices. Replaces the HA Status module.
• FTD HA Status: Monitors the active and standby FTD HA pair and the sync status between
the devices.
• File System Integrity Check: Performs a file system integrity check if the system has CC
mode or UCAPL mode enabled.
• Flow Offload: Monitors hardware flow offload statistics on the Firepower 9300 and 4100
platforms.
• Hit Count: Monitors the number of times a particular rule is hit on the access control
policy.
• MySQL Status: Monitors the status of the MySQL database.
• NTP Status FTD: Monitors the NTP clock synchronisation status of the managed device.
• RabbitMQ Status: Monitors the status of the RabbitMQ messaging broker.
• Routing Statistics: Monitors both IPv4 and IPv6 route information from the FTD.
• SSE Connection Status: Monitors SSE cloud connectivity from the FTD.
• Sybase Status: Monitors the status of the Sybase database.
• Unresolved Groups Monitor: Monitors the unresolved groups used in access control
policies.
• VPN Statistics: Monitors site-to-site and remote access VPN tunnel statistics.
• xTLS Counters: Monitors xTLS/SSL flows, memory and cache effectiveness.

464
Health monitor 7.0.0 The health monitor adds the following enhancements:
enhancements
• Enhanced FMC dashboard with summary views of:
• High Availability
• Event Rate & Capacity
• Process Health
• CPU thresholds
• Memory
• Interface rates
• Disk Usage
• Enhanced FTD dashboard:

• Health alert for split brain scenario
• Additional health metrics available from new Health Modules
New health modules 6.7.0 The CPU Usage module is no longer used. Instead, see the following modules for CPU usage:
• CPU Usage (per core): Monitors the CPU usage on all of the cores.
• CPU Usage Data Plane: Monitors the average CPU usage of all data plane processes on
the device.
• CPU Usage Snort: Monitors the average CPU usage of the Snort processes on the device.
• CPU Usage System: Monitors the average CPU usage of all system processes on the
device.
The following modules were added to track statistics:

• Connection Statistics: Monitors the connection statistics and NAT translation counts.
• Critical Process Statistics: Monitors the state of critical processes, their resource
consumption, and the restart counts.
• Deployed Configuration Statistics: Monitors statistics about the deployed configuration,
such as the number of ACEs and IPS rules.
• Snort Statistics: Monitors the Snort statistics for events, flows, and packets.
The following modules were added to track memory usage:

• Memory Usage Data Plane: Monitors the percentage of allocated memory used by the
Data Plane processes.
• Memory Usage Snort: Monitors the percentage of allocated memory used by the Snort
process.

465
Health monitor 6.7.0 The health monitor adds the following enhancements:
enhancements
• Health Status summary page that provides an at-a-glance view of the health of the
Firepower Management Center and all of the devices that the FMC manages.
• The Monitoring navigation pane allows you to navigate the device hierarchy.
• Managed devices are listed individually, or grouped according to their geolocation, high
availability, or cluster status where applicable.
• You can view health monitors for individual devices from the navigation pane.
• Custom dashboards to correlate interrelated metrics. Select from predefined correlation
groups, such as CPU and Snort; or create a custom correlation dashboard by building
your own variable set from the available metric groups.
Functionality moved to the 6.7.0 The Local Malware Analysis module is no longer used. Instead, see the Threat Data Updates
Threat Data Updates on on Devices module for this information.
Devices module
Some information formerly provided by the Security Intelligence module and the URL Filtering
Module is now provided by the Threat Data Updates on Devices module.
New health module: 7.0.0 Version 6.6.3 improves device memory management and introduces a new health module:
Configuration Memory Configuration Memory Allocation.
6.6.3
Allocation
This module alerts when the size of your deployed configurations puts a device at risk of
running out of memory. The alert shows you how much memory your configurations require,
and by how much this exceeds the available memory. If this happens, re-evaluate your
configurations. Most often you can reduce the number or complexity of access control rules
or intrusion policies.
URL Filtering Monitor 6.5.0 The URL Filtering Monitor module now alerts if the FMC fails to register to the Cisco cloud.
improvements
URL Filtering Monitor 6.4.0 You can now configure time thresholds for URL Filtering Monitor alerts.
improvements
New health module: Threat 6.3.0 A new module, Threat Data Updates on Devices, was added.
Data Updates on Devices
This module alerts you if certain intelligence data and configurations that devices use to detect
threats has not been updated on the devices within the time period you specify.

466
CHAPTER 16
Monitoring the System
The following topics describe how to monitor the Firepower System:
• About System Statistics, on page 467
• The Host Statistics Section, on page 467
• The Disk Usage Section, on page 468
• The Processes Section, on page 468
• The SFDataCorrelator Process Statistics Section, on page 474
• The Intrusion Event Information Section, on page 475
• Viewing System Statistics, on page 476
About System Statistics

The Statistics page lists the current status of general appliance statistics, including disk usage and system
processes, Data Correlator statistics, and intrusion event information.
The Host Statistics Section

The following table describes the host statistics listed on the Statistics page.
Table 51: Host Statistics
Category Description
Time The current time on the system.
Uptime The number of days (if applicable), hours, and minutes

since the system was last started.
Memory Usage The percentage of system memory that is being used.
Load Average The average number of processes in the CPU queue

for the past 1 minute, 5 minutes, and 15 minutes.
Disk Usage The percentage of the disk that is being used. Click
the arrow to view more detailed host statistics.

467
The Disk Usage Section
Processes A summary of the processes running on the system.
The Disk Usage Section

The Disk Usage section of the Statistics page provides a quick synopsis of disk usage, both by category and
by partition status. If you have a malware storage pack installed on a device, you can also check its partition
status. You can monitor this page from time to time to ensure that enough disk space is available for system
processes and the database.
Tip You can also use the Disk Usage health monitor to monitor disk usage and alert on low disk space conditions.
The Processes Section

The Processes section of the Statistics page allows you to see the processes that are currently running on an
appliance. It provides general process information and specific information for each running process. You
can use the Firepower Management Center’s web interface to view the process status for any managed device.
Note that there are two different types of processes that run on an appliance: daemons and executable files.
Daemons always run, and executable files are run when required.
Process Status Fields

When you expand the Processes section of the Statistics page, you can also view the following:
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

468
Process Status Fields
• total number of free kilobytes in memory

• total number of buffered 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.
Table 52: Process List Columns
Column Description
Pid The process ID number
Username The name of the user or group running the process
Pri The process priority
Nice The nice value, which is a value that indicates the

scheduling priority of a process. Values range between
-20 (highest priority) and 19 (lowest priority)
Size The memory size used by the process (in kilobytes

unless the value is followed by m, which indicates
megabytes)
Res The amount of resident paging files in memory (in

kilobytes unless the value is followed by m, which
indicates megabytes)

469
System Daemons
Column Description
State The process state:

• D — process is in uninterruptible sleep (usually
Input/Output)
• N — process has a positive nice value
• R — process is runnable (on queue to run)
• S — process is in sleep mode
• T — process is being traced or stopped
• W — process is paging
• X — process is dead
• Z — process is defunct
• < — process has a negative nice value
Time The amount of time (in hours:minutes:seconds) that

the process has been running
Cpu The percentage of CPU that the process is using
Command The executable name of the process
Related Topics
System Daemons, on page 470
Executables and System Utilities, on page 472
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.
Table 53: System Daemons
Daemon Description
crond Manages the execution of scheduled commands (cron

jobs)
dhclient Manages dynamic host IP addressing

470
System Daemons
Daemon Description
fpcollect Manages the collection of client and server

fingerprints
httpd Manages the HTTP (Apache web server) process
httpsd Manages the HTTPS (Apache web server with SSL)

service, and checks for working SSL and valid
certificate authentication; runs in the background to
provide secure web access to the appliance
keventd Manages Linux kernel event notification messages
klogd Manages the interception and logging of Linux kernel

messages
kswapd Manages Linux kernel swap memory
kupdated Manages the Linux kernel update process, which

performs disk synchronization
mysqld Manages database processes
ntpd Manages the Network Time Protocol (NTP) process
pm Manages all Firepower System processes, starts

required processes, restarts any process that fails
unexpectedly
reportd Manages reports
safe_mysqld Manages safe mode operation of the database; restarts

the database daemon if an error occurs and logs
runtime information to a file
SFDataCorrelator Manages data transmission
sfestreamer (FMC only) Manages connections to third-party client applications

that use the Event Streamer
sfmgr Provides the RPC service for remotely managing and

configuring an appliance using an sftunnel connection
to the appliance
SFRemediateD (FMC only) Manages remediation responses
sftimeserviced (FMC only) Forwards time synchronization messages to managed

devices

471
Executables and System Utilities
Daemon Description
sfmbservice Provides access to the sfmb message broker process

running on a remote appliance, using an sftunnel
connection to the appliance. Currently used only by
health monitoring to send health events and alerts
from a managed device to a Firepower Management
Center.
sftroughd Listens for connections on incoming sockets and then

invokes the correct executable (typically the Cisco
message broker, sfmb) to handle the request
sftunnel Provides the secure communication channel for all

processes requiring communication with a remote
appliance
sshd Manages the Secure Shell (SSH) process; runs in the

background to provide SSH access to the appliance
syslogd Manages the system logging (syslog) process

There are a number of executables on the system that run when executed by other processes or through user
action. The following table describes the executables that you may see on the Process Status page.
Table 54: System Executables and Utilities
Executable Description
awk Utility that executes programs written in the awk

programming language
bash GNU Bourne-Again Shell
cat Utility that reads files and writes content to standard

output
chown Utility that changes user and group file permissions
chsh Utility that changes the default login shell
SFDataCorrelator (FMC only) Analyzes binary files created by the system to generate
events, connection data, and network maps
cp Utility that copies files
df Utility that lists the amount of free space on the

appliance
echo Utility that writes content to standard output

472
egrep Utility that searches files and folders for specified

input; supports extended set of regular expressions
not supported in standard grep
find Utility that recursively searches directories for

specified input
grep Utility that searches files and directories for specified

input
halt Utility that stops the server
httpsdctl Handles secure Apache Web processes
hwclock Utility that allows access to the hardware clock
ifconfig Indicates the network configuration executable.

Ensures that the MAC address stays constant
iptables Handles access restriction based on changes made to

the Access Configuration page.
iptables-restore Handles iptables file restoration
iptables-save Handles saved changes to the iptables
kill Utility that can be used to end a session and process
killall Utility that can be used to end all sessions and

processes
ksh Public domain version of the Korn shell
logger Utility that provides a way to access the syslog

daemon from the command line
md5sum Utility that prints checksums and block counts for

specified files
mv Utility that moves (renames) files
myisamchk Indicates database table checking and repairing
mysql Indicates a database process; multiple instances may

appear
openssl Indicates authentication certificate creation
perl Indicates a perl process
ps Utility that writes process information to standard

output
sed Utility used to edit one or more text files

473
The SFDataCorrelator Process Statistics Section
sfheartbeat Identifies a heartbeat broadcast, indicating that the

appliance is active; heartbeat used to maintain contact
between a device and Firepower Management Center
sfmb Indicates a message broker process; handles

communication between Firepower Management
Centers and device.
sh Public domain version of the Korn shell
shutdown Utility that shuts down the appliance
sleep Utility that suspends a process for a specified number

of seconds
smtpclient Mail client that handles email transmission when

email event notification functionality is enabled
snmptrap Forwards SNMP trap data to the SNMP trap server

specified when SNMP notification functionality is
enabled
snort Indicates that Snort is running
ssh Indicates a Secure Shell (SSH) connection to the

appliance
sudo Indicates a sudo process, which allows users other

than admin to run executables
top Utility that displays information about the top CPU

processes
touch Utility that can be used to change the access and

modification times of specified files
vim Utility used to edit text files
wc Utility that performs line, word, and byte counts on

specified files
Related Topics
Configure an Access List, on page 1376
The SFDataCorrelator Process Statistics Section

On a Firepower Management Center, you can view statistics about the Data Correlator and network discovery
processes for the current day. As the managed devices perform data acquisition, decoding, and analysis, the
network discovery process correlates the data with the fingerprint and vulnerability databases, then produces

474
The Intrusion Event Information Section
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.
Table 55: Data Correlator Process Statistics
Events/Sec Number of discovery events that the Data Correlator

receives and processes per second
Connections/Sec Number of connections that the Data Correlator

receives and processes per second
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
VmSize (KB) Average size of memory allocated to the Data

Correlator for the current day, in kilobytes
VmRSS (KB) Average amount of memory used by the Data

Correlator for the current day, in kilobytes
The Intrusion Event Information Section

On both the Firepower Management Center and managed devices, you can view summary information about
intrusion events on the Statistics page. This information includes the date and time of the last intrusion event,
the total number of events that have occurred in the past hour and the past day, and the total number of events
in the database.
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.
Table 56: Intrusion Event Information
Statistic Description
Last Alert Was The date and time that the last event occurred

475
Viewing System Statistics
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
Viewing System Statistics

The display includes statistics for the Firepower Management Center and its managed devices.
Before you begin

You must be an Admin or Maintenance user and be in the Global domain to view system statistics.
Procedure
Step 1 Choose System > Monitoring > Statistics.

Step 2 Choose a device from the Select Device(s) list, and click Select Devices.
Step 3 View available statistics.
Step 4 In the Disk Usage section, you can:
• Hover your pointer over a disk usage category in the By Category stacked bar to view (in order):
• the percentage of available disk space used by that category
• the actual storage space on the disk
• the total disk space available for that category
• 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 468.

476
CHAPTER 17
Auditing the System
The following topics describe how to audit activity on your system:
• The System Log, on page 477
• About System Auditing, on page 479
The System Log

The System Log (syslog) page provides you with system log information for the appliance.
You can audit activity on your system in two ways. The appliances that are part of the Firepower System
generate an audit record for each user interaction with the web interface, and also record system status messages
in the system log.
The system log displays each message generated by the system. The following items are listed in order:
• the date that the message was generated
• the time that the message was generated
• the host that generated the message
• the message itself
Viewing the System Log

System log information is local. For example, you cannot use the Firepower Management Center to view
system status messages in the system logs on your managed devices.
You can filter messages using most syntax accepted by the UNIX file search utility Grep. This includes using
Grep-compatible regular expressions for pattern matching.
Before you begin

You must be an Admin or Maintenace user and be in the Global domain to view system statistics.
Procedure
Step 1 Choose System > Monitoring > Syslog.

477
Syntax for System Log Filters
Step 2 To search for specific message content in the system log:

a) Enter a word or query in the filter field as described in Syntax for System Log Filters, on page 478.
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.
Syntax for System Log Filters

The following table shows the regular expression syntax you can use in System Log filters:
Table 57: System Log Filter Syntax
Syntax Component Description Example
. Matches any character or white Admi. matches Admin, AdmiN,

space Admi1, and Admi&
[[:alpha:]] Matches any alphabetic character [[:alpha:]]dmin matches Admin,

bdmin, and Cdmin
[[:upper:]] Matches any uppercase alphabetic [[:upper:]]dmin matches Admin,

character Bdmin, and Cdmin
[[:lower:]] Matches any lowercase alphabetic [[:lower:]]dmin matches admin,

character bdmin, and cdmin
[[:digit:]] Matches any numeric character [[:digit:]]dmin matches 0dmin,

1dmin, and 2dmin
[[:alnum:]] Matches any alphanumeric [[:alnum:]]dmin matches 1dmin,

character admin, 2dmin, and bdmin
[[:space:]] Matches any white space, including Feb[[:space:]]29 matches logs

tabs from February 29th
* Matches zero or more instances of ab* matches a, ab, abb, ca, cab, and
the character or expression it cabb
follows
[ab]* matches anything
? Matches zero or one instances ab? matches a or ab

478
About System Auditing
Syntax Component Description Example
\ Allows you to search for a alert\? matches alert?

character typically interpreted as
regular expression syntax
About System Auditing

The appliances that are part of the Firepower System generate an audit record for each user interaction with
the web interface.
Related Topics
Standard Reports, on page 2605
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.
Related Topics
SSO Guidelines for the FMC, on page 78
Viewing Audit Records

On a Firepower Management Center, you can view a table of audit records. The predefined audit workflow
includes a single table view of events. You can manipulate the table view depending on the information you
are looking for. You can also create a custom workflow that displays only the information that matches your
specific needs.
Before you begin

Procedure
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 2754.
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.

479
Audit Log Workflow Fields

• To learn more about the contents of the columns in the table, see The System Log, on page 477.
• To sort and constrain events on the current workflow page, see Using Table View Pages, on page 2744.
• 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 2736.
• To drill down to the next page in the workflow, see Using Drill-Down Pages, on page 2744.
• 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 2760 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 2767.
• To navigate to the bookmark management page, click View Bookmarks. For more information, see
Bookmarks, on page 2767.
• 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 2609.
• 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 482.
Related Topics
Event View Constraints, on page 2760
Audit Log Workflow Fields

The following table describes the audit log fields that can be viewed and searched.
Table 58: Audit Log Fields
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.

480
The Audit Events Table View
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.
Source IP IP address associated with the host used by the user.

Note: When searching this field you must type a
specific IP address; you cannot use IP ranges when
searching audit logs.
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.
Configuration Change Specifies whether to view audit records of

configuration changes in the search results. (yes or
(search only)
no)
Count The number of events that match the information that

appears in each row. Note that the Count field appears
only after you apply a constraint that creates two or
more identical rows. This field is not searchable.
Related Topics
Event Searches, on page 2771
The Audit Events Table View

You can change the layout of the event view or constrain the events in the view by a field value. When disabling
columns, after you click the Close ( ) in the column heading that you want to hide, in the pop-up window
that appears, click Apply. When you disable a column, it is disabled for the duration of your session (unless
you add it back later). Note that when you disable the first column, the Count column is added.
To hide or show other columns, or to add a disabled column back to the view, select or clear the appropriate
check boxes before you click Apply.
Clicking a value within a row in a table view constrains the table view and does not drill down to the next
page in the workflow.
Tip Table views always include “Table View” in the page name.

481
Using the Audit Log to Examine Changes
Related Topics
Using Workflows, on page 2736
Using the Audit Log to Examine Changes

You can use the audit log to view detailed reports of some of the changes to your system. These reports
compare the current configuration of your system to its most recent configuration before a supported change
was made.
The Compare Configurations page displays the differences between the system configuration before changes
and the running configuration in a side-by-side format. The audit event type, time of last modification, and
name of the user who made the change are displayed in the title bar above each configuration.
Differences between the two configurations are highlighted:
• Blue indicates that the highlighted setting is different in the two configurations, and the difference is
noted in red text.
• Green indicates that the highlighted setting appears in one configuration but not the other.
Before you begin

Procedure
Step 1 Choose System > Monitoring > Audit.

Step 2 Click Compare next to an applicable audit log event in the Message column.
Tip You can navigate through changes individually by clicking Previous or Next above the title bar. If
the change summary is more than one page long, you can also use the scroll bar on the right to view
additional changes.
Suppressing Audit Records

If your auditing policy does not require that you audit specific types of user interactions with the Firepower
System, you can prevent those interactions from generating audit records. For example, by default, each time
a user views the online help, the Firepower System generates an audit record. If you do not need to keep a
record of these interactions, you can automatically suppress them.
To configure audit event suppression, you must have access to an appliance’s admin user account, and you
must be able to either access the appliance’s console or open a secure shell.
Caution Make sure that only authorized personnel have access to the appliance and to its admin account.

482
Audit Block Types
Before you begin

Procedure
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 483:
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.
Audit Block Types

The contents for each audit block type must be in a specific format, as described in the following table. Make
sure you use the correct capitalization for the file names. Note also that the contents of the files are case
sensitive.
Note that when you add an AuditBlock file, an audit record with a subsystem of Audit and a message of
Audit Filter type Changed is added to the audit events. For security reasons, this audit record cannot be
suppressed.
Table 59: Audit Block Types
Type Description
Address Create a file named AuditBlock.address and include,

one per line, each IP address that you want to suppress
from the audit log. You can use partial IP addresses
provided that they map from the beginning of the
address. For example, the partial address 10.1.1
matches addresses from 10.1.1.0 through
10.1.1.255.
Message Create a file named AuditBlock.message and include,

one per line, the message substrings that you want to
suppress.
Note that substrings are matched so that if you include
backup in your file, all messages that include the word
backup are suppressed.
Subsystem Create a file named AuditBlock.subsystem and

include, one per line, each subsystem that you want
to suppress.
Note that substrings are not matched. You must use
exact strings. See Audited Subsystems, on page 484
for a list of subsystems that are audited.

483
Audited Subsystems
Type Description
User Create a file named AuditBlock.user and include,

one per line, each user account that you want to
suppress. You can use partial string matching provided
that they map from the beginning of the username.
For example, the partial username IPSAnalyst
matches the user names IPSAnalyst1 and
IPSAnalyst2.
Audited Subsystems
The following table lists audited subsystems.
Table 60: Subsystem Names
Name Includes user interactions with...
Admin Administrative features such as system and access

configuration, time synchronization, backup and
restore, device management, user account
management, and scheduling
Alerting Alerting functions such as email, SNMP, and syslog

alerting
Audit Log Audit event views
Audit Log Search Audit event searches
Command Line Command line interface
Configuration Email alerting
contextual cross-launch External resources added to the system or accessed

from dashboards and event views
COOP Continuity of operations feature
Date Date and time range for event views
Default Subsystem Options that do not have assigned subsystems
Detection & Prevention Policy Menu options for intrusion policies
Error System-level errors
eStreamer eStreamer configuration
EULA Reviewing the end user license agreement
Events Intrusion and discovery event views
Events Clipboard Intrusion event clipboard

484
Audited Subsystems
Events Reviewed Reviewed intrusion events
Events Search Any event search
Failed to install rule update rule_update_id Installing rule updates
Header Initial presentation of the user interface after a user

logs in
Health Health monitoring
Health Events Health monitoring event views
Help Online help
High Availability Establishing and managing Firepower Management

Centers in high availability pairs
IDS Impact Flag Impact flag configuration for intrusion events
IDS Policy Intrusion policies
IDSRule sid:sig_id rev:rev_num Intrusion rules by SID
Incidents Intrusion incidents
Install Installing updates
Intrusion Events Intrusion events
Login Web interface login and logout functions
Logout Web interface logout functions
Menu Any menu option
Configuration export > config_type > config_name Importing configurations of a specific type and name
Permission Escalation User role escalation
Preferences User preferences, such as the time zone for a user

account and individual event preferences
Policy Any policy, including intrusion policies
Register Registering devices on a FMC
RemoteStorageDevice Configuring remote storage devices
Reports Report listing and report designer features
Rules Intrusion rules, including the intrusion rules editor

and the rule importation process

485
About Sending Audit Logs to an External Location
Rule Update Import Log Viewing the rule update import log
Rule Update Install Installing rule updates
Session Expiration Web interface session timeouts
Status Syslog, as well as host and performance statistics
System Various system-wide settings
Task Queue Viewing background process status
Users Creating and modifying user accounts and roles
About Sending Audit Logs to an External Location

To send audit logs to an external location from the FMC, see:
• Audit Logs, on page 1377
• Audit Log Certificate, on page 1379
For Classic devices, see:

• Stream Audit Logs from Classic Devices, on page 1417
• Require Valid Audit Log Server Certificates for Classic Devices, on page 1419

486
CHAPTER 18
SNMP
This chapter describes common SNMP counters and traps that are commonly used to monitor the Cisco
Firepower Threat Defense.
• About SNMP, on page 487
• SNMP Terminology, on page 487
• MIBs and Traps, on page 488
• Supported Tables and Objects in MIBs, on page 489
About SNMP
SNMP is an application-layer protocol that facilitates the exchange of management information between
network devices and is part of the TCP/IP protocol suite. The Firepower Threat Defense provides support for
network monitoring using SNMP Versions 1, 2c, and 3, and support the use of all three versions simultaneously.
The SNMP agent running on the Firepower Threat Defense interface lets you monitor the network devices
through network management systems (NMSes), such as HP OpenView. The Firepower Threat Defense
supports SNMP read-only access through issuance of a GET request. SNMP write access is not allowed, so
you cannot make changes with SNMP. In addition, the SNMP SET request is not supported.
You can configure the Firepower Threat Defense to send traps, which are unsolicited messages from the
managed device to the management station for certain events (event notifications) to an NMS, or you can use
the NMS to browse the Management Information Bases (MIBs) on the security devices. MIBs are a collection
of definitions, and the Firepower Threat Defense maintain a database of values for each definition. Browsing
a MIB means issuing a series of GET-NEXT or GET-BULK requests of the MIB tree from the NMS to
determine values.
An SNMP agent notifies the designated management stations if events occur that are predefined to require a
notification, for example, when a link in the network goes up or down. The notification it sends includes an
SNMP OID, which identifies itself to the management stations. The agent also replies when a management
station asks for information.
SNMP Terminology
The following table lists the terms that are commonly used when working with SNMP.

487
MIBs and Traps
Table 61: SNMP Terminology
Term Description
Agent The SNMP server running on the Firepower Threat Defense. The SNMP agent has the following features:
• Responds to requests for information and actions from the network management station.
• Controls access to its Management Information Base, the collection of objects that the SNMP manager can
view or change.
• Does not allow SET operations.
Browsing Monitoring the health of a device from the network management station by polling required information from
the SNMP agent on the device. This activity may include issuing a series of GET-NEXT or GET-BULK requests
of the MIB tree from the network management station to determine values.
Management Standardized data structures for collecting information about packets, connections, buffers, failovers, and so on.
Information MIBs are defined by the product, protocols, and hardware standards used by most network devices. SNMP
Bases (MIBs) network management stations can browse MIBs and request specific data or events be sent as they occur.
Network The PCs or workstations set up to monitor SNMP events and manage devices.
management
stations (NMSs)
Object identifier The system that identifies a device to its NMS and indicates to users the source of information monitored and
(OID) displayed.
Trap Predefined events that generate a message from the SNMP agent to the NMS. Events include alarm conditions
such as linkup, linkdown, coldstart, warmstart, authentication, or syslog messages.
MIBs and Traps

MIBs are either standard or enterprise-specific. Standard MIBs are created by the IETF and documented in
various RFCs. A trap reports significant events occurring on a network device, most often errors or failures.
SNMP traps are defined in either standard or enterprise-specific MIBs. Standard traps are created by the IETF
and documented in various RFCs. SNMP traps are compiled into the ASA software.
If needed, you can also download RFCs, standard MIBs, and standard traps from the following locations:
http://www.ietf.org/
Browse the SNMP Object Navigator to look up Cisco MIBs, traps, and OIDs from the following location:
https://snmp.cloudapps.cisco.com/Support/SNMP/do/BrowseOID.do?local=en
In addition, download Cisco OIDs by FTP from the following location:
ftp://ftp.cisco.com/pub/mibs/oid/oid.tar.gz

488
Supported Tables and Objects in MIBs

The following sections list the supported tables and objects for the specified MIBs.
Remote Access VPN Polling
Table 62: CISCO-REMOTE-ACCESS-MONITOR-MIB
Counter OID Description
Active Sessions crasNumSessions The number of currently

active sessions.
(1.3.6.1.4.1.9.9.392.1.3.1)
Users crasNumUsers The number of users who

have active sessions.
(1.3.6.1.4.1.9.9.392.1.3.3)
Peak Sessions crasNumPeakSessions The number of peak RA

sessions since system up.
(1.3.6.1.4.1.9.9.392.1.3.41)
Site-to-Site VPN Tunnel Polling
Table 63: CISCO-REMOTE-ACCESS-MONITOR-MIB
LAN to LAN Sessions crasL2LNumSessions The number of currently

active LAN to LAN
(1.3.6.1.4.1.9.9.392.1.3.29)
sessions.
Peak LAN to LAN crasL2LPeakConcurrentSessions The number of peak

Sessions concurrent LAN to LAN
(1.3.6.1.4.1.9.9.392.1.3.31)
sessions since the system
is up.
Connection Polling
Table 64: CISCO-FIREWALL-MIB
Active Connections cfwConnectionActive The number of

connections currently in
(1.3.6.1.4.1.9.9.147.1.2.2.2.1.3.40.6)
use by the entire firewall.
Peak Connections cfwConnectionPeak The highest number of

connections in use at any
(1.3.6.1.4.1.9.9.147.1.2.2.2.1.3.40.7)
one time since system
startup.

489
Connections Per Second cfwConnectionPerSecond The current connections

per second rate on the
(1.3.6.1.4.1.9.9.147.1.2.2.3)
firewall.
Peak Connections Per cfwConnectionPerSecondPeak The highest number of

Second connections per second on
(1.3.6.1.4.1.9.9.147.1.2.2.4)
the firewall since system
startup.
NAT Translation Polling
Table 65: CISCO-NAT-EXT-MIB
Active Translations cneAddrTranslationNumActive The total number of

address translation entries
(1.3.6.1.4.1.9.9.532.1.1.1.1)
that are currently available
in the NAT device. This
indicates the aggregate of
the translation entries
created from both the
static and dynamic
address translation
mechanisms.
Peak Active Translations cneAddrTranslationNumPeak The maximum number of

address translation entries
(1.3.6.1.4.1.9.9.532.1.1.1.2)
that are active at any one
time since the system
startup. This indicates the
high watermark of address
translation entries that are
active at any one time
since the system startup.
This object includes the
translation entries created
from both the static and
dynamic address
translation mechanisms.

490
Routing Table Entries Polling
Table 66: IP-FORWARD-MIB
Active Translations inetCidrRouteNumber The total number of

current
(1.3.6.1.2.1.4.24.6)
inetCidrRouteTable
entries that valid.
Interface Duplex Status Polling
Table 67: CISCO-IF-EXTENSION-MIB
Duplex Status cieIfDuplexCfgStatus This object specifies the

configured duplex status
(1.3.6.1.4.1.9.9.276.1.1.2.1.20)
on the given interface.
Detected Duplex Status cieIfDuplexDetectStatus This object specifies the

detected duplex status on
(1.3.6.1.4.1.9.9.276.1.1.2.1.21)
the given interface.
Snort 3 Intrusion Event Rate Polling
Table 68: CISCO-UNIFIED-FIREWALL-MIB
Snort 3 Intrusion Event cufwAaicIntrusionEvtRate The rate at which

Rate intrusion events were
(1.3.6.1.4.1.9.9.491.1.5.3.2.1)
recorded by Snort on this
firewall averaged over the
last 300 seconds.
BGP Peer-Flap Trap Notification
Table 69: BGP4-MIB
BGP Peer-flap bgpBackwardTransition The

BGPBackwardTransition
(1.3.6.1.4.1.9.9.491.1.5.3.2.1)
Event is generatedwhen
the BGP FSM moves
from a higher numbered
state to a lower numbered
state.

491

492
CHAPTER 19
Troubleshooting the System
The following topics describe ways to diagnose problems you may encounter with the Firepower System:
• First Steps for Troubleshooting, on page 493
• System Messages, on page 493
• View Basic System Information, on page 496
• Managing System Messages, on page 496
• Memory Usage Thresholds for Health Monitor Alerts, on page 500
• Disk Usage and Drain of Events Health Monitor Alerts, on page 501
• Health Monitor Reports for Troubleshooting, on page 504
• General Troubleshooting, on page 506
• Connection-based Troubleshooting, on page 507
• Advanced Troubleshooting for the Firepower Threat Defense Device, on page 508
• Feature-Specific Troubleshooting, on page 513
First Steps for Troubleshooting

• Before you make changes to try to fix a problem, generate a troubleshooting file to capture the original
problem. See Health Monitor Reports for Troubleshooting, on page 504 and its subsections.
You may need this troubleshooting file if you need to contact Cisco TAC for support.
• Start your investigation by looking at error and warning messages in the Message Center. See System
Messages, on page 493
• Look for applicable Tech Notes and other troubleshooting resources under the "Troubleshoot and Alerts"
heading on the product documentation page for your product. See Top-Level Documentation Listing
Pages for FMC Deployments, on page 22.
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.

493
Message Types
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 and any number of warnings are present on the system.
• — Indicates one or more warnings and no errors are present on the system.
• — 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 552. 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 425. 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

494
Message Management
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).

495
View Basic System Information
• 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.
View Basic System Information

The About page displays information about your appliance, including the model, serial number, and version
information for various components of the Firepower System. It also includes Cisco copyright information.
Procedure
Step 1 Click Help in the toolbar at the top of the page.

Step 2 Choose About.
View Appliance Information

Procedure
Choose System > Configuration.
Managing System Messages

Procedure
Step 1 Click System Status to display the Message Center.

• Click Deployments to view messages related to configuration deployments. See Viewing Deployment
Messages, on page 497. You must be an Admin user or have the Deploy Configuration to Devices
permission to view these messages.

496
Viewing Deployment Messages
• Click Health to view messages related to the health of your Firepower Management Center and the
devices registered to it. See Viewing Health Messages, on page 498. You must be an Admin user or have
the Health permission to view these messages.
• Click Tasks to view or manage messages related to long-running tasks. See Viewing Task Messages,
on page 498 or Managing Task Messages, on page 499. Everyone can see their own tasks. To see the tasks
of other users, you must be an Admin user or have the View Other Users' Tasks permission.
• Click Cog ( ) in the upper right corner of the Message Center to configure pop-up notification behavior.
See Configuring Notification Behavior, on page 500.
Viewing Deployment Messages

You must be an Admin user or have the Deploy Configuration to Devices permission to view these messages.
Procedure

Step 2 Click Deployments.
• Click total to view all current deployment statuses.
• Click a status value to view only messages with that deployment status.
• Hover your cursor over the time elapsed indicator for a message (for example, 1m 5s) to view the elapsed
time, and start and stop times for the deployment.
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

497
Viewing Health Messages
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.
========= CLI APPLY =========
FMC >> interface GigabitEthernet0/0

FMC >> nameif outside
FTDv 192.168.0.152 >> [info] : INFO: Security level for "outside" set to 0 by default.
Related Topics
Deploy Configuration Changes, on page 535
Viewing Health Messages

You must be an Admin user or have the Health permission to view these messages.
Procedure

Step 2 Click Health.
• Click total to view all current health statuses.
• Click on a status value to view only messages with that status.
• Hover your cursor over the relative time indicator for a message (for example, 3 day(s) ago) to view the
time of the most recent update for that message.
• To view detailed health status information for a particular message, click the message.
• To view complete health status on the Health Monitoring page, click Health Monitor.
Related Topics
About Health Monitoring, on page 425
Viewing Task Messages

Everyone can see their own tasks. To see the tasks of other users, you must be an Admin user or have the
View Other Users' Tasks permission.

498
Managing Task Messages
Procedure

Step 2 Click Tasks.
• Click total to view all current task statuses.
• Click a status value to view only messages for tasks with the that status.
Note Messages for stopped tasks appear only in the total list of task status messages. You cannot
filter on stopped tasks.
• 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.
Managing Task Messages

Everyone can see their own tasks. To see the tasks of other users, you must be an Admin user or have the
View Other Users' Tasks permission.
Procedure

Step 2 Click Tasks.
• If more task status messages are available for display, click on Fetch more messages at the bottom of
the message list to retrieve them.
• To remove a single message for a completed task (status stopped, success, or failure), click on Remove
( ) next to the message.
• To remove all messages for all tasks that have completed (status stopped, success, or failure), filter the
messages on total and click on Remove all completed tasks.
• To remove all messages for all tasks that have completed successfully, filter the messages on success,
and click on Remove all successful tasks.
• To remove all messages for all tasks that have failed, filter the messages on failure, and click on Remove
all failed tasks.

499
Configuring Notification Behavior
Configuring Notification Behavior
Note This setting affects all pop-up notifications and persists between login sessions.
Procedure
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.
Step 4 Click Cog ( ) again to hide the slider.

Step 5 Click System Status again to close the Message Center.
Memory Usage Thresholds for Health Monitor Alerts

The Memory Usage health module compares memory usage on an appliance to the limits configured for the
module and alerts when usage exceeds the levels. The module monitors data from managed devices and from
the FMC itself.
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.

500
Disk Usage and Drain of Events Health Monitor Alerts
Table 70: Memory Usage Thresholds Based On Installed RAM
User-input Threshold Value Enforced Threshold Per Installed Memory (RAM)
4 GB 6 GB 32 GB 48 GB
10% 10% 34% 72% 81%
20% 20% 41% 75% 83%
30% 30% 48% 78% 85%
40% 40% 56% 81% 88%
50% 50% 63% 84% 90%
60% 60% 70% 88% 92%
70% 70% 78% 91% 94%
80% 80% 85% 94% 96%
90% 90% 93% 97% 98%
100% 100% 100% 100% 100%

The Disk Usage health module compares disk usage on a managed device’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.
This topic describes the symptoms and troubleshooting guidelines for two health alerts generated by the Disk
Usage health module:
• Frequent Drain of Events
• Drain of Unprocessed Events
The disk manager process manages the disk usage of a device. Each type of file monitored by the disk manager
is assigned a silo. Based on the amount of disk space available on the system the disk manager computes a
High Water Mark (HWM) and a Low Water Mark (LWM) for each silo.
To display detailed disk usage information for each part of the system, including silos, LWMs, and HWMs,
use the show disk-manager command.
Examples
Following is an example of the disk manager information.
> show disk-manager

Silo Used Minimum Maximum
Temporary Files 0 KB 499.197 MB 1.950 GB

501
Action Queue Results 0 KB 499.197 MB 1.950 GB

User Identity Events 0 KB 499.197 MB 1.950 GB
UI Caches 4 KB 1.462 GB 2.925 GB
Backups 0 KB 3.900 GB 9.750 GB
Updates 0 KB 5.850 GB 14.625 GB
Other Detection Engine 0 KB 2.925 GB 5.850 GB
Performance Statistics 33 KB 998.395 MB 11.700 GB
Other Events 0 KB 1.950 GB 3.900 GB
IP Reputation & URL Filtering 0 KB 2.437 GB 4.875 GB
Archives & Cores & File Logs 0 KB 3.900 GB 19.500 GB
Unified Low Priority Events 1.329 MB 4.875 GB 24.375 GB
RNA Events 0 KB 3.900 GB 15.600 GB
File Capture 0 KB 9.750 GB 19.500 GB
Unified High Priority Events 0 KB 14.625 GB 34.125 GB
IPS Events 0 KB 11.700 GB 29.250 GB
Health Alert Format

When the Health Monitor process on the FMC runs (once every 5 minutes or when a manual run is triggered)
the Disk Usage module looks into the diskmanager.log file and, if the correct conditions are met, the respective
health alert is triggered.
The structures of these health alerts are as follows:
• Frequent drain of <SILO NAME>
• Drain of unprocessed events from <SILO NAME>
For example,
• Frequent drain of Low Priority Events
• Drain of unprocessed events from Low Priority Events
It’s possible for any silo to generate a Frequent drain of <SILO NAME> health alert. However, the most
commonly seen are the alerts related to events. Among the event silos, the Low Priority Events are often seen
because these type of events are generated by the device more frequently.
A Frequent drain of <SILO NAME> event has a Warning severity level when seen in relation to an
event-related silo, because events will be queued to be sent to the FMC. For a non-event related silo, such as
the Backups silo, the alert has a Critical severity level because this information is lost.
Important Only event silos generate a Drain of unprocessed events from <SILO NAME> health alert. This alert always
has Critical severity level.
Additional symptoms besides the alerts can include:

• Slowness on the FMC user interface
• Loss of events
Common Troubleshoot Scenarios

A Frequent drain of <SILO NAME> event is caused by too much input into the silo for its size. In this case,
the disk manager drains (purges) that file at least twice in the last 5-minute interval. In an event type silo, this
is typically caused by excessive logging of that event type.

502
In the case of a Drain of unprocessed events of <SILO NAME> health alert, this can also be caused by a
bottleneck in the event processing path.
There are three potential bottlenecks with respect to these Disk Usage alerts:
• Excessive logging ― The EventHandler process on FTD is oversubscribed (it reads slower than what
Snort writes).
• Sftunnel bottleneck ― The Eventing interface is unstable or oversubscribed.
• SFDataCorrelator bottleneck ― The data transmission channel between the FMC and the managed device
is oversubscribed.
Excessive Logging
One of the most common causes for the health alerts of this type is excessive input. The difference between
the Low Water Mark (LWM) and High Water Mark (HWM) gathered from the show disk-manager command
shows how much space there is available to take on that silo to go from LWM (freshly drained) to the HWM
value. If there are frequent drain of events (with or without unprocessed events) the first thing to review is
the logging configuration.
• Check for double logging ― Double logging scenarios can be identified if you look at the correlator
perfstats on the FMC:
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
• Check logging settings for the ACP ― Review the logging settings of the Access Control Policy (ACP).
If logging both "Beginning" and "End" of connection, log only the end as it will include everything
included when the beginning is logged as well as reduce the amount of events.
Ensure that you follow the best practices described in Best Practices for Connection Logging, on page
2810.
Communications Bottleneck ― Sftunnel

Sftunnel is responsible for encrypted communications between the FMC and the managed device. Events are
sent over the tunnel to the FMC. Connectivity issues and/or instability in the communication channel (sftunnel)
between the managed device and the FMC can be due to:
• Sftunnel is down or is unstable (flaps).
Ensure that the FMC and the managed device have reachability between their management interfaces
on TCP port 8305.
The sftunnel process should be stable and should not restart unexpectedly. Verify this by checking the
/var/log/message file and search for messages that contain the sftunneld string.
• Sftunnel is oversubscribed.
Review trend data from the Heath Monitor and look for signs of oversubscription of the FMC's
management interface, which can be a spike in management traffic or a constant oversubscription.
Use as a secondary management interface for Firepower-eventing. To use this interface, you must
configure its IP address and other parameters at the FTD CLI using the configure network
management-interface command.

503
Health Monitor Reports for Troubleshooting
Communications Bottleneck ― SFDataCorrelator

The SFDataCorrelator manages data transmission between the FMC and the managed device; on the FMC,
it analyzes binary files created by the system to generate events, connection data, and network maps. The first
step is to review the diskmanager.log file for important information to be gathered, such as:
• The frequency of the drain.
• The number of files with Unprocessed Events drained.
• The occurrence of the drain with Unprocessed Events.
Each time the disk manager process runs it generates an entry for each of the different silos on its own log
file, which is located under [/ngfw]/var/log/diskmanager.log. Information gathered from the diskmanager.log
(in CSV format) can be used to help narrow the search for a cause.
Additional troubleshooting steps:
• The command stats_unified.pl can help you to determine if the managed device does have some data
which needs to be sent to FMC. This condition can happen when the managed device and the FMC
experience a connectivity issue. The managed device stores the log data onto a hard drive.
admin@FMC:~$ sudo stats_unified.pl
• The manage_proc.pl command can reconfigure the correlator on the FMC side.
root@FMC:~# manage_procs.pl
Before You Contact Cisco Technical Assistance Center (TAC)

It is highly recommended to collect these items before you contact Cisco TAC:
• Screenshots of the health alerts seen.
• Troubleshoot file generated from the FMC.
• Troubleshoot file generated from the affected managed device.
Date and Time when the problem was first seen.
• Information about any recent changes done to the policies (if applicable).
The output of the stats_unified.pl command as described in the Communications Bottleneck ―
SFDataCorrelator, on page 504.
Health Monitor Reports for Troubleshooting

In some cases, if you have a problem with your appliance, Support may ask you to supply troubleshooting
files to help them diagnose the problem. The system can produce troubleshooting files with information
targeted to specific functional areas, as well as advanced troubleshooting files you retrieve in cooperation
with Support. You can select any of the options listed in the table below to customize the contents of a
troubleshooting file for a specific function.
Note that some options overlap in terms of the data they report, but the troubleshooting files will not contain
redundant copies, regardless of what options you select.

504
Producing Troubleshooting Files for Specific System Functions
Table 71: Selectable Troubleshoot Options
This option... Reports...
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
All Log Data all logs collected by the appliance database
Network Map Information current network topology data
Producing Troubleshooting Files for Specific System Functions

You can generate and download customized troubleshooting files that you can send to Support.
In a multidomain deployment, you can generate and download troubleshooting files for devices in descendant
domains.
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 546 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 5508-X, 5516-X NGIPSv.
Before you begin

You must be an Admin, Maintenance, Security Analyst, or Security Analyst (Read Only) user to perform this
task.

505
Downloading Advanced Troubleshooting Files
Procedure
Step 1 Perform the steps in Viewing the Device Health Monitor, on page 450.
Step 2 Click Generate Troubleshooting Files.
Step 3 Choose All Data to generate all possible troubleshooting data, or check individual boxes as described in
Viewing Task Messages, on page 498.
Step 4 Click OK.
Step 5 View task messages in the Message Center; see Viewing Task Messages, on page 498.
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.
Downloading Advanced Troubleshooting Files

In a multidomain deployment, you can generate and download troubleshooting files for devices in descendant
domains. You can download files from the Firepower Management Center only from the Global domain.
Before you begin

You must be an Admin, Maintenance, Security Analyst, or Security Analyst (Read Only) user to perform this
task.
Procedure
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.

506
Connection-based Troubleshooting
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
Note Connection-based debugging is not supported on Firepower 2100 Series devices.
For more information about the troubleshooting connections, see Troubleshoot a Connection , on page 507.
Troubleshoot a Connection
Procedure
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 3 Start debugging the packets using the following command:

debug packet-start
Step 4 Fetch the debug messages from database to analyze the debug messages using the following command:
show packet-debugs
Step 5 Stop debugging the packets using the following command:

debug packet-stop

507
Advanced Troubleshooting for the Firepower Threat Defense Device
Advanced Troubleshooting for the Firepower Threat Defense

Device
You can use Packet Tracer and Packet Capture features for performing an in-depth troubleshooting analysis
on a Firepower Threat Defense device. Packet-tracer allows a firewall administrator to inject a virtual packet
into the security appliance and track the flow from ingress to egress. Along the way, the packet is evaluated
against flow and route lookups, ACLs, protocol inspection, NAT, and intrusion detection. The power of the
utility comes from the ability to simulate real-world traffic by specifying source and destination addresses
with protocol and port information. Packet capture is available with the trace option, which provides you with
a verdict as to whether the packet is dropped or successful.
For more information about the troubleshooting files, see Downloading Advanced Troubleshooting Files, on
page 506.
Using the FTD CLI from the Web Interface

You can execute selected FTD command line interface (CLI) commands from the Firepower Management
Center web interface. These commands are ping, traceroute, and show (except for show history and show
banner).
In a multidomain deployment, you can enter FTD CLI commands through the Firepower Management Center
web interface for managed devices in descendant domains.
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.
Before you begin

You must be an Admin, Maintenance, or Security Analyst user to use the CLI.
Procedure
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.

508
Packet Tracer Overview
Packet Tracer Overview

Using the packet tracer, you can test your policy configuration by modeling a packet based on source and
destination addressing, and protocol characteristics. The trace does a policy lookup to test access rules, NAT,
routing, access policies and rate limiting policies, to check if the packet would be permitted or denied. The
packet flow is simulated based on interfaces, source address, destination address, ports and protocols. By
testing packets this way, you can see the results of your policies and test whether the types of traffic you want
to allow or deny are handled as desired. Besides verifying your configuration, you can use the tracer to debug
unexpected behavior, such as packets being denied when they should be allowed. To simulate the packet fully,
packet tracer traces the data path; slow-path and fast-path modules. Processing is transacted based on per-session
and per-packet basis. Tracing packets and capture with trace log the tracing data on per packet basis when the
Next-Generation Firewall (NGFW) processes packets per-session or per-packet.
Use the Packet Tracer

You can use packet tracer on Firepower Threat Defense devices. You must be an Admin or Maintenance user
to use this tool.
Procedure
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 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.
Step 7 Select the ingress Interface for the packet trace.

Step 8 Select the Source type for the packet trace, and enter the source IP address.
Source and destination types include IPv4, IPv6, and fully-qualified domain names (FQDN). You can specify
IPv4 or IPv6 addresses and FQDN, if you use Cisco TrustSec.
Step 9 Select the Source Port for the packet trace.

Step 10 Select the Destination type for the packet trace, and enter the destination IP address.
Step 11 Select the Destination Port for the packet trace.
Step 12 Optionally, if you want to trace a packet where the Security Group Tag (SGT) value is embedded in the Layer
2 CMD header (TrustSec), enter a valid SGT number.
Step 13 If you want packet tracer to enter a parent interface, which is later redirected to a sub-interface, enter a VLAN
ID.
This value is optional for non-sub-interfaces only, since all the interface types can be configured on a
sub-interface.

509
Packet Capture Overview
Step 14 Specify a Destination MAC Address for the packet trace.

If the Firepower Threat Defense device is running in transparent firewall mode, and the ingress interface is
VTEP, Destination MAC Address is required if you enter a value in VLAN ID. Whereas if the interface is
a bridge group 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.
Step 15 Select the Output Format for the packet logs.

Step 16 Click Start.

The packet capture feature with trace option allows real packets that are captured on the ingress interface to
be traced through the system. The trace information is displayed at a later stage. These packets are not dropped
on the egress interface, as they are real data-path traffic. Packet capture for Firepower Threat Defense devices
supports troubleshooting and analysis of data packets.
Once the packet is acquired, Snort detects the tracing flag that is enabled in the packet. Snort writes tracer
elements, through which the packet traverses. Snort verdict as a result of capturing packets can be one of .the
following:
Table 72: Snort Verdicts
Verdict Description
Pass Allow analyzed packet.
Block Packet not forwarded.
Replace Packet modified.
AllowFlow Flow passed without inspection.
BlockFlow Flow was blocked.
Ignore Flow was blocked; occurs only for sessions with flows
blocked on passive interfaces.
Retry Flow is stalled, waiting on a enamelware or URL

category/reputation query. In the event of a timeout,
processing continues with an unknown result: in the
case of enamelware, the file is allowed; in the case of
URL category/reputation, AC rule lookup continues
with an uncategorized and unknown reputation.
Based on the Snort verdict, the packets are dropped or allowed. For example, the packet is dropped if the
Snort verdict is BlockFlow, and the subsequent packets in the session are dropped before reaching Snort.
When the Snort verdict is Block or BlockFlow, the Drop Reason can be one of the following:

510
Table 73: Drop Reasons
Blocked or Flow Blocked by... Cause
Snort Snort is unable to process the packet, erg., snort can’t

decode packet since it is corrupted or has invalid
format.
the App Id preprocessed App Id module/preprocessed does not block packet

by itself; but this may indicate that aphid detection
causes other module (erg., firewall) to match a
blocking rule.
the SSL preprocessed There is a block/reset rule in SSL policy to match the
traffic.
the firewall There is a block/reset rule in firewall policy to match

the traffic.
the captive portal preprocessed There is a block/reset rule using the identity policy to
match the traffic.
the safe search preprocessed There is a block/reset rule using the safe-search feature
in firewall policy to match the traffic.
the SI preprocessed There is a block/reset rule a in Security Intelligence

tab of AC Policy to block the traffic, erg., DNS or
URL SI rule.
the filterer preprocessed There is a block/reset rule in filterer tab of AC policy

to match the traffic.
the stream preprocessed There is an intrusion rule blocking/reset stream

connection, erg., blocking when TCP normalization
error.
the session preprocessed This session was already blocked earlier by some
other module, so session preprocessed is blocking
further packets of the same session.
the fragmentation preprocessed Blocking because earlier fragment of the data is

blocked.
the snort response preprocessed There is a react snort rule, erg., sending a response
page on a particular HTTP traffic.
the snort response preprocessed There is a snort rule to send custom response on
packets matching conditions.
the reputation preprocessed Packet matches a reputation rule, erg., blocking a

given IP address.
the x-Link2State preprocessed Blocking due to buffer overflow vulnerability detected

in SMTP.

511
Use the Capture Trace
Blocked or Flow Blocked by... Cause
back orifice preprocessed Blocking due to detection of back orifice data.
the SMB preprocessed There is a snort rule to block SMB traffic.
the file process preprocessed There is file policy that blocks a file, erg., enamelware
blocking.
the IPS preprocessed There is a snort rule using IPS, erg., rate filtering.
The packet capture feature allows you to capture and download packets that are stored in the system memory.
However, the buffer size is limited to 32 MB due to memory constraint. Systems capable of handling very
high volume of packet captures exceed the maximum buffer size quickly and thereby the necessity of increasing
the packet capture limit is required. It is achieved by using the secondary memory (by creating a file to write
the capture data). The maximum supported file size is 10 GB.
When the file-size is configured, the captured data gets stored to the file and the file name is assigned based
on the capture name recapture .
The file-size option is used when you need to capture packets with the size limit more than 32 MB.
For information, see the Command Reference for Firepower Threat Defense.
Use the Capture Trace

Packet capture data includes information from Snort and preprocessors about verdicts and actions the system
takes while processing a packet. Multiple packet captures are possible at a time. You can configure the system
to modify, delete, clear, and save captures.
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.
Before you begin

You can use packet capture on Firepower Threat Defense devices. You must be an Admin or Maintenance
user to use this tool.
Procedure
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 5 Select Capture w/Trace.

512
Feature-Specific Troubleshooting
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.
See the following table for feature-specific troubleshooting tips and techniques.
Table 74: Feature-Specific Troubleshooting Topics
Feature Relevant Troubleshooting Information
Application control Troubleshoot Application Control Rules, on page 583
LDAP external authentication Troubleshooting LDAP Authentication Connections, on page 130
Licensing Troubleshoot FTD Licensing, on page 197

Troubleshoot Specific License Reservation, on page 191
FMC high availability Troubleshooting Firepower Management Center High Availability,

on page 325
User rule conditions Troubleshoot User Control, on page 588

513
Feature Relevant Troubleshooting Information
User identity sources Troubleshoot the ISE/ISE-PIC or Cisco TrustSec Issues, on page
2461
Troubleshoot the TS Agent Identity Source, on page 2484
Troubleshoot the Captive Portal Identity Source, on page 2477
Troubleshoot the Remote Access VPN Identity Source, on page
2480
Troubleshooting LDAP Authentication Connections, on page 130
URL filtering Troubleshoot URL Filtering, on page 1673
Realms and user data downloads Troubleshoot Realms and User Downloads, on page 2438
Network discovery Troubleshooting Your Network Discovery Strategy, on page 2518
Custom Security Group Tag (SGT) rule conditions Troubleshooting Custom SGT Conditions, on page 593
SSL rules Troubleshoot TLS/SSL Rules, on page 1827
Cisco Threat Intelligence Director (TID) Troubleshoot Cisco Threat Intelligence Director (TID), on page
1926
Firepower Threat Defense syslog About Configuring Syslog, on page 1450
Intrusion performance statistics Intrusion Performance Statistic Logging Configuration, on page

2156
NGIPSv generate-troubleshoot, on page 3078

ASA with FirePOWER Services (Command in the Command Line Interface (CLI))
Connection-based Troubleshooting Connection-based Troubleshooting, on page 507

514
PA R T IV
Deployment Management
• Domain Management, on page 517
• Policy Management, on page 525
• Rule Management: Common Characteristics, on page 561
• Reusable Objects, on page 599
• Firepower Threat Defense Certificate-Based Authentication, on page 717
CHAPTER 20
Domain Management
The following topics describe how to manage multitenancy using domains:
• Introduction to Multitenancy Using Domains, on page 517
• Requirements and Prerequisites for Domains, on page 520
• Managing Domains, on page 520
• Creating New Domains, on page 521
• Moving Data Between Domains, on page 522
• Moving Devices Between Domains, on page 523
• History for Domain Management, on page 524
Introduction to Multitenancy Using Domains

The Firepower System allows you to implement multitenancy using domains. Domains segment user access
to managed devices, configurations, and events. You can create up to 100 subdomains under a top-level Global
domain, in two or three levels.
When you log into the Firepower Management Center, you log into a single domain, called the current domain.
Depending on your user account, you may be able to switch to other domains.
In addition to any restrictions imposed by your user role, your current domain level can also limit your ability
to modify various Firepower System configurations. The system limits most management tasks, like system
software updates, to the Global domain.
The system limits other tasks to leaf domains, which are domains with no subdomains. For example, you must
associate each managed device with a leaf domain, and perform device management tasks from the context
of that leaf domain.
Each leaf domain builds its own network map, based on the discovery data collected by that leaf domain’s
devices. Events reported by a managed device (connection, intrusion, malware, and so on) are also associated
with the device's leaf domain.
One Domain Level: Global

If you do not configure multitenancy, all devices, configurations, and events belong to the Global domain,
which in this scenario is also a leaf domain. Except for domain management, the system hides domain-specific
configurations and analysis options until you add subdomains.

517
Domains Terminology
Two Domain Levels: Global and Second-Level

In a two-level multidomain deployment, the Global domain has direct descendant domains only. For example,
a managed security service provider (MSSP) can use a single Firepower Management Center to manage
network security for multiple customers:
• Administrators at the MSSP logging into the Global domain, cannot view or edit customers’ deployments.
They must log into respective second-level named subdomains to manage the customers' deployment.
• Administrators for each customer can log into second-level named subdomains to manage only the
devices, configurations, and events applicable to their organizations. These local administrators cannot
view or affect the deployments of other customers of the MSSP.
Three Domain Levels: Global, Second-Level, and Third-Level

In a three-level multidomain deployment, the Global domain has subdomains, at least one of which has its
own subdomain. To extend the previous example, consider a scenario where an MSSP customer—already
restricted to a subdomain—wants to further segment its deployment. This customer wants to separately manage
two classes of device: devices placed on network edges and devices placed internally:
• Administrators for the customer logging into the second-level subdomain cannot view or edit the customer's
edge network deployments. They must log into the respective leaf domain to manage the devices deployed
on the network edge.
• Administrators for the customer’s edge network can log into a third-level (leaf) domain to manage only
the devices, configurations, and events applicable to devices deployed on the network edge. Similarly,
administrators for the customer’s internal network can log into a different third-level domain to manage
internal devices, configurations, and events. Edge and internal administrators cannot view each other's
deployment.
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.
Related Topics
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.

518
Domain Properties
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.

519
Requirements and Prerequisites for Domains
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 2346
Network Discovery Data Storage Settings, on page 2514
Requirements and Prerequisites for Domains

Model Support
Any.
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.
Procedure
Step 1 Choose System > Domains.

520
Creating New Domains
Step 2 Manage your domains:

• Add — Click Add Domain, or click Add Subdomain next to the parent domain; see Creating New
Domains, on page 521.
• Edit — Click Edit ( ) next to the domain you want to modify; see Domain Properties, on page 519.
• 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 522.
• If you moved devices between domains and must assign new policies and security zones or interface
groups, see Moving Devices Between Domains, on page 523.
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.
Creating New Domains

You can create up to 100 subdomains under a top-level Global domain, in two or three levels.
You must assign all devices to a leaf domain before you can implement the domain configuration. When you
add a subdomain to a leaf domain, the domain stops being a leaf domain and you must reassign its devices.
Procedure
Step 1 In a Global or a second-level domain, choose System > Domains.

Step 2 Click Add Domain, or click Add Subdomain next to the parent domain.
Step 3 Enter a Name and Description.
Step 4 Choose a Parent Domain.
Step 5 On Devices, choose the Available Devices to add to the domain, then click Add to Domain or drag and drop
into the list of Selected Devices.
Step 6 Optionally, click Advanced to limit the number of hosts the new domain may monitor; see Domain Properties,
on page 519.
Step 7 Click Save to return to the domain management page.
The system warns you if any devices are assigned to non-leaf domains. Click Create New Domain to create
a new domain for those devices. Click Keep Unassigned if you plan to move the devices to existing domains.

521
Moving Data Between Domains
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 522.
• If you moved devices between domains and must assign new policies and security zones or interface
groups, see Moving Devices Between Domains, on page 523.
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.
Moving Data Between Domains

Because events and network maps are associated with leaf domains, when you change a leaf domain to a
parent domain, you have two choices:
• Move the network map and associated events to a new leaf domain.
• Delete the network map but retain the events. In this case, the events remain associated with the parent
domain until the system prunes events as needed or as configured. Or, you can delete old events manually.
Before you begin

Implement a domain configuration where a former leaf domain is now a parent domain; see Managing Domains,
on page 520.
Procedure
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.
Step 2 Click Save.
What to do next

522
Moving Devices Between Domains
Moving Devices Between Domains

You can move devices between domains when you are in the global domain or a second-level domain. Moving
a device between domains can affect the configurations and policies applied to the device. The system
automatically retains and updates what it can. It deletes what it cannot update, namely, object overrides,
dynamic routing configuration, static routes, IP pool associated with the diagnostic interface,and DDNS.
When you assign a remote access VPN policy to a device, you can move the device from one domain to
another, only if the target domain is a descendant of the domain in which remote access VPN is configured.
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.
Before you begin

• Implement a domain configuration where you moved a device from domain to domain and now must
assign new policies and security zones; see Managing Domains, on page 520.
Procedure
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.

523
History for Domain Management
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.
History for Domain Management

Increased maximum number of 6.5 You can now add up to to 100

supported domains domains. Previously, the maximum
was 50 domains.
Supported platforms: Firepower
Management Center

524
CHAPTER 21
Policy Management
The following topics describe how to manage various policies on the Firepower Management Center:
• Requirements and Prerequisites for Policy Management, on page 525
• Policy Deployment, on page 525
• Policy Comparison, on page 550
• Policy Reports, on page 551
• Out-of-Date Policies, on page 552
• Performance Considerations for Limited Deployments, on page 553
• History for Policy Management, on page 555
Requirements and Prerequisites for Policy Management

Model Support
Any.
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

525
Best Practices for Deploying Configuration Changes
• Device-related policies: NAT, VPN, QoS, platform settings

• Access control and related policies: DNS, file, identity, intrusion, network analysis, prefilter, SSL
• Network discovery policy
• Intrusion rule updates
• Configurations and objects associated with any of these elements
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.
Best Practices for Deploying Configuration Changes

The following are guidelines for deploying configuration changes.
Inline vs Passive Deployments

Do not apply inline configurations to devices deployed passively, and vice versa.
Time to Deploy and Memory Limitations

The time it takes to deploy depends on multiple factors, including (but not limited to):
• The configurations you send to the device. For example, if you dramatically increase the number of
Security Intelligence entries you block, deploy can take longer.
• Device model and memory. On lower-memory devices, deploying can take longer.
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 1610.
Interruptions to Traffic Flow and Inspection During Deploy

When you deploy, resource demands may result in a small number of packets dropping without inspection.
For Firepower Threat Defense devices, the Inspect Interruption column in the Deploy dialog warns you
when deploying might interrupt traffic flow or inspection. You can either proceed with, cancel, or delay
deployment; see Restart Warnings for Firepower Threat Defense Devices, on page 527 for more information.

526
Restart Warnings for Firepower Threat Defense Devices
Caution We strongly recommend you deploy in a maintenance window or at a time when interruptions will have the
least impact.
Auto-Enabling Application Detectors

If you are performing application control but disable required detectors, the system automatically enables the
appropriate system-provided detectors upon policy deploy. If none exist, the system enables the most recently
modified user-defined detector for the application.
Asset Rediscovery with Network Discovery Policy Changes

When you deploy changes to a network discovery policy, the system deletes and then rediscovers MAC
address, TTL, and hops information from the network map for the hosts in your monitored networks. Also,
the affected managed devices discard any discovery data that has not yet been sent to the Firepower Management
Center.
Related Topics
Snort® Restart Scenarios, on page 545
Restart Warnings for Firepower Threat Defense Devices

When you deploy, the Inspect Interruption column in the deploy page specifies whether a deployed
configuration restarts the Snort process on a Firepower Threat Defense device. When the traffic inspection
engine referred to as the Snort process restarts, inspection is interrupted until the process resumes. Whether
traffic is interrupted or passes without inspection during the interruption depends on how the device handles
traffic. Note that you can proceed with the deployment, cancel the deployment and modify the configuration,
or delay the deployment until a time when deploying would have the least impact on your network.
When the Inspect Interruption column indicates Yes and you expand the device configuration listing, the
system indicates any specific configuration type that would restart the Snort process with an Inspect
Interruption ( ). When you hover your mouse over the icon, a message informs you that deploying the
configuration may interrupt traffic.
The following table summarizes how the deploy page displays inspection interruption warnings.

527
Deployment Status
Table 75: Inspection Interruption Indicators
Type Inspect Interruption Description
FTD Inspect Interruption At least one configuration would interrupt

inspection on the device if deployed, and might
( )Yes
interrupt traffic depending on how the device
handles traffic. You can expand the device
configuration listing for more information.
-- Deployed configurations will not interrupt traffic

on the device.
Undetermined The system cannot determine if a deployed

configuration may interrupt traffic on the device.
Undetermined status is displayed before the first
deployment after a software upgrade, or in some
cases during a Support call.
Errors ( ) The system cannot determine the status due to an

internal error.
Cancel the operation and click Deploy again to
allow the system to redetermine the Inspect
Interruption status. If the problem persists,
contact Support.
sensor -- The device identified as sensor is not a Firepower

Threat Defense device; the system does not
determine if a deployed configuration may
interrupt traffic on this device.
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 548.
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.

528
Deployment Estimate
• 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 Notes
Deployment notes are custom notes that a user can add as part of the deployment, and the deployment notes
are optional.
You can view the deployemnt notes in the Deployment History page. On the Firepower Management Center
menu bar, click Deploy and then select Deployment History to view the Deployment Notes column for each
job.
Use the Search option on the Deployment History page to search using job name, device name, user name,
status, or deployment notes.
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
because they are not deployed on the device.
On the Deployment page, the Preview column provides a Preview ( ) icon 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 Filter icon ( provided on the Preview page provides an option to filter the policies at the user level
and policy level. Click the Filter icon ( . Select the policy or user name, or both, and then click Apply to
restrict the displayed listing to only the selected items. To view all the pending deployments, ensure that you
click the Filter icon and select Reset.

529
Deployment Preview
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 Version on Device
column) versus the changes that are due for deployment (in the Version on FMC 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.
The Modified By column lists the users who have modified, or added the configuration settings. At the policy
level, FMC displays all the users who have modified the policy, and at the rule level, FMC displays only the
last user who has modified the rule.
You can download a copy of the change log by clicking the Download as PDF button.

530
Deployment Preview
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 1404.
• The preview does not show the reordering of rules across policies.
For DNS policies, reordered rules appear in the preview list as rule additions and deletions. For example,
moving a rule from position 1 to position 3 in the rule order is displayed as if the rule was deleted from
position 1 and added as a new rule in position 3. Similarly, when a rule is deleted, the rules under it are
listed as edited rules as they have changed their positions. The changes are displayed in the final order
in which they appear in the policy.
• 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 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
• The change log is not supported on NGIPS devices.

• User information at rule level is not available for intrusion policies.
• FMC displays the username as system for the following operations:
• Rollback
• Upgrade
• FTD backup and restore
• SRU update
• LSP update
• VDB update
• If you change the FMC name in System > Configuration > Information, the deployment preview does
not specify this change, yet it requires deploy.

531
Filter Support for Deployment
Filter Support for Deployment

The Filter icon ( ) provided on the Deployment page provides an option to filter the device listings that are
pending deployment. The filter icon provides options to filter the listings based on selected devices and user
names. You can use the filter along with the search option to narrow down to the required listing.
Click the filter icon ( ). Select the device or user name, or both, and then click Apply to restrict the displayed
listing to only the selected items. To view all the pending deployments, ensure that you click the filter icon
( ) and select Reset.
Selective Policy Deployment

FMC allows you to select a specific policy within the list of all the changes on the device that are due for
deployment and deploy only the selected policy. Selectively deployment is available only for the following
policies:
• Access control policies
• Intrusion policies
• Malware and file policies
• DNS policies
• Identity policies
• SSL policies
• QoS policies
• Prefilter policies
• Network discovery
• NAT policies
• Routing policies
• VPN policies
On the deployment page, after you click Expand Arrow ( ) to view device-specific configuration changes,
Policy selection ( ) icon 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.

532
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 deselected 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 527.
There are certain limitations to selectively deploying policies. Follow the contents in the table below to
understand when selective policy deployment can be used.
Table 76: Limitations for Selective Deployment
Type Description Scenarios
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).

533
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.
Scenarios wherein multiple policies are

automatically selected:
• When a new object is associated with an
existing policy, and the same object is already
associated with other policies, all the
associated policies are automatically selected.
• When a shared object is modified, all the
associated policies are automatically selected.
Interdependent The FMC dynamically detects Scenarios wherein color-coded interdependent

policy changes dependencies in-between policies, policies or objects are automatically selected:
(shown using and between the shared objects and
• When all the out-of-date policies have
color-coded tags) the policies. The interdependency
interdependent changes.
of the objects or policies is shown
using color-coded tags. For example, when an access control policy,
an intrusion policy, and a NAT policy are
out-of-date. Since access control policy and
NAT policy share an object, all policies are
selected together for deployment.
• When all out-of-date policies share an object,
and the object is modified.

534
Deploy Configuration Changes
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,
Hide Policy ( ). except file policy and intrusion policy, are
selected when the access control policy is
selected for deployment.
However, if the access control policy is
out-of-date, intrusion and file policies can be
individually selected or deselected irrespective
of whether the access control policy is selected
or not, unless there are any dependent changes.
For example, if a new intrusion policy is
assigned to an access control rule, it indicates
that there are dependent changes, then both
the access control policy and the intrusion
policy will be automatically selected when
either of them is selected.
• If no access control policy is out-of-date, other
out-of-date policies in this group can be
selected and deployed individually.

After you change configurations, deploy them to the affected devices. We strongly recommend that you deploy
in a maintenance window or at a time when any interruptions to traffic flow and inspection will have the least
impact.
Before you begin

• Review the guidelines described in Best Practices for Deploying Configuration Changes, on page 526.
• Be sure all managed devices use the same revision of the Security Zones object. If you have edited
security zone objects: 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.
See Synchronizing Security Zone Object Revisions, on page 732.

535
Note Policy deployment process fails if the sensor configuration is being read by the system during deployment.
Executing commands such as show running-config from the sensor CLI disturbs the deployment, which
results in deployment failure.
Procedure
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 Modified By column lists the users who have modified the policies or objects. On expanding the
device listing, you can view the users who have modified the policies against each policy listing.
Note Usernames are not provided for deleted policies and objects.
• 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 527 for information to help you
identify configurations that interrupt traffic inspection and might interrupt traffic when deployed to
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 529.
• The Status column provides the status for each deployment. For more information, see Deployment
Status, on page 528.
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 532.
Optionally, use Show or Hide Policy ( ) to selectively view or hide the associated unmodified policies.

536
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 529.

Step 5 If the system identifies errors or warnings in the changes to be deployed, it displays them in the Validation
Messages window. To view complete details, click the arrow icon before the warnings or errors.
You have the following choices:
• Deploy—Continue deploying without resolving warning conditions. You cannot proceed if the system
identifies errors.
• Close—Exit without deploying. Resolve the error and warning conditions, and attempt to deploy the
configuration again.
What to do next
• (Optional) Monitor deployment status; see Viewing Deployment Messages, on page 497.
• If deploy fails, see Best Practices for Deploying Configuration Changes, on page 526.
• 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.
Configuration Changes Exists? Traffic Impacted?
Threat Defense Service changes Yes Yes

in an access control policy
VRF Yes Yes
Interface Yes Yes
QoS Yes Yes

537
Redeploy Existing Configurations to a Device
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
Redeploy Existing Configurations to a Device

You can force-deploy existing (unchanged) configurations to a single managed device. We strongly recommend
you deploy in a maintenance window or at a time when any interruptions to traffic flow and inspection will
have the least impact.
Before you begin

Review the guidelines described in Best Practices for Deploying Configuration Changes, on page 526.
Procedure

Step 2 Click Edit ( ) next to the device where you want to force deployment.

Step 4 Click Edit ( ) next to the General section heading.
Step 5 Click Force Deploy ( ).

Note Force-deploy takes more time than the regular deployment because it involves the complete generation
of the policy rules to be deployed on the FTD.

The system identifies any errors or warnings with the configurations you are deploying. You can click Proceed
to continue without resolving warning conditions. However, you cannot proceed if the system identifies an
error.

538
View Deployment History
What to do next
• (Optional) Monitor deployment status; see Viewing Deployment Messages, on page 497.
• If deploy fails, see Best Practices for Deploying Configuration Changes, on page 526.
Related Topics
View Deployment History

Procedure
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.
Note The transcript for the rollback operation does not provide the CLI commands information. To
view the rollback commands, see View the Deployment Rollback Transcript, on page 544.
• 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.
========= CLI APPLY =========


539
View Deployment History Preview
Step 4 (Optional) Click Preview ( ) to view the policy and object changes deployed on the device versus the
previously deployed version.
The Modified By column lists the users who have modified the policies or objects. At the policy level, FMC
displays all the user names who have modified the policy. At the rule level, FMC displays the last user who
has modified the rule.
Additionally, to compare any two versions and view the change log, choose the required versions in the
drop-down boxes and click the Show button. Click the Download as PDF button to download a copy of the
change log.
Note Deployment history preview is not supported for certificate enrollments, HA operations, and failed
deployments.
View Deployment History Preview

Procedure
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 Preview ( ) to view the policy and object changes deployed on the device versus the
previously deployed version.
a. To compare any two versions and view the change log, choose the required versions in the drop-down
boxes and click the Show button. The drop-down boxes show the deployment job name and the end time
of the deployment.
Note The drop-down boxes also show failed deployments.
b. The Modified By column lists the users who have modified the policies or objects.
1. At the policy level, FMC displays all the user names who have modified the policy.
2. At the rule level, FMC displays the last user who has modified the rule.
c. You can also download a copy of the change log by clicking the Download as PDF button.
The Modified By column lists the users who have modified the policies or objects. At the policy level, FMC
displays all the user names who have modified the policy. At the rule level, FMC displays the last user who
has modified the rule.
Additionally, to compare any two versions and view the change log, choose the required versions in the
drop-down boxes and click the Show button. Click the Download as PDF button to download a copy of the
change log.

540
HA Scenarios where Preview is not Supported
Note Deployment history preview is not supported for certificate enrollments, HA operations, and failed
deployments.
Note • Deployment history preview is supported for all the deployments done in the FMC 7.0 release
only. Preview is not supported for deployments done prior to 7.0.
• When a device is registered, preview is not supported for the job history record that is created.
• In the deployment history, the last 10 successful deployments, the last 5 failed deployments,
and last 5 rollback deployments are captured.
HA Scenarios where Preview is not Supported

Preview is not supported in the following HA scenarios:
• If a device was in standalone mode and if a chain is made, then an auto-deployment is triggered. For that
particular job, preview is not supported. On hover over the Preview ( ), a message is displayed that it
is a HA bootstrap deployment, and no preview is supported.
• Configuration groups - Consider a flow in which a device was initially standalone. Subsequently, three
deployments took place. In the fourth deployment, the device was a HA bootstrap deployement. After
these, the user deploys devices 5, 6, and 7. The deployment 7 is an HA break deployment, and the user
deploys devices 8, 9, and 10.
In this flow, the preview between 3 and 5 is not supported because 4 was a HA deployment. Similarly,
the preview between 8 and 3 is also not supported. Preview is supported only from 3 to 1, 7,6, 5, 4, and
10, 9, and 8.
• If a device is broken (HA is broken) then the new device is considered as a fresh device.
Deployment Rollback
Rollback is a deployment functionality provided to clear the existing deployment on an FTD device and to
reconfigure the device with the previously deployed configuration.
After a policy deployment, if the traffic through an FTD is affected in an unintended way, rollback provides
an option to revert the device to the earlier state, which existed before the faulty deployment.
When a deployment has gone awry and caused traffic interruption in an unintended way, it is recommended
that you should identify the change in the deployment that has caused the condition, and fix it. To know the
changes in the previous deployment, choose Deploy > Deployment History, expand the last deployed job,
and click the preview icon ( ). The preview page provides an option to compare deployments, which can be
useful to identify specific changes for a deployment compared to a previous deployment. After identifying
the change causing the problem, rectify the configuration, and redeploy it on the device. This is the
recommended approach. However, if the change causing the problem is unidentifiable, roll back to the last
stable deployed version on the device.
After a successful rollback operation, go to Deploy > Deployment, and click the Preview icon next to the
rolled back device. View the changes between the rolled back configuration and the current changes in the
FMC. Identify the change that has caused the issue and rectify it.

541
Deployment Rollback
Rollback reverts all the configurations on the device except a few. See the table below for details.
Configurations that are reverted during a rollback Configurations that are not reverted during a rollback
• All policy configurations • Snort binaries

Note Rollback from Snort 3 to Snort 2
• Interface configurations
version policies and vice versa are
supported.
• SRU configurations
• VDB configurations • Geo DB
• LSP configurations
• VPN configurations
• FXOS configurations
Important • Rollback is a disruptive operation. During this operation, all the existing connections and routes are
dropped, and the traffic is disrupted. Rollback removes the current configuration on all the selected FTD
devices and reconfigures them with the chosen rollback version.
• Initiate a rollback during low traffic conditions for optimal performance.
• Rollback to a particular version can be performed only once.
• Consecutive rollbacks to the same version is not allowed. However, the same version can be selected for
rollback at a later time.
• You can roll back to any one of the last 10 versions before the currently deployed version. Rollback to
versions prior to these are not supported. The rollback icon is greyed out for unsupported versions.
• Two consecutive rollback operations are not allowed. However, you can rollback again after a deployment.
• Rollback reverts the configuration only on the selected FTDs. FMC retains all the changes. With the
configuration changes retained in the FMC, the devices are marked as out-of-date on the FMC after a
rollback operation. To see the changes that are retained in FMC versus the configuration on the device,
go to Deploy > Deployment, and click the Preview icon next to the rolled back device.
• Be cautious of the changes you want to deploy in the first deployment after you have rolled back, as it
would be a full deployment, and you will not be able to roll back to the rolled back version again.
• For FTDs with very large access lists, if the Object Group Search setting is disabled, then the rollback
operation may take a longer duration to complete. To verify the Object Group Search setting, go to
Devices > Device Management, then select the device and click Edit Advanced Settings.

542
Roll Back Deployment on a Device
Note • Rollback is supported only on FTD versions 6.7.0 and above.

• Rollback is not supported on NGIPS devices.
• Rollback is supported for Snort3 policies as well.
• Rollback is not supported if the connection interface between the FMC and the FTD is changed from
management to data or vice versa.
• In Firepower 4100/9300, when interface changes are made from the Firepower Chassis Manager (FCM)
in a previous deployment, then sync the interfaces using the FCM before initiating a rollback. Failing to
do so can cause traffic interruptions.
• Independent certificate enrollments are also listed as deployment jobs in the Deployment History page.
However, you cannot rollback to these versions. A rollback from a deployment version created after
certificate enrolments reverts the certificate associations as well. In the next deployment after a rollback,
manually associate the certificates before proceeding with the deployment.
• Rollback is not supported on the first version after an upgrade of FMC or FTD. For example, if the FMC
is upgraded from 6.7.0 to 6.7.0.1, then you will not be able to roll back to any deployment packages
associated with 6.7.0.
• If a deployment for a device with a FlexConfig object configured with a deployment frequency set to
Once is rolled back, then you will not be able to redeploy the object even though it is displayed as
out-of-date on the Preview page. After a rollback, you will have to manually unassign and then reassign
the FlexConfig object to the device before the next deployment.
Rollback in HA Scenarios
Rollback is not supported in the following HA scenarios:
• When the version you want to roll back to contains the FTD HA bootstrap configuration.
• When the version you want to roll back to contains the FTD HA break configuration.
• When an FTD which is currently in standalone mode, was part of a HA or cluster in the previous
deployment version.
Rollback in Cluster Scenarios

Rollback is not supported if there are multiple control nodes in a cluster.
Roll Back Deployment on a Device
Procedure
Step 1 On the Firepower Management Center menu bar, choose Deploy > Deployment History.
A list of all the previous deployment jobs is displayed in reverse chronological order.
Step 2 Click Rollback.

543
View the Deployment Rollback Transcript
Step 3 Filter the list of devices displayed by either selecting the Job option and choosing a job from the Selected
Job drop-down list, or by selecting Device List.
Step 4 (Optional) Enter the device name in the Search Device search box to filter the device list.
Step 5 Select the device.
Step 6 Choose the version from the Rollback Version drop-down list. The job names and associated deployment
notes are also listed for a particular rollback version.
Step 7 (Optional) Click the preview icon ( ) to view the changes deployed in the selected version.
Step 8 Click Rollback.
What to do next
To know the status of the rollback, choose Deploy > Deployment. You can view the rollback status next to
the device name.
View the Deployment Rollback Transcript

Rollback transcript is a written version of the commands that are sent to the device, along with the responses
returned from the device. If a rollback operation has failed, the transcript in the Deploy > Deployment History
page provides the reason for the failure. However, to know the CLI commands executed for a successful
rollback operation, follow the steps given below after a rollback operation has completed. Note that this
information is available only until the next deployment.
Note The CLI command information is available after a rollback is complete and is available only until the next
deployment. The first deployment after a rollback operation erases all the rollback-related information.
Note For any rollback deployment, the Deployment Notes are updated automatically as Rollback Job. In the
Deployment History page, the user can filter the Rollback Jobs easily using the Search option.
Procedure
Step 1 On the Firepower Management Center menu bar, choose System > Health > Monitor.
Step 2 Select the device, which was rolled back, from the left pane.
Step 3 Click View System & Troubleshooting Details link.
Step 5 Click Threat Defense CLI.
Step 6 Select show from the Command drop-down box.
Step 7 Enter running in the Parameter field.
Step 8 Click Execute.

544
Snort® Restart Scenarios
Snort® Restart Scenarios

When the traffic inspection engine referred to as the Snort process on a managed device restarts, inspection
is interrupted until the process resumes. 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
546 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.
Table 77: Snort Restart Scenarios
Restart Scenario More Information
Deploying a specific configuration that requires the Configurations that Restart the Snort Process When
Snort process to restart. Deployed or Activated, on page 548
Modifying a configuration that immediately restarts Changes that Immediately Restart the Snort Process,
the Snort process. on page 549
Traffic-activation of the currently deployed Automatic Configure Automatic Application Bypass, on page
Application Bypass (AAB) configuration. 387
Related Topics
Access Control Policy Advanced Settings, on page 1628
Configurations that Restart the Snort Process When Deployed or Activated, on page 548
Inspect Traffic During Policy Apply

Inspect traffic during policy apply is an advanced access control policy general setting that allows managed
devices to inspect traffic while deploying configuration changes; this is the case unless a configuration that
you deploy requires the Snort process to restart. You can configure this option as follows:
• Enabled — Traffic is inspected during the deployment unless certain configurations require the Snort
process to restart.
When the configurations you deploy do not require a Snort restart, the system initially uses the currently
deployed access control policy to inspect traffic, and switches during deployment to the access control
policy you are deploying.
• Disabled — Traffic is not inspected during the deployment. The Snort process always restarts when you
deploy.
The following graphic illustrates how Snort restarts can occur when you enable or disable Inspect traffic
during policy apply.

545
Snort® Restart Traffic Behavior

The following tables explain how different devices handle traffic when the Snort process restarts.
Table 78: FTD and FTD Virtual Restart Traffic Effects
Interface Configuration Restart Traffic Behavior
inline: Snort Fail Open: Down: disabled dropped
inline: Snort Fail Open: Down: enabled passed without inspection

Some packets can be delayed in buffer for several
seconds before the system recognizes that Snort is
down. This delay can vary depending upon the load
distribution. However, the buffered packets are
eventually passed.

546
routed, transparent (including EtherChannel, existing TCP/UDP flows: passed without inspection
redundant, subinterface): preserve-connection so long as at least one packet arrives while Snort is
enabled (configure snort preserve-connection down
enable; default)
new TCP/UDP flows and all non-TCP/UDP flows:
For more information, see Cisco Firepower Threat dropped
Defense Command Reference.
Note that the following traffic drops even when
preserve-connection is enabled:
• plaintext, passthrough prefilter tunnel traffic that
matches an Analyze rule action or an Analyze
all tunnel traffic default policy action
• connections that do not match an access control
rule and are instead handled by the default action.
• decrypted TLS/SSL traffic
• a safe search flow
• a captive portal flow
routed, transparent (including EtherChannel, dropped

redundant, subinterface): preserve-connection
disabled (configure snort preserve-connection
disable)
inline: tap mode egress packet immediately, copy bypasses Snort
passive uninterrupted, not inspected
Table 79: NGIPSv Restart Traffic Effects
inline: Failsafe enabled or disabled passed without inspection

A few packets might drop if Failsafe is disabled and
Snort is busy but not down.
inline: tap mode egress packet immediately, copy bypasses Snort
passive uninterrupted, not inspected
Table 80: ASA FirePOWER Restart Traffic Effects
routed or transparent with fail-open passed without inspection
routed or transparent with fail-close dropped

547
Configurations that Restart the Snort Process When Deployed or Activated
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 740) or the Snort Fail Open Busy option (see Configure an Inline
Set, on page 875). 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.
Configurations that Restart the Snort Process When Deployed or Activated

Deploying any of the following configurations except AAB restarts the Snort process as described. Deploying
AAB does not cause a restart, but excessive packet latency activates the currently deployed AAB configuration,
causing a partial restart of the Snort process.
Access Control Policy Advanced Settings

• Deploy when Inspect Traffic During Policy Apply is disabled.
• Add or remove an SSL policy.
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).
• Enable or disable Store files in a Detect Files or Block Files rule.

• Add the first or remove the last active file rule that combines the Malware Cloud Lookup or Block
Malware 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).
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.

548
Changes that Immediately Restart the Snort Process
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: For managed devices running Snort 2, deploying configurations the first time after installing a
vulnerability database (VDB) update that includes changes applicable to managed devices will require
a detection engine restart and may result in a temporary traffic interruption. 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 detection engine restarts, and you
cannot deploy them.
For managed devices running Snort 3, deploying configurations the first time after installing a vulnerability
database (VDB) update may temporarily interrupt application detection, but there will be no traffic
interruptions.
Related Topics
Deploy Configuration Changes, on page 535
Changes that Immediately Restart the Snort Process

The following changes immediately restart the Snort process without going through the deploy process. How
the restart affects traffic depends on how the target device handles traffic. See Snort® Restart Traffic Behavior,
• Take any of the following actions involving applications or application detectors:
• Activate or deactivate a system or custom application detector.

549
Policy Comparison
• Delete an activated custom detector.

• Save and Reactivate an activated custom detector.
• Create a user-defined application.
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.
Procedure
Step 1 Access the management page for the policy you want to compare:
• DNS—Policies > Access Control > DNS
• File—Policies > Access Control > Malware & File

550
Policy Reports
• 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.
• SSL—Policies > Access Control > SSL
Step 2 Click Compare Policies.

Step 3 From the Compare Against drop-down list, choose the type of comparison you want to make:
• To compare two different policies, choose Other Policy.
• To compare two revisions of the same policy, choose Other Revision.
• To compare another policy to the currently active policy, choose Running Configuration.
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.
Step 5 Click OK.

Step 6 Review the comparison results:
• Comparison Viewer—To use the comparison viewer to navigate individually through policy differences,
click Previous or Next above the title bar.
• Comparison Report—To generate a PDF report that lists the differences between the two policies, click
Comparison Report.
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.
Generating Current Policy Reports

You can generate policy reports 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.

551
Out-of-Date Policies
Procedure
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.
• SSL—Policies > Access Control > SSL
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:
• network, port, VLAN tag, URL, and geolocation objects
• Security Intelligence lists and feeds
• application filters or detectors
• intrusion policy variable sets
• file lists
• decryption-related objects and security zones
• 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

552
Performance Considerations for Limited Deployments
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 Do Not Block list using the context menu
• automatic updates to URL filtering data
• scheduled geolocation database (GeoDB) updates
Performance Considerations for Limited Deployments

Host, application, and user discovery data allow the system to create a complete, up-to-the-minute profile of
your network. The system can also act as an intrusion detection and prevention system (IPS), analyzing
network traffic for intrusions and exploits and, optionally, dropping offending packets.
Combining discovery and IPS gives context to your network activity and allows you to take advantage of
many features, including:
• impact flags and indications of compromise, which can tell you which of your hosts are vulnerable to a
particular exploit, attack, or piece of malware
• adaptive profile updates and Firepower recommendations, which allow you to examine traffic differently
depending on the destination host
• correlation, which allows you to respond to intrusions (and other events) differently depending on the
affected host
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.
Discovery Without Intrusion Prevention

The discovery feature allows you to monitor network traffic and determine the number and types of hosts
(including network devices) on your network, as well as the operating systems, active applications, and open
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:

553
Intrusion Prevention Without Discovery
• Do not use the Security Intelligence feature. Remove any populated global Block or Do Not Block 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 2162
Intrusion Prevention Without Discovery

Disabling discovery if you don't need it (for example, in an IPS-only deployment) can improve performance.
To disable discovery you must implement all of these changes:
• Delete all rules from your network discovery policy.
• Use only simple network-based conditions to perform access control: zone, IP address, VLAN tag, and
port.
Do not perform any kind of Security Intelligence, application, user, URL, or geolocation control. Although
you can disable storage of discovery data, the system still must collect and examine it to implement those
features.
• Disable network and URL-based Security Intelligence by deleting all Block and Do Not 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 Do-Not-Block 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.

554
History for Policy Management

Deployment preview and user 7.0 The Deployment page has the
information in preview following newly added features:
• On the Deploymentpage, the
Modified By column lists the
users who have modified the
policies against each policy
listing.
• Filter support for deployment
– The Filter icon provided on
the Deployment page
provides an option to filter the
device listings that are
pending deployment. The
Filter icon provides options to
filter the listings based on
selected devices and user
names.
• Deployment History Preview–
Click Preview to view the
policy and object changes
deployed on the device versus
the previously deployed
version. In the deployment
history, the last 10 successful
deployments, the last five
failed deployments, and last
five rollback deployments are
captured.
• Deployment Notes – The
Deployment Notes are
custom and optional notes that
a user can add as part of
deployment. You can view the
Deployment Notes column in
the Deployment Historypage.
• Deployment rollback is
available for Snort 3 policies
as well.

Management Center

555
Rollback deployment on an FTD 6.7 Rollback is a deployment

device functionality provided to remove
the existing deployment on an FTD
device and to reconfigure the
device with the previously deployed
configuration.
New/modified pages: The Deploy >
Deployment History page provides
a new Rollback column with the
rollback icons. Similar rollback
icons can also be found when the
jobs are expanded, to initiate
rollback at the device level.
Management Center

556
Revamp of the deploy section in 6.6

the Firepower Management Center.

557

The Deploy button on the FMC
menu bar is changed to Deploy
menu. There are two new sub-menu
options under it. These are
Deployment and Deployment
History. The Deployment page has
undergone an improvement along
with newly added features, and the
new Deployment History page
provides a legend of all the
previous deployments.
The Deployment page has the
following newly added features:
• Deployment status - On the
Deployment page, the Status
column provides the
deployment status for each
device.
• Deployment estimate - The
Estimate link is available on
the Deployment page after you
select a device, a policy, or a
configuration. The Estimate
link provides an estimate of
the deployment duration once
clicked.
• 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.
• Selective policy deployment -
FMC allows you to select a
specific policy within the list
of all the changes on the
device that are due for
deployment and deploy only
the selected policy.

558

Management Center

559

560
CHAPTER 22
Rule Management: Common Characteristics
The following topics describe how to manage common characteristics of rules in various policies on the
Firepower Management Center:
• Requirements and Prerequisites for Rule Management, on page 561
• Introduction to Rules, on page 561
• Rule Condition Types, on page 563
• Apply Rules Based on Day and Time, on page 593
• Searching for Rules, on page 594
• Filtering Rules by Device, on page 594
• Identify Rules with Issues, on page 595
• Rule and Other Policy Warnings, on page 596
• History for Rule Management: Common Characteristics, on page 597
Requirements and Prerequisites for Rule Management

Model Support
Any.
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.

561
Introduction to Rules
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.
Rules with Shared Characteristics

This chapter documents many common aspects of the following rules and configurations. For information on
non-shared configurations, see:
• Access control rules: Access Control Rules, on page 1637
• Prefilter rules: Tunnel and Prefilter Rule Components, on page 1717
• Tunnel rules: Tunnel and Prefilter Rule Components, on page 1717
• SSL rules: Creating and Modifying TLS/SSL Rules, on page 1790
• DNS rules: Creating and Editing DNS Rules, on page 1702
• Identity rules: Create an Identity Rule, on page 2489
• Network analysis rules: Configuring Network Analysis Rules, on page 2165
• QoS rules: Configuring QoS Rules, on page 900
• Intelligent Application Bypass (IAB): Intelligent Application Bypass, on page 1729

562
Rule Condition Types
• Application filters: Application Filters, on page 616
Rules without Shared Characteristics

Rules whose configurations are not documented in this chapter include:
• Intrusion rules: Tuning Intrusion Policies Using Rules, on page 1977
• File and malware rules: File Rules, on page 1864
• Correlation rules: Configuring Correlation Rules, on page 2541
• NAT rules (Firepower Threat Defense): Network Address Translation (NAT) for Firepower Threat
Defense, on page 1489

The following table describes the common rule conditions documented in this chapter, and lists the
configurations where they are used.
Condition Controls Traffic By... Supported Rules/Configurations
Interface Conditions, on page 566 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 568 Source and destination IP address, Access control rules
and where supported, geographical
Prefilter rules
location or originating client
SSL rules
DNS rules
Identity rules
QoS rules
Tunnel Endpoint Conditions, on Source and destination tunnel Tunnel rules

page 571 endpoints for plaintext, passthrough
tunnels

563
VLAN Conditions, on page 572 VLAN tag Access control rules

Note VLAN tags in access
rules only apply to
inline sets; they cannot
be used in access rules
applied to firewall
interfaces.
Tunnel rules
Prefilter rules
SSL rules
DNS rules
Identity rules
Port and ICMP Code Conditions, Source and destination ports, Access control rules
on page 573 protocols, and ICMP codes
Prefilter rules
SSL rules
Identity rules
QoS rules
Encapsulation Conditions, on page Encapsulation protocol Tunnel rules

575 (nonencrypted)
Application Conditions Application or application Access control rules

(Application Control), on page 575 characteristic (type, risk, business
SSL rules
relevance, category, and tags)
Identity rules
QoS rules
Application filters
Intelligent Application Bypass
(IAB)
URL Conditions (URL Filtering), URL, and where supported, URL Access control rules
on page 585 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)
585 ISE attributes
QoS rules

564
Rule Condition Mechanics
External Attributes Conditions, on Custom Security Group Tag (SGT) Access control rules
page 590
Dynamic Objects QoS rules (SGT only)
Rule Condition Mechanics

Rule conditions specify the traffic that each rule handles. You can configure each rule with multiple conditions,
and traffic must match all conditions to match the rule. The available condition types depend on the rule type.
In rule editors, each condition type has its own tab page. Build conditions by choosing the traffic characteristics
you want to match. In general, choose criteria from one or two lists of available items on the left, then add or
combine those criteria into one or two lists of selected items on the right. For example, in URL conditions in
access control rules, you can combine URL category and reputation criteria to create a single group of websites
to block.
To help you build conditions, you can match traffic using various system-provided and custom configurations,
including realms, ISE attributes, and various types of objects and object groups. Often, you can manually
specify rule criteria.
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 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.
Source and Destination Criteria

Where a rule involves source and destination criteria (zones, networks, ports), usually you can use either or
both criteria as constraints. If you use both, matching traffic must originate from one of the specified source
zones, networks, or ports and leave through one of the destination zones, networks, or ports.
Items per Condition

You can add up to 50 items to each condition. For rules with source and destination criteria, you can use up
to 50 of each. Traffic that matches any of the selected items matches the condition.
Simple Rule Mechanics

In rule editors, you have the following general choices. For detailed instructions on building conditions, see
the topics for each condition type.

565
Interface Conditions
• 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 620.
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.
Tunnel Zones vs Security Zones

In some configurations, you can use tunnel zones instead of security zones to constrain interface conditions.
Tunnel zones allow you to use prefiltering to tailor subsequent traffic handling to certain types of encapsulated
connections.
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 1718.

566
Configuring Interface Conditions
Rules with Interface Conditions
Rule Type Supports Security Zones? Supports Tunnel Zones? Supports Interface
Groups?
Access control yes yes no
Tunnel and prefilter yes n/a; you assign tunnel yes

zones in the prefilter
policy
SSL yes no no
DNS (source only) yes no no
Identity yes no no
Network analysis yes no no
QoS (routed only, yes no yes

required)
Example: Access Control Using Security Zones

Consider a deployment where you want hosts to have unrestricted access to the internet, but you
nevertheless want to protect them by inspecting incoming traffic for intrusions and malware.
First, create two security zones: Internal and External. Then, assign interface pairs on one or more
devices to those zones, with one interface in each pair in the Internal zone and one in the External
zone. Hosts connected to the network on the Internal side represent your protected assets.
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.
Configuring Interface Conditions
Before you begin

• (Access control only) If you want to constrain traffic by tunnel zones instead of security zones, make
sure the associated prefilter policy assigns those zones; see Associating Other Policies with Access
Control, on page 1632.

567
Network Conditions
Procedure
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 1718.
Step 3 Click Add to Source or Add to Destination, or drag and drop.

Step 4 Save or continue editing the rule.
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 1719.
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.
Geolocation in Network Conditions

Some rules can match traffic using the geographical location of the source or destination. If a rule type supports
geolocation, you can mix network and geolocation criteria. To ensure you are using up-to-date geolocation
data to filter your traffic, Cisco strongly recommends you regularly update the geolocation database (GeoDB).

568
Configuring Network Conditions
Original Client in Network Conditions (Filtering Proxied Traffic)

For some rules, you can handle proxied traffic based on the originating client. Use a source network condition
to specify proxy servers, then add an original client constraint to specify original client IP addresses. The
system uses a packet's X-Forwarded-For (XFF), True-Client-IP, or custom-defined HTTP header field to
determine original client IP.
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
Rules with Network Conditions
Rule Type Supports Geolocation Constrains? Supports Original Client Constraints?
Access control yes yes
Prefilter no no
SSL yes no
DNS (source networks no no

only)
Identity yes no
Network analysis no no
QoS yes yes
Procedure
Step 1 In the rule editor, click Networks.

569
Step 2 Find and choose the predefined networks you want to add from the Available Networks list.
If the rule supports geolocation, you can mix network and geolocation criteria in the same rule:
• Networks—Click Networks to choose networks.
• Geolocation—Click Geolocation to choose geolocation objects.
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:
• Source/Proxy—Click Source to specify proxy servers.
• Original Client—Click Original Client to add a network as an original client constraint. In proxied
connections, the original client's IP address must match one of these networks to match the rule.
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.
Example: Network Condition in an Access Control Rule

The following graphic shows the network condition for an access control rule that blocks connections
originating from your internal network and attempting to access resources either in North Korea or
on 93.184.216.119 (example.com).
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.

570
Tunnel Endpoint Conditions
What to do next
Tunnel Endpoint Conditions

Tunnel endpoint conditions are specific to tunnel rules. They are similar to the network conditions for other
rule types.
Tunnel endpoint conditions control certain types of plaintext, passthrough tunnels (see Encapsulation Conditions,
on page 575) by their source and destination IP address, using outer encapsulation headers. These are the IP
addresses of the tunnel endpoints—the routed interfaces of the network devices on either side of the tunnel.
Tunnel rules are bidirectional by default, and handle all matching tunnels between any of the source endpoints
and any of the destination endpoints. However, you can configure unidirectional tunnel rules that match
source-to-destination traffic only; see Tunnel and Prefilter Rule Components, on page 1717.
You can use predefined network objects to build tunnel endpoint conditions, or manually specify individual
IP addresses or address blocks.
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.
Configuring Tunnel Endpoint Conditions

Tunnel endpoint conditions apply to Firepower Threat Defense devices only.
Procedure
Step 1 In the rule editor, click Tunnel Endpoints.

Step 2 Find and choose the predefined networks you want to add from the Available Tunnel Endpoints list.
Because tunnel endpoints are simply the IP addresses of the routed interfaces of the network devices on either
side of the tunnel, you can use network objects to build tunnel endpoint conditions.

Tunnel rules are bidirectional by default so they can handle all traffic between the two endpoints. However,
if you choose to Match tunnels only from source, the tunnel rule matches source-to-destination traffic only.
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.

571
VLAN Conditions
What to do next
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.
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.
Rules with VLAN Conditions

The folllowing rule types support VLAN conditions:
• Access control
Note VLAN tags in access rules only apply to inline sets; they cannot be used in access
rules applied to firewall interfaces.
• Tunnel and prefilter (uses outermost VLAN tag)

• SSL
• DNS

572
Port and ICMP Code Conditions
• Identity
• Network analysis
Port and ICMP Code Conditions

Port conditions allow you to control traffic by its source and destination ports. Depending on the rule type,
“port” can represent any of the following:
• TCP and UDP—You can control TCP and UDP traffic based on the transport layer protocol. The system
represents this configuration using the protocol number in parentheses, plus an optional associated port
or port range. For example: TCP(6)/22.
• ICMP—You can control ICMP and ICMPv6 (IPv6-ICMP) traffic based on its internet layer protocol
plus an optional type and code. For example: ICMP(1):3:3.
• No port—You can control traffic using other protocols that do not use ports.
Best Practices for Port-Based Rules

Specifying ports is the traditional way to target applications. However, applications can be configured to use
unique ports to bypass access control blocks. Thus, whenever possible, use application filtering criteria rather
than port criteria to target traffic.
Application filtering is also recommended for applications, like FTD, that open separate channels dynamically
for control vs. data flow. Using port-based access control rules can prevent these kinds of applications from
performing correctly, and could result in blocking desirable connections.
Using Source and Destination Port Constraints

If you add both source and destination port constraints, you can only add ports that share a single transport
protocol (TCP or UDP). For example, if you add DNS over TCP as a source port, you can add Yahoo Messenger
Voice Chat (TCP) as a destination port but not Yahoo Messenger Voice Chat (UDP).
If you add only source ports or only destination ports, you can add ports that use different transport protocols.
For example, you can add both DNS over TCP and DNS over UDP as source port conditions in a single access
control rule.
Matching Non-TCP Traffic with Port Conditions

Although you can configure port conditions to match non-TCP traffic, there are some restrictions:
• Access control rules—For Classic devices, you can match GRE-encapsulated traffic with an access
control rule by using the GRE (47) protocol as a destination port condition. To a GRE-constrained rule,
you can add only network-based conditions: zone, IP address, port, and VLAN tag. Also, the system
uses outer headers to match all traffic in access control policies with GRE-constrained rules. For Firepower
Threat Defense devices, use tunnel rules in the prefilter policy to control GRE-encapsulated traffic.
• SSL rules—SSL rules support TCP port conditions only.

573
Configuring Port Conditions
•
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 546 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.
Rules with Port Conditions

The following rules support port conditions:
• Access control
• Prefilter
• SSL (supports TCP traffic only)
• Identity (active authentication supports TCP traffic only)
• QoS
Configuring Port Conditions
Procedure
Step 1 In the rule editor, click Ports.

Step 2 Find and choose the predefined ports you want to add from the Available Ports list.
Step 4 Add any source or destination ports that you want to specify manually:
• Source—Choose a Protocol, enter a single Port from 0 to 65535, and click Add.
• Destination (non-ICMP)—Choose or enter a Protocol. If you do not want to specify a protocol, or if you
choose TCP or UDP, enter a single Port from 0 to 65535. Click Add.
• Destination (ICMP)—Choose ICMP or IPv6-ICMP from the Protocol drop down list, then choose a
Type and related Code in the pop-up window that appears. For more information on ICMP types and
codes, see the Internet Assigned Numbers Authority (IANA) website.

574
Encapsulation Conditions
What to do next
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)
Application Conditions (Application Control)

When the system analyzes IP traffic, it can identify and classify the commonly used applications on your
network. This discovery-based application awareness is the basis for application control—the ability to
control application traffic.
System-provided application filters help you perform application control by organizing applications according
to basic characteristics: type, risk, business relevance, category, and tags. You can create reuseable user-defined
filters based on combinations of the system-provided filters, or on custom combinations of applications.
At least one detector must be enabled for each application rule condition in the policy. If no detector is enabled
for an application, the system automatically enables all system-provided detectors for the application; if none
exist, the system enables the most recently modified user-defined detector for the application. For more
information about application detectors, see Application Detector Fundamentals, on page 2392.
You can use both application filters and individually specified applications to ensure complete coverage.
However, understand the following note before you order your access control rules.
As part of application control, you can also use access control rules to enforce content restriction (such as
Safe Search and YouTube EDU).

575
Configuring Application Conditions and Filters
Benefits of Application Filters

Application filters help you quickly configure application control. For example, you can easily use
system-provided filters to create an access control rule that identifies and blocks all high risk, low business
relevance applications. If a user attempts to use one of those applications, the system blocks the session.
Using application filters simplifies policy creation and administration. It assures you that the system controls
application traffic as expected. Because Cisco frequently updates and adds application detectors via system
and vulnerability database (VDB) updates, you can ensure that the system uses up-to-date detectors to monitor
application traffic. You can also create your own detectors and assign characteristics to the applications they
detect, automatically adding them to existing filters.
Configurations with Application Conditions

The configurations in the following table help you perform application control. The table also shows how you
can constrain application control, depending on the configuration.
Configuration Type, Risk, Tags User-Defined Filters Content Restriction

Relevance,
Category
Access control rules yes yes yes yes
SSL rules yes no; automatically no no

constrained to
encrypted application
traffic by the SSL
Protocol tag
Identity rules (to yes no; automatically no no

exempt applications constrained by the
from active User-Agent
authentication) Exclusion tag
QoS rules yes yes yes no
User-defined yes yes no; you cannot nest no

application filter in user-defined filters
the object manager
Intelligent yes yes yes no

Application Bypass
(IAB)
Related Topics
Overview: Application Detection, on page 2391

To build an application condition or filter, choose the applications whose traffic you want to control from a
list of available applications. Optionally (and recommended), constrain the available applications using filters.
You can use filters and individually specified applications in the same condition.

576
Before you begin

• Adaptive profiling must be enabled (its default state) as described in Configuring Adaptive Profiles, on
page 2324 for access control rules to perform application control.
• For Classic device models, you must have the Control license to configure these conditions.
Procedure
Step 1 Invoke the rule or configuration editor:

• Access control, SSL, QoS rule condition—In the rule editor, click Applications.
• Identity rule condition—In the rule editor, click Realms & Settings and enable active authentication;
see Create an Identity Rule, on page 2489.
• Application filter—On the Application Filters page of the object manager, add or edit an application
filter. Provide a unique Name for the filter.
• Intelligent Application Bypass (IAB)—In the access control policy editor, click Advanced, edit IAB
settings, then click Bypassable Applications and Filters.
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 1739.
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.
Step 4 Click Add to Rule, or drag and drop.

Tip Before you add more filters and applications, click Clear Filters to clear your current choices.

577
Application Characteristics
The web interface lists filters added to a condition above and separately from individually added applications.
Step 5 Save or continue editing the rule or configuration.
Example: Application Condition in an Access Control Rule

The following graphic shows the application condition for an access control rule that blocks a
user-defined application filter for MyCompany, all applications with high risk and low business
relevance, gaming applications, and some individually selected applications.
What to do next
Application Characteristics
The system characterizes each application that it detects using the criteria described in the following table.
Use these characteristics as application filters.
Table 81: Application Characteristics
Characteristic Description Example
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.

578
Best Practices for Application Control
Characteristic Description Example
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.

Keep in mind the following guidelines and limitations for application control:
Ensuring that Adaptive Profiling is Enabled

If adaptive profiling is not enabled (its default state), access control rules cannot perform application control.
Automatically Enabling Application Detectors

If no detector is enabled for an application you want to detect, the system automatically enables all
system-provided detectors for the application. If none exist, the system enables the most recently modified
user-defined detector for the application.
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 2162.
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.
Create Separate Rules for URL and Application Filtering

Create separate rules for URL and application filtering whenever possible, because combining application
and URL criteria can lead to unexpected results, especially for encrypted traffic.

579
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.
URL Rules Before Application and Other Rules

For the most effective URL matching, place rules that include URL conditions before other rules, particularly
if the URL rules are block rules and the other rules meet both of the following criteria:
• They include application conditions.
• The traffic to be inspected is encrypted.
Application Control for Encrypted and Decrypted Traffic

The system can identify and filter encrypted and decrypted traffic:
• Encrypted traffic—The system can detect application traffic encrypted with StartTLS, including SMTPS,
POPS, FTPS, TelnetS, and IMAPS. In addition, it can identify certain encrypted applications based on
the Server Name Indication in the TLS ClientHello message, or the subject distinguished name value
from the server certificate. These applications are tagged SSL Protocol; in an SSL rule, you can
choose only these applications. Applications without this tag can only be detected in unencrypted or
decrypted traffic.
• Decrypted traffic—The system assigns the decrypted traffic tag to applications that the system
can detect in decrypted traffic only, not encrypted or unencrypted.
TLS Server Identity Discovery and Application Control

The latest version of the Transport Layer Security (TLS) protocol 1.3, defined by RFC 8446, is the preferred
protocol for many web servers to provide secure communications. Because the TLS 1.3 protocol encrypts the
server's certificate for additional security, and the certificate is needed to match application and URL filtering
criteria in access control rules, the Firepower System provides a way to extract the server certificate without
decrypting the entire packet.
We strongly recommend enabling it for any traffic you want to match on application or URL criteria, especially
if you want to perform deep inspection of that traffic. An SSL policy is not required because traffic is not
decrypted in the process of extracting the server certificate.
For more information, see Access Control Policy Advanced Settings, on page 1628.
Exempting Applications from Active Authorization

In an identity policy, you can exempt certain applications from active authentication, allowing traffic to
continue to access control. These applications are tagged User-Agent Exclusion. In an identity rule,
you can choose only these applications.
Handling Application Traffic Packets Without Payloads

When performing access control, the system applies the default policy action to packets that do not have a
payload in a connection where an application is identified.

580
Best Practices for Configuring Application Control
Handling Referred Application Traffic

To handle traffic referred by a web server, such as advertisement traffic, match the referred application rather
than the referring application.
Controlling Application Traffic That Uses Multiple Protocols (Skype, Zoho)

Some applications use multiple protocols. To control their traffic, make sure your access control policy covers
all relevant options. For example:
• Skype—To control Skype traffic, choose the Skype tag from the Application Filters list rather than
selecting individual applications. This ensures that the system can detect and control all Skype traffic
the same way.
• Zoho—To control Zoho mail, choose both Zoho and Zoho mail from the Available Application list.
Search Engines Supported for Content Restriction Features

The system supports Safe Search filtering for specific search engines only. The system assigns the
safesearch supported tag to application traffic from these search engines.
Controlling Evasive Application Traffic

See Application-Specific Notes and Limitations, on page 582.
Additional Guidelines for Rule Ordering for Application Control

For guidelines about rule ordering for application control, see Best Practices for Configuring Application
Control, on page 581.
Related Topics
Inspection of Packets That Pass Before Traffic Is Identified, on page 2162
Special Considerations for Application Detection, on page 2395
Best Practices for Configuring Application Control

We recommend controlling applications' access to the network as follows:
• To allow or block application access from a less secure network to a more secure network: Use Port
(Selected Destination Port) conditions on the access control rule
For example, allow ICMP traffic from the internet (less secure) to an internal network (more secure.)
• To allow or block applications being accessed by user groups: Use Application conditions on the access
control rule
For example, block Facebook from being accessed by members of the Contractors group

581
Application-Specific Notes and Limitations
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
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)
Application-Specific Notes and Limitations

• Office 365 Admin Portal:
Limitation: If the access policy has logging enabled at the beginning as well as at the end, the first packet
will be detected as Office 365 and the end of connection will be detected as Office 365 Admin Portal.
This should not affect blocking.

582
Troubleshoot Application Control Rules
• Skype:
See Best Practices for Application Control, on page 579
• GoToMeeting
In order to fully detect GoToMeeting, your rule must include all of the following applications:
• GoToMeeting
• Citrix Online
• Citrix GoToMeeting Platform
• LogMeIn
• STUN
• Zoho:
See Best Practices for Application Control, on page 579
• 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.

If your application control rules don't function as you expect, use the guidelines discussed in this section.
We recommend controlling applications' access to the network as follows:
• To allow or block application access from a less secure network to a more secure network: Use Port
(Selected Destination Port) conditions on the access control rule
For example, allow ICMP traffic from the internet (less secure) to an internal network (more secure.)
• To allow or block applications being accessed by user groups: Use Application conditions on the access
control rule
For example, block Facebook from being accessed by members of the Contractors group

583
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
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
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)
Initial Packets Are Passing Uninspected

See Inspection of Packets That Pass Before Traffic Is Identified, on page 2162 and subtopics.
Related Topics
Best Practices for Ordering Rules, on page 1610

584
URL Conditions (URL Filtering)
URL Conditions (URL Filtering)

Use URL conditions to control the websites that users on your network can access.
For complete information, see URL Filtering, on page 1655.
User, Realm, and ISE Attribute Conditions (User Control)

You can perform user control with the authoritative user identity data collected by the Firepower System.
Identity sources monitor users as they log in and out, or as they authenticate using Microsoft Active Directory
(AD) or LDAP credentials. You can then configure rules that use this collected identity data to handle traffic
based on the logged-in authoritative user associated with a monitored host. A user remains associated with a
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 2338.
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 591.
Rules with User Conditions
Rule Type Supports User and Realm Conditions? Supports ISE Attribute Conditions?
Access control yes yes
SSL yes no
QoS yes yes

SGT matching is supported only as source
matching criteria, not destination matching
criteria

585
User Control Prerequisites
Related Topics
The ISE/ISE-PIC Identity Source, on page 2447
The Terminal Services (TS) Agent Identity Source, on page 2483
The Captive Portal Identity Source, on page 2465
User Control Prerequisites
Configure Identity Sources/Authentication Methods

Configure identity sources for the types of authentication you want to perform. For more information, see
About User Identity Sources, on page 2338.
If you configure an ISE/ISE/PIC 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 and TS
Agent servers, and perform a user download. For more information, see Create a Realm and Realm Directory,
on page 2418.
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.
Create Identity Policies

Create an identity policy to associate the realm with an authentication method, and associate that policy with
access control. For more information, see Create an Identity Policy, on page 2492.
Policies that perform user control on a device (access control, SSL, QoS) share an identity policy. That identity
policy determines the realms, users, and groups that you can use in rules affecting traffic on those devices.
Before you configure a user condition in a QoS rule, you must make sure the devices targeted by the QoS
policy are using the correct identity policy, as defined in the access control policy deployed to the devices.
Because the QoS policy and access control policy deployed to the same device are not explicitly linked, the
QoS rule editor can allow you to choose invalid realms, users, and groups. These invalid elements are those
from identity policies that exist on the Firepower Management Center, but that are not applied to the
QoS-targeted devices. If you use these elements, the system cannot determine that you made an invalid choice
until deploy-time.

586
Configuring User and Realm Conditions
Configuring User and Realm Conditions

You can constrain a rule by realm, or by users and user groups within that realm.
Before you begin

• Fulfill the user control prerequsities described in User, Realm, and ISE Attribute Conditions (User
Control), on page 585.
Procedure
Step 1 In the rule editor, click Users.

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.
What to do next
Configuring ISE Attribute Conditions
Before you begin

• Fulfill the user control prerequisites described in User, Realm, and ISE Attribute Conditions (User
Control), on page 585.
Procedure
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 591.
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)
• QoS—Click ISE Attributes.

587
Troubleshoot User Control
• Location IP (also referred to as Endpoint Location)
Step 3 Further constrain the rule by choosing attribute metadata from the Available Metadata list. Or, keep the
default: any.
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
Troubleshoot User Control

If you notice unexpected user rule behavior, consider tuning your rule, identity source, or realm configurations.
For other related troubleshooting information, see:
• Troubleshoot the ISE/ISE-PIC or Cisco TrustSec Issues, on page 2461
• Troubleshoot the TS Agent Identity Source, on page 2484
• Troubleshoot the Captive Portal Identity Source, on page 2477
• Troubleshoot Realms and User Downloads, on page 2438
Rules targeting realms, users, or user groups are not matching traffic
If you configure a TS 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.

588
External Attributes 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 Agentor 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.
Rules are not matching all ISE users

This is expected behavior. You can perform user control on ISE users who were authenticated by an Active
Directory domain controller. You cannot perform user control on ISE users who were authenticated by an
LDAP, RADIUS, or RSA domain controller.
Rules are not matching all ISE/ISE-PIC users

This is expected behavior. You can perform user control on ISE/ISE-PIC users who were authenticated by
an Active Directory domain controller. You cannot perform user control on ISE/ISE-PIC users who were
authenticated by an LDAP, RADIUS, or RSA domain controller.
Users and groups using too much memory

If processing users and groups is using too much memory, health alerts are displayed. Remember that all user
sessions are propagated to all devices managed by an FMC. If your FMC manages devices with different
amounts of memory, the device with the least amount of memory determines the number of user sessions the
system can handle without errors.
If issues persist, you have the following options:
• Segregate lower capacity managed devices on subnets and configure ISE/ISE-PIC to not report passive
authentication data to those subnets.
See the chapter on managing network devices in the Cisco Identity Services Engine Administrator Guide.
• Unsubscribe from Security Group Tags (SGTs).
For more information, see Configure ISE/ISE-PIC for User Control, on page 2458.
• Upgrade your managed device to a model with more memory.

External attributes include the following:
• Dynamic objects
• SGT objects
• Location IP objects

589
• Device type objects

• Endpoint profile objects
External attributes can be used as source criteria and destination criteria in access control rules. Use the
following guidelines:
• Objects of different types are ANDd together
• Objects of a similar type are ORd together
For example, if you choose source destination criteria SGT 1, SGT 2, and device type 1; the rule is matched
if device type 1 is detected on either SGT 1 or SGT 2.
Related Topics
Configure External Attributes Conditions, on page 590

You can define any of the following dynamic attribute conditions in access control rules:
• Custom SGT Conditions, on page 591
• External Attributes Conditions, on page 589
Configure External Attributes Conditions

When you configure external attributes for an access control rule, objects of the same type are ORd together
and objects of different types are ANDd together. An example is shown at the end of this topic.
Before you begin

Create some dynamic objects and understand how those objects are used in access control policy.
For more information about dynamic objects, see About Dynamic Objects, on page 679.
For more information about how dynamic objects are used in access control policy, see External Attributes
Conditions, on page 589
Procedure
Step 1 In the rule editor, click External Attributes.

Step 2 Do any of the following in the Available Attributes section:
• Enter part of all of the name of an attribute in the field.
• Click Security Group Tag or Dynamic Objects to view only objects of that type.
Step 3 To apply the objects you selected to source matching criteria, click Add to Source.
Step 4 To apply the objects you selected to destination matching criteria, click Add to Destination.
Step 5 When you're finished configuring the rule, click Save.

590
Custom SGT Conditions
Example: Using multiple source conditions in a block rule

The following example blocks traffic from Security Group Tags Contractors or Guests; and device
types Android or Blackberry from accessing the dynamic object __azure1.
What to do next
Custom SGT Conditions

If you do not configure ISE/ISE-PIC as an identity source, you can control traffic using Security Group Tags
(SGTs) that were not assigned by ISE. SGTs specify the privileges of traffic sources within a trusted network.
Custom SGT rule conditions use manually created SGT objects to filter traffic, rather than ISE SGTs obtained
from the system's connection to an ISE server. These manually created SGT objects correspond to the SGT
attributes on the traffic you want to control. Controlling traffic using custom SGTs is not considered user
control.
Rules with Custom SGT Conditions

The following rules support custom SGT conditions:
• Access control
• QoS

591
ISE SGT vs Custom SGT Rule Conditions
ISE SGT vs Custom SGT Rule Conditions

Some rules allow you to control traffic based on assigned SGT. Depending on the rule type and your identity
source configuration, you can use either ISE-assigned SGTs or custom SGTs to match traffic with assigned
SGT attributes.
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.
Condition Type Requires SGTs Listed in Rule Editor
ISE SGT ISE identity source SGTs obtained by querying the ISE server, with
automatically updated metadata
Custom SGT No ISE/ISE-PIC identity Static SGT objects you create

source
Related Topics
User, Realm, and ISE Attribute Conditions (User Control), on page 585
Autotransition from Custom SGTs to ISE SGTs

If you create rules that match custom SGTs, then configure ISE/ISE-PIC as an identity source, the system:
• Disables Security Group Tag options in the object manager. Although the system retains existing SGT
objects, you cannot modify them or add new ones.
• Retains existing rules with custom SGT conditions. However, these rules do not match traffic. You also
cannot add additional custom SGT criteria to existing rules, or create new rules with custom SGT
conditions.
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 2458
Configuring Custom SGT Conditions

The following procedure describes how to filter 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/ISE-PIC as an identity source;
see ISE SGT vs Custom SGT Rule Conditions, on page 592.
Before you begin

• Disable ISE/ISE-PIC connections. Custom SGT matching does not work if you use ISE/ISE-PIC as an
identity source.
• Configure Security Group Tag objects that correspond with the SGTs you want to match; see Creating
Security Group Tag Objects, on page 617.

592
Troubleshooting Custom SGT Conditions
Procedure
Step 1 In the rule editor, click SGT/ISE Attributes.

Step 2 Choose Security Group Tag from the Available Attributes list.
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
Troubleshooting Custom SGT Conditions

If you notice unexpected rule behavior, consider tuning your custom SGT object configuration.
Security Group Tag objects unavailable

Custom SGT objects are only available if you do not configure ISE/ISE-PIC as an identity source. For more
information, see Autotransition from Custom SGTs to ISE SGTs, on page 592.
Apply Rules Based on Day and Time

In the following types of policies, you can apply rules depending on day and time:
• Access control
• Prefilter
• VPN Group
You can specify a continuous time range or a recurring time period.

For example, a rule can apply only during weekday working hours, or every weekend, or during a holiday
shutdown period.
Time-based rules are applied based on the local time of the device that processes the traffic.
Time-based rules are supported only on FTD devices. If you assign a policy with a time-based rule to a different
type of device, the time restriction associated with the rule is ignored on that device. You will see warnings
in this case.
Procedure
Step 1 (Optional) Assign a local time zone to each device. By default, devices use the UTC time zone.

593
Searching for Rules
Go to Devices > Platform Settings and create and assign time zone objects.
Step 2 Specify applicable time ranges in supported rules:

While configuring a rule, create and select a time range object.
Step 3 Deploy changes.
Searching for Rules

In many policies, you can search for and within rules. The system matches your input to rule names and
condition values, including objects and object groups.
You cannot search for values in a Security Intelligence or URL list or feed.
Procedure
Step 1 In the policy editor, click Rules.

Step 2 (Access control rules only) Click Search Rules, enter a complete or partial search string into one or more
fields, then press Enter.
If you enter criteria in multiple fields, search results will include rules that match all entered criteria (a logical
"AND" search.)
To include multiple search criteria in a single field, separate values with a comma. Search results will include
rules matching any of the entered values (a logical "OR" search.)
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.
Filtering Rules by Device

Some policy editors allow you to filter your rule view by affected devices.
Filter by device only works for rules that use zones or interface groups. (Otherwise a rule applies to all devices.)

594
Identify Rules with Issues
The system uses a rule's interface constraints to determine if the rule affects a device. If you constrain a rule
by interface (security zone or interface group condition), the device where that interface is located is affected
by that rule. Rules with no interface constraint apply to any interface, and therefore every device.
QoS rules are always constrained by interface.
Procedure
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.
Step 3 Click OK.
Related Topics
Create and Edit Access Control Rules, on page 1643
Configure Prefiltering, on page 1714
Configuring QoS Rules, on page 900
Configure NAT for Threat Defense, on page 1503
Identify Rules with Issues

The system will flag each rule that will prevent deploy (these are marked with a red icon) or that will never
match traffic because another rule above it in the rule order will match instead (these are marked with a yellow
icon).
Important The system does not flag rules that partially match other rules, which may also prevent some subsequent rules
from matching.
Procedure
Step 1 Select Policies > Access Control > Access Control.

Step 2 Click a policy name.
Step 3 Do one or both of the following:
• Look for Show Warnings near the top of the window.
If the system has not identified issues, this button will not appear.

595
Rule and Other Policy Warnings
If there are issues, click this button to open a list of all rules with issues.
To see all issues, click both tabs (Rule Errors and Rule Warnings).
To locate a rule in the table of rules below, click the rule name in the error or warnings list.
• Select the Show Rule Conflicts check box.
This will indicate each problem rule in the list with an Error (red) or Warning (yellow).
If necessary, scroll down to see all rules in the policy.
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.
Rule and Other Policy Warnings

Policy and rule editors use icons to mark configurations that could adversely affect traffic analysis and flow.
Depending on the issue, the system may warn you when you deploy or prevent you from deploying entirely.
Tip Hover your pointer over an icon to read the warning, error, or informational text.
Table 82: Policy Error Icons
Icon Description Example
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.

596
History for Rule Management: Common Characteristics
Icon Description Example
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 579
Best Practices for URL Filtering, on page 1657

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.
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.

597
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 1655.

598
CHAPTER 23
Reusable Objects
The following topics describe how to manage reusable objects in the Firepower System:
• Introduction to Reusable Objects, on page 600
• The Object Manager, on page 602
• Network Objects, on page 612
• Port Objects, on page 614
• Tunnel Zones, on page 616
• Application Filters, on page 616
• VLAN Tag Objects, on page 616
• Security Group Tag Objects, on page 617
• URL Objects, on page 618
• Geolocation Objects, on page 619
• Interface Objects: Interface Groups and Security Zones, on page 620
• Time Range Objects, on page 622
• Time Zone Object, on page 623
• Variable Sets, on page 623
• Security Intelligence Lists and Feeds, on page 638
• Sinkhole Objects, on page 650
• File Lists, on page 651
• Cipher Suite Lists, on page 656
• Distinguished Name Objects, on page 656
• PKI Objects, on page 658
• Key Chain Objects, on page 676
• DNS Server Group Objects, on page 678
• About Dynamic Objects, on page 679
• SLA Monitor Objects, on page 679
• Prefix Lists, on page 681
• Route Maps, on page 682
• Access List, on page 685
• AS Path Objects, on page 688
• Community Lists, on page 688
• Policy Lists, on page 690
• VPN Objects, on page 691
• Address Pools, on page 708

599
Introduction to Reusable Objects
• FlexConfig Objects, on page 709

• RADIUS Server Groups, on page 710
• Add a Single Sign-on Server, on page 712
• History for Reusable Objects, on page 714

For increased flexibility and web interface ease-of-use, the Firepower System uses named objects, which are
reusable configurations that associate a name with a value. When you want to use that value, use the named
object instead. The system supports object use in various places in the web interface, including many policies
and rules, event searches, reports, dashboards, and so on. The system provides many predefined objects that
represent frequently used configurations.
Use the object manager to create and manage objects. Many configurations that use objects also allow you to
create objects on the fly, as needed. You can also use the object manager to:
• View the policies, settings, and other objects where a network, port, VLAN, or URL object is used; see
Viewing Objects and Their Usage, on page 606.
• Group objects to reference multiple objects with a single configuration; see Object Groups, on page 607.
• Override object values for selected devices or, in a multidomain deployment, selected domains; see
Object Overrides, on page 609.
After you edit an object used in an active policy, you must redeploy the changed configuration for your changes
to take effect. You cannot delete an object that is in use by an active policy.
Note An object is configured on a managed device if, and only if, the object is used in a policy that is assigned to
that device. If you remove an object from all policies assigned to a given device, the object is also removed
from the device configuration on the next deployment, and subsequent changes to the object are not reflected
in the device configuration.
Object Types
The following table lists the objects you can create in the Firepower System, and indicates whether each object
type can be grouped or configured to allow overrides.
Object Type Groupable? Allows Overrides?
Network yes yes
Port yes yes
Interface: no no
• Security Zone
• Interface Group
Tunnel Zone no no

600
Object Type Groupable? Allows Overrides?
Application Filter no no
VLAN Tag yes yes
External Attribute: Security Group Tag (SGT) and no no

Dynamic Object
URL yes yes
Geolocation no no
Time Range no no
Variable Set no no
Security Intelligence: Network, DNS, and URL lists and no no

feeds
Sinkhole no no
File List no no
Cipher Suite List no no
Distinguished Name yes no
Public Key Infrastructure (PKI): yes no

• Internal and Trusted CA
• Internal and External Certs
Key Chain no yes

DNS Server Group no no
SLA Monitor no no
Prefix List: IPv4 and IPv6 no yes
Route Map no yes
Access List: Standard and Extended no yes
AS Path no yes
Community List no yes
Policy List no yes
FlexConfig: Text and FlexConfig objects no yes

601
The Object Manager
Objects and Multitenancy

In a multidomain deployment, you can create objects in Global and descendant domains with the exception
of Security Group Tag (SGT) objects, which you can create only in the Global domain. The system displays
objects created in the current domain, which you can edit. It also displays objects created in ancestor domains,
which you cannot edit, with the exception of security zones and interface groups.
Note Because security zones and interface groups are tied to device interfaces, which you configure at the leaf
level, administrators in descendant domains can view and edit zones and groups created in ancestor domains.
Subdomain users can add and delete interfaces from ancestor zones and groups, but cannot delete or rename
the zones/groups.
Object names must be unique within the domain hierarchy. The system may identify a conflict with the name
of an object you cannot view in your current domain.
For objects that support grouping, you can group objects in the current domain with objects inherited from
ancestor domains.
Object overrides allow you to define device-specific or domain-specific values for certain types of object,
including network, port, VLAN tag, and URL. In a multidomain deployment, you can define a default value
for an object in an ancestor domain, but allow administrators in descendant domains to add override values
for that object.
The Object Manager

You can use the object manager to create and manage objects and object groups.
The object manager displays 20 objects or groups per page. If you have more than 20 of any type of object
or group, use the navigation links at the bottom of the page to view additional pages. You can also go to a
specific page or click Refresh ( ) to refresh your view.
By default, the page lists objects and groups alphabetically by name. You can filter the objects on the page
by name or value.
Importing Objects
Objects can be imported from a comma-separated values file. Up to 1000 objects can be imported in one
attempt. The contents of the comma-separated values file should follow a specific format. The format is
different for each object type. Only a few types of objects can be imported. See the following table to know
the supported object types and the corresponding rules.

602
Importing Objects
Object Type Rules
Individual object • The column header must be mentioned in capital letters.

• The file must have the following columns headers:
• NAME
• DN
• Both NAME and DN column entries are mandatory to import

an entry.
• You can import individual objects directly into an existing
distinguised name object group.
Network object • The column header must be mentioned in capital letters.

• NAME
• DESCRIPTION
• TYPE
• VALUE
• LOOKUP
• The NAME and VALUE column entries are mandatory to import

an entry of host, range, or network object type.
• For an FQDN object, the TYPE column entry must mention
'fqdn,' and the LOOKUP column entry must be specified as
'ipv4,' 'ipv6,' or 'ipv4_ipv6.'
• If no content is provided in the LOOKUP column entry for the
FQDN object, then the object is saved with the ipv4_ipv6 field
value.

603
Importing Objects
Object Type Rules
Port • The column header must be mentioned in capital letters.

• NAME
• PROTOCOL
• PORT
• ICMPCODE
• ICMPTYPE
• The NAME column entry is mandatory.

• For 'tcp' and 'udp' protocol types, the PORT column entry is
mandatory.
• For 'icmp' and 'icmp6' protocol types, the ICMPCODE and
ICMPTYPE column entries are mandatory.
URL • The column header must be mentioned in capital letters.

• NAME
• DESCRIPTION
• URL
• The NAME and URL column entries are mandatory to import

an entry.
VLAN Tag • The column header must be mentioned in capital letters.

• NAME
• DESCRIPTION
• TAG
• The NAME and TAG column entries are mandatory to import

an entry.
Procedure
Step 1 Choose Objects > Object Management.

Step 2 Choose one of the following object types from the left pane:

604
Editing Objects
• Distinguished Name > Individual Objects >

• Network Object
• Port
• URL
• VLAN Tag
Step 3 Choose Import Object from the Add [Object Type] drop-down list.
Note If you have selected Individual Objects in the previous step, click Import.
Step 4 Click Browse.

Step 5 Locate and select the comma-separated file on your system.
Step 6 Click Open.
Note While importing Distinguished Name objects, you can optionally check the Add imported
Distinguished Name objects to the below object group check box and select the group name from
the drop-down box to import the objects directly to an existing distinguised name object group.
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.
Procedure

Step 2 Choose an object type from the list; see Introduction to Reusable Objects, on page 600.
Step 3 Click Edit ( ) next to the object you want to edit.
If View ( ) appears instead, the object belongs to an ancestor domain and has been configured not to allow
overrides, or you do not have permission to modify the object.
Step 4 Modify the object settings as desired.

Step 5 If you are editing a variable set, manage the variables in the set; see Managing Variables, on page 636.
Step 6 For objects that can be configured to allow overrides:
• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 610. 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
Step 7 Click Save.

605
Viewing Objects and Their Usage
Step 8 If you are editing a variable set, and that set is in use by an access control policy, click Yes to confirm that
you want to save your changes.
What to do next
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 535.
Viewing Objects and Their Usage

You can view usage details of objects on the Object Management page. Firepower Management Center
provides this functionality for many object types. However, some object types are not supported.
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.
Procedure

Step 2 Choose one of the following supported object types:
• Access List > Extended
• Access List > Standard
• AS Path
• Community List
• Interface
• Network
• Policy List
• Port
• Prefix List > IPv4 Prefix List
• Prefix List > IPv6 Prefix List
• Route Map
• SLA Monitor
• URL
• VLAN Tag
Step 3 Click the Find Usage ( ) icon next to the object.

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

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

Step 2 Enter your filter criteria in the Filter field.
The page updates as you type to display matching items.
You can use the following wildcards:
• The asterisk (*) matches zero or more occurrences of a character.
• The caret (^) matches content at the beginning of a string.
• The dollar sign ($) matches content at the end of a string.
Step 3 Check the Show Unused Object check box to view the objects and the object groups that are unused anywhere
in the system.
Note • In case an object is a part of an unused object group, the object is considered as used. However,
the unused object group is displayed when the Show Unused Object check box is checked.
• The Show Unused Object check box is available only for network, port, URL and VLAN tag
object types.
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.

607
Grouping Reusable Objects
Deleting a group does not delete the objects in the group, just their association with each other. Additionally,
you cannot delete a group that is in use in an active policy. For example, you cannot delete a VLAN tag group
that you are using in a VLAN condition in a saved access control policy.
Grouping Reusable Objects

You can group objects in the current domain with objects inherited from ancestor domains.
Procedure

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

Step 5 Enter a unique Name.
Step 6 Choose one or more objects from the list, and click Add.
You can also:
• Use the filter field Search ( ) to search for existing objects to include, which updates as you type to
display matching items. Click Reload ( ) above the search field or click Clear ( ) in the search field
to clear the search string.
• Click Add ( ) to create objects on the fly if no existing objects meet your needs.
Step 7 Optionally for Network, Port, URL, and VLAN Tag groups:
• Enter a Description.

608
Object Overrides
• Check the Allow Overrides check box to allow overrides for this object group; see Allowing Object
Overrides, on page 610.
Step 8 Click Save.
What to do next
• If an active policy references your object group, deploy configuration changes; see Deploy Configuration
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

609
Managing Object Overrides
• Access List
• AS Path
• Community List
• Policy List
• PKI Enrollment
• Key Chain
If you can override an object, the Override column appears for the object type in the object manager. Possible
values for this column include:
• Green checkmark — indicates that you can create overrides for the object and no overrides have been
added yet
• Red X — indicates that you cannot create overrides for the object
• Number — represents a count of the overrides that have been added to that object (for example, "2"
indicates two overrides have been added)
Managing Object Overrides
Procedure

Step 2 Choose from the list of object types; see Introduction to Reusable Objects, on page 600.
Step 3 Click Edit ( ) next to the object you want to edit.
If View ( ) appears instead, the object belongs to an ancestor domain and has been configured not to allow
overrides, or you do not have permission to modify the object.
Step 4 Manage the object overrides:

• Add—Add object overrides; see Adding Object Overrides, on page 611.
• Allow—Allow object overrides; see Allowing Object Overrides, on page 610.
• Delete—In the object editor, click Delete ( ) next to the override you want to remove.
• Edit—Edit object overrides; see Editing Object Overrides, on page 611.
Allowing Object Overrides
Procedure
Step 1 In the object editor, check the Allow Overrides check box.
Step 2 Click Save.

610
Adding Object Overrides
What to do next
Add object override values; see Adding Object Overrides, on page 611.
Adding Object Overrides
Before you begin

Allow object overrides; see Allowing Object Overrides, on page 610.
Procedure
Step 1 In the object editor, expand the Override section.

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

Step 8 Click Save.
What to do next
Editing Object Overrides

You can modify the description and the value of an existing override, but you cannot modify the existing
target list. Instead, you must add a new override with new targets, which replaces the existing override.
Procedure
Step 1 In the object editor, expand the Override section.

Step 2 Click Edit ( ) next to the override you want to modify.
Step 3 Optionally, modify the Description.
Step 4 Modify the override value.
Step 5 Click Save to save the override.
Step 6 Click Save to save the object.

611
Network Objects
What to do next
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, identity policies, 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
Note Security Intelligence ignores IP address blocks using a /0 netmask.

612
Creating Network Objects
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
678 and the DNS platform settings in Configure DNS, on page 1427.
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.
Creating Network Objects

Procedure

Step 2 Choose Network from the list of object types.
Step 3 Choose Add Object from the Add Network drop-down menu.
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 6 In the Network field, select the required option and enter an appropriate value; see Network Objects, on page
612.
Step 7 (FQDN objects only) Select the DNS resolution from the Lookup drop-down menu to determine whether
you want the IPv4, IPv6, or both IPv4 and IPv6 addresses associated with the FQDN.
Step 8 Manage overrides for the object:

613
Importing Network Objects
Step 9 Click Save.
What to do next
Importing Network Objects

For details on importing network objects, see Importing Objects, on page 602.
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:

614
Creating Port Objects
• You cannot add any protocol other than TCP or UDP for source port conditions in access control rules.
Also, you cannot mix transport protocols when setting both source and destination port conditions in a
rule.
• If you add an unsupported protocol to a port object group used in a source port condition, the rule where
it is used does not take affect on the managed device when the configuration is deployed.
• If you create a port object containing both TCP and UDP ports, then add it as a source port condition in
a rule, you cannot add a destination port, and vice versa.
Creating Port Objects

Procedure

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

Step 8 Click Save.
What to do next
Importing Port Objects

For details on importing port objects, see Importing Objects, on page 602.

615
Tunnel Zones
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 1718.
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 575.
VLAN Tag Objects

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

Procedure

Step 2 Choose VLAN Tag from the list of object types.
Step 3 Choose Add Object from the Add VLAN Tag drop-down list.
Step 5 Enter a Description.
Step 6 Enter a value in the VLAN Tag field. Use a hyphen to specify a range of VLAN tags.

616
Security Group Tag Objects
Step 8 Click Save.
What to do next
Security Group Tag Objects

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

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

• Disable ISE/ISE-PIC connections. You cannot create custom SGT objects if you use ISE/ISE-PIC as an
identity source.
Procedure
Step 1 Click Objects > Object Management.

Step 2 Click External Attributes > Dynamic Objects.
Step 3 Click Add Security Group Tag.
Step 6 In the Tag field, enter a single SGT.
Step 7 Click Save.
What to do next

617
URL Objects
Related Topics
Autotransition from Custom SGTs to ISE SGTs, on page 592
Custom SGT Conditions, on page 591
ISE SGT vs Custom SGT Rule Conditions, on page 592
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 1668.
A URL object defines a single URL or IP address, whereas a URL group object can define more than one
URL or address. You can use URL objects and groups in various places in the system’s web interface, including
access control policies and event searches.
When creating URL objects, keep the following points in mind:
• If you do not include a path (that is, there is no / character in the URL), the match is based on the server’s
hostname only. The hostname is considered a match if it comes after the :// separator, or after any dot in
the hostname. For example, ign.com matches ign.com and www.ign.com, but it does not match
verisign.com.
• If you include one or more / character, the entire URL string is used for a substring match, including the
server name, path, and any query parameters. However, we recommend that you do not use manual URL
filtering to block or allow individual web pages or parts of sites, as servers can be reorganized and pages
moved to new paths. Substring matching can also lead to unexpected matches, where the string you
include in the URL object also matches paths on unintended servers or strings within query parameters.
• The system disregards the encryption protocol (HTTP vs HTTPS). In other words, if you block a website,
both HTTP and HTTPS traffic to that website is blocked, unless you use an application condition to
target a specific protocol. When creating a URL object, you do not need to specify the protocol when
creating an object. For example, use example.com rather than http://example.com.
• 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.
However, please understand that the subject common name in the certificate might be completely unrelated
to a web site’s domain name. For example, the subject common name in the certificate for youtube.com
is *.google.com (this of course might change at any time). You will get more consistent results if you
use the SSL Decryption policy to decrypt HTTPS traffic so that URL filtering rules work on decrypted
traffic.
Note URL objects will not match HTTPS traffic if the browser resumes a TLS session
because the certificate information is no longer available. Thus, even if you
carefully configure the URL object, you might get inconsistent results for HTTPS
connections.

618
Creating URL Objects
Creating URL Objects

Procedure

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

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

Procedure

Step 2 Choose Geolocation from the list of object types.

619
Interface Objects: Interface Groups and Security Zones
Step 3 Click Add Geolocation.

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
Interface Objects: Interface Groups and Security Zones

Interface objects segment your network to help you manage and classify traffic flow. An interface object
simply groups interfaces. These groups may span multiple devices; you can also configure multiple interface
objects on a single device.
There are two types of interface objects:
• Security zones—An interface can belong to only one security zone.
• Interface groups—An interface can belong to multiple interface groups (and to one security zone).
You can use interface groups in Firepower Threat Defense NAT policies, prefilter policies, and QoS
policies.
Although tunnel zones are not interface objects, you can use them in place of security zones in certain
configurations; see Tunnel Zones and Prefiltering, on page 1718.
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.
Interface Objects and Multitenancy

In a multidomain deployment, you can create interface objects at any level. An interface object created in an
ancestor domain can contain interfaces that reside on devices in different domains. In this situation, subdomain

620
Creating Security Zone and Interface Group Objects
users viewing the ancestor interface object configuration in the object manager can see only the interfaces in
their domain.
Unless restricted by role, subdomain users can view and edit interface objects created in ancestor domains.
Subdomain users can add and delete interfaces from these interface objects. They cannot, however, delete or
rename the interface objects. You can neither view nor edit interface objects created in descendant domains.
Creating Security Zone and Interface Group Objects
Tip You can create empty interface objects and add interfaces to them later. To add an interface, the interface
must have a name. You can also create security zones (but not interface groups) while configuring interfaces
in Devices > Device Management.
Before you begin

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

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

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

621
Time Range Objects
Time Range Objects

Use time range objects to define time periods that you will use to determine when rules apply.
Note Time-based ACLs is supported in Snort 3 also from FMC 7.0 onwards.
Creating Time Range Objects

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

Time ranges are applied based on the time zone associated with the device that processes the traffic. By default,
this is UTC. To change the time zone associated with a device, go to Device > Platform Settings.
Procedure

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

622
Time Zone Object
Step 5 Click Save.
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 696 and Group Policy Advanced Options, on page 702.
Time Zone Object

To specify a local time zone for a managed device, create a time zone object and specify it in the device
platform settings policy assigned to the device.
This device local time is used ONLY for applying time ranges in rules in policies that support time ranges,
such as access control, prefilter, and VPN Group policies. If you do not assign a time zone to a device, UTC
is used by default when applying time ranges in these policies. No other functionality in the Firepower system
uses the time zone specified in a time zone object.
Time zone objects are supported only for Firepower Threat Defense devices.
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

623
Variable Sets
$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 636
Managing Variable Sets, on page 634

624
Variable Sets in Intrusion Policies
Variable Sets in Intrusion Policies

By default, the Firepower System links the default variable set to all intrusion policies used in an access control
policy. When you deploy an access control policy that uses an intrusion policy, intrusion rules that you have
enabled in the intrusion policy use the variable values in the linked variable set.
When you modify a custom variable set used by an intrusion policy in an access control policy, the system
reflects the status for that policy as out-of-date on the Access Control Policy page. You must re-deploy the
access control policy to implement changes in your variable set. When you modify the default set, the system
reflects the status of all access control policies that use intrusion policies as out-of-date, and you must re-deploy
all access control policies to implement your changes.
Variables
Variables belong to one of the following categories:
Default Variables
Variables provided by the Firepower System. You cannot rename or delete a default variable, and you
cannot change its default value. However, you can create a customized version of a default variable.
Customized Variables
Variables you create. These variables can include:
• customized default variables
When you edit the value for a default variable, the system moves the variable from the Default
Variables area to the Customized Variables area. Because variable values in the default set determine
the default values of variables in custom sets, customizing a default variable in the default set
modifies the default value of the variable in all other sets.
• user-defined variables
You can add and delete your own variables, customize their values within different variable sets,
and reset customized variables to their default values. When you reset a user-defined variable, it
remains in the Customized Variables area.
User-defined variables can be one of the following types:
• 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.

625
Predefined Default Variables

By default, the Firepower System provides a single default variable set, which is comprised of predefined
default variables. The Cisco Talos Intelligence Group (Talos) uses rule updates to provide new and updated
intrusion rules and other intrusion policy elements, including default variables.
Because many intrusion rules provided by the system use predefined default variables, you should set
appropriate values for these variables. Depending on how you use variable sets to identify traffic on your
network, you can modify the values for these default variables in any or all variable sets.
Caution Importing an access control or an intrusion policy overwrites existing default variables in the default variable
set with the imported default variables. If your existing default variable set contains a custom variable not
present in the imported default variable set, the unique variable is preserved.
The following table describes the variables provided by the system and indicates which variables you typically
would modify. For assistance determining how to tailor variables to your network, contact Professional
Services or Support.
Table 83: System-Provided Variables
Variable Name Description Modify?
Defines known AOL Instant Messenger Not required.

$AIM_SERVERS
(AIM) servers, and is used in chat-based
rules and rules that look for AIM exploits.
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 non-encrypted ports used in Not required.

$FILE_DATA_PORTS
intrusion rules that detect files in a network
stream.
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 data channel ports where the Not required.

$GTP_PORTS
packet decoder extracts the payload inside
a GTP (General Packet Radio Service
[GPRS] Tunneling Protocol) PDU.

626
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
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 the ports you want the system to Not required.

$SHELLCODE_PORTS
scan for shell code exploits, and is used in
rules that detect exploits that use shell code.
Defines the ports of SIP servers on your Not required.

$SIP_PORTS
network, and is used for SIP exploit rules.
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

627
Network Variables
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

628
Port 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

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

• The default value for included ports in any variable you add is the word any, which indicates any port
or port range. The default value for excluded ports is none, which indicates no ports.
Tip To create a variable with the value any, name and save the variable without adding
a specific value.
• You cannot logically exclude the value any which, if excluded, would indicate no ports. For example,
you cannot save a variable set when you add a variable with the value any to the list of excluded ports.
• Adding ports to the excluded list negates the specified ports and port ranges. That is, you can match any
port with the exception of the excluded ports or port ranges.
• Excluded values must resolve to a subset of included values. For example, you cannot include the port
range 10-50 and exclude port 60.
Advanced Variables
Advanced variables allow you to configure features that you cannot otherwise configure via the web interface.
The Firepower System currently provides only only one advanced variable, the USER_CONF variable.
USER_CONF
USER_CONF provides a general tool that allows you to configure one or more features not otherwise available
via the web interface.
Caution Do not use the advanced variable USER_CONF to configure an intrusion policy feature unless you are
instructed to do so in the feature description or by Support. Conflicting or duplicate configurations will halt
the system.
When editing USER_CONF, you can type up to 4096 total characters on a single line; the line wraps
automatically. You can include any number of valid instructions or lines until you reach the 8192 maximum
character length for a variable or a physical limit such as disk space. Use the backslash (\) line continuation
character after any complete argument in a command directive.
Resetting USER_CONF empties it.

630
Variable Reset
Variable Reset
You can reset a variable to its default value on the variable set new or edit variables page. The following table
summarizes the basic principles of resetting variables.
Table 84: Variable Reset Values
Resetting this variable type... In this set type... Resets it to...
default default the rule update value
user-defined default any
default or user-defined custom the current default set value

(modified or unmodified)
Resetting a variable in a custom set simply resets it to the current value for that variable in the default set.
Conversely, resetting or modifying the value of a variable in the default set always updates the default value
of that variable in all custom sets. When the reset icon is grayed out, indicating that you cannot reset the
variable, this means that the variable has no customized value in that set. Unless you have customized the
value for a variable in a custom set, a change to the variable in the default set updates the value used in any
intrusion policy where you have linked the variable set.
Note It is good practice when you modify a variable in the default set to assess how the change affects any intrusion
policy that uses the variable in a linked custom set, especially when you have not customized the variable
value in the custom set.
You can hover your pointer over the Reset icon in a variable set to see the reset value. When the customized
value and the reset value are the same, this indicates one of the following:
• you are in the custom or default set where you added the variable with the value any
• you are in the custom set where you added the variable with an explicit value and elected to use the
configured value as the default value
Adding Variables to Sets

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

631
Example: Adding User-Defined Variables to Default Sets
Example: Adding User-Defined Variables to Default Sets

The following diagram illustrates set interactions when you add the user-defined variable Var1 to the default
set with the value 192.168.1.0/24.
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.
Example: Adding User-Defined Variables to Custom Sets

The next two examples illustrate variable set interactions when you add a user-defined variable to a custom
set. When you save the new variable, you are prompted whether to use the configured value as the default
value for other sets. In the following example, you elect to use the configured value.
Note that, except for the origin of Var1 from Custom Set 1, this example is identical to the example above
where you added Var1 to the default set. Adding the customized value 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.

632
Nesting Variables
This approach adds Var1 to all sets with a default value of any. After adding Var1, you can customize its
value in any set. An advantage of this approach is that, by not initially customizing Var1 in the default set,
you decrease your risk of customizing the value in the default set and thus inadvertently changing the current
value in a set such as Custom Set 2 where you have not customized Var1.
Nesting Variables
You can nest variables so long as the nesting is not circular. Nested, negated variables are not supported.
Valid Nested Variables

In this example, SMTP_SERVERS, HTTP_SERVERS, and OTHER_SERVERS are valid nested
variables.
Variable Type Included Networks Excluded Networks
SMTP_SERVERS customized default 10.1.1.1 —
HTTP_SERVERS customized default 10.1.1.2 —
OTHER_SERVERS user-defined 10.2.2.0/24 —
HOME_NET customized default 10.1.1.0/24 SMTP_SERVERS

OTHER_SERVERS HTTP_SERVERS
An Invalid Nested Variable

In this example, HOME_NET is an invalid nested variable because the nesting of HOME_NET is
circular; that is, the definition of OTHER_SERVERS includes HOME_NET, so you would be nesting
HOME_NET in itself.
SMTP_SERVERS customized default 10.1.1.1 —
HTTP_SERVERS customized default 10.1.1.2 —
OTHER_SERVERS user-defined 10.2.2.0/24 —

HOME_NET

633
Managing Variable Sets
HOME_NET customized default 10.1.1.0/24 SMTP_SERVERS

OTHER_SERVERS HTTP_SERVERS
An Unsupported Nested, Negated Variable

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

10.2.0.0/16
10.3.0.0/16
EXTERNAL_NET customized default — HOME_NET
DMZ_NET user-defined 10.4.0.0/16 —
NOT_DMZ_NET user-defined — DMZ_NET
NONCORE_NET user-defined EXTERNAL_NET —

NOT_DMZ_NET
Alternative to an Unsupported Nested, Negated Variable

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

10.2.0.0/16
10.3.0.0/16
DMZ_NET user-defined 10.4.0.0/16 —
NONCORE_NET user-defined — HOME_NET

DMZ_NET
Managing Variable Sets

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

634
Creating Variable Sets
Procedure

Step 2 Choose Variable Set from the list of object types.
Step 3 Manage your variable sets:
• Add — If you want to add a custom variable set, click Add Variable Set; see Creating Variable Sets,
on page 635.
• Delete — If you want to delete a custom variable set, click Delete ( ) next to the variable set, then
click Yes. You cannot delete the default variable set or variable sets belonging to ancestor domains.
Note Variables created in a variable set you delete are not deleted or otherwise affected in other sets.
• Edit — If you want to edit a variable set, click Edit ( ) next to the variable set you want to modify; see
Editing Objects, on page 605.
• 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 636.
Creating Variable Sets
Procedure

Step 3 Click Add Variable Set.

Step 6 Manage the variables in the set; see Managing Variables, on page 636.
Step 7 Click Save.
What to do next

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

Step 3 Click Edit ( ) next to the variable set you want to edit.
If View ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission
Step 4 Manage your variables:

• Display — If you want to display the complete value for a variable, hover your pointer over the value
in the Value column next to the variable.
• Add — If you want to add a variable, click Add; see Adding Variables, on page 637.
• Delete — Click Delete ( ) next to the variable. If you have saved the variable set since adding the
variable, click Yes to confirm that you want to delete the variable.
You cannot delete the following:
• default variables
• user-defined variables that are used by intrusion rules or other variables
• variables belonging to ancestor domains
• Edit — Click Edit ( ) next to the variable you want to edit; see Editing Variables, on page 638.
• 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.

636
Adding Variables
What to do next
Adding Variables
Procedure
Step 1 In the variable set editor, click Add.

Step 2 Enter a unique variable Name.
Step 3 From the Type drop-down list, choose either Network or Port.
Step 4 Specify values for the variable:
• If you want to move items from the list of available networks or ports to the list of included or excluded
items, you can choose one or more items and then drag and drop, or click Include or Exclude.
Tip If addresses or ports in the included and excluded lists for a network or port variable overlap,
excluded addresses or ports take precedence.
• Enter a single literal value, then click Add. For network variables, you can enter a single IP address or
address block. For port variables you can add a single port or port range, separating the upper and lower
values with a hyphen (-). Repeat this step as needed to enter multiple literal values.
• If you want to remove an item from the included or excluded lists, click Delete ( ) next to the item.
Note The list of items to include or exclude can be comprised of any combination of literal strings and
existing variables, objects, and network object groups in the case of network variables.
Step 5 Click Save to save the variable. If you are adding a new variable from a custom set, you have the following
options:
• Click Yes to add the variable using the configured value as the customized value in the default set and,
consequently, the default value in other custom sets.
• Click No to add the variable as the default value of any in the default set and, consequently, in other
custom sets.
Step 6 Click Save to save the variable set. Your changes are saved, and any access control policy the variable set is
linked to displays an out-of-date status.
What to do next

637
Editing Variables
Editing Variables
You can edit both custom and default variables.
You cannot change the Name or Type values in an existing variable.
Procedure
Step 1 In the variable set editor, click Edit ( ) next to the variable you want to modify.
If View ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission to
modify the object.
Step 2 Modify the variable:

• If you want to move items from the list of available networks or ports to the list of included or excluded
items, you can select one or more items and then drag and drop, or click Include or Exclude.
Tip If addresses or ports in the included and excluded lists for a network or port variable overlap,
excluded addresses or ports take precedence.
• Enter a single literal value, then click Add. For network variables, you can enter a single IP address or
address block. For port variables you can add a single port or port range, separating the upper and lower
values with a hyphen (-). Repeat this step as needed to enter multiple literal values.
• If you want to remove an item from the included or excluded lists, click Delete ( ) next to the item.
Note The list of items to include or exclude can be comprised of any combination of literal strings and
existing variables, objects, and network object groups in the case of network variables.
Step 3 Click Save to save the variable.

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

Security Intelligence functionality requires the Threat license (for FTD devices) or the Protection license (all
other device types).

638
Security Intelligence Lists and Feeds
Security Intelligence lists and feeds are collections of IP addresses, domain names, and URLs that you can
use to quickly filter traffic that matches an entry on a list or feed.
• A list is a static collection that you manage manually.
• A feed is a dynamic collection that updates on an interval over HTTP or HTTPS.
Security Intelligence lists/feeds are grouped into:

• DNS (Domain names )
• Network (IP addresses)
• URLs
System-Provided Feeds
Cisco provides the following feeds as Security Intelligence objects:
• Security Intelligence feeds updated regularly with the latest threat intelligence from Talos:
• Cisco-DNS-and-URL-Intelligence-Feed (under DNS Lists and Feeds)
• Cisco-Intelligence-Feed (for IP addresses, under Network Lists and Feeds)
You cannot delete the system-provided feeds, but you can change the frequency of (or disable) their
updates.
• Cisco-TID-Feed (under Network Lists and Feeds)
This feed is not used in the Security Intelligence tab of the access control policy.
Instead, you must enable and configure Cisco Threat Intelligence Director (TID) to use this feed, which
is a collection of TID observables data.
Use this object to set how frequently this data is published to TID elements.
For more information, see Cisco Threat Intelligence Director (TID), on page 1887.
Predefined Lists: Global Block Lists and Global Do Not Block Lists
The system ships with predefined global Block lists and Do Not Block lists for domains (DNS), IP addresses
(Networks), and URLs.
These lists are empty until you populate them. To build these lists, see Global and Domain Security Intelligence
Lists, on page 640.
By default, access control and DNS policies use these lists as part of Security Intelligence.
Custom Feeds
You can use third-party feeds, or use a custom internal feed to easily maintain an enterprise-wide Block list
in a large deployment with multiple Firepower Management Center appliances.
See Custom Security Intelligence Feeds, on page 646.
Custom Lists
Custom lists can augment and fine-tune feeds and the Global lists.

639
How to Modify Security Intelligence Objects
See Custom Security Intelligence Lists, on page 648.
Where Security Intelligence Lists and Feeds Are Used

• IP address and address blocks—Use Block and Do Not Block lists in access control policies, as part of
Security Intelligence.
• Domain Names—Use Block and Do Not Block lists in DNS policies, as part of Security Intelligence.
• URLs—Use Block and Do Not Block lists in access control policies, as part of Security Intelligence.
You can also use URL lists in access control and QoS rules, whose analysis and traffic handling phases
occur after Security Intelligence.
How to Modify Security Intelligence Objects

To add or delete entries on a Block list, Do Not Block list, feed, or sinkhole object:
Object Type Edit Capabilities Requires Redeploy After Edit?
Custom Block and Do Not Block Upload new and replacement lists Yes
lists using the object manager.
Default (but custom-populated) Add entries using the context menu No

Block lists and Do Not Block lists: or delete entries using the object
Global, descendant, and manager.
domain-specific
System-provided Intelligence Feeds Disable or change update frequency No

using the object manager.
Custom feeds Fully modify using the object No

manager.
Sinkhole Fully modify using the object Yes

manager.
Global and Domain Security Intelligence Lists

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

640
Security Intelligence Lists and Multitenancy
Note These options apply to Security Intelligence only. Security Intelligence cannot block traffic that has already
been fastpathed. Similarly, adding an item to a Security Intelligence Do Not Block list does not automatically
trust or fastpath matching traffic. For more information, see About Security Intelligence, on page 1685.
In a multidomain deployment, you can choose the Firepower System domains where you want to enforce
blocking, or exempting from Security Intelligence blocking, by adding items to Domain lists as well as the
Global lists; see Security Intelligence Lists and Multitenancy, on page 641.
Security Intelligence Lists and Multitenancy

In a multidomain deployment, the Global domain owns the Global Block lists and Do Not Block lists. Only
Global administrators can add to or remove items from the Global lists. So that subdomain users can add
networks, domain names, and URLs to Block and Do Not Block lists, multitenancy adds:
• Domain lists—Block or Do Not Block lists whose contents apply to a particular subdomain only. The
Global lists are Domain lists for the Global domain.
• Descendant Domain lists—Block or Do Not Block lists that aggregate the Domain lists of the current
domain’s descendants.
Domain Lists
In addition to being able to access (but not edit) the Global lists, each subdomain has its own named lists, the
contents of which apply only to that subdomain. For example, a subdomain named Company A owns:
• Domain Block list - Company A and Domain Do Not Block list - Company A
• Domain Block list for DNS - Company A, Domain Do Not Block list for DNS - Company A
• Domain Block list for URL - Company A, Domain Do Not Block list for URL - Company A
Any administrator at or above the current domain can populate these lists. You can use the context menu to
add an item to the Block or Do Not Block list in the current and all descendant domains. However, only an
administrator in the associated domain can remove an item from a Domain list.
For example, a Global administrator could choose to add the same IP address to the Block list in the Global
domain and Company A’s domain, but not add it to the Block list in Company B’s domain. This action would
add the same IP address to:
• Global Block list (where it can be removed only by Global administrators)
• Domain Block list - Company A (where it can be removed only by Company A administrators)
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.
Descendant Domain Lists

A Descendant Domain list is a Do Not Block list or Block list that aggregates the Domain lists of the current
domain’s descendants. Leaf domains do not have Descendant Domain lists.

641
Add Entries to Global Security Intelligence Lists
Descendant Domain lists are useful because a higher-level domain administrator can enforce general Security
Intelligence settings, while still allowing subdomain users to add items to a Block or Do Not Block list in
their own deployment.
For example, the Global domain has the following Descendant Domain lists:
• Descendant Block lists - Global, Descendant Do Not Block lists - Global
• Descendant Block lists for DNS - Global, Descendant Do Not Block lists for DNS - Global
• Descendant Block lists for URL - Global, Descendant Do Not Block lists for URL - Global
Note Descendant Domain lists do not appear in the object manager because they are symbolic aggregations, not
hand-populated lists. They appear where you can use them: in access control and DNS policies.
Add Entries to Global Security Intelligence Lists

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

Because adding an entry to a Security Intelligence list affects access control, you must have one of the following
user roles:
• Administrator
• A combination of roles: Network Admin or Access Admin, plus Security Analyst and Security Approver
• A custom role with both Modify Access Control Policy and Deploy Configuration to Devices permissions
If appropriate, verify that these lists are used in the policies in which you expect them to be used.
Procedure
Step 1 Navigate to an event that includes an IP address, domain, or URL that you want to always block using Security
Intelligence, or exempt from Security Intelligence blocking.
Step 2 Right-click the IP address, domain, or URL and choose the appropriate option:

642
Delete Entries from Global Security Intelligence Lists
Item Type Context Menu Option
IP address Add IP to Block List

Add IP to Do-Not-Block List
These options add the IP address to the respective lists for Networks.
URL Add URL to Global Block List for URL

Add URL to Global Do-Not-Block List for URL
Domain of a URL in the URL field Add Domain to Global Block List for URL
Add Domain to Global Do-Not-Block List for URL
Domain in the DNS Query field Add Domain to Global Block List for DNS
Add Domain to Global Do-Not-Block List for DNS
What to do next
You do NOT need to redeploy for these changes to take effect.
If you want to delete an item from a list, see Delete Entries from Global Security Intelligence Lists, on page
643.
Delete Entries from Global Security Intelligence Lists
Note • In multi-domain deployments, the names of these lists may not be "Global." For more information, see
Security Intelligence Lists and Multitenancy, on page 641.
• To add entries to these lists, see Add Entries to Global Security Intelligence Lists, on page 642.
Procedure

Step 2 Click Security Intelligence.
Step 3 Click the appropriate option:
• Network Lists and Feeds (for IP addresses)
• DNS Lists and Feeds (for domain names)
• URL Lists and Feeds
Step 4 Click the pencil beside the Global Block or Global Do-Not-Block list.

643
List and Feed Updates for Security Intelligence
Step 5 Click the trash button beside the entry to delete.
List and Feed Updates for Security Intelligence

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

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

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

modify the object.
Step 4 Edit the Update Frequency.

Step 5 Click Save.

644
Custom Security Intelligence Lists and Feeds
Custom Security Intelligence Lists and Feeds

Custom Lists and Feeds: Requirements
List and Feed Formatting

Each list or feed must be a simple text file no larger than 500MB. List files must have the .txt extension.
Include one entry or comment per line: one IP address, one URL, one domain name.
Tip The number of entries you can include is limited by the maximum size of the file. For example, a URL list
with no comments and an average URL length of 100 characters (including Punycode or percent Unicode
representations and newlines) can contain more than 5.24 million entries.
In a DNS list entry, you can specify an asterisk (*) wildcard character for a domain label. All labels match
the wildcard. For example, an entry of 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.
Feed Requirements
When you configure a feed, you specify its location using a URL; the URL cannot be Punycode-encoded.
For feed update intervals of 30 minutes or less, you must specify an MD5 URL. This prevents frequent
downloads of unchanged feeds. If your feed server does not provide an MD5 URL, you must use a download
interval of at least 30 minutes.
If you use an MD5 checksum, the checksum must be stored in a simple text file with only the checksum.
Comments are not supported.
URL Lists and Feeds: URL Syntax and Matching Criteria

Security Intelligence URL lists and feeds, including custom lists and feeds and entries in the global Block list
and Do Not Block list, can include the following, which have the matching behavior as described:
• Hostnames
For example, www.example.com.
• URLs
example.com matches example.com and all subdomains, including www.example.com,
eu.example.com, example.com/abc, and www.example.com/def -- but NOT
example.co.uk or examplexyz.com or example.com.malicious-site.com
You can also include an entire URL path, such as
https://www.cisco.com/c/en/us/products/security/firewalls/index.html
• A slash at the end of a URL to specify an exact match
example.com/ matches ONLY example.com; it does NOT match www.example.com or any
other URL.

645
Custom Security Intelligence Feeds
• A wildcard (*) to represent any domain in a URL

An asterisk can represent a complete domain string separated by dots, but not a partial domain string,
and not any part of the URL following the first slash.
Valid examples:
• *.example.com
• www.*.com
• example.*
(This will match example.com and example.org and example.de, for example, but NOT
example.co.uk)
• *.example.*
• example.*/
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.*.*.
See also Custom Security Intelligence Lists, on page 648.
Custom Security Intelligence Feeds

Custom or third-party Security Intelligence feeds allow you to augment the system-provided Intelligence
Feeds with other regularly-updated reputable Block lists and Do Not Block lists on the Internet. You can also
set up an internal feed, which is useful if you want to update multiple Firepower Management Center appliances
in your deployment using one source list.
Note You cannot add address blocks to Block or Do Not Block lists using a /0 netmask in a Security Intelligence
feed. If you want to monitor or block all traffic targeted by a policy, use an access control rule with the Monitor
or Block rule action, respectively, and a default value of any for the Source Networks and Destination
Networks.
You also can configure the system to use an MD5 checksum to determine whether to download an updated
feed. If the checksum has not changed since the last time the system downloaded the feed, the system does
not need to re-download it. You may want to use MD5 checksums for internal feeds, especially if they are
large.
Note The system does not perform peer SSL certificate verification when downloading custom feeds, nor does the
system support the use of certificate bundles or self-signed certificates to verify the remote peer.

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

Procedure

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

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

Step 6 Enter a Feed URL.
Step 7 Enter an MD5 URL.
This is used to determine whether the feed contents have changed since the last update, so the system does
not download unchanged feeds.
MD5 URL is required for update intervals shorter than 30 minutes.
If your feed server does not provide an MD5 URL, you must choose an interval of at least 30 minutes.
Step 8 Choose an Update Frequency.

Step 9 Click Save.
Unless you disabled feed updates, the system attempts to download and verify the feed.
Manually Updating Security Intelligence Feeds

Before you begin

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

647
Custom Security Intelligence Lists
Procedure

Step 2 Expand the Security Intelligence node, then choose a feed type.
Step 3 Click Update Feeds, then confirm.
Step 4 Click OK.
After the Firepower Management Center downloads and verifies the feed updates, it communicates any changes
to its managed devices. Your deployment begins filtering traffic using the updated feeds.
Custom Security Intelligence Lists

Security Intelligence lists are simple static lists of IP addresses and address blocks, URLs, or domain names
that you manually upload to the system. Custom lists are useful if you want to augment and fine-tune feeds
or one of the global lists, for a single Firepower Management Center’s managed devices.
For example, if a reputable feed improperly blocks your access to vital resources but is overall useful to your
organization, you can create a custom Do Not Block list that contains only the improperly classified IP
addresses, rather than removing the IP address feed object from the access control policy’s Block list.
Note You cannot add address blocks to a Block or Do Not Block list using a /0 netmask in a Security Intelligence
list. If you want to monitor or block all traffic targeted by a policy, use an access control rule with the Monitor
or Block rule action, respectively, and a default value of any for the Source Networks and Destination
Networks.
Regarding list entry formatting, note the following:

• Netmasks for address blocks can be integers from 0 to 32 or 0 to 128, for IPv4 and IPv6, respectively.
• Unicode in domain names must be encoded in Punycode format, and are case insensitive.
• Characters in domain names are case-insensitive.
• Unicode in URLs should be encoded in percent-encoding format.
• Characters in URL subdirectories are case-sensitive.
• List entries that start with the pound sign (#) are treated as comments.
• See additional formatting requirements at Custom Lists and Feeds: Requirements, on page 645.
Regarding matching list entries, note the following:

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

648
Uploading New Security Intelligence Lists to the Firepower Management Center
Uploading New Security Intelligence Lists to the Firepower Management Center

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

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

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

Step 6 Click Browse to browse to the list .txt file, then click Upload.
Step 7 Click Save.
What to do next
Updating Security Intelligence Lists

Procedure

Step 2 Expand the Security Intelligence node, then choose a list type.
Step 3 Next to the list you want to update, click Edit ( ).
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.

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

Procedure

Step 2 Choose Sinkhole from the list of object types.
Step 3 Click Add Sinkhole.
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.

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

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

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

You must have the Malware license for this procedure.
You can submit a file’s SHA-256 value to add it to a file list. You cannot add duplicate SHA-256 values.
Before you begin

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

Step 2 Choose File List from the list of object types.
Step 3 Click Edit ( ) next to the clean list or custom detection list where you want to add a file.
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

652
Uploading Individual Files to File Lists
Note After configuration changes are deployed, the system no longer queries the AMP cloud for files on the list.
Uploading Individual Files to File Lists

If you have a copy of the file you want to add to a file list, you can upload the file to the Firepower Management
Center for analysis; the system calculates the file’s SHA-256 value and adds the file to the list. The system
does not enforce a limit on the size of files for SHA-256 calculation.
Procedure

Step 3 Click Edit ( ) next to the clean list or custom detection list where you want to add a file.
modify the object.
Step 4 From the Add by drop-down list, choose Calculate SHA.

Step 5 Optionally, enter a description of the file in the Description field. If you do not enter a description, the file
name is used for the description on upload.
Step 6 Click Browse, and choose a file to upload.
Step 7 Click Calculate and Add SHA.
Step 8 Click Save.
What to do next
Note After you deploy configuration changes, the system no longer queries the AMP cloud for files on the list.
Uploading Source Files to File Lists


653
Editing SHA-256 Values in File Lists
Procedure

Step 2 Click File List.
Step 3 Click Edit ( ) next to the file list where you want to add values from a source file.
modify the object.
Step 4 In the Add by drop-down list, choose List of SHAs.

Step 5 Optionally, enter a description of the source file in the Description field. If you do not enter a description,
the system uses the file name.
Step 6 Click Browse to browse to the source file, then click Upload and Add List.
Step 7 Click Save.
What to do next
Note After you deploy the policies, the system no longer queries the AMP cloud for files on the list.
Editing SHA-256 Values in File Lists

You can edit or delete individual SHA-256 values on a file list. Note that you cannot directly edit a source
file within the object manager. To make changes, you must first modify your source file directly, delete the
copy on the system, then upload the modified source file.
Procedure

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

654
Downloading Source Files from File Lists
modify the object.
Step 4 You can:
• Click Edit ( ) next to the SHA-256 value you want to change, and modify the SHA-256 or Description
values as desired.
• Click Delete ( ) next to the SHA-256 value you want to delete.
Step 5 Click Save to update the file entry in the list.

Step 6 Click Save to save the file list.
What to do next
Note After configuration changes are deployed, the system no longer queries the AMP cloud for files on the list.
Downloading Source Files from File Lists

Procedure

Step 3 Click Edit ( ) next to the clean list or custom detection list where you want to download a source file.
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.

655
Cipher Suite Lists
Cipher Suite Lists

A cipher suite list is an object comprised of several cipher suites. Each predefined cipher suite value represents
a cipher suite used to negotiate an SSL- or TLS-encrypted session. You can use cipher suites and cipher suite
lists in SSL rules to control encrypted traffic based on whether the client and server negotiated the SSL session
using that cipher suite. If you add a cipher suite list to an SSL rule, SSL sessions negotiated with any of the
cipher suites in the list match the rule.
Note Although you can use cipher suites in the web interface in the same places as cipher suite lists, you cannot
add, modify, or delete cipher suites.
Creating Cipher Suite Lists

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

Step 2 Choose Cipher Suite List from the list of object types.
Step 3 Click Add 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
Distinguished Name Objects

Each distinguished name object represents the distinguished name listed for a public key certificate’s subject
or issuer. You can use distinguished name objects and groups in SSL rules to control encrypted traffic based
on whether the client and server negotiated the SSL session using a server certificate with the distinguished
name as subject or issuer.

656
Distinguished Name Objects
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.
Table 85: Distinguished Name Attributes
Attribute Description Allowed Values
C Country Code two alphabetic characters
CN Common Name up to 64 alphanumeric, backslash

(/), hyphen (-), quotation ("), or
asterisk (*) characters, or spaces
O Organization up to 64 alphanumeric, backslash

OU Organizational Unit up to 64 alphanumeric, backslash

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.
Table 86: Common Name Attribute Wild Card Examples
Attribute Matches Does Not Match
CN=”*ample.com” example.com mail.example.com

example.text.com
ampleexam.com
CN=”exam*.com” example.com mail.example.com

example.text.com
ampleexam.com
CN=”*xamp*.com” example.com mail.example.com

example.text.com
ampleexam.com
CN=”*.example.com” mail.example.com example.com

example.text.com
ampleexam.com
CN=”*.com” example.com mail.example.com

ampleexam.com example.text.com

657
Creating Distinguished Name Objects
Attribute Matches Does Not Match
CN=”*.*.com” mail.example.com example.com

example.text.com ampleexam.com
Creating Distinguished Name Objects

Procedure

Step 2 Expand the Distinguished Name node, and choose Individual Objects.
Step 3 Click Add Distinguished Name.
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 656 separated by commas.
• If you add a common name, you can include multiple labels and wild cards.
Step 6 Click Save.
What to do next
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.

658
Internal Certificate Authority Objects
If you use trusted certificate authority objects to configure realms, you can configure secure connections to
LDAP or AD servers.
If you use PKI objects in SSL rules, you can match traffic encrypted with:
• the certificate in an external certificate object
• a certificate either signed by the CA in a trusted CA object, or within the CA’s chain of trust
If you use PKI objects in SSL rules, you can decrypt:

• outgoing traffic by re-signing the server certificate with an internal CA object
• incoming traffic using the known private key in an internal certificate object
You can manually input certificate and key information, upload a file containing that information, or in some
cases, generate a new CA certificate and private key.
When you view a list of PKI objects in the object manager, the system displays the certificate’s Subject
distinguished name as the object value. Hover your pointer over the value to view the full certificate Subject
distinguished name. To view other certificate details, edit the PKI object.
Note The Firepower Management Center and managed devices encrypt all private keys stored in internal CA objects
and internal certificate objects with a randomly generated key before saving them. If you upload private keys
that are password protected, the appliance decrypts the key using the user-supplied password, then reencrypts
it with the randomly generated key before saving it.
PKI Objects for Certificate Enrollment

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

Each internal certificate authority (CA) object you configure represents the CA public key certificate of a CA
your organization controls. The object consists of the object name, CA certificate, and paired private key.
You can use internal CA objects and groups in SSL rules to decrypt outgoing encrypted traffic by re-signing
the server certificate with the internal CA.
Note If you reference an internal CA object in a Decrypt - Resign SSL rule and the rule matches an encrypted
session, the user’s browser may warn that the certificate is not trusted while negotiating the SSL handshake.
To avoid this, add the internal CA object certificate to either the client or domain list of trusted root certificates.
You can create an internal CA object in the following ways:

659
CA Certificate and Private Key Import
• import an existing RSA-based or elliptic curve-based CA certificate and private key

• generate a new self-signed RSA-based CA certificate and private key
• generate an unsigned RSA-based CA certificate and private key. You must submit a certificate signing
request (CSR) to another CA to sign the certificate before using the internal CA object.
After you create an internal CA object containing a signed certificate, you can download the CA certificate
and private key. The system encrypts downloaded certificates and private keys with a user-provided password.
Whether system-generated or user-created, you can modify the internal CA object name, but cannot modify
other object properties.
You cannot delete an internal CA object that is in use. Additionally, after you edit an internal CA object used
in an SSL policy, the associated access control policy goes out-of-date. You must re-deploy the access control
policy for your changes to take effect.
CA Certificate and Private Key Import

You can configure an internal CA object by importing an X.509 v3 CA certificate and private key. You can
upload files encoded in one of the following supported formats:
• Distinguished Encoding Rules (DER)
• Privacy-enhanced Electronic Mail (PEM)
If the private key file is password-protected, you can supply the decryption password. If the certificate and
key are encoded in the PEM format, you can also copy and paste the information.
You can upload only files that contain proper certificate or key information, and that are paired with each
other. The system validates the pair before saving the object.
Note If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced
internal CA certificate’s encryption algorithm type, in addition to any configured rule conditions. You must
upload an elliptic curve-based CA certificate to decrypt outgoing traffic encrypted with an elliptic curve-based
algorithm, for example.
Importing a CA Certificate and Private Key

Procedure

Step 2 Expand the PKI node, and choose Internal CAs.
Step 3 Click Import CA.

660
Generating a New CA Certificate and Private Key
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
Generating a New CA Certificate and Private Key

You can configure an internal CA object by providing identification information to generate a self-signed
RSA-based CA certificate and private key.
The generated CA certificate is valid for ten years. The Valid From date is a week before generation.
Procedure

Step 3 Click Generate CA.
Step 5 Enter the identification attributes.

Step 6 Click Generate self-signed CA.
New Signed Certificates

You can configure an internal CA object by obtaining a signed certificate from a CA. This involves two steps:
• Provide identification information to configure the internal CA object. This generates an unsigned
certificate and paired private key, and creates a certificate signing request (CSR) to a CA you specify.

661
Creating an Unsigned CA Certificate and CSR
• After the CA issues the signed certificate, upload it to the internal CA object, replacing the unsigned
certificate.
You can only reference an internal CA object in an SSL rule if it contains a signed certificate.
Creating an Unsigned CA Certificate and CSR

Procedure

Step 3 Click Generate CA.
Step 5 Enter the identification attributes.

Step 6 Click Generate CSR.
Step 7 Copy the CSR to submit to a CA.
Step 8 Click OK.
What to do next
• You must upload a signed certificate issued by a CA as described in Uploading a Signed Certificate
Issued in Response to a CSR, on page 662
Uploading a Signed Certificate Issued in Response to a CSR

Once uploaded, the signed certificate can be referenced in SSL rules.
Procedure

Step 3 Click Edit ( ) next to the CA object containing the unsigned certificate awaiting the CSR.
Step 4 Click Install Certificate.
Step 5 Click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate file.

662
CA Certificate and Private Key Downloads
Step 6 If the uploaded file is password protected, check the Encrypted, and the password is: check box, and enter
the password.
Step 7 Click Save to upload a signed certificate to the CA object.
What to do next
CA Certificate and Private Key Downloads

You can back up or transfer a CA certificate and paired private key by downloading a file containing the
certificate and key information from an internal CA object.
Caution Always store downloaded key information in a secure location.
The system encrypts the private key stored in an internal CA object with a randomly generated key before
saving it to disk. If you download a certificate and private key from an internal CA object, the system first
decrypts the information before creating a file containing the certificate and private key information. You
must then provide a password the system uses to encrypt the downloaded file.
Caution Private keys downloaded as part of a system backup are decrypted, then stored in the unencrypted backup
file.
Downloading a CA Certificate and Private Key

You can download CA certificates for both the current domain and ancestor domains.
Procedure

Step 3 Next to the internal CA object whose certificate and private key you want to download, click Edit ( ).
In a multidomain deployment, click View ( ) to download the certificate and private key for an object in
an ancestor domain.
Step 4 Click Download.

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

663
Trusted Certificate Authority Objects
Step 6 Click OK.
Trusted Certificate Authority Objects

Each trusted certificate authority (CA) object you configure represents a CA public key certificate belonging
to a trusted CA. The object consists of the object name and CA public key certificate. You can use external
CA objects and groups in:
• your SSL policy to control traffic encrypted with a certificate signed either by the trusted CA, or any CA
within the chain of trust.
• your realm configurations to establish secure connections to LDAP or AD servers.
• your ISE/ISE-PIC connection. Select trusted certificate authority objects for the pxGrid Server CA and
MNT Server CA fields.
After you create the trusted CA object, you can modify the name and add certificate revocation lists (CRL),
but cannot modify other object properties. There is no limit on the number of CRLs you can add to an object.
If you want to modify a CRL you have uploaded to an object, you must delete the object and recreate it.
Note Adding a CRL to an object has no effect when the object is used in your ISE/ISE-PIC integration configuration.
You cannot delete a trusted CA object that is in use. Additionally, after you edit a trusted CA object that is in
use, the associated access control policy goes out-of-date. You must re-deploy the access control policy for
your changes to take effect.
Trusted CA Object
You can configure an external CA object by uploading an X.509 v3 CA certificate. You can upload a file
encoded in one of the following supported formats:
If the file is password-protected, you must supply the decryption password. If the certificate is encoded in the
PEM format, you can also copy and paste the information.
You can upload a CA certificate only if the file contains proper certificate information; the system validates
the certificate before saving the object.
Adding a Trusted CA Object

Procedure

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

664
Certificate Revocation Lists in Trusted CA Objects
Step 3 Click Add Trusted CAs.

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

Step 6 If the file is password-protected, check the Encrypted, and the password is: check box, and enter the
password.
Step 7 Click Save.
What to do next
Certificate Revocation Lists in Trusted CA Objects

You can upload CRLs to a trusted CA object. If you reference that trusted CA object in an SSL policy, you
can control encrypted traffic based on whether the CA that issued the session encryption certificate subsequently
revoked the certificate. You can upload files encoded in one of the following supported formats:
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.
Adding a Certificate Revocation List to a Trusted CA Object


665
External Certificate Objects
Procedure

Step 2 Expand the PKI node, and choose Trusted CAs.
Step 3 Click Edit ( ) next to a trusted CA object.
Step 4 Click Add CRL to upload a DER or PEM-encoded CRL file.

Step 5 Click OK.
What to do next
External Certificate Objects

Each external certificate object you configure represents a server public key certificate that does not belong
to your organization. The object consists of the object name and certificate. You can use external certificate
objects and groups in SSL rules to control traffic encrypted with the server certificate. For example, you can
upload a self-signed server certificate that you trust, but cannot verify with a trusted CA certificate.
You can configure an external certificate object by uploading an X.509 v3 server certificate. You can upload
a file in one of the following supported formats:
You can upload only files that contains proper server certificate information; the system validates the file
before saving the object. If the certificate is encoded in the PEM format, you can also copy and paste the
information.
Adding External Certificate Objects

Procedure

Step 2 Expand the PKI node, and choose External Certs.
Step 3 Click Add External Cert.

666
Internal Certificate Objects
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
Internal Certificate Objects

Each internal certificate object you configure represents a server public key certificate belonging to your
organization. The object consists of the object name, public key certificate, and paired private key. You can
use internal certificate objects and groups in:
• your SSL rules to decrypt traffic incoming to one of your organization’s servers using the known private
key.
• your ISE/ISE-PIC connection. Select an internal certificate object for the MC Server Certificate field.
• your captive portal configuration to authenticate the identity of your captive portal device when connecting
to users' web browsers. Select an internal certificate object for the Server Certificate field.
You can configure an internal certificate object by uploading an X.509 v3 RSA-based or elliptic curve-based
server certificate and paired private key. You can upload a file in one of the following supported formats:
If the file is password-protected, you must supply the decryption password. If the certificate and key are
encoded in the PEM format, you can also copy and paste the information.
You can upload only files that contain proper certificate or key information, and that are paired with each
other. The system validates the pair before saving the object.
After you create the internal certificate object, you can modify the name, but cannot modify other object
properties.
You cannot delete an internal certificate object that is in use. Additionally, after you edit an internal certificate
object that is in use, the associated access control policy goes out-of-date. You must re-deploy the access
control policy for your changes to take effect.
Adding Internal Certificate Objects

Procedure

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

667
Certificate Enrollment Objects
Step 3 Click Add Internal Cert.

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.
Certificate Enrollment Objects

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

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

To manage certificate enrollment objects, go to Objects > Object Management, then from the navigation
pane choose PKI > Cert Enrollment. The following information is shown:
• Existing certificate enrollment objects are listed in the Name column.
Use the search field (the magnifying glass) to filter the list.

668
Adding Certificate Enrollment Objects
• The enrollment type of each object is shown in the Type column. The following enrollment methods
can be used:
• Self Signed—The managed device generates its own self signed root certificate.
• EST—Enrollment over Secure Transport is used by the device to obtain an identity certificate from
the CA.
• SCEP—(Default) Simple Certificate Enrollment Protocol is used by the device to obtain an identity
certificate from the CA.
• Manual—The process of enrolling is carried out manually by the administrator.
• PKCS12 File—Import a PKCS12 file on a Firepower Threat Defense managed device that supports
VPN connectivity. A PKCS#12, or PFX or P12 file holds the server certificate, any intermediate
certificates, and the private key in one encrypted file. Enter the Passphrase value for decryption.
• The Override column indicates whether the object allows overrides (a green check mark) or not (a red
X). If a number is displayed, it is the number of overrides in place.
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 609 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 669. Then install the certificate on
each managed, headend device.
Related Topics
Installing a Certificate Using Self-Signed Enrollment , on page 720
Installing a Certificate using EST Enrollment, on page 721
Installing a Certificate Using SCEP Enrollment, on page 720
Installing a Certificate Using Manual Enrollment, on page 722
Installing a Certificate Using a PKCS12 File, on page 723

You can use these objects with FTD devices. You must have Admin or Network Admin privileges to do this
task.
Procedure
Step 1 Open the Add Cert Enrollment dialog:

669
• Directly from Object Management: In the Objects > Object Management screen, choose PKI > Cert
Enrollment from the navigation pane, and press Add Cert Enrollment.
• While configuring a managed device: In the Devices > Certificates screen, choose Add > Add New
Certificate and click (+) for the Certificate Enrollment field.
Step 2 Enter the Name, and optionally, a Description of this enrollment object.
When enrollment is complete, this name is the name of the trustpoint on the managed devices with which it
is associated.
Step 3 Open the CA Information tab and choose the Enrollment Type.
• Self-Signed Certificate—The managed device, acting as a CA, generates its own self-signed root
certificate. No other information is needed in this pane.
Note When enrolling a self-signed certificate you must specify the Common Name (CN) in the
certificate parameters.
• EST—Enrollment over Secure Transport protocol. Specify the EST information. See Certificate Enrollment
Object EST Options, on page 671.
• SCEP—(Default) Simple Certificate Enrollment Protocol. Specify the SCEP information. See Certificate
Enrollment Object SCEP Options, on page 672.
• Manual
• CA Only—Select this checkbox to create only the CA certificate from the selected CA. An identity
certificate will not be created for this certificate.
If you do not select this checkbox, a CA certificate is not mandatory. You can generate the CSR
without having a CA certificate and obtain the identity certificate.
• CA Certificate—Paste CA certificate information in the box. You can also obtain a CA certificate
by copying it from another device.
You can leave this box empty if you choose to generate a CSR without the CA certificate.
• 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.
• Skip Check for CA flag in basic constraints of the CA Certificate—
Select this check box if you want to skip checking the basic constraints extension and the CA flag in a
trustpoint certificate.
Step 4 (Optional) Open the Certificate Parameters tab and specify the certificate contents. See Certificate Enrollment
Object Certificate Parameters, on page 672.
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 673.
Step 6 (Optional) Click the Revocation tab, and specify the revocation options: See Certificate Enrollment Object
Revocation Options, on page 675.

670
Certificate Enrollment Object EST Options
Step 7 Allow Overrides of this object if desired. See Object Overrides, on page 609 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 EST Enrollment, on page 721
Certificate Enrollment Object EST Options
Firepower Management Center Navigation Path

Objects > Object Management, then from the navigation pane choose PKI > Cert Enrollment. Click (+)
Add Cert Enrollment to open the Add Cert Enrollment dialog, and select the CA Information tab.
Fields
Enrollment Type—set to EST.
Note • EST enrollment type does not support EdDSA key.

• EST's ability to auto-enroll a device when its certificate expires is not supported.
Enrollment URL—The URL of the CA server to which devices should attempt to enroll.
Use an HTTPS URL in the form of https://CA_name:port, where CA_name is the host DNS name or IP
address of the CA server. The port number is mandatory.
Username—The username to access the CA server.
Password / Confirm Password—The password to access the CA server.
Fingerprint—When retrieving the CA certificate using EST, 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.
Source Interface—The interface that interacts with the CA server. By default, the diagnostic interface is
displayed. To configure a data interface as the source interface, choose the respective security zone or interface
group object.
Ignore EST Server Certificate Validations—The EST server certificate validation is done by default. Check
the check box if you want to ignore FTD validating EST server certificate.

671
Certificate Enrollment Object SCEP Options
Certificate Enrollment Object SCEP Options

Objects > Object Management, then from the navigation pane choose PKI > PKI Enrollment. Press (+)
Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the CA Information tab.
Fields
Enrollment Type—set to SCEP.
Enrollment URL—The URL of the CA server to which devices should attempt to enroll.
Use an HTTP URL in the form of 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.
Certificate Enrollment Object Certificate Parameters

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

672
Certificate Enrollment Object Key Options

Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the Certificate Parameters tab.
Fields
Enter all information using the standard LDAP X.500 format.
• Include FQDN—Whether to include the device’s fully qualified domain name (FQDN) in the certificate
request. Choices are:
• Use Device Hostname as FQDN
• Don't use FQDN in certificate
• Custom FQDN—Select this and then specify it in the Custom FQDN field that displays.
• Include Device's IP Address—The interface whose IP address is included in the certificate request.
• Common Name (CN)—The X.500 common name to include in the certificate.
Note When enrolling a self-signed certificate you must specify the Common Name
(CN) in the certificate parameters.
• Organization Unit (OU)—The name of the organization unit (for example, a department name) to
include in the certificate.
• Organization (O)—The organization or company name to include in the certificate.
• Locality (L)—The locality to include in the certificate.
• State (ST)—The state or province to include in the certificate.
• County Code (C)—The country to include in the certificate. These codes conform to ISO 3166 country
abbreviations, for example "US" for the United States of America.
• Email (E)—The email address to include in the certificate.
• Include Device's Serial Number—Whether to include the serial number of the device in the certificate.
The CA uses the serial number to either authenticate certificates or to later associate a certificate with a
particular device. If you are in doubt, include the serial number, as it is useful for debugging purposes.
Certificate Enrollment Object Key Options

Objects > Object Management, then from the navigation pane choose PKI > Cert Enrollment. Press (+)
Add Cert Enrollment to open the Add Cert Enrollment dialog, and select the Key tab.
Fields
• Key Type—RSA, ECDSA, EdDSA.

673
PKI Enrollment of Certificates with Weak-Crypto
Note • For EST enrollment type, do not select EdDSA key as it is not supported.
• EdDSA is supported only in Site-to-Site VPN topologies.
• EdDSA is not supported as an identity certificate for the Remote Access
VPN.
• Key Name—If the key pair you want to associate with the certificate already exists, this field specifies
the name of that key pair. If the key pair does not exist, this field specifies the name to assign to the key
pair that will be generated during enrollment. If you do not specify a name, the fully qualified domain
name (FQDN) key pair is used instead.
• Key Size—If the key pair does not exist, defines the desired key size (modulus), in bits. The recommended
size is 2048 bits. The larger the modulus size, the more secure the key. However, keys with larger modulus
sizes take longer to generate (a minute or more when larger than 512 bits) and longer to process when
exchanged.
Important • On FMC and FTD Versions 7.0 and higher, you cannot enroll certificates
with RSA key sizes smaller than 2048 bits and keys using SHA-1 with the
RSA Encryption algorithmn. However, you can use PKI Enrollment of
Certificates with Weak-Crypto to allow certificates that use SHA-1 with
RSA Encryption algorithm and smaller key size.
• You cannot generate RSA keys with sizes smaller than 2048 bits for FTD
7.0, even when you enable the weak-crypto option.
• 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.
PKI Enrollment of Certificates with Weak-Crypto

SHA-1 hashing signature algorithm, and RSA key sizes that are smaller than 2048 bits for certification are
not supported on FMC and FTD Version 7.0 and higher. You cannot enroll certificates with RSA key sizes
that are smaller than 2048 bits.
To override these restrictions on FMC 7.0 managing FTDs running Versions lesser than 7.0, you can use the
enable weak-crypto option on the FTD. We do not recommend you to permit weak-crypto keys, because, such
keys are not as secure as the ones with higher key sizes.

674
Certificate Enrollment Object Revocation Options
Note FTD 7.0 or higher does not support generating RSA keys with sizes smaller than 2048 bits even when you
permit weak-crypto.
To enable weak-crypto on the device, navigate to the Devices > Certificates page. Click the Enable
Weak-Crypto ( ) button provided against the FTD device. When the weak-crypto option is enabled, the
button changes to . By default, the weak-crypto option is disabled.
Note When a certificate enrollment fails due to weak cipher usage, the FMC displays a warning message prompting
you to enable the weak-crypto option. Similarly, when you turn on the enable weak-crypto button, the FMC
displays a warning message before enabling weak-crypto configuration on the device.
Upgrading Earlier Versions to Firepower Threat Defense 7.0

When you are upgrading to FTD 7.0, the existing certificate configurations are retained. However, if those
certificates have RSA keys smaller than 2048 bits and use SHA-1 encryption algorithm, they cannot be used
to establish VPN connections. You must either procure a certificate with RSA key sizes bigger than 2048 bits
or enable the permit weak-crypto option for VPN connections.
Certificate Enrollment Object Revocation Options

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

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

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

675
Key Chain Objects
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.
Key Chain Objects

To enhance data security and protection of devices, rotating keys for authenticating IGP peers that have a
duration of 180 days or less is introduced. The rotating keys prevent any malicious user from guessing the
keys used for routing protocol authentication and thereby protecting the network from advertising incorrect
routes and redirecting traffic. Changing the keys frequently reduces the risk of them eventually being guessed.
When configuring authentication for routing protocols that provide key chains, configure the keys in a key
chain to have overlapping lifetimes. This helps to prevent loss of key-secured communication due to absence
of an active key. The rotating keys are applicable only for OSPFv2 protocol. If the key lifetime expires and
no active keys are found, OSPF uses the last valid key to maintain the adjacency with peers.
Note Only MD5 cryptographic algorithm is used for authentication.
Lifetime of a Key
To maintain stable communications, each device stores key chain authentication keys and uses more than one
key for a feature at the same time. Based on the send and accept lifetimes of a key, key chain management
provides a secured mechanism to handle key rollover. The device uses the lifetimes of keys to determine
which keys in a key chain are active.
Each key in a key chain has two lifetimes:
• Accept lifetime—The time interval within which the device accepts the key during key exchange with
another device.
• 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.

676
Creating Key Chain Objects
Creating Key Chain Objects

Procedure

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

Step 6 Specify the key identifier in the Key ID field.
The key id value can be between 0 and 255. Use the value 0 only when you want to signal an invalid key.
Step 7 The Algorithm field and the Crypto Encryption Type field displays the supported algorithm and the
encryption type, namely MD5 and Plain Text respectively.
Step 8 Enter the password in the Crypto Key String field, and re-enter the password in the Confirm Crypto Key
String field.
• The password can be of a maximum length of 80 characters.
• The passwords cannot be a single digit nor those starting with a digit followed by a white space. For
example, "0 pass" or "1" are invalid.
Step 9 To set the time interval for a device to accept/send the key during key exchange with another device, provide
the lifetime values in the Accept Lifetime and Send Lifetime fields:
Note The Date Time values default to UTC timezones.
The end time can be the duration, the absolute time when the accept/send lifetime ends, or never expires. The
default end time is DateTime.
Following are the validation rules for the start and end values:
• Start lifetime cannot be null when the end lifetime is specified.
• The start lifetime for accept or send lifetime must be earlier than the respective end lifetime.
Step 10 Click Add.

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


677
DNS Server Group Objects
Step 12 Click Save.
What to do next
DNS Server Group Objects

Domain Name System (DNS) servers resolve fully-qualified domain names (FQDN), such as
www.example.com, to IP addresses.
Creating DNS Server Group Objects

Procedure

Step 2 Click DNS Server Group from the network objects list.
Step 3 Click Add DNS Server Group.
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.
Step 8 Click Save.
What to do next
The DNS servers configured in the DNS server group should be assigned to interface objects in the DNS
platform settings. For more information, see Configure DNS, on page 1427.

678
About Dynamic Objects
About Dynamic Objects

A dynamic object is an IP address, with or without or classless inter-domain routing (CIDR), that can be used
in access control rules much like a network object. Differences follow:
• A dynamic object does not need to be deployed. It takes effect as soon as it's updated.
• A dynamic object does not support fully-qualified domain names or address ranges.
• You must update the dynamic object IP address using an API.
Related Topics
Add or Edit a Dynamic Object, on page 679
Add or Edit a Dynamic Object

This procedure discusses how to add or edit a dynamic object, which is a group of IP addresses, with or without
or classless inter-domain routing (CIDR), that can be used in access control rules much like a network object.
Before you begin

Consult the Firepower Management Center REST API Quick Start Guide for information about using the
object services API to populate the IP object with an address. Dynamic objects do not require deployment.
Procedure
Step 1 Click Objects > Object Management.

Step 2 Click External Attributes > Dynamic Objects.
Step 3 Click Add Dynamic Object or Edit ( ).
Step 4 Enter a Name for the object and an optional Description.
Step 5 From the Type list, click IP.
What to do next
If necessary, update the dynamic object using the API. Deployment is not required.
SLA Monitor Objects

Each Internet Protocol Service Level Agreement (SLA) monitor defines a connectivity policy to a monitored
address and tracks the availability of a route to the address. The route is periodically checked for availability
by sending ICMP echo requests and waiting for the response. If the requests time out, the route is removed
from the routing table and replaced with a backup route. SLA monitoring jobs start immediately after
deployment and continue to run unless you remove the SLA monitor from the device configuration (that is,
they do not age out). The Internet Protocol Service Level Agreement (SLA) Monitor Object is used in the

679
SLA Monitor Objects
Route Tracking field of an IPv4 Static Route Policy. IPv6 routes do not have the option to use SLA monitor
via route tracking.
You can use these objects with FTD devices.
Procedure
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.

680
Prefix Lists
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 621. The host will be configured on a device
only if the device includes the selected interfaces or zones.
Step 14 Click Save.
Prefix Lists
You can create prefix list objects for IPv4 and IPv6 to use when you are configuring route maps, policy maps,
OSPF Filtering, or BGP Neighbor Filtering.
Configure IPv6 Prefix List

Use the Configure IPv6 Prefix list page to create, copy and edit prefix list objects. You can create prefix list
objects to use when you are configuring route maps, policy maps, OSPF Filtering, or BGP Neighbor Filtering.
You can use this object with FTD devices.
Procedure
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

681
Step 12 Click Save.

Use the Configure IPv4 Prefix list page to create, copy and edit prefix list objects. You can create prefix list
objects to use when you are configuring route maps, policy maps, OSPF Filtering, or BGP Neighbor Filtering.
Procedure
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 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.

682
Route Maps
Before you begin

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

683
Route Maps
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.
• Others — Match routes or traffic based on the following criteria.

a. Enter the metric values to use for matching in the Metric Route Value field, to enable matching the
metric of a route. You can enter multiple values separated by commas. This setting allows you to
match any routes that have a specified metric. The metric values can range from 0 to 4294967295.
b. Enter the tag values to use for matching in the Tag Values field. You can enter multiple values
separated by commas. This setting allows you to match any routes that have a specified security
group tag. The tag values can range from 0 to 4294967295.
c. Check the appropriate Route Type option to enable matching of the route type. Valid route types
are External1, External2, Internal, Local, NSSA-External1, and NSSA-External2. You can choose
more than one route type from the list.
Step 7 Click the Set Clauses tab to set routes/traffic based on the following criteria, which you select in the table of
contents:
• Metric Values — Set either Bandwidth, all of the values or none of the values.
a. Enter a metric value or bandwidth in Kbits per second in the Bandwidth field. Valid values are an
integer value in the range from 0 to 4294967295.
b. Select to specify the type of metric for the destination routing protocol, from the Metric Type
drop-down list. Valid values are : internal, type-1, or type-2.
• BGP Clauses — Set BGP routes based on the following criteria; select the tab to define the criteria.
a. Click the AS Path tab to modify an autonomous system path for BGP routes.
1. Enter an AS path number in the Prepend AS Path field to prepend an arbitrary autonomous
system path string to BGP routes. Usually the local AS number is prepended multiple times,
increasing the autonomous system path length. If you specify more than one AS path number
then the route can prepend either AS number.
2. Enter an AS path number in the Prepend Last AS to AS Path field to prepend the AS path with
the last AS number. Enter a value for the AS number from 1 to 10.
3. Check the Convert route tag into AS path check box to convert the tag of a route into an
autonomous system path.
b. Click the Community List tab to set the community attributes.

1. Click the None radio button, to remove the community attribute from the prefixes that pass the
route map.

684
Access List
2. Click the Specific Community radio button, to enter a community number, if applicable. Valid
values are from 1 to 4294967295.
3. Check the Add to existing communities check box, to add the community to the already existing
communities.
4. Select the Internet, No-Advertise, or No-Export check-boxes to use one of the well-known
communities.
c. Click the Others tab to set additional attributes.

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

Step 10 Click Save.
Access List
An access list object, also known as an access control list (ACL), selects the traffic to which a service will
apply. You use these objects when configuring particular features, such as route maps, for 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.

685
Configure Extended ACL Objects
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.
Configure Extended ACL Objects

Use extended ACL objects when you want to match traffic based on source and destination addresses, protocol
and port, or if the traffic is IPv6.
Procedure
Step 1 Select Objects > Object Management and choose Access Control Lists > Extended from the table of
contents.
• Click Add Extended ACL to create a new object.
• Click Edit ( ) to edit an existing object.
Step 3 In the Extended ACL Object dialog box, enter a name for the object (no spaces allowed), and configure the
access control entries:
a) Do one of the following:
• Click Add to create a new entry.
• Click Edit ( ) to edit an existing entry.
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.

686
Configure Standard ACL Objects
• Select the desired port objects from the Available list and click Add to Source or Add to Destination.
You can create new objects by clicking the + button above the list. The object can specify TCP/UDP
ports, ICMP/ICMPv6 message types, or other protocols (including “any”). However, the source port,
which you typically would leave empty, accepts TCP/UDP only. You cannot select port groups.
• Type or select a port or protocol in the edit box below the source or destination list and click Add.
Note To get an entry that applies to all IP traffic, select a destination port object that specifies “all”
protocols.
e) Click Add to add the entry to the object.

f) If necessary, click and drag the entry to move it up or down in the rule order to the desired location.
Repeat the process to create or edit additional entries in the object.
Step 5 Click Save.
Configure Standard ACL Objects

Use standard ACL objects when you want to match traffic based on destination IPv4 address only. Otherwise,
use extended ACLs.
Procedure
Step 1 Select Objects > Object Management and choose Access Control Lists > Standard from the table of
contents.
• 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.
• Click Edit ( ) to edit an existing 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.

687
AS Path Objects
c) Click Add to add the entry to the object.

d) If necessary, click and drag the entry to move it up or down in the rule order to the desired location.
Repeat the process to create or edit additional entries in the object.
Step 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.
Procedure
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 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

688
Community Lists
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.
Procedure
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.
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.
b) Specify the regular expression in the Expressions field.
Step 7 Click Add.
Step 9 Click Save.

689
Policy Lists
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.
Procedure
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.
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.
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.

690
VPN Objects
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 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.
FTD IKE Policies

Internet Key Exchange (IKE) is a key management protocol that is used to authenticate IPsec peers, negotiate
and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs). The IKE
negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which
enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes SAs for
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 1121.
Configure IKEv1 Policy Objects

Use the IKEv1 Policy page to create, delete, or edit an IKEv1 policy object. These policy objects contain the
parameters required for IKEv1 policies.
Procedure
Step 1 Choose Objects > Object Management and then VPN > IKEv1 Policy from the table of contents.

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

When deciding which encryption and Hash Algorithms to use for the IKEv1 policy, your choice is limited to
algorithms supported by the peer devices. For an extranet device in the VPN topology, you must choose the
algorithm that matches both peers. For IKEv1, select one of the options. For a full explanation of the options,
see Deciding Which Encryption Algorithm to Use, on page 1127.
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 1128.
Step 8 Set the Diffie-Hellman Group.

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 1128.
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.

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

The new IKEv1 policy is added to the list.

Use the IKEv2 policy dialog box to create, delete, and edit an IKEv2 policy object. These policy objects
contain the parameters required for IKEv2 policies.
Procedure
Step 1 Choose Objects > Object Management and then VPN > IKEv2 Policy from the table of contents.
Previously configured policies are listed including system defined defaults. Depending on your level of access,
you may Edit ( ), View ( ), or Delete ( ) a policy.
Step 2 Choose Add ( )Add IKEv2 Policy to create a new policy.

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

A description of the policy object. A maximum of 1024 characters is allowed.
Step 5 Enter the Priority.

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

693
FTD IPsec Proposals
Step 8 Choose the Encryption Algorithm used to establish the Phase 1 SA for protecting Phase 2 negotiations.
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 1127.
Step 9 Choose the PRF Algorithm.

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

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

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

IPsec Proposals (or Transform Sets) are used when configuring VPN topologies. During the IPsec security
association negotiation with ISAKMP, the peers agree to use a particular proposal to protect a particular data
flow. The proposal must be the same for both peers.
There are separate IPsec proposal objects based on the IKE version, IKEv1, or IKEv2:
• When you create an IKEv1 IPsec Proposal (Transform Set) object, you select the mode in which IPsec
operates, and define the required encryption and authentication types. You can select single options for
the algorithms. If you want to support multiple combinations in a VPN, create multiple IKEv1 IPsec
Proposal objects.
• When you create an IKEv2 IPsec Proposal object, you can select all of the encryption and Hash Algorithms
allowed in a VPN. During IKEv2 negotiations, the peers select the most appropriate options that each
support.
The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec Proposals. It provides
authentication, encryption, and antireplay services. ESP is IP protocol type 50.
Note We recommend using both encryption and authentication on IPsec tunnels.

694
Configure IKEv1 IPsec Proposal Objects
Procedure
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
Step 4 Enter a Description for this Proposal.

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 1127.
Step 6 Select an option for ESP Hash.

For a full explanation of the options, see Deciding Which Hash Algorithms to Use, on page 1128.
Step 7 Click Save

The new Proposal is added to the list.
Procedure
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 4 Enter a Description for this Proposal.


695
FTD Group Policy Objects
Step 5 Choose the ESP Hash method, the hash or integrity algorithm to use in the Proposal for authentication.
Note FTD does not support IPSec tunnels with NULL encryption. Make sure that you do not choose
NULL encryption for IPSec IKEv2 proposal.
For IKEv2, select all the options you want to support for ESP Hash. For a full explanation of the options,
see Deciding Which Hash Algorithms to Use, on page 1128.
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 1127.
Step 7 Click Save

The new Proposal is added to the list.
FTD Group Policy Objects

A group policy is a set of attribute and value pairs, stored in a group policy object, that define the remote
access VPN experience. For example, in the group policy object, you configure general attributes such as
addresses, protocols, and connection settings.
The group policy applied to a user is determined when the VPN tunnel is being established. The RADIUS
authorization server assigns the group policy, or it is obtained from the current connection profile.
Note There is no group policy attribute inheritance on the 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 696
Configure Group Policy Objects

See FTD Group Policy Objects, on page 696.

696
Group Policy General Options
Procedure
Step 1 Choose Objects > Object Management > VPN > Group Policy.
Previously configured policies are listed including the system default. Depending on your level of access, you
may edit, view, or delete a group policy.
Step 2 Click Add Group Policy or choose a current policy to edit.

Step 3 Enter a Name and optionally a Description for this policy.
The name can be up to 64 characters, spaces are allowed. The description can be up to 1,024 characters.
Step 4 Specify the General parameters for this Group Policy as described in Group Policy General Options, on page
697.
Step 5 Specify the AnyConnect parameters for this Group Policy as described in Group Policy AnyConnect Options,
on page 699.
Step 6 Specify the Advanced parameters for this Group Policy as described in Group Policy Advanced Options, on
page 702.
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.
VPN Protocols Fields

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

697
2. RADIUS attribute for Group Policy

3. Address Pool in Group Policy mapped to a Connection Profile
4. IPv4Address Pool in Connection Profile
Some limitations around using IP address pools in Group Policy:

• IPv6 address pool is not supported.
• Maximum of six IPv4 address pools can be configured in a Group Policy.
• Deployment failures are seen when address pools in use are modified. You must logoff all the users
before making any changes to the address pools.
• When address pools are renamed or overlapping address pools are configured, deployment could fail.
You must deploy the changes by removing the old address pool and later deploying the changed address
pool.
Some troubleshooting commands :
• show ip local pool <address-pool-name>
• show vpn-sessiondb detail anyconnect
• vpn-sessiondb loggoff all noconfirm
Banner Fields
Specifies the banner text to present to users at login. The length can be up to 491 characters. There is no default
value. The IPsec VPN client supports full HTML for the banner, however, the AnyConnect client supports
only partial HTML. To ensure that the banner displays properly to remote users, use the /n tag for IPsec clients,
and the <BR> tag for SSL clients.
DNS/WINS Fields
Domain Naming System (DNS) and Windows Internet Naming System (WINS) servers. Used for AnyConnect
client name resolution.
• Primary DNS Server and Secondary DNS Server—Choose or create a Network Object which defines
the IPv4 or IPv6 addresses of the DNS servers you want this group to use.
• Primary WINS Server and Secondary WINS Server—Choose or create a Network Object containing
the IP addresses of the WINS servers you want this group to use.
• DHCP Network Scope—Choose or create a Network Object containing a routeable IPv4 address on
the same subnet as the desired pool, but not within the pool. The DHCP server determines which subnet
this IP address belongs to and assigns an IP address from that pool. If not set properly, deployment of
the VPN policy fails.
If you configure DHCP servers for the address pool in the connection profile, the DHCP scope identifies
the subnets to use for the pool for this group. The DHCP server must also have addresses in the same
subnet identified by the scope. The scope allows you to select a subset of the address pools defined in
the DHCP server to use for this specific group.
If you do not define a network scope, the DHCP server assigns IP addresses in the order of the address
pools configured. It goes through the pools until it identifies an unassigned address.

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

Split tunneling directs some network traffic through the VPN tunnel (encrypted) and the remaining network
traffic outside the VPN tunnel (unencrypted or “in the clear”).
• IPv4 Split Tunneling / IPv6 Split Tunneling—By default, split tunneling is not enabled. For both IPv4
and IPv6 it is set to Allow all traffic over tunnel. Left as is, all traffic from the endpoint goes over the
VPN connection.
To configure split tunneling, choose the Tunnel networks specified below or Exclude networks
specified below policy. Then configure an access control list for that policy.
• Split Tunnel Network List Type—Choose the type of Access List you are using. Then choose or create
a Standard Access List or Extended Access List. See Access List, on page 685 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

These specifications apply to the operation of the AnyConnect VPN client.
Navigation
Objects > Object Management > VPN > Group Policy. Click Add Group Policy or choose a current policy
to edit. Then select the AnyConnect tab.
Profile Fields
Profile—Choose or create a file object containing an AnyConnect Client Profile. See FTD File Objects, on
page 703 for object creation details.

699
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.
Management Profile Fields

A Management VPN Tunnel provides connectivity to the corporate network whenever the endpoint is powered
up, even if end-user does not connect over VPN.
Management VPN Profile—The Management Profile file contains settings for enabling and establishing
Management VPN Tunnel on endpoint.
The Standalone Management VPN Tunnel profile editor can be used to create a new profile file or modify an
existing file. You can download the profile editor from Cisco Software Download Center.
For more information about adding a profile file, see FTD File Objects, on page 703.
Client Modules Fields

Cisco AnyConnect VPN client offers enhanced security through various built-in modules. These modules
provide services such as web security, network visibility into endpoint flows, and off-network roaming
protection. Each client module includes a client profile that includes a group of custom configurations as per
your requirement.
The following AnyConnect modules are optional and you can configure these modules to be downloaded
when a VPN user downloads AnyConnect:
• AMP Enabler —Deploys advanced malware protection (AMP) for endpoints.
• DART—Captures a snapshot of system logs and other diagnostic information, which can be sent to the
Cisco TAC for troubleshooting.
• ISE Posture —Uses the OPSWAT library to perform posture checks to assess an endpoint's compliance.
• Network Access Manager —Provides 802.1X (Layer 2) and device authentication for access to both
wired and wireless networks.
• Network Visibility —Enhances the enterprise administrator's ability to do capacity and service planning,
auditing, compliance, and security analytics.
• Start Before Login —Forces the user to connect to the enterprise infrastructure over a VPN connection
before logging on to Windows by starting AnyConnect before the Windows login dialog box appears.
• Umbrella Roaming Security —Provides DNS-layer security when no VPN is active.
• Web Security —Analyzes the elements of a web page, allows acceptable content, and blocks malicious
or unacceptable content based on a defined security policy.
Click Add and select the following for each client module:
• Client Module—Select an AnyConnect module from the list.
• Profile to download—Choose or create a file object containing an AnyConnect Client Profile. See FTD
File Objects, on page 703 for object creation details.

700
• Enable module download—Select to enable endpoints to download the client module along with the
profile. If not selected, the endpoints can download only the client profile.
Use the GUI-based AnyConnect Profile Editor, an independent configuration tool to create a client profile
for each module. Download the AnyConnect 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.
SSL Settings Fields

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

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

701
Group Policy Advanced Options
• SSL rekey—Enables the client to rekey the connection, renegotiating the crypto keys and initialization
vectors, increasing the security of the connection. This is disabled by default. When enabled, the
renegotiation can be done at a specified interval and rekey the existing tunnel or create a new tunnel by
setting the following fields:
• Method—Available when SSL rekey is enabled. Create a New Tunnel (default), or renegotiate,
the Existing Tunnel's specifications.
• Interval—Available when SSL rekey is enabled. Set to a default of 4 minutes with a range of
4-10080 minutes (1 week).
• Client Firewall Rules—Use the Client Firewall Rules to configure firewall settings for the VPN client's
platform. Rules are based on criteria such as source address, destination address, and protocol. Extended
Access Control List building block objects are used to define the traffic filter criteria. Choose or create
an Extended ACL for this group policy. Define a Private Network Rule to control data flowing to the
private network, a Public Network Rule to control data flowing "in the clear", outside of the established
VPN tunnel, or both.
Note Ensure that the ACL contains only TCP/UDP/ICMP/IP ports and source network
as any, any-ipv4 or any-ipv6.
Only VPN clients running Microsoft Windows can use these firewall settings.
Custom Attributes Fields

This section lists the AnyConnect Custom attributes that are used by the AnyConnect client to configure
features such as Per App VPN, Allow or defer upgrade, and Dynamic split tunneling. Click Add to add custom
attributes to the group policy.
1. Select an AnyConnect Attribute:Per App VPN, Allow Defer Update, or Dynamic Split Tunneling.
2. Select a Custom Attribute Object from the list.
Note Click Add (+) to create a new custom attribute object for the selected AnyConnect attribute. You can also
create a custom attribute object at Objects > Object Management > VPN > Custom Attribute. See Add
AnyConnect Custom Attributes Objects, on page 706.
3. Click Add to save the attributes to the group policy and then click Save to save the changes to the group
policy.
Related Topics
Group Policy Advanced Options
Navigation Path
Objects > Object Management > VPN > Group Policy, click Click Add Group Policy or choose a current
policy to edit., then select the Advanced tab.

702
FTD File Objects
Traffic Filter Fields

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

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

Use the Add and Edit File Object dialog boxes to create, and edit file objects. File objects represent files used
in configurations, typically for remote access VPN policies. They can contain AnyConnect Client Profile and
AnyConnect Client Image files.
Profiles are also created for each AnyConnect module and AnyConnect Management VPN using independent
profile editors and deployed to administrator-defined end user requirements and authentication policies on
endpoints as part of AnyConnect, and they make the preconfigured network profiles available to end users.
When you create a file object, the Firepower Management Center makes a copy of the file in its repository.
These files are backed up whenever you create a backup of the database, and they are restored if you restore
the database. When copying a file to the Firepower Management Center platform to be used in a file object,
do not copy the file directly to the file repository.

703
FTD File Objects
When you deploy configurations that specify a file object, the associated file is downloaded to the device in
the appropriate directory.
You can click one of the following options against each file:
• Download —Click to download an AnyConnect file.
• Edit —Modify the file object details.
• Delete —Delete an AnyConnect file object. When you delete a file object, the associated file is not
deleted from the file repository, only the object is deleted.
Navigation Path
Objects > Object Management > VPN > AnyConnect File > Add AnyConnect File.
Fields
• Name—Enter the name of the file to identify the file object; you can add up to 128 characters.
• File Name—Click Browse to select the file. The file name and full path of the file are added when you
select the file.
• File Type—Choose the file type corresponding to the file you have selected. The following file types
are available:
• AnyConnect Client Image—Select this type when you add the AnyConnect client image you have
downloaded from the Cisco Software Download Center.
You can associate any new or additional AnyConnect client images to the remote access VPN policy.
You can also unassociate the unsupported or end of life client packages that are no longer required.
• AnyConnect VPN Profile—Choose this type for an AnyConnect VPN profile file.
The profile file is created using the GUI-based AnyConnect Profile Editor, an independent
configuration tool. See the AnyConnect Profile Editor chapter in the appropriate release of the Cisco
AnyConnect Secure Mobility Client Administrator Guide for details.
• AnyConnect Management VPN Profile—Select this type when you add a profile file for an
AnyConnect management VPN tunnel.
Download the AnyConnect VPN Management Tunnel Standalone Profile Editor from Cisco
Software Download Center if you have not done already and create a profile with required settings
for the AnyConnect management VPN tunnel.
• AMP Enabler Service Profile—The profile is used for the AnyConnect AMP Enabler. The AMP
Enabler along with this profile is pushed to the endpoints from FTD when a remote access VPN
user connects to the VPN.
• Feedback Profile—You can add a Customer Experience Feedback profile and select this type to
receive information about the features and modules customers have enabled and use.
• ISE Posture Profile—Choose this option if you are adding a profile file for the AnyConnect ISE
Posture module.
• NAM Service Profile—Configure and add the NAM profile file using the Network Access Manager
profile editor.

704
FTD Certificate Map Objects
• Network Visibility Service Profile—Profile file for AnyConnect Network Visibility module. You
can create the profile using the NVM profile editor.
• Umbrella Roaming Security Profile—You must select this file type if you are deploying the
Umbrella Roaming Security module using the .json file created using the profile editor.
• Web Security Service Profile—Select this file type when you add a prole file for the Web security
module.
• Description—Add an optional description.
Related Topics
Cisco AnyConnect Secure Mobility Client Image, on page 1187
Group Policy AnyConnect Options, on page 699
FTD Certificate Map Objects

Certificate Map objects are a named set of certificate matching rules. These objects are used to provide an
association between a received certificate and a Remote Access VPN connection profile. Connection Profiles
and Certificate Map objects are both part of a remote access VPN policy. If a received certificate matches the
rules contained in the certificate map, the connection is "mapped", or associated with the specified connection
profile. The rules are in priority order, they are matched in the order they are shown in the UI. The matching
ends when the first rule within the Certificate Map object results in a match.
Navigation
Objects > Object Management > VPN > Certificate Map
Fields
• Name—Identify this object so it can be referred to from other configurations, such as Remote Access
VPN.
• Mapping Criteria—Specify the contents of the certificate to evaluate. If the certificate satisifies these
rules, the user will be mapped to the connection profile containing this object.
• Component—Select the component of the client certificate to use for the matching rule.
• Field—Select the field for the matching rule according to the Subject or the Issuer of the client
certificate.
If the Field is set to Alternative Subject or Extended Key Usage the Component will be frozen as
Whole Field
• Operator—Select the operator for the matching rule as follows:
• Equals—The certificate component must match the entered value. If they do not match exactly,
the connection is denied.
• Contains—The certificate component must contain the entered value. If the component does
not contain the value, the connection is denied.
• Does Not Equal—The certificate component cannot equal the entered value. For example, for
a selected certificate component of Country, and an entered value of US, if the client county
value equals US, then the connection is denied.

705
AnyConnect Custom Attributes Objects
• 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 1189
AnyConnect Custom Attributes Objects

Custom attributes are used by the AnyConnect client to configure features such as Per App VPN, Allow or
defer upgrade, and Dynamic split tunneling. A custom attribute has a type and a named value. The type of
the attribute is defined first, then one or more named values of this type can be defined. You can create an
AnyConnect custom attributes objects using the FMC, add the objects to a group policy and associate the
group policy with a remote access VPN to enable the features for the VPN clients.
FTD supports the following features using the custom attribute objects:
• Per App VPN—The Per App VPN feature helps identify an app and tunnel only applications allowed
by the FTD administrator over the VPN.
• Allow or defer upgrade— Deferred Upgrade allows the AnyConnect user to delay download of the
AnyConnect client upgrade. When a client update is available, You can configure the attributes for
AnyConnect to open a dialog asking the user if they would like to update, or to defer the upgrade.
• Dynamic Split Tunneling— With dynamic split tunneling, you can provision policies that either include
or exclude IP addresses or networks from the VPN tunnel. Dynamic split tunneling is configured by
creating a custom attribute and adding it to a group policy.
For step-by-step instructions to configure AnyConnect custom attributes, see Add AnyConnect Custom
Attributes Objects, on page 706 and
For details about the specific custom attributes to configure for a feature, see the Cisco AnyConnect Secure
Mobility Client Administrator Guide for the AnyConnect release you are using.
Related Topics
Add AnyConnect Custom Attributes Objects
Before you begin

Ensure that you have done the following before adding a custom attribute object for Per App VPN:
• Per App VPN must be properly configured via MDM and each device must be enrolled to the MDM
server
• Create a base64 encoded string for each app using the Cisco AnyConnect Enterprise Application Selector
Tool.
1. Download the Cisco AnyConnect Enterprise Application Selector Tool from here.

706
Add AnyConnect Custom Attributes Objects
2. Open the Application Selection Tool and select the mobile platform from the drop down menu located
on the upper left.
3. Add rule by entering Friendly name and App ID; rest of the fields are optional.
4. On the menu bar, click on Policy. The encoded base65 rule is displayed in its encoded format.
5. Select and copy the policy string, and save it to use later when you create the AnyConnect Custom
Attributes object.
Procedure
Step 1 Choose Objects > Object Management > VPN > Custom Attributes.
Step 2 Click Add AnyConnect Custom Attributes.
Step 3 Enter a Name and optionally a Description for the attribute.
Step 4 Select an AnyConnect Attribute from the list:
• Per App VPN — Select this option and specify the base64 encoded string in the Attribute Value box.
• Allow Defer Update—Select one of the following options and specify the required information to allow
or defer AnyConnect client update:
• Show the prompt until user takes action—Display the prompt to the VPN user until the user
chooses to allow or defer the VPN client update.
• Show the prompt until times out—Choose this option to display the prompt for a specified duration
and specify the duration int the Timeout box.
• Do not show the prompt and take automatic action—Choose this option to automatically allow
or defer the VPN update.
• Default Action—Select the default action to be taken when the user does not respond, or when you
want to configure an automatic action without the user's intervention. You can choose to update the
AnyConnect client or postpone the update.
• Minimum Version—Specify the minimum AnyConnect version to be present on the client system
to allow or defer the update.
• Dynamic Split Tunneling—Select this option to include or exclude IP addresses or networks from the
VPN tunnel.
• Include domains—Specify domain names that will be included in the remote access VPN tunnel.
• Exclude domains—Specify domain names that will be excluded from the remote access VPN
tunnel.
Step 5 Select the Allow Overrides check box to allow object overrides.
Step 6 Click Save.
The custom attributes object is added to the list.

707
Add Custom Attributes to a Group Policy
What to do next
Associate the custom attributes with a group policy. See Add Custom Attributes to a Group Policy, on page
708 .
Add Custom Attributes to a Group Policy

You must associate AnyConnect custom attributes with a group policy to use them for remote access VPN
connections. You
Procedure
Step 1 Select Objects > Object Management > VPN > Group Policy.
Step 2 Add a new group policy or edit an existing group policy.
Step 3 Click AnyConnect > Custom Attributes.
Step 4 Click Add.
Step 5 Select an AnyConnect Attribute:Per App VPN, Allow Defer Update, or Dynamic Split Tunneling.
Step 6 Select a Custom Attribute Object from the list.
Note Click Add (+) to create a new custom attribute object for the selected AnyConnect attribute. You
can also create a custom attribute object at Objects > Object Management > VPN > Custom
Attribute. See Add AnyConnect Custom Attributes Objects, on page 706.
Step 7 Click Add to save the attributes to the group policy and then click Save to save the changes to the group
policy.
Related Topics
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.
Procedure
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.

708
FlexConfig Objects
• Mask—Identifies the subnet on which this IP address pool resides.

• Allow Overrides—Check this check box to enable object overrides. Click the expand arrow to show
the Overrides table. You can add a new override by clicking Add. See Object Overrides, on page 609
Step 3 Click Save.

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

709
RADIUS Server Groups
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
1299.
RADIUS Server Groups

RADIUS Server Group objects contain one or more references to RADIUS servers. These servers are used
to authenticate users logging in through Remote Access VPN connections.
Before you begin
Note You cannot override RADIUS Server Group Objects.
Procedure
Step 1 Select Objects > Object Management > AAA Server > 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 711 and RADIUS Server Group Options, on page 710 to configure this
object.
Step 3 Click Save
RADIUS Server Group Options

Navigation Path
Objects > Object Management > AAA Server > RADIUS Server Group. Choose and edit a configured
RADIUS Server Group object or add a new one.
Fields
• Name and Description—Enter a name and optionally, a description to identify this RADIUS Server
Group object.

710
RADIUS Server Options
• 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 711.
Related Topics
RADIUS Server Groups, on page 710
RADIUS Server Options

Navigation Path
Objects > Object Management > AAA Server > RADIUS Server Group. Choose and edit a listed RADIUS
Server Group object or add a new one. Then, in the RADIUS Server Group dialog, choose and edit a listed
RADIUS Server or add a new one.
Fields
• IP Address/Hostname—The network object that identifies the hostname or IP address of the RADIUS
server to which authentication requests will be sent. You may only select one, to add additional servers,
add additional RADIUS Server to the RADIUS Server Group list.

711
Add a Single Sign-on Server
Note Firepower Threat Defense now supports IPv6 IP addresses for RADIUS
authentication.
• Authentication Port—The port on which RADIUS authentication and authorization are performed. The
default is 1812.
• Key and Confirm Key— The shared secret that is used to encrypt data between the managed device
(client) and the RADIUS server.
The key is a case-sensitive, alphanumeric string of up to 127 characters. Special characters are permitted.
The key you define in this field must match the key on the RADIUS server. Enter the key again in the
Confirm field.
• Accounting Port—The port on which RADIUS accounting is performed. The default is 1813.
• Timeout— Session timeout for authentication.
Note The timeout value must be 60 seconds or more for RADIUS two factor
authentication. The default timeout value is 10 seconds.
• Connect Using —Establishes connectivity from Firepower Threat Defense to a RADIUS server using
a route lookup or using a specific interface. Select Routing to use the routing table. Or select Specific
Interface and choose a security zone/interface group or the Diagnostic interface (the default).
• 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 Group Options, on page 710

Before you begin
Obtain the following from your SAML identity provider:
• Identity Provider Entity ID URL
• Sign-in URL

712
• Sign-out URL
• Identity provider certificate and enroll the certificate in FTD using the FMC web interface (Devices >
Certificates)
For more information, see Configuring a SAML Single Sign-on Authentication, on page 1221.
Procedure
Step 1 Choose Object > Object Management > AAA Server > Single Sign-on Server.
Step 2 Click Add Single Sign-on Server and provide the following details:
• Name—The name of the SAML single sign-on server object.
• Identity Provider Entity ID—The URL that is defined in SAML IdP to identify a service provider
uniquely.
The URL for a page that serves a metadata XML that describes how the SAML Issuer is going to respond
to requests.
• Sign In URL—The URL for signing into the SAML identity provider server.
• Sign Out URL—The URL for signing out of the SAML identity provider server.
• Base URL—URL that will redirect the user back to FTD once the identity provider authentication is
done. This is the URL of the access interface configured for the FTD remote access VPN.
• Identity Provider Certificate—Certificate of the IdP enrolled into the FTD to verify the messages
signed by the IdP.
• Service Provider Certificate—FTD certificate, which will be used to sign the requests and build circle
of trust with IdP.
If you have not enrolled internal FTD certificates, click + to add and enroll a certificate. For more
information, see Managing FTD Certificates, on page 718.
• Request Signature—Select the encryption algorithm to sign the SAML single sign-on requests.
The signatures are listed from weakest to strongest: SHA1,SHA256, SHA384, SHA512. Select None to
disable encryption.
• Request Timeout—Specify the SAML assertion validity duration for the users to complete the single
sing-on request. The SAML IdP has two time outs: NotBefore and NotOnOrAfter. If you set a timeout
longer than the IdP's NotOnOrAfter timeout, the specified timeout is ignored and the NotOnOrAfter
timeout is selected. If the sum of the specified timeout and the NotBefore timeout is less than the
NotOnOrAfter time, FTD timeout overrides the timeout.
The timeout range is 1-7200 seconds; the default is 300 seconds.
• Enable IdP only accessible on Internal Network—Select this option if the SAML IdP resides on the
internal network. FTD acts as a gateway and establishes communication between the users and IdP using
an anonymous webvpn session.
• Request IdP re-authentication on Login—Select this option to authenticate user at each login even if
the previous IdP session is valid.
• Allow Overrides—Select this check box to allow overrides for this single sign-on server object.

713
History for Reusable Objects
Step 3 Click Save.
Related Topics
Configure AAA Settings for Remote Access VPN, on page 1178

Time-based ACL support for Snort 3 7.0 Time-based rules in access control and
prefilter policies are supported in Snort 3
as well.
EST for certificate enrollment 7.0 Support for Enrollment over Secure
Transport for certificate enrollment was
provided.
New/Modified Screens: New enrollment
options when configuring Objects > PKI
> Cert Enrollment > CA Information tab.
Management Center
Support for EdDSA certificate type 7.0 A new certificate key type- EdDSA was
added with key size 256.
New/Modified Screens: New certificate key
options when configuring Objects > PKI
> Cert Enrollment > Key tab.
Management Center
Restrictions on ciphers and key sizes 7.0 Certificates having SHA-1 with RSA
Encryption signature algorithm, and RSA
key sizes smaller than 2048 bits are not
supported. To override these restrictions on
existing certificates, you can enable the
weak-crypto option on FTD. However, you
cannot generate RSA keys with sizes
smaller than 2048 bits.
New/Modified Screens: New toggle button
when configuring Devices > Certificates.
Management Center

714
Security Intelligence feed options 6.7 New update frequency options (5 and 15
minutes) for custom Security Intelligence
feeds.
Update frequencies of less than 30 minutes
require an MD5 URL, to prevent
unnecessary downloads if the feed has not
changed.
New/Modified Screens: New frequency
choices when configuring Security
Intelligence > Network Lists and Feeds.
Management Center
Bulk upload of objects using a 6.7 Objects can be imported from a

comma-separated-values (csv) file comma-separated-values file. Up to 1000
objects can be imported in one attempt.
New/Modified Screens: The following
object types have a new Import Object
option in the Add [Object Type]
drop-down list.
• Distinguished Name > Individual
Objects
• Network Object
• Port
• URL
• VLAN Tag

Management Center
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.
Management Center

715
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.
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.
Management Center

716
CHAPTER 24
Firepower Threat Defense Certificate-Based
Authentication
• Requirements and Prerequisites for FTD Certificate-Based Authentication, on page 717
• Firepower Threat Defense VPN Certificate Guidelines and Limitations, on page 718
• Managing FTD Certificates, on page 718
• Installing a Certificate Using Self-Signed Enrollment , on page 720
• Installing a Certificate Using SCEP Enrollment, on page 720
• Installing a Certificate using EST Enrollment, on page 721
• Installing a Certificate Using Manual Enrollment, on page 722
• Installing a Certificate Using a PKCS12 File, on page 723
• Troubleshooting FTD Certificates, on page 723
• History for Firepower Threat Defense Certificate-Based Authentication, on page 724
Requirements and Prerequisites for FTD Certificate-Based

Authentication
Model Support
FTD
Supported Domains
Any
User Roles
Admin
Network Admin

717
Firepower Threat Defense VPN Certificate Guidelines and Limitations
Firepower Threat Defense VPN Certificate Guidelines and

Limitations
• When a PKI enrollment object is associated with and then installed on a device, the certificate enrollment
process starts immediately. The process is automatic for self-signed and SCEP enrollment types; it does
not require any additional administrator's action. Manual certificate enrollment requires administrator's
action.
• When the certificate 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 VPN Authentication Method.
• FTD devices support certificate enrollment using Microsoft Certificate Authority(CA) Service, and CA
Services provided on Cisco Adaptive Security Appliances(ASA) and Cisco IOS Router.
• FTD devices cannot be configured as a certificate authority (CA).
Guidlelines for Certificate Management Across Domains and Devices

• Certificate enrollment can be done in a child or parent domain.
• When enrollment is done from a parent domain, the certificate enrollment object also needs to be in the
same domain. If the trustpoint on a device is overridden in the child domain, the overridden value will
be deployed on the device.
• When the certificate enrollment is done on a device in a leaf domain, the enrollment will be visible to
the parent domain or another child domain. Also, adding additional certificates is possible.
• When a leaf domain is deleted, certificate enrollments on the contained devices will be automatically
removed.
• Once a device has certificates enrolled in one domain, it will be allowed to be enrolled in any other
domain. The certificates can be added in the the other domain.
• When you move a device from one domain to another, the certificates also get moved accordingly. You
will receive an alert to delete the enrollments on these devices.
Managing FTD Certificates

See PKI Infrastructure and Digital Certificates , on page 1129 for an introduction to Digital Certificates.
See Certificate Enrollment Objects, on page 668 for a description of the objects used to enroll and obtain
certificates on managed devices.
Procedure
Step 1 Select Devices > Certificates.

You can see the following columns for each device listed on this screen:

718
Managing FTD Certificates
• Name—Lists the devices that already have trustpoints associated with them. Expand the device to see
the list of associated trustpoints.
• Domain—Displays the certificates that are enrolled in a specific domain.
• Enrollment Type—Displays the type of enrollment used for a trustpoint.
• Status—Provides the status of the CA Certificate and Identity Certificate. You can view the certificate
contents, when Available, by clicking the magnifying glass.
When you view the CA certificate information, you can view the hierarchy of all the certifying authorities,
which issued your CA certificate.
If the enrollment fails, click status to view the failure message.
• The additional column lists icons to perform the following tasks:
• Export Certificate—Click to export and download a copy of the certificate. You can choose to
export the PKCS12 (Complete Certificate Chain) or the PEM(Identity Certificate Only) format.
You must provide a pass phrase to export a PKCS12 certificate format to import the file later.
• Re-enroll certificate—Re-enroll an existing certificate.
• Refresh certificate status—Refresh a certificate to synchronize the Firepower Threat Defense
device certificate status to the Firepower Management Center.
• Delete certificate—Delete all the associated certificates for a trustpoint.
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

719
Installing a Certificate Using Self-Signed Enrollment
Installing a Certificate Using Self-Signed Enrollment

Procedure
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 Self-Signed from the drop-down list.
• Click (+), to add a new Certificate Enrollment Object, see Adding Certificate Enrollment Objects, on
page 669.
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
Installing a Certificate Using SCEP Enrollment

Before you begin
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.
Procedure

720
Installing a Certificate using EST Enrollment
• Choose a Certificate Enrollment Object of the type SCEP from the drop-down list.
page 669.
Step 4 Press Add, to start the automatic enrollment process.

For SCEP enrollment type trustpoints, the CA Certificate status will transition from InProgress to Available
as the CA Certificate is obtained from the CA server and installed on the device.
The Identity Certificate will go from InProgress to Available as the device obtains its identity
certificate using SCEP from the specified CA. Sometimes, a manual refresh might be required to obtain the
identity certificate.
Step 5 Click the magnifying glass to view the Identity Certificate created and installed on this device.
What to do next
Method
Installing a Certificate using EST Enrollment

Before you begin
Note Using EST 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.
Note EST's ability to auto-enroll a device when its certificate expires is not supported.
Procedure
Step 1 On the Devices > Certificates screen, click Add to open the Add New Certificate dialog.
• Choose the EST certificate enrollment object from the Cert Enrollment drop-down list.
page 669.
Step 4 Click Add to enroll the certificate on the device.

721
Installing a Certificate Using Manual Enrollment
The Identity Certificate will go from InProgress to Available as the device obtains its identity
certificate using EST from the specified CA. Sometimes, a manual refresh might be required to obtain the
identity certificate.
Step 5 Click the magnifying glass to view the Identity Certificate created and installed on this device.
Installing a Certificate Using Manual Enrollment

Procedure
• Choose a Certificate Enrollment Object of the type Manual from the drop-down list.
page 669.
Step 4 Press Add to start the enrollment process.

Step 5 Execute the appropriate activity with your PKI CA Server to obtain an identity certificate.
a) Click Identity Certificate warning to view and copy the CSR.
b) Execute the appropriate activity with your PKI CA Server to obtain an identity certificate using this CSR.
This activity is completely independent of the Firepower Management Center or the managed device.
When complete, you will have an Identity Certificate for the managed device. You can place it in a file.
c) To finish the manual process, install the obtained identity certificate onto the managed device.
Return to the Firepower Management Center dialog and select Browse Identity Certificate to choose
the identity certificate file.
Step 6 Select Import to import the Identity Certificate.

The Identity Certificate status will be Available when the import complete.
Step 7 Click the magnifying glass to view the Identity Certificate for this device.
What to do next
Method

722
Installing a Certificate Using a PKCS12 File
Installing a Certificate Using a PKCS12 File

Procedure
Step 1 Go to Devices > Certificates screen, choose Add to open the Add New Certificate dialog.
Step 2 Choose a pre-configured managed device from the Device drop down list.
• Choose a Certificate Enrollment Object of the PKCS type from the drop-down list.
page 669.
Step 4 Press Add.

The CA Certificate and Identity Certificate status will go from In Progress to Available as it installs
the PKCS12 file on the device.
Note When you upload the PKCS12 file for the first time, the file is stored in Firepower Management
Center as part of the CertEnrollment object. For any failed enrollments due to a wrong passphrase
or failed deployment, retry enrolling the PKCS12 certificate without uploading the file again. A
PKCS12 file size should not be larger than 24K.
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.
Troubleshooting FTD Certificates

See Firepower Threat Defense VPN Certificate Guidelines and Limitations, on page 718 to determine if
variations in your certificate enrollment environment may be causing a problem. Then consider the following:
• Ensure there is a route to the CA Server from the device.
If the CA Server's host name is given in the Enrollment Object, use Flex Config to configure DNS
appropriately to reach the server. Alternatively, use the IP Address of the CA Server.
• If you are using a Microsoft 2012 CA Server, the default IPsec Template is not accepted by the managed
device and must be changed.
To configure a working template, follow these steps as you use MS CA documentation as a reference.
1. Duplicate the IPsec (Offline Request) template.
2. In Extensions > Application policies, select IP security end system, instead of the IP security IKE
intermediate.
3. Set the permissions and the template name.

723
History for Firepower Threat Defense Certificate-Based Authentication
4. Add the new template and change the registry settings to reflect the new template name.
History for Firepower Threat Defense Certificate-Based

Authentication
Enhancements to Manual 6.7 You can now create only a CA

Enrollment certificate without an identity
certificate. You can also generate
a CSR without a CA certificate and
obtain an identity certificate from
the CA.
PKCS CA Chain 6.7 You can view and manage the chain
of certifying authorities (CAs)
issuing your certificates. You can
also export a copy of the
certificates.

724
PA R T V
Classic Device Configuration Basics
• Classic Device Management Basics, on page 727
• IPS Device Deployments and Configuration, on page 735
CHAPTER 25
Classic Device Management Basics
The following topics describe how to manage Classic devices (ASA with FirePOWER Services/NGIPSv) in
the Firepower System:
• Requirements and Prerequisites for Classic Device Management, on page 727
• Remote Management Configuration (Classic Devices), on page 727
• Interface Configuration Settings, on page 728
RequirementsandPrerequisitesforClassicDeviceManagement
Model Support
Classic models as indicated in the procedures.
Supported Domains
Leaf unless indicated otherwise.
User Roles
• Admin
• Network Admin
Remote Management Configuration (Classic Devices)

For information on configuring remote management for devices that use Classic licenses, see the quick start
guide for your device.
Changing the Management Port

Appliances communicate using a two-way, SSL-encrypted communication channel, which by default is on
port 8305.

727
Interface Configuration Settings
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.
You must perform this task in the global domain.
Procedure
Step 1 Choose System > Configuration.

Step 2 Click Management Interfaces.
Step 3 In the Shared Settings section, enter the port number that you want to use in the Remote Management Port
field.
Step 4 Click Save.
What to do next
Repeat this procedure for every appliance in your deployment that must communicate with this appliance.
Interface Configuration Settings

The Interfaces page of the appliance editor displays detailed interface configuration information. The page is
composed of the physical hardware view and the interfaces table view, which allow you to drill down to
configuration details. You can add and edit interfaces from this page.
The Interfaces Page

The interfaces page lists all the available interfaces you have on a device. The table includes an expandable
navigation tree you can use to view all configured interfaces. You can click the arrow icon next to an interface
to collapse or expand the interface to hide or view its subcomponents. The interfaces table view also provides
summarized information about each interface.

728
Interface Icons
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 729.
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 ( ).
Used by (NGIPSv The inline set where the interface is assigned.

only)
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 87: Interface Icon Types and Descriptions
Icon Interface Type Description See
Passive Passive Sensing interface configured to analyze Configuring Passive Interfaces, on

traffic in a passive deployment. page 736
Inline Inline Sensing interface configured to handle Configuring Inline Interfaces, on page
traffic in an inline deployment. 739
ASA ASA FirePOWER Interface configured on an ASA device Managing Cisco ASA FirePOWER
FirePOWER with the ASA FirePOWER module Interfaces, on page 731
installed.

729
Configuring Sensing Interfaces
Configuring Sensing Interfaces

You can configure the sensing interfaces of a managed device, according to your Firepower deployment, from
the Interfaces page of the appliance editor. Note that you can only configure a total of 1024 interfaces on a
managed device.
Note The Firepower Management Center does not display ASA interfaces when the ASA FirePOWER is deployed
in SPAN port mode.
Procedure

Step 2 Next to the device where you want to configure an interface, click Edit ( ).
Step 3 Click Edit ( ) next to the interface you want to configure.

Step 4 Use the interface editor to configure the sensing interface:
• Inline — If you want an interface configured to handle traffic in an inline deployment, click Inline and
proceed as described in Configuring Inline Interfaces, on page 739.
• Passive — If you want an interface configured to analyze traffic in a passive deployment, click Passive
and proceed as described in Configuring Passive Interfaces, on page 736.
Step 5 Click Save.
What to do next
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.
Procedure

Step 2 Next to the device where you want to disable the interface, click Edit ( ).

730
Managing Cisco ASA FirePOWER Interfaces
Step 3 Next to the interface you want to disable, click Edit ( ).

Step 4 Click None.
Step 5 Click Save.
What to do next
Managing Cisco ASA FirePOWER Interfaces

When editing an ASA FirePOWER interface, you can configure only the interface’s security zone from the
You fully configure ASA FirePOWER interfaces using the ASA-specific software and CLI. If you edit an
ASA FirePOWER and switch from multiple context mode to single context mode (or visa versa), the ASA
FirePOWER renames all of its interfaces. You must reconfigure all Firepower System security zones, correlation
rules, and related configurations to use the updated ASA FirePOWER interface names. For more information
about ASA FirePOWER interface configuration, see the ASA documentation.
Note You cannot change the type of ASA FirePOWER interface, nor can you disable the interface from the Firepower
Management Center.
Procedure

Step 2 Next to the device where you want to edit the interface, click Edit ( ).
Step 3 Click Interfaces if it is not already displaying.

Step 4 Next to the interface you want to edit, click Edit ( ).
Step 5 Choose an existing security zone from the Security Zone drop-down list, or choose New to add a new security
zone.
Step 6 Click Save to configure the security zone.
What to do next

731
MTU Ranges for NGIPSv
MTU Ranges for NGIPSv

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 546 for more information.
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.
Platform MTU Range
NGIPSv 576-9018 (all interfaces, inline sets)
Related Topics
About the MTU, on page 858
Synchronizing Security Zone Object Revisions

When you update a security zone object, the system saves a new revision of the object. As a result, if you
have managed devices in the same security zone that have different revisions of the security zone object
configured in the interfaces, you may log what appear to be duplicate connections.
If you notice duplicate connection reporting, you can update all managed devices to use the same revision of
the object.
This procedure applies to NGIPSv.
Procedure

Step 2 Next to the device where you want to update the security zone selection, click Edit ( ).
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

732
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.

733

734
CHAPTER 26
IPS Device Deployments and Configuration
The following topics describe how to configure your device in an IPS deployment:
• Introduction to IPS Device Deployment and Configuration, on page 735
• License Requirements for IPS Device Deployment, on page 735
• Requirements and Prerequisites for IPS Device Deployment, on page 735
• Passive IPS Deployments, on page 736
• Inline IPS Deployments, on page 737
Introduction to IPS Device Deployment and Configuration

You can configure your device in either a passive or inline IPS deployment. In a passive deployment, you
deploy the system out of band from the flow of network traffic. In an inline deployment, you configure the
system transparently on a network segment by binding two ports together.
License Requirements for IPS Device Deployment

FTD License
Threat
Classic License
Protection
Requirements and Prerequisites for IPS Device Deployment

Model Support
Any.
Supported Domains
Leaf.

735
Passive IPS Deployments
User Roles
• Admin
• Network Admin
Passive IPS Deployments

In a passive IPS deployment, the Firepower System monitors traffic flowing across a network using a switch
SPAN (or mirror) port. The SPAN port allows for traffic to be copied from other ports on the switch. This
provides the system visibility within the network without being in the flow of network traffic. When configured
in a passive deployment, the system 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. Passive
interfaces support both local SPAN and remote SPAN (RSPAN) traffic.
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.
Passive Interfaces on the Firepower System

You can configure one or more physical ports on a managed device as passive interfaces.
When you enable a passive interface to monitor traffic, you designate mode and MDI/MDIX settings, which
are available only for copper interfaces.
When you disable a passive interface, users can no longer access it for security purposes.
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
Related Topics
MTU Ranges for NGIPSv, on page 732
Configuring Passive Interfaces

Procedure

736
Inline IPS Deployments
Step 2 Click Edit ( ) next to the device where you want to configure the passive interface.
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 621.
Step 6 Check the Enabled check box.

If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.
Step 7 Enter a maximum transmission unit (MTU) in the MTU field.

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 546 for
more information.
Step 8 Click Save.
What to do next

In an inline IPS deployment, you configure the Firepower System transparently on a network segment by
binding two ports together. This 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.
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.

737
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

738
Inline Interfaces on the Firepower System
Inline Interfaces on the Firepower System

You can configure one or more physical ports on a managed device as inline interfaces. You must assign a
pair of inline interfaces to an inline set before they can handle traffic in an inline deployment.
Note:
• The system warns you if you set the interfaces in an inline pair to different speeds or if the interfaces
negotiate to different speeds.
• If you configure an interface as an inline interface, the adjacent port on its NetMod automatically becomes
an inline interface as well to complete the pair.
• To configure inline interfaces on an NGIPSv device, you must create the inline pair using adjacent
interfaces.
Configuring Inline Interfaces

Procedure

Step 2 Click Edit ( ) next to the device where you want to configure the interface.
Step 3 Click Edit ( ) next to the interface you want to configure.

Step 4 Click Inline.
Step 5 If you want to associate the inline 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 621.
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 741.
Step 7 Check the Enabled check box.

If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.
Step 8 Click Save.
What to do next

739
Inline Sets on the Firepower System
Inline Sets on the Firepower System

Before you can use inline interfaces in an inline deployment, you must configure inline sets and assign inline
interface pairs to them. An inline set is a grouping of one or more inline interface pairs on a device; an inline
interface pair can belong to only one inline set at a time.
The Inline Sets tab of the Device Management page displays a list of all inline sets you have configured on
a device.
You can add inline sets from the Inline Sets tab of the Device Management page or you can add inline sets
as you configure inline interfaces.
You can assign only inline interface pairs to an inline set. If you want to create an inline set before you
configure the inline interfaces on your managed devices, you can create an empty inline set and add interfaces
to it later. You can use alphanumeric characters and spaces when you type a name for an inline set.
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
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.

740
Viewing Inline Sets
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 548 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
Viewing Inline Sets

Procedure

Step 2 Click Edit ( ) next to the device where you want to view the inline sets.
Step 3 Click Inline Sets.
Adding Inline Sets

Procedure

Step 2 Click Edit ( ) next to the device where you want to add the inline set.

Step 4 Click Add Inline Set.
Step 6 Next to Interfaces, choose one or more inline interface pairs, then click Add Selected. To add all interface
pairs to the inline set, click Add All.
Tip To remove inline interfaces from the inline set, choose one or more inline interface pairs and click
Remove Selected. To remove all interface pairs from the inline set, click Remove All. Disabling
either interface in a pair from Interfaces also removes the pair.
Step 7 Enter a maximum transmission unit (MTU) in the MTU field.


741
Advanced Inline Set Options
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 546 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 740 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 742.
Step 10 Click OK.
What to do next
Related Topics
Advanced Inline Set Options

There are a number of advanced options you may consider as you configure inline sets.
Transparent Inline Mode

Transparent Inline Mode option allows the device to act as a “bump in the wire” and means that the device
forwards all the network traffic it sees, regardless of its source and destination.
Configuring Advanced Inline Set Options

Procedure

Step 2 Click Edit ( ) next to the device where you want to edit the inline set.

Step 4 Click Edit ( ) next to the inline set you want to edit.
Step 5 Click Advanced.

742
Deleting Inline Sets
Step 6 Configure options as described in Advanced Inline Set Options, on page 742.
Note Link state propagation and strict TCP enforcement are not supported on virtual devices.
Step 7 Click OK.
What to do next

When you delete an inline set, any inline interfaces assigned to the set become available for inclusion in
another set. The interfaces are not deleted.
Procedure

Step 2 Next to the device where you want to delete the inline set, click Edit ( ).
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

743

744
PA R T VI
Firepower Threat Defense Getting Started
• Transparent or Routed Firewall Mode for Firepower Threat Defense, on page 747
• Logical Devices for the Firepower Threat Defense on the Firepower 4100/9300, on page 759
CHAPTER 27
Transparent or Routed Firewall Mode for
This chapter describes how to set the firewall mode to routed or transparent, as well as how the firewall works
in each firewall mode.
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 869 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.
• About the Firewall Mode, on page 747

• Default Settings, on page 755
• Guidelines for Firewall Mode, on page 755
• Set the Firewall Mode, on page 756
About the Firewall Mode

The Firepower Threat Defense device supports two firewall modes for regular firewall interfaces: Routed
Firewall mode and Transparent Firewall mode.
About Routed Firewall Mode

In routed mode, the Firepower Threat Defense device is considered to be a router hop in the network. Each
interface that you want to route between is on a different subnet.
With Integrated Routing and Bridging, you can use a "bridge group" where you group together multiple
interfaces on a network, and the Firepower Threat Defense device uses bridging techniques to pass traffic
between the interfaces. Each bridge group includes a Bridge Virtual Interface (BVI) to which you assign an
IP address on the network. The Firepower Threat Defense device routes between BVIs and regular routed
interfaces. If you do not need clustering or EtherChannel or redundant member interfaces, you might consider
using routed mode instead of transparent mode. 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.

747
About Transparent Firewall Mode
About Transparent Firewall Mode

Traditionally, a firewall is a routed hop and acts as a default gateway for hosts that connect to one of its
screened subnets. 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. However, like any other
firewall, access control between interfaces is controlled, and all of the usual firewall checks are in place.
Layer 2 connectivity is achieved by using a "bridge group" where you group together the inside and outside
interfaces for a network, and the Firepower Threat Defense device uses bridging techniques to pass traffic
between the interfaces. Each bridge group includes a Bridge Virtual Interface (BVI) to which you assign an
IP address on the network. You can have multiple bridge groups for multiple networks. In transparent mode,
these bridge groups cannot communicate with each other.
Using the Transparent Firewall in Your Network

The Firepower Threat Defense device connects the same network between its interfaces. Because the firewall
is not a routed hop, you can easily introduce a transparent firewall into an existing network.
The following figure shows a typical transparent firewall network where the outside devices are on the same
subnet as the inside devices. The inside router and hosts appear to be directly connected to the outside router.
Figure 7: Transparent Firewall Network
Passing Traffic For Routed-Mode Features

For features that are not directly supported on the transparent firewall, you can allow traffic to pass through
so that upstream and downstream routers can support the functionality. For example, by using an access rule,
you can allow DHCP traffic (instead of the unsupported DHCP relay feature) or multicast traffic such as that
created by IP/TV. You can also establish routing protocol adjacencies through a transparent firewall; you can
allow OSPF, RIP, EIGRP, or BGP traffic through based on an access rule. Likewise, protocols like HSRP or
VRRP can pass through the Firepower Threat Defense device.

748
About Bridge Groups
About Bridge Groups

A bridge group is a group of interfaces that the Firepower Threat Defense device bridges instead of routes.
Bridge groups are supported in both transparent and routed firewall mode. Like any other firewall interfaces,
access control between interfaces is controlled, and all of the usual firewall checks are in place.
Bridge Virtual Interface (BVI)

Each bridge group includes a Bridge Virtual Interface (BVI). The Firepower Threat Defense device uses the
BVI IP address as the source address for packets originating from the bridge group. The BVI IP address must
be on the same subnet as the bridge group member interfaces. The BVI does not support traffic on secondary
networks; only traffic on the same network as the BVI IP address is supported.
In transparent mode: Only bridge group member interfaces are named and can be used with interface-based
features.
In routed mode: The BVI acts as the gateway between the bridge group and other routed interfaces. To route
between bridge groups/routed interfaces, you must name the BVI. For some interface-based features, you can
use the BVI itself:
• DHCPv4 server—Only the BVI supports the DHCPv4 server configuration.
• Static routes—You can configure static routes for the BVI; you cannot configure static routes for the
member interfaces.
• Syslog server and other traffic sourced from the Firepower Threat Defense device—When specifying a
syslog server (or SNMP server, or other service where the traffic is sourced from the Firepower Threat
Defense device), you can specify either the BVI or a member interface.
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.
Bridge Groups in Transparent Firewall Mode

Bridge group traffic is isolated from other bridge groups; traffic is not routed to another bridge group within
the Firepower Threat Defense device, and traffic must exit the Firepower Threat Defense device before it is
routed by an external router back to another bridge group in the Firepower Threat Defense device. Although
the bridging functions are separate for each bridge group, many other functions are shared between all bridge
groups. For example, all bridge groups share a syslog server or AAA server configuration.
You can include multiple interfaces per bridge group. See Guidelines for Firewall Mode, on page 755 for the
exact number of bridge groups and interfaces supported. If you use more than 2 interfaces per bridge group,
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.

749
Bridge Groups in Routed Firewall Mode
Figure 8: Transparent Firewall Network with Two Bridge Groups
Bridge Groups in Routed Firewall Mode

Bridge group traffic can be routed to other bridge groups or routed interfaces. You can choose to isolate bridge
group traffic by not assigning a name to the BVI interface for the bridge group. If you name the BVI, then
the BVI participates in routing like any other regular interface.
One use for a bridge group in routed mode is to use extra interfaces on the FTD instead of an external switch.
For example, the default configuration for some devices include an outside interface as a regular interface,
and then all other interfaces assigned to the inside bridge group. Because the purpose of this bridge group is
to replace an external switch, you need to configure an access policy so all bridge group interfaces can freely
communicate.

750
Allowing Layer 3 Traffic
Figure 9: Routed Firewall Network with an Inside Bridge Group and an Outside Routed Interface
Allowing Layer 3 Traffic

• Unicast IPv4 and IPv6 traffic requires an access rule to be allowed through the bridge group.
• ARPs are allowed through the bridge group in both directions without an access rule. ARP traffic can
be controlled by ARP inspection.
• IPv6 neighbor discovery and router solicitation packets can be passed using access rules.
• Broadcast and multicast traffic can be passed using access rules.
Allowed MAC Addresses

The following destination MAC addresses are allowed through the bridge group if allowed by your access
policy (see Allowing Layer 3 Traffic, on page 751). Any MAC address not on this list is dropped.
• TRUE broadcast destination MAC address equal to FFFF.FFFF.FFFF
• IPv4 multicast MAC addresses from 0100.5E00.0000 to 0100.5EFE.FFFF
• IPv6 multicast MAC addresses from 3333.0000.0000 to 3333.FFFF.FFFF
• BPDU multicast address equal to 0100.0CCC.CCCD
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

751
MAC Address vs. Route Lookups
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 1277.
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.
access-list permit-bpdu ethertype trust bpdu

access-group permit-bpdu in interface <if-name>
MAC Address vs. Route Lookups

For traffic within a bridge group, the outgoing interface of a packet is determined by performing a destination
MAC address lookup instead of a route lookup.
Route lookups, however, are necessary for the following situations:
• Traffic originating on the Firepower Threat Defense device—Add a default/static route on the Firepower
Threat Defense device for traffic destined for a remote network where a syslog server, for example, is
located.
• Voice over IP (VoIP) and TFTP traffic, and the endpoint is at least one hop away—Add a static route
on the Firepower Threat Defense device for traffic destined for the remote endpoint so that secondary
connections are successful. The Firepower Threat Defense device creates a temporary "pinhole" in the
access control policy to allow the secondary connection; and because the connection might use a different
set of IP addresses than the primary connection, the Firepower Threat Defense device needs to perform
a route lookup to install the pinhole on the correct interface.
Affected applications include:
• H.323
• RTSP
• SIP
• Skinny (SCCP)
• SQL*Net
• SunRPC
• TFTP
• 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.

752
Unsupported Features for Bridge Groups in Transparent Mode
Figure 10: NAT Example: NAT within a Bridge Group
Unsupported Features for Bridge Groups in Transparent Mode

The following table lists the features are not supported in bridge groups in transparent mode.
Table 88: Unsupported Features in Transparent Mode
Feature Description
Dynamic DNS —
DHCP relay The transparent firewall can act as a DHCPv4 server,

but it does not support DHCP relay. DHCP relay is
not required because you can allow DHCP traffic to
pass through using two access rules: one that allows
DCHP requests from the inside interface to the
outside, and one that allows the replies from the server
in the other direction.

753
Unsupported Features for Bridge Groups in Routed Mode
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.
Unsupported Features for Bridge Groups in Routed Mode

The following table lists the features are not supported in bridge groups in routed mode.
Table 89: Unsupported Features in Routed Mode
Feature Description
EtherChannel member interfaces Only physical interfaces, redundant interfaces, and

subinterfaces are supported as bridge group member
interfaces.
Diagnostic interfaces are also not supported.
Clustering Bridge groups are not supported in clustering.
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.
QoS Non-bridge group interfaces support QoS.

754
Default Settings
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.
Guidelines for Firewall Mode

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.
Bridge Group Guidelines (Transparent and Routed Mode)

• You can create up to 250 bridge groups, with 64 interfaces per bridge group.
• Each directly-connected network must be on the same subnet.
• The Firepower Threat Defense device does not support traffic on secondary networks; only traffic on
the same network as the BVI IP address is supported.
• An IP address for the BVI is required for each bridge group for to-the-device and from-the-device
management traffic, as well as for data traffic to pass through the Firepower Threat Defense device. For
IPv4 traffic, specify an IPv4 address. For IPv6 traffic, specify an IPv6 address.
• You can only configure IPv6 addresses manually.
• The BVI IP address must be on the same subnet as the connected network. You cannot set the subnet to
a host subnet (255.255.255.255).
• Management interfaces are not supported as bridge group members.
• For the Firepower 1010, you cannot mix logical VLAN interfaces and physical firewall interfaces in the
same bridge group.

755
Set the Firewall Mode
• 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.

Any N/A FTD Any Admin
Access Admin
Network Admin
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.
Procedure
Step 1 Deregister the FTD device from the FMC.

You cannot change the mode until you deregister the device.
a) Choose Devices > Device Management.
b) Select the device from the list of managed devices.
c) Delete the device (click Trash can), confirm, and wait for system to remove the device.
Step 2 Access the FTD device CLI, preferably from the console port.

756
If you use SSH to the diagnostic interface, then changing the mode erases your interface configuration and
you will be disconnected. You should instead connect to the management interface.
Step 3 Change the firewall mode:

configure firewall [routed | transparent]
Example:
> configure firewall transparent

This will destroy the current interface configurations, are you sure that you want to
proceed? [y/N] y
The firewall mode was changed successfully.
Step 4 Re-register with the FMC:

configure manager add {hostname | ip_address | DONTRESOLVE} reg_key [nat_id]
where:
• {hostname | ip_address | DONTRESOLVE } specifies either the fully qualified host name or IP address
of the FMC. If the FMC is not directly addressable, use DONTRESOLVE.
• reg_key is the unique alphanumeric registration key required to register a device to the FMC.
• nat_id is an optional alphanumeric string used during the registration process between the FMC and the
device. It is required if the hostname is set to DONTRESOLVE.

757

758
CHAPTER 28
Logical Devices for the Firepower Threat Defense
on the Firepower 4100/9300
The Firepower 4100/9300 is a flexible security platform on which you can install one or more logical devices.
Before you can add the FTD to the FMC, you must configure chassis interfaces, add a logical device, and
assign interfaces to the device on the Firepower 4100/9300 chassis using the Firepower Chassis Manager or
the FXOS CLI. This chapter describes basic interface configuration and how to add a standalone or High
Availability logical device using the Firepower Chassis Manager. To add a clustered logical device, see
Clustering for the Firepower Threat Defense, on page 935. To use the FXOS CLI, see the FXOS CLI
configuration guide. For more advanced FXOS procedures and troubleshooting, see the FXOS configuration
guide.
• About Firepower Interfaces, on page 759
• About Logical Devices, on page 772
• Licenses for Container Instances, on page 780
• Requirements and Prerequisites for Logical Devices, on page 781
• Guidelines and Limitations for Logical Devices, on page 785
• Configure Interfaces, on page 788
• Configure Logical Devices, on page 792
• History for Firepower Threat Defense Logical Devices, on page 802
About Firepower Interfaces

The Firepower 4100/9300 chassis supports physical interfaces, VLAN subinterfaces for container instances,
and EtherChannel (port-channel) interfaces. EtherChannel interfaces can include up to 16 member interfaces
of the same type.
Chassis Management Interface

The chassis management interface is used for management of the FXOS Chassis by SSH or Firepower Chassis
Manager. This interface appears at the top of the Interfaces tab as MGMT, and you can only enable or disable
this interface on the Interfaces tab. This interface is separate from the mgmt-type interface that you assign
to the logical devices for application management.
To configure parameters for this interface, you must configure them from the CLI. To view information about
this interface in the FXOS CLI, connect to local management and show the management port:

759
Interface Types
Firepower # connect local-mgmt

Firepower(local-mgmt) # show mgmt-port
Note that the chassis management interface remains up even if the physical cable or SFP module are unplugged,
or if the mgmt-port shut command is performed.
Note The chassis management interface does not support jumbo frames.
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, FMC,: 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 759.
• 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. If you later configure a data interface for management, you cannot use a separate
eventing 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.

760
FXOS Interfaces vs. Application Interfaces
Table 90: Interface Type Support
Application Data Data: Data-Sharing Data-Sharing: Mgmt Firepower-Eventing Cluster Cluster:

Subinterface Subinterface (EtherChannel Subinterface
only)
FTD Standalone Yes — — — Yes Yes — —

Native
Instance
Standalone Yes Yes Yes Yes Yes Yes — —

Container
Instance
Cluster Yes — — — Yes Yes Yes —

Native
(EtherChannel
Instance
only for
inter-chassis
cluster)
Cluster Yes — — — Yes Yes Yes Yes

Container
(EtherChannel
Instance
only for
inter-chassis
cluster)
ASA Standalone Yes — — — Yes — Yes —

Native
Instance
Cluster Yes — — — Yes — Yes —

Native
(EtherChannel
Instance
only for
inter-chassis
cluster)

The Firepower 4100/9300 manages the basic Ethernet settings of physical interfaces, VLAN subinterfaces
for container instances, and EtherChannel (port-channel) interfaces. Within the application, you configure
higher level settings. For example, you can only create EtherChannels in FXOS; but you can assign an IP
address to the EtherChannel within the application.
The following sections describe the interaction between FXOS and the application for interfaces.
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

761
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

762
Shared Interface Scalability
Independent Interface States in the Chassis and in the Application

You can administratively enable and disable interfaces in both the chassis and in the application. 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 application.
The default state of an interface within the application depends on the type of interface. For example, the
physical interface or EtherChannel is disabled by default within the application, but a subinterface is enabled
by default.
Shared Interface Scalability

Container instances can share data-sharing type interfaces. This capability lets you conserve physical interface
usage as well as support flexible networking deployments. When you share an interface, the chassis uses
unique MAC addresses to forward traffic to the correct instance. However, shared interfaces can cause the
forwarding table to grow large due to the need for a full mesh topology within the chassis (every instance
must be able to communicate with every other instance that is sharing the same interface). Therefore, there
are limits to how many interfaces you can share.
In addition to the forwarding table, the chassis maintains a VLAN group table for VLAN subinterface
forwarding.You can create up to 500 VLAN subinterfaces.
See the following limits for shared interface allocation:

763
Shared Interface Best Practices
Shared Interface Best Practices

For optimal scalability of the forwarding table, share as few interfaces as possible. Instead, you can create up
to 500 VLAN subinterfaces on one or more physical interfaces, and then divide the VLANs among the
container instances.
When sharing interfaces, follow these practices in the order of most scalable to least scalable:
1. Best—Share subinterfaces under a single parent, and use the same set of subinterfaces with the same
group of instances.
For example, create a large EtherChannel to bundle all of your like-kind interfaces together, and then
share subinterfaces of that EtherChannel: Port-Channel1.2, 3, and 4 instead of Port-Channel2,
Port-Channel3, and Port-Channel4. When you share subinterfaces from a single parent, the VLAN group
table provides better scaling of the forwarding table than when sharing physical/EtherChannel interfaces
or subinterfaces across parents.
Figure 12: Best: Shared Subinterface Group on One Parent
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

764
Shared Interface Usage Examples
2. Fair—Share subinterfaces across parents.

For example, share Port-Channel1.2, Port-Channel2.3, and Port-Channel3.4 instead of Port-Channel2,
Port-Channel4, and Port-Channel4. Although this usage is not as efficient as only sharing subinterfaces
on the same parent, it still takes advantage of VLAN groups.
Figure 14: Fair: Shared Subinterfaces on Separate Parents
3. Worst—Share individual parent interfaces (physical or EtherChannel).

This method uses the most forwarding table entries.
Figure 15: Worst: Shared Parent Interfaces

See the following tables for examples of interface sharing and scalability. The below scenarios assume use
of one physical/EtherChannel interface for management shared across all instances, and another physical or
EtherChannel interface with dedicated subinterfaces for use with High Availability.
• Table 91: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with Three SM-44s, on
page 766
• Table 92: Subinterfaces on One Parent and Instances on a Firepower 9300 with Three SM-44s, on page
767
• Table 93: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with One SM-44, on
page 769
• Table 94: Subinterfaces on One Parent and Instances on a Firepower 9300 with One SM-44, on page 770

765
Firepower 9300 with Three SM-44s

The following table applies to three SM-44 security modules on a 9300 using only physical interfaces or
EtherChannels. Without subinterfaces, the maximum number of interfaces are limited. Moreover, 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 91: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with Three SM-44s
Dedicated Shared Interfaces Number of Instances % Forwarding Table Used

Interfaces
32: 0 4: 16%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4
30: 0 2: 14%
• 15 • Instance 1
14: 1 14: 46%

• 14 (1 ea.) • Instance 1-Instance 14
33: 3: 33: 98%

• 11 (1 ea.) •1 • Instance 1-Instance 11
33: 3: 34: 102%

• 11 (1 ea.) •1 • Instance 1-Instance 11 DISALLOWED
30: 1 6: 25%

766

Interfaces
30: 3: 6: 23%
• 10 (5 ea.) •1 • Instance 1-Instance2
30: 2 5: 28%
30: 4: 5: 26%
24: 7 4: 44%
•6 • Instance 1
•6 • Instance 2
•6 • Instance 3
•6 • Instance 4
24: 14: 4: 41%

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 92: Subinterfaces on One Parent and Instances on a Firepower 9300 with Three SM-44s
Dedicated Shared Subinterfaces Number of Instances % Forwarding Table Used

Subinterfaces
168: 0 42: 33%


767

Subinterfaces
224: 0 14: 27%

14: 1 14: 46%

33: 3: 33: 98%

70: 1 14: 46%

165: 3: 33: 98%

70: 2 14: 46%

165: 6: 33: 98%

70: 10 14: 46%

165: 30: 33: 102%

• 55 (5 ea.) • 10 • Instance 1-Instance 11 DISALLOWED
• 55 (5 ea.) • 10 • Instance 12-Instance 22

768
Firepower 9300 with One SM-44

The following table applies to the Firepower 9300 with one SM-44 using only physical interfaces or
EtherChannels. Without subinterfaces, the maximum number of interfaces are limited. Moreover, sharing
multiple physical interfaces uses more forwarding table resources than sharing multiple subinterfaces.
The Firepower Firepower 9300 with one SM-44 can support up to 14 instances.
Table 93: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with One SM-44

Interfaces
32: 0 4: 16%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4
30: 0 2: 14%
14: 1 14: 46%

14: 2: 14: 37%

32: 1 4: 21%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4
32: 2 4: 20%

769

Interfaces
32: 2 4: 25%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4
32: 4: 4: 24%
24: 8 3: 37%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
10: 10 5: 69%
10: 20: 5: 59%

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 94: Subinterfaces on One Parent and Instances on a Firepower 9300 with One SM-44

Subinterfaces
112: 0 14: 17%


770
Viewing Shared Interface Resources

Subinterfaces
224: 0 14: 17%

14: 1 14: 46%

14: 2: 14: 37%

112: 1 14: 46%

112: 2: 14: 37%

112: 2 14: 46%

112: 4: 14: 37%

140: 10 14: 46%

140: 20: 14: 37%

Viewing Shared Interface Resources

To view forwarding table and VLAN group usage, see the Devices & Network > Interface Forwarding
Utilization area. For example:

771
Inline Set Link State Propagation for the Firepower Threat Defense
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.
About Logical Devices

A logical device lets you run one application instance (either ASA or Firepower Threat Defense) and also one
optional decorator application (Radware DefensePro) to form a service chain.
When you add a logical device, you also define the application instance type and version, assign interfaces,
and configure bootstrap settings that are pushed to the application configuration.
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.
Standalone and Clustered Logical Devices

You can add the following logical device types:
• Standalone—A standalone logical device operates as a standalone unit or as a unit in a High Availability
pair.

772
Logical Device Application Instances: Container and Native
• 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.
Logical Device Application Instances: Container and Native

Application instances run in the following deployment types:
• Native instance—A native instance uses all of the resources (CPU, RAM, and disk space) of the security
module/engine, so you can only install one native instance.
• Container instance—A container instance uses a subset of resources of the security module/engine, so
you can install multiple container instances. Multi-instance capability is only supported for the Firepower
Threat Defense using FMC; it is not supported for the ASA or the FTD using FDM.
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).
Container Instance Interfaces

To provide flexible physical interface use for container instances, you can create VLAN subinterfaces in
FXOS and also share interfaces (VLAN or physical) between multiple instances. Native instances cannot use
VLAN subinterfaces or shared interfaces. A multi-instance cluster cannot use VLAN subinterfaces or shared
interfaces. An exception is made for the cluster control link, which can use a subinterface of the Cluster
EtherChannel. See Shared Interface Scalability, on page 763 and Add a VLAN Subinterface for Container
Instances, on page 791.
How the Chassis Classifies Packets

Each packet that enters the chassis must be classified, so that the chassis can determine to which instance to
send a packet.
• Unique Interfaces—If only one instance is associated with the ingress interface, the chassis classifies the
packet into that instance. For bridge group member interfaces (in transparent mode or routed mode),
inline sets, or passive interfaces, this method is used to classify packets at all times.
• Unique MAC Addresses—The chassis automatically generates unique MAC addresses for all interfaces,
including shared interfaces. If multiple instances share an interface, then the classifier uses unique MAC
addresses assigned to the interface in each instance. An upstream router cannot route directly to an

773
Classification Examples
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.
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.

774
Figure 17: Incoming Traffic from Inside Networks
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.

775
Figure 18: Transparent Firewall Instances
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.

776
Cascading Container Instances
Figure 19: Inline Sets for FTD
Cascading Container Instances

Placing a container instance directly in front of another instance is called cascading container instances; the
outside interface of one instance is the same interface as the inside interface of another instance. You might
want to cascade instances if you want to simplify the configuration of some instances by configuring shared
parameters in the top instance.
The following figure shows a gateway instance with two instances behind the gateway.

777
Typical Multi-Instance Deployment
Figure 20: Cascading Container Instances
Typical Multi-Instance Deployment

The following example includes three container instances in routed firewall mode. They include the following
interfaces:
• Management—All instances use the Port-Channel1 interface (management type). This EtherChannel
includes two 10 Gigibit Ethernet interfaces. Within each application, the interface uses a unique IP address
on the same management network.
• Inside—Each instance uses a subinterface on Port-Channel2 (data type). This EtherChannel includes
two 10 Gigibit Ethernet interfaces. Each subinterface is on a separate network.
• Outside—All instances use the Port-Channel3 interface (data-sharing type). This EtherChannel includes
two 10 Gigibit Ethernet interfaces. Within each application, the interface uses a unique IP address on
the same outside network.
• Failover—Each instance uses a subinterface on Port-Channel4 (data type). This EtherChannel includes
two 10 Gigibit Ethernet interfaces. Each subinterface is on a separate network.

778
Automatic MAC Addresses for Container Instance Interfaces
Automatic MAC Addresses for Container Instance Interfaces

The FXOS chassis automatically generates MAC addresses for container instance interfaces, and guarantees
that a shared interface in each instance uses a unique MAC address.
If you manually assign a MAC address to a shared interface within the application, then the manually-assigned
MAC address is used. If you later remove the manual MAC address, the autogenerated address is used. In the
rare circumstance that the generated MAC address conflicts with another private MAC address in your network,
we suggest that you manually set the MAC address for the interface within the application.
Because autogenerated addresses start with A2, you should not start manual MAC addresses with A2 due to
the risk of overlapping addresses.
The FXOS chassis generates the MAC address using the following format:
A2xx.yyzz.zzzz
Where xx.yy is a user-defined prefix or a system-defined prefix, and zz.zzzz is an internal counter generated
by the chassis. The system-defined prefix matches the lower 2 bytes of the first MAC address in the burned-in
MAC address pool that is programmed into the IDPROM. Use connect fxos, then show module to view the
MAC address pool. For example, if the range of MAC addresses shown for module 1 is b0aa.772f.f0b0 to
b0aa.772f.f0bf, then the system prefix will be f0b0.
The user-defined prefix is an integer that is converted into hexadecimal. For an example of how the user-defined
prefix is used, if you set a prefix of 77, then the chassis converts 77 into the hexadecimal value 004D (yyxx).
When used in the MAC address, the prefix is reversed (xxyy) to match the chassis native form:
A24D.00zz.zzzz
For a prefix of 1009 (03F1), the MAC address is:
A2F1.03zz.zzzz

779
Container Instance Resource Management
Container Instance Resource Management

To specify resource usage per container instance, create one or more resource profiles in FXOS. When you
deploy the logical device/application instance, you specify the resource profile that you want to use. The
resource profile sets the number of CPU cores; RAM is dynamically allocated according to the number of
cores, and disk space is set to 40 GB per instance. To view the available resources per model, see Requirements
and Prerequisites for Container Instances, on page 783. To add a resource profile, see Add a Resource Profile
for Container Instances, on page 792.
Performance Scaling Factor for Multi-Instance Capability

The maximum throughput (connections, VPN sessions, and TLS proxy sessions) for a platform is calculated
for a native instance’s use of memory and CPU (and this value is shown in show resource usage). If you use
multiple instances, then you need to calculate the throughput based on the percentage of CPU cores that you
assign to the instance. For example, if you use a container instance with 50% of the cores, then you should
initially calculate 50% of the throughput. Moreover, the throughput available to a container instance may be
less than that available to a native instance.
For detailed instructions on calculating the throughput for instances, see https://www.cisco.com/c/en/us/
products/collateral/security/firewalls/white-paper-c11-744750.html.
Container Instances and High Availability

You can use High Availability using a container instance on 2 separate chassis; for example, if you have 2
chassis, each with 10 instances, you can create 10 High Availability pairs. Note that High Availability is not
configured in FXOS; configure each High Availability pair in the application manager.
For detailed requirements, see Requirements and Prerequisites for High Availability, on page 784 and Add a
High Availability Pair, on page 798.
Container Instances and Clustering

You can create a cluster of container instances using one container instance per security module/engine. See
Requirements and Prerequisites for Clustering, on page 941 for detailed requirements.
Licenses for Container Instances

All licenses are consumed per security engine/chassis (for the Firepower 4100) or per security module (for
the Firepower 9300), and not per container instance. See the following details:
• Base licenses are automatically assigned: one per security module/engine.
• Feature licenses are manually assigned to each instance; but you only consume one license per feature
per security module/engine. For example, for the Firepower 9300 with 3 security modules, you only need
one URL Filtering license per module for a total of 3 licenses, regardless of the number of instances in
use.
• For High Availability, see License Requirements for FTD Devices in a High Availability Pair, on page
908.
For example:

780
Requirements and Prerequisites for Logical Devices
Table 95: License Usage for Container Instances on a Firepower 9300
Firepower 9300 Instance Licenses
Security Module 1 Instance 1 Base, URL Filtering, Malware
Instance 2 Base, URL Filtering
Instance 3 Base, URL Filtering
Security Module 2 Instance 4 Base, Threat
Instance 5 Base, URL Filtering, Malware,

Threat
Security Module 3 Instance 6 Base, Malware, Threat
Instance 7 Base, Threat
Table 96: Total Number of Licenses
Base URL Filtering Malware Threat
3 2 3 2
Requirements and Prerequisites for Logical Devices

See the following sections for requirements and prerequisites.
Requirements and Prerequisites for Hardware and Software Combinations

The Firepower 4100/9300 supports multiple models, security modules, application types, and high availability
and scalability features. See the following requirements for allowed combinations.
Firepower 9300 Requirements

The Firepower 9300 includes 3 security module slots and multiple types of security modules. See the following
requirements:
• Security Module Types—You can install modules of different types in the Firepower 9300. For example,
you can install the SM-36 as module 1, SM-40 as module 2, and SM-44 as module 3.
• Native instance Clustering—All security modules in the cluster, whether it is intra-chassis or inter-chassis,
must be the same type. You can have different quantities of installed security modules in each chassis,
although all modules present in the chassis must belong to the cluster including any empty slots. For
example, you can install 2 SM-36s in chassis 1, and 3 SM-36s in chassis 2. You cannot use clustering if
you install 1 SM-24 and 2 SM-36s in the same chassis.
• Container instance Clustering—You can create a cluster using instances on different model types. For
example, you can create a cluster using an instance on a Firepower 9300 SM-56, SM-40, and SM-36.
You cannot mix the Firepower 9300 and the Firepower 4100 in the same cluster, however.

781
Requirements and Prerequisites for Hardware and Software Combinations
• 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.
Firepower 4100 Requirements

The Firepower 4100 comes in multiple models. See the following requirements:
• Native and Container instances—When you install a container instance on a Firepower 4100, that device
can only support other container instances. A native instance uses all of the resources for a device, so
you can only install a single native instance on the device.
• Native instance Clustering—All chassis in the cluster must be the same model.
• Container instance Clustering—You can create a cluster using instances on different model types. For
example, you can create a cluster using an instance on a Firepower 4140 and a 4150. You cannot mix
the Firepower 9300 and the Firepower 4100 in the same cluster, however.

782
Requirements and Prerequisites for Container Instances
• High Availability—High Availability is only supported between same-type models.

• ASA and FTD application types—The Firepower 4100 can only run a single application type.
• FTD container instance versions—You can run different versions of FTD as separate container instances
on the same module.
Requirements and Prerequisites for Container Instances

Supported Application Types
• Firepower Threat Defense using FMC
Maximum Container Instances and Resources per Model

For each container instance, you can specify the number of CPU cores to assign to the instance. RAM is
dynamically allocated according to the number of cores, and disk space is set to 40 GB per instance.
Table 97: Maximum Container Instances and Resources per Model
Model Max. Container Available CPU Cores Available RAM Available Disk Space
Instances
Firepower 4110 3 22 53 GB 125.6 GB
Firepower 4112 3 22 78 GB 308 GB
Firepower 4115 7 46 162 GB 308 GB
Firepower 4120 3 46 101 GB 125.6 GB
Firepower 4125 10 62 162 GB 644 GB
Firepower 4140 7 70 222 GB 311.8 GB

783
Requirements and Prerequisites for High Availability
Model Max. Container Available CPU Cores Available RAM Available Disk Space
Instances
Firepower 4145 14 86 344 GB 608 GB
Firepower 4150 7 86 222 GB 311.8 GB
Firepower 9300 SM-24 security 7 46 226 GB 656.4 GB

module

module
Firepower 9300 SM-40 security 13 78 334 GB 1359 GB

module

module

module

module
Firepower Management Center Requirements

For all instances on a Firepower 4100 chassis or Firepower 9300 module, you must use the same Firepower
Management Center (FMC) due to the licensing implementation.

• The two units in a High Availability Failover configuration must:
• Be on a separate chassis; intra-chassis High Availability for the Firepower 9300 is not supported.
• Be the same model.
• Have the same interfaces assigned to the High Availability logical devices.
• Have the same number and types of interfaces. All interfaces must be preconfigured in FXOS
identically before you enable High Availability.
• 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
907.

784
Guidelines and Limitations for Logical Devices
Guidelines and Limitations for Logical Devices

See the following sections for guidelines and limitations.
Guidelines and Limitations for Firepower Interfaces

VLAN Subinterfaces
• Subinterfaces (and the parent interfaces) can only be assigned to container instances.
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.

785
Guidelines and Limitations for Firepower Interfaces
• You cannot use a data-sharing interface in a cluster.

• See the following limitations within the logical device application; keep these limitations in mind when
planning your interface allocation.
• You cannot use a data-sharing interface with a transparent firewall mode device.
• You cannot use a data-sharing interface with FTD inline sets or passive interfaces.
• You cannot use a data-sharing interface for the failover link.
Inline Sets for FTD

• Supported for physical interfaces (both regular and breakout ports) and EtherChannels. Subinterfaces
are not supported.
• Link state propagation is supported.
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.

786
General Guidelines and Limitations
• 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.
Default MAC Addresses

For native instances:
Default MAC address assignments depend on the type of interface.
• Physical interfaces—The physical interface uses the burned-in MAC address.
• EtherChannels—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.
For container instances:

• MAC addresses for all interfaces are taken from a MAC address pool. For subinterfaces, if you decide
to manually configure MAC addresses, make sure you use unique MAC addresses for all subinterfaces
on the same parent interface to ensure proper classification. See Automatic MAC Addresses for Container
Instance Interfaces, on page 779.
General Guidelines and Limitations

Firewall Mode
You can set the firewall mode to routed or transparent in the bootstrap configuration for the FTD.
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
• 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
• FMC UCAPL/CC mode
• Flow offload to hardware

787
Configure Interfaces
Configure Interfaces
By default, physical interfaces are disabled. You can enable interfaces, add EtherChannels, add VLAN
subinterfaces, and edit interface properties.
Enable or Disable an Interface

You can change the Admin State of each interface to be enabled or disabled. By default, physical interfaces
are disabled. For VLAN subinterfaces, the admin state is inherited from the parent interface.
Procedure
Step 1 Choose Interfaces to open the Interfaces page.

The Interfaces page shows a visual representation of the currently installed interfaces at the top of the page
and provides a listing of the installed interfaces in the table below.
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 enabled 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.
Configure a Physical Interface

You can physically enable and disable interfaces, as well as set the interface speed and duplex. To use an
interface, it must be physically enabled in FXOS and logically enabled in the application.
Before you begin

• Interfaces that are already a member of an EtherChannel cannot be modified individually. Be sure to
configure settings before you add it to the EtherChannel.
Procedure

The All Interfaces page shows a visual representation of the currently installed interfaces at the top of the
page and provides a listing of the installed interfaces in the table below.

788
Add an EtherChannel (Port Channel)
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 760 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.

An EtherChannel (also known as a port channel) can include up to 16 member interfaces of the same media
type and capacity, and must be set to the same speed and duplex. 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. The Link
Aggregation Control Protocol (LACP) aggregates interfaces by exchanging the Link Aggregation Control
Protocol Data Units (LACPDUs) between two network devices.
You can configure each physical Data or Data-sharing interface in an EtherChannel to be:
• Active—Sends and receives LACP updates. An active EtherChannel can establish connectivity with
either an active or a passive EtherChannel. You should use the active mode unless you need to minimize
the amount of LACP traffic.
• On—The EtherChannel is always on, and LACP is not used. An “on” EtherChannel can only establish
a connection with another “on” EtherChannel.
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.
Non-data interfaces only support active mode.

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.

789
When the Firepower 4100/9300 chassis creates an EtherChannel, the EtherChannel stays in a Suspended
state for Active LACP mode or a Down state for On LACP mode until you assign it to a logical device, even
if the physical link is up. The EtherChannel will be brought out of this Suspended state in the following
situations:
• The EtherChannel is added as a data or management interface for a standalone logical device
• 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.
Procedure

The All Interfaces page shows a visual representation of the currently installed interfaces at the top of the
page and provides a listing of the installed interfaces in the table below.
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.
• 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.

790
Add a VLAN Subinterface for Container Instances
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.
Add a VLAN Subinterface for Container Instances

You can add between 250 and 500 VLAN subinterfaces to the chassis, depending on your network deployment.
You can add up to 500 subinterfaces to your chassis.
For multi-instance clustering, you can only add subinterfaces to the Cluster-type interface; subinterfaces on
data interfaces are not supported.
VLAN IDs per interface must be unique, and within a container instance, VLAN IDs must be unique across
all assigned interfaces. You can reuse VLAN IDs on separate interfaces as long as they are assigned to different
container instances. However, each subinterface still counts towards the limit even though it uses the same
ID.
You can also add subinterfaces within the application. For more information on when to use FXOS subinterfaces
vs. application subinterfaces, see FXOS Interfaces vs. Application Interfaces, on page 761.
Procedure
Step 1 Choose Interfaces to open the All Interfaces tab.

The All Interfaces tab shows a visual representation of the currently installed interfaces at the top of the page
and provides a listing of the installed interfaces in the table below.
Step 2 Click Add New > Subinterface to open the Add Subinterface dialog box.
• Data

791
Configure Logical Devices
• 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.
Step 4 Choose the parent Interface from the drop-down list.

You cannot add a subinterface to a physical interface that is currently allocated to a logical device. If other
subinterfaces of the parent are allocated, you can add a new subinterface as long as the parent interface itself
is not allocated.
Step 5 Enter a Subinterface ID, between 1 and 4294967295.

This ID will be appended to the parent interface ID as interface_id.subinterface_id. For example, if you add
a subinterface to Ethernet1/1 with the ID of 100, then the subinterface ID will be: Ethernet1/1.100. This ID
is not the same as the VLAN ID, although you can set them to match for convenience.
Step 6 Set the VLAN ID between 1 and 4095.

Step 7 Click OK.
Expand the parent interface to view all subinterfaces under it.
Configure Logical Devices

Add a standalone logical device or a High Availability pair on the Firepower 4100/9300 chassis.
For clustering, see Clustering for the Firepower Threat Defense, on page 935.
Add a Resource Profile for Container Instances

To specify resource usage per container instance, create one or more resource profiles. When you deploy the
logical device/application instance, you specify the resource profile that you want to use. The resource profile
sets the number of CPU cores; RAM is dynamically allocated according to the number of cores, and disk
space is set to 40 GB per instance.
• The minimum number of cores is 6.
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.
• The maximum number of cores available depends on the security module/chassis model; see Requirements
and Prerequisites for Container Instances, on page 783.

792
Add a Standalone Firepower Threat Defense
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.
Procedure
Step 1 Choose Platform Settings > Resource Profiles , and click Add.
The Add Resource Profile dialog box appears.
Step 2 Set the following paramters.

• 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.
Step 3 Click OK.

Standalone logical devices work either alone or in a High Availability pair. On the Firepower 9300 with
multiple security modules, you can deploy either a cluster or standalone devices. The cluster must use all
modules, so you cannot mix and match a 2-module cluster plus a single standalone device, for example.
You can use native instances on some modules, and container instances on the other module(s).
Before you begin

• Download the application image you want to use for the logical device from Cisco.com, and then upload
that image to the Firepower 4100/9300 chassis.
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).

793
• 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. See the configure
network management-data-interface command in the FTD command reference for more information.
• 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
• 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 792.
• 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
Procedure
Step 1 Choose Logical Devices.

Step 2 Click Add > Standalone, and set the following parameters:
a) Provide a Device Name.

This name is used by the chassis supervisor to configure management settings and to assign interfaces; it
is not the device name used in the application configuration.
b) For the Template, choose Cisco Firepower Threat Defense.
c) Choose the Image Version.

794
d) Choose the Instance Type: Container or Native.

A native instance uses all of the resources (CPU, RAM, and disk space) of the security module/engine,
so you can only install one native instance. A container instance uses a subset of resources of the security
module/engine, so you can install multiple container instances.
e) Click OK.
You see the Provisioning - device name window.
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.
Step 4 Click the device icon in the center of the screen.

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.

795
Step 5 On the General Information page, complete the following:
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:

796
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.

797
Add a High Availability Pair
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.
Add a High Availability Pair

FTD High Availability (also known as failover) is configured within the application, not in FXOS. However,
to prepare your chassis for high availability, see the following steps.
Before you begin

See Requirements and Prerequisites for High Availability, on page 784.

798
Change an Interface on a Firepower Threat Defense Logical Device
Procedure
Step 1 Allocate the same interfaces to each logical device.

Step 2 Allocate 1 or 2 data interfaces for the failover and state link(s).
These interfaces exchange high availability traffic between the 2 chassis. We recommend that you use a 10
GB data interface for a combined failover and state link. If you have available interfaces, you can use separate
failover and state 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
907.
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.

You can allocate or unallocate an interface, or replace a management interface on the FTD logical device.
You can then sync the interface configuration in FMC.
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. 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.
Deleting an interface will delete any configuration associated with that interface.
Before you begin

• Configure your interfaces, and add any EtherChannels according to Configure a Physical Interface, on
page 788 and Add an EtherChannel (Port Channel), on page 789.
• If you want to add an already-allocated interface to an EtherChannel (for example, all interfaces are
allocated by default to a cluster), you need to unallocate the interface from the logical device first, then
add the interface to the EtherChannel. For a new EtherChannel, you can then allocate the EtherChannel
to the device.
• If you want to replace the management or firepower eventing interface with a management EtherChannel,
then you need to create the EtherChannel with at least 1 unallocated data member interface, and then
replace the current management interface with the EtherChannel. After the FTD reboots (management
interface changes cause a reboot), and you sync the configuration in FMC, you can add the (now
unallocated) management interface to the EtherChannel as well.

799
• For clustering or High Availability, make sure you add or remove the interface on all units before you
sync the configuration in the FMC. We recommend that you make the interface changes on the data/standby
unit(s) first, and then on the control/active unit. Note that new interfaces are added in an administratively
down state, so they do not affect interface monitoring.
Procedure
Step 1 In the Firepower Chassis Manager, choose Logical Devices.

Step 2 Click the Edit icon at the top right to edit the logical device.
Step 3 Allocate a new data interface by selecting the interface in the Data Ports area.
Do not delete any interfaces yet.
Step 4 Replace the management or eventing interface:

For these types of interfaces, the device reboots after you save your changes.
a) Click the device icon in the center of the page.
b) On the General or Cluster Information tab, choose the new Management Interface from the drop-down
list.
c) On the Settings tab, choose the new Eventing Interface from the drop-down list.
d) Click OK.
If you change the IP address of the Management interface, then you must also change the IP address for the
device in the Firepower Management Center: go to Devices > Device Management > Device/Cluster. In the
Management area, set the IP address to match the bootstrap configuration address.
Step 5 Click Save.

Step 6 Sync the interfaces in FMC.
a) Log into the FMC.
b) Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is
selected by default.
c) Click the Sync Device button on the top left of the Interfaces page.
d) After the changes are detected, you will see a red banner on the Interfaces page indicating that the interface
configuration has changed. Click the Click to know more link to view the interface changes.

800
Connect to the Console of the Application
e) If you plan to delete an interface, manually transfer any interface configuration from the old interface to
the new interface.
Because you have not yet deleted any interfaces, you can refer to the existing configuration. You will
have additional opportunity to fix the configuration after you delete the old interface and re-run the
validation. The validation will show you all locations in which the old interface is still used.
f) 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.
g) Click Save.
h) Click Deploy > Deployment.
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 8 Click Save.

Step 9 Sync the interfaces again in FMC.
Connect to the Console of the Application

Use the following procedure to connect to the console of the application.
Procedure
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.

801
History for Firepower Threat Defense Logical Devices
Example:
Firepower# connect module 1 console

Telnet escape character is '~'.
Trying 127.5.1.1...
Connected to 127.5.1.1.
Escape character is '~'.
CISCO Serial Over LAN:

Close Network Connection to Exit
Firepower-module1>
Step 2 Connect to the application console.

connect ftd name
To view the instance names, enter the command without a name.
Example:
Firepower-module1> connect ftd ftd1

Connecting to ftd(ftd-native) console... enter exit to return to bootCLI
[...]
>
Step 3 Exit the application console to the FXOS module CLI.

• FTD—Enter exit
Step 4 Return to the supervisor level of the FXOS CLI.

Exit the console:
a) Enter ~
You exit to the Telnet application.
b) To exit the Telnet application, enter:
telnet>quit
Exit the Telnet session:

a) Enter Ctrl-], .

Flow Offload Support for Container 7.0 Container instances now support flow offload to hardware.
Instances
Note Requires FXOS 2.10.

802
Synchronization between the FTD 6.7 The chassis can now synchronize the FTD operational link state with
operational link state and the physical the physical link state for data interfaces. Currently, interfaces will be
link state in an Up state as long as the FXOS admin state is up and the physical
link state is up. The FTD application interface admin state is not
considered. Without synchronization from FTD, data interfaces can
be in an Up state physically before the FTD application has completely
come online, for example, or can stay Up for a period of time after you
initiate an FTD shutdown. For inline sets, this state mismatch can result
in dropped packets because external routers may start sending traffic
to the FTD before the FTD can handle it. This feature is disabled by
default, and can be enabled per logical device in FXOS.
Note This feature is not supported for clustering, container
instances, or an FTD with a Radware vDP decorator. It is
also not supported for the ASA.
New/Modified Firepower Chassis Manager screens: Logical Devices

> Enable Link State
New/Modified FXOS commands: set link-state-sync enabled, show
interface expand detail
FTD configuration backup and restore 6.7 You can now use the FMC backup/restore tool on an FTD container
using FMC for container instances instance.
New/Modified FMC screens: System > Tools > Backup/Restore >
Managed Device Backup
New/Modified FTD CLI commands: restore
Supported platforms: Firepower 4100/9300
Note Requires FXOS 2.9.
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.
FTD on the Firepower 4112 6.6 We introduced the Firepower 4112.


803
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.
Logical Devices > Add Device > Settings > Hardware Crypto
drop-down menu
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.
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.
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.

804
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.
New/Modified Firepower Management Center screens:

• Devices > Device Management > Edit icon > Interfaces tab

• Overview > Devices
• Interfaces > All Interfaces > Add New drop-down menu >
Subinterface
• Interfaces > All Interfaces > Type
• Logical Devices > Add Device
• Platform Settings > Mac Pool
• Platform Settings > Resource Profiles
New/Modified FXOS commands: connect ftd name, connect module

telnet, create bootstrap-key PERMIT_EXPERT_MODE, create
resource-profile, create subinterface, scope auto-macpool, set
cpu-core-count, set deploy-type, set port-type data-sharing, set
prefix, set resource-profile-name, set vlan, scope app-instance ftd
name, show cgroups container, show interface, show mac-address,
show subinterface, show tech-support module app-instance, show
version

805
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
New/Modified FXOS commands: set cluster-control-link network

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.
• Interfaces > All Interfaces > Edit Port Channel > Mode
New/Modified FXOS commands: set port-channel-mode

Support for EtherChannels in FTD 6.2 You can now use EtherChannels in a FTD inline set.
inline sets
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.
• 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.
• Devices > Device Management > Interfaces > Edit Physical
Interface

806
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
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.
• Logical Devices > Configuration
New/Modified FXOS commands: enter mgmt-bootstrap ftd, enter

bootstrap-key FIREPOWER_MANAGER_IP, enter bootstrap-key
FIREWALL_MODE, enter bootstrap-key-secret
REGISTRATION_KEY, enter bootstrap-key-secret PASSWORD,
enter bootstrap-key FQDN, enter bootstrap-key DNS_SERVERS,
enter bootstrap-key SEARCH_DOMAINS, enter ipv4 firepower,
enter ipv6 firepower, set value, set gateway, set ip,
accept-license-agreement

807

808
PA R T VII
Firepower Threat Defense Interfaces and Device
Settings
• Interface Overview for Firepower Threat Defense, on page 811
• Regular Firewall Interfaces for Firepower Threat Defense, on page 821
• Inline Sets and Passive Interfaces for Firepower Threat Defense, on page 869
• DHCP and DDNS Services for Threat Defense, on page 881
• SNMP for the Firepower 1000/2100, on page 893
• Quality of Service (QoS) for Firepower Threat Defense, on page 897
CHAPTER 29
Interface Overview for Firepower Threat Defense
The FTD device includes data interfaces that you can configure in different modes, as well as a
management/diagnostic interface.
• Management/Diagnostic Interface, on page 811
• Interface Mode and Types, on page 812
• Security Zones and Interface Groups, on page 813
• Auto-MDI/MDIX Feature, on page 814
• Default Settings for Interfaces, on page 814
• Enable the Physical Interface and Configure Ethernet Settings, on page 815
• Sync Interface Changes with the Firepower Management Center, on page 816
Management/Diagnostic Interface
The physical management interface is shared between the Diagnostic logical interface and the Management
logical interface.
Management Interface
The Management 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.
You can alternatively manage the FTD using a data interface instead of the Management interface.
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.

811
Firepower Threat Defense Interfaces and Device Settings
Interface Mode and Types
Interface Mode and Types

You can deploy FTD interfaces in two modes: Regular firewall mode and IPS-only mode. You can include
both firewall and IPS-only interfaces on the same device.
Regular Firewall Mode

Firewall mode interfaces subject traffic to firewall functions such as maintaining flows, tracking flow states
at both IP and TCP layers, IP defragmentation, and TCP normalization. You can also optionally configure
IPS functions for this traffic according to your security policy.
The types of firewall interfaces you can configure depends on the firewall mode set for the device: routed or
transparent mode. See Transparent or Routed Firewall Mode for Firepower Threat Defense, on page 747 for
more information.
• Routed mode interfaces (routed firewall mode only)—Each interface that you want to route between is
on a different subnet.
• Bridge group interfaces (routed and transparent firewall mode)—You can group together multiple
between the interfaces. Each bridge group includes a Bridge Virtual Interface (BVI) to which you assign
an IP address on the network. In routed mode, the Firepower Threat Defense device routes between BVIs
and regular routed interfaces. In transparent mode, each bridge group is separate and cannot communicate
with each other.
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.
passive interfaces. IPS-only interfaces can be used in both firewall modes.
IPS-only interfaces can be deployed as the following types:

• Inline Set, with optional Tap mode—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 FTD 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.
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

812
Security Zones and Interface Groups
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.
Security Zones and Interface Groups

Each interface can be assigned to a security zone and/or interface group. You then apply your security policy
based on zones or groups. For example, you can assign the "inside" interface to the "inside" zone; and the
"outside" interface to the "outside" zone. You can configure your access control policy to enable traffic to go
from inside to outside, but not from outside to inside, for example. Note that the interface or zone name itself
does not provide any default behvior in regards to the security policy, we recommend using names that are
self-describing to avoid mistakes in future configuration. A good name signifies a logical segment or traffic
specification, for example:
• Names of internal interfaces—InsideV110, InsideV160, InsideV195
• Names of DMZ interfaces—DMZV11, DMZV12, DMZV-TEST
• Names of external interfaces—Outside-ASN78, Outside-ASN91
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 620. 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.
Note Policies that apply to any zone (a global policy) apply to interfaces in zones as well as any interfaces that are
not assigned to a zone.

813
Auto-MDI/MDIX Feature
The Diagnostic/Management interface does not belong to a zone or interface group.
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.
Default Settings for Interfaces

This section lists default settings for interfaces.
Default State of Interfaces

The default state of an interface depends on the type.
• Physical interfaces—Disabled. The exception is the Diagnostic interface that is enabled for initial setup.
• Redundant Interfaces—Enabled. However, for traffic to pass through the redundant interface, the member
physical interfaces must also be enabled.
• VLAN subinterfaces—Enabled. However, for traffic to pass through the subinterface, the physical
interface must also be enabled.
• EtherChannel port-channel interfaces (ASA models)—Enabled. However, for traffic to pass through the
EtherChannel, the channel group physical interfaces must also be enabled.
• EtherChannel port-channel interfaces (Firepower models)—Disabled.
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.
Default Speed and Duplex

By default, the speed and duplex for copper (RJ-45) interfaces are set to auto-negotiate.
By default, the speed and duplex for fiber (SFP) interfaces are set to the maximum speed, with auto-negotiation
enabled.

814
Enable the Physical Interface and Configure Ethernet Settings
Enable the Physical Interface and Configure Ethernet Settings

This section describes how to:
• Enable the physical interface. By default, physical interfaces are disabled (with the exception of the
Diagnostic interface).
• Set a specific speed and duplex. By default, speed and duplex are set to Auto.
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 788 for more information.
Note For Firepower 1010 switch ports, see Configure Firepower 1010 Switch Ports, on page 822.
Before you begin

If you changed the physical interfaces on the device after you added it to the FMC, you need to refresh the
interface listing by clicking Sync Interfaces from device on the top left of Interfaces.
Procedure
Step 1 Select Devices > Device Management and click Edit ( ) for your FTD device. The Interfaces page is
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 Full, Half, or Auto. Auto is the default for RJ-45 interfaces. You cannot select Auto
for SFP interfaces.
• Speed—Choose Auto to have the interface negotiate the speed, link status, and flow control (Auto is
only available for RJ-45 interfaces), or pick a specific speed: 10, 100, 1000, 10000 Mbps. For SFP
interfaces, setting the speed enables auto-negotiation of link status and flow control. For SFP interfaces,
depending on your hardware, you can select No Negotiate to set the speed to 1000 and disable link
negotiation. You cannot disable link negotiation for the 10000 speed setting.
Step 6 In the Mode drop-down list, choose one of the following:.

815
Sync Interface Changes with the Firepower Management Center
• None—Choose this setting for regular firewall interfaces and inline sets. The mode will automatically
be changed to Routed, Switched, or Inline based on futher configuration.
• Passive—Choose this setting for passive IPS-only interfaces.
• Erspan—Choose this setting for ERSPAN passive IPS-only interfaces.
Step 7 Click OK.

Step 8 Click Save.
You can now go to Deploy > Deployment and deploy the policy to assigned devices. The changes are not
Step 9 Continue configuring interfaces.

• Regular Firewall Interfaces for Firepower Threat Defense, on page 821
• Inline Sets and Passive Interfaces for Firepower Threat Defense, on page 869
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
There are two types of interface changes performed outside of FMC that need to be synched:
• Addition or deletion of physical interfaces—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.
When the FMC detects changes, the Interface page shows status (removed, changed, or added) to the
left of each interface.
• FMC access interface changes—If you configure a data interface for FMC management using the
configure network management-data-interface command, you must manually make matching
configuration changes in FMC and then acknowledge the changes. These interface changes cannot be
made automatically.

816
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.
Before you begin

• Model Support—FTD
• User Roles:
• Admin
• Access Admin
• Network Admin
Procedure
Step 2 If required, click Sync Device on the top left of Interfaces.
Step 3 After the changes are detected, see the following steps.
Addition or Deletion of Physical Interfaces
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.
FMC Access Interface Changes

a) You will see a yellow banner in the top right of the Device page indicating that the FMC access
configuration has changed. Click the View details link to view the interface changes.
The FMC Access - Configuration Details dialog box opens.

b) Take note of all highlighted configurations, especially the pink highlighted ones. You need to match any
values on the FTD by manually configuring them on the FMC.
For example, the pink highlights below show configuration that exists on the FTD but not yet on the FMC.

817
The following example shows this page after configuring the interface in FMC; the interface settings
match, and the pink highlight was removed.
c) Click Acknowledge.
We recommend that you do not click Acknowledge until you have finished the FMC configuration, and
are ready to deploy. Clicking Acknowledge removes the block on deployment. The next time you deploy,

818
the FMC configuration will overwrite any remaining conflicting settings on the FTD. It is your responsibility
to manually fix the configuration in the FMC before you re-deploy.
d) You can now go to Deploy > Deployment and deploy the policy to assigned devices.

819

820
CHAPTER 30
Regular Firewall Interfaces for Firepower Threat
Defense
This chapter includes regular firewall FTD interface configuration including EtherChannels, VLAN
subinterfaces, IP addressing, and more.
Note For initial interface configuration on the Firepower 4100/9300, see Configure Interfaces, on page 788.
• Requirements and Prerequisites for Regular Firewall Interfaces, on page 821

• Configure Firepower 1010 Switch Ports, on page 822
• Configure EtherChannel and Redundant Interfaces, on page 831
• Configure VLAN Subinterfaces and 802.1Q Trunking, on page 839
• Configure Routed and Transparent Mode Interfaces, on page 841
• Configure Advanced Interface Settings, on page 856
• History for Regular Firewall Interfaces for Firepower Threat Defense, on page 866
Requirements and Prerequisites for Regular Firewall Interfaces

Model Support
FTD
User Roles
• Admin
• Access Admin
• Network Admin

821
Configure Firepower 1010 Switch Ports
Configure Firepower 1010 Switch Ports

You can configure each Firepower 1010 interface to run as a regular firewall interface or as a Layer 2 hardware
switch port. This section includes tasks for starting your switch port configuration, including enabling or
disabling the switch mode and creating VLAN interfaces and assigning them to switch ports. This section
also describes how to customize Power over Ethernet (PoE) on supported interfaces.
About Firepower 1010 Switch Ports

This section describes the switch ports of the Firepower 1010.
Understanding Firepower 1010 Ports and Interfaces
Ports and Interfaces

For each physical Firepower 1010 interface, you can set its operation as a firewall interface or as a switch
port. See the following information about physical interface and port types as well as logical VLAN interfaces
to which you assign switch ports:
• Physical firewall interface—In routed mode, these interfaces forward traffic between networks at Layer
3, using the configured security policy to apply firewall and VPN services. In transparent mode, these
interfaces are bridge group members that forward traffic between the interfaces on the same network at
Layer 2, using the configured security policy to apply firewall services. In routed mode, you can also
use Integrated Routing and Bridging with some interfaces as bridge group members and others as Layer
3 interfaces. By default, the Ethernet 1/1 interface is configured as a firewall interface. You can also
configure these interfaces to be IPS-only (inline sets and passive interfaces).
• Physical switch port—Switch ports forward traffic at Layer 2, using the switching function in hardware.
Switch ports on the same VLAN can communicate with each other using hardware switching, and traffic
is not subject to the FTD security policy. Access ports accept only untagged traffic, and you can assign
them to a single VLAN. Trunk ports accept untagged and tagged traffic, and can belong to more than
one VLAN. By default, Ethernet 1/2 through 1/8 are configured as access switch ports on VLAN 1. You
cannot configure the Diagnostic interface as a switch port.
• Logical VLAN interface—These interfaces operate the same as physical firewall interfaces, with the
exception being that you cannot create subinterfaces, redundant interfaces, IPS-only interfaces (inline
sets and passive interfaces), or EtherChannel interfaces. When a switch port needs to communicate with
another network, then the FTD applies the security policy to the VLAN interface and routes to another
logical VLAN interface or firewall interface. You can even use Integrated Routing and Bridging with
VLAN interfaces as bridge group members. Traffic between switch ports on the same VLAN are not
subject to the FTD security policy, but traffic between VLANs in a bridge group are subject to the security
policy, so you may choose to layer bridge groups and switch ports to enforce the security policy between
certain segments.
Power Over Ethernet

Ethernet 1/7 and Ethernet 1/8 support Power over Ethernet+ (PoE+).

822
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.
Guidelines and Limitations for Firepower 1010 Switch Ports

High Availability and Clustering
• No cluster support.
• You should not use the switch port functionality when using High Availability. Because the switch ports
operate in hardware, they continue to pass traffic on both the active and the standby units. High Availability
is designed to prevent traffic from passing through the standby unit, but this feature does not extend to
switch ports. In a normal High Availability network setup, active switch ports on both units will lead to
network loops. We suggest that you use external switches for any switching capability. Note that VLAN
interfaces can be monitored by failover, while switch ports cannot. Theoretically, you can put a single
switch port on a VLAN and successfully use High Availability, but a simpler setup is to use physical
firewall interfaces instead.
• You can only use a firewall interface as the failover link.
Logical VLAN Interfaces

• You can create up to 60 VLAN interfaces.
• If you also use VLAN subinterfaces on a firewall interface, you cannot use the same VLAN ID as for a
logical VLAN interface.
• MAC Addresses:
• Routed firewall mode—All VLAN interfaces share a MAC address. Ensure that any connected
switches can support this scenario. If the connected switches require unique MAC addresses, you
can manually assign MAC addresses. See Configure the MAC Address, on page 862.
• 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 862.
Bridge Groups
You cannot mix logical VLAN interfaces and physical firewall interfaces in the same bridge group.
VLAN Interface and Switch Port Unsupported Features

VLAN interfaces and switch ports do not support:
• Dynamic routing

823
Configure Switch Ports and Power Over Ethernet
• 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)
Other Guidelines and Limitiations

• You can configure a maximum of 60 named interfaces on the Firepower 1010.
• You cannot configure the Diagnostic interface as a switch port.
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.
Configure Switch Ports and Power Over Ethernet

To configure switch ports and PoE, complete the following tasks.
Enable or Disable Switch Port Mode

You can set each interface independently to be either a firewall interface or a switch port. By default, Ethernet
1/1 is a firewall interface, and the remaining Ethernet interfaces are configured as switch ports.
Procedure
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 825). You cannot set the Diagnostic interface to
switch port mode. When you change the switch port mode, all unsupported configuration is removed:

824
Configure a VLAN Interface
Configure a VLAN Interface

This section describes how to configure VLAN interfaces for use with associated switch ports. By default,
switch ports are assigned to VLAN1; however, you must manually add the logical VLAN1 interface (or
whichever VLAN you set for these switch ports) for traffic to be routed and to participate in the FTD security
policy.
Procedure
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.

825
Configure Switch Ports as Access Ports
a) Set the VLAN ID, between 1 and 4070, excluding IDs in the range 3968 to 4047, which are reserved for
internal use.
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 844
• Configure General Bridge Group Member Interface Parameters, on page 848
Step 5 Click OK.

Step 6 Click Save.

To assign a switch port to a single VLAN, configure it as an access port. Access ports accept only untagged
traffic. By default, Ethernet1/2 through Ethernet 1/8 switch ports are assigned to VLAN 1.
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.
Procedure

826

Step 5 Set the Port Mode to Access.

Step 6 In the VLAN ID field, set the VLAN for this switch port, between 1 and 4070.
The default VLAN ID is 1.
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.

827
Configure Switch Ports as Trunk Ports
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 9 Click OK.

Step 10 Click Save.

This procedure describes how to create a trunk port that can carry multiple VLANs using 802.1Q tagging.
Trunk ports accept untagged and tagged traffic. Traffic on allowed VLANs pass through the trunk port
unchanged.
When the trunk receives untagged traffic, it tags it to the native VLAN ID so that the ASA can forward the
traffic to the correct switch ports, or can route it to another firewall interface. When the ASA sends native
VLAN ID traffic out of the trunk port, it removes the VLAN tag. Be sure to set the same native VLAN on
the trunk port on the other switch so that the untagged traffic will be tagged to the same VLAN.
Procedure

828

Step 5 Set the Port Mode to Trunk.

Step 6 In the Native VLAN ID field, set the native VLAN for this switch port, between 1 and 4070.
The default native VLAN ID is 1.
Each port can only have one native VLAN, but every port can have either the same or a different native VLAN.
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.

829
Configure Power Over Ethernet
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 10 Click OK.

Step 11 Click Save.
Configure Power Over Ethernet

Ethernet 1/7 and Ethernet 1/8 support Power over Ethernet (PoE) for devices such as IP phones or wireless
access points. The Firepower 1010 supports both IEEE 802.3af (PoE) and 802.3at (PoE+). PoE+ uses Link
Layer Discovery Protocol (LLDP) to negotiate the power level. PoE+ can deliver up to 30 watts to a powered
device. Power is only supplied when needed.
If you shut down the switch port, or configure the port as a firewall interface, then you disable power to the
device.
PoE is enabled by default on Ethernet 1/7 and Ethernet 1/8. This procedure describes how to disable and
enable PoE and how to set optional parameters.
Procedure
Step 2 Click Edit ( ) for Ethernet1/7 or 1/8.

830
Configure EtherChannel and Redundant Interfaces
Step 3 Click PoE.
Step 4 Check the Enable PoE check box.

PoE is enabled by default.
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.
Step 6 Click OK.

Step 7 Click Save.
Configure EtherChannel and Redundant Interfaces

This section tells how to configure EtherChannels and redundant interfaces.
Note For the Firepower 4100/9300, you configure EtherChannels in FXOS. See Add an EtherChannel (Port Channel),
Note Only ASA 5500-X models support redundant interfaces; Firepower models do not support them.

831
About EtherChannels and Redundant Interfaces
About EtherChannels and Redundant Interfaces

This section describes EtherChannels and Redundant Interfaces.
About Redundant Interfaces (ASA Platform Only)

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 Firepower Threat Defense device reliability.
You can configure up to 8 redundant interface pairs.
Redundant Interface MAC Address

The 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. Alternatively, you can assign a manual MAC address to the redundant
interface, which is used regardless of the member interface MAC addresses. When the active interface fails
over to the standby, the same MAC address is maintained so that traffic is not disrupted.
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.
Channel Group Interfaces

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. For 16 active interfaces, be sure that your switch supports the feature (for example, the
Cisco Nexus 7000 with F2-Series 10 Gigabit Ethernet Module).
All interfaces in the channel group must be the same type and speed. The first interface added to the channel
group determines the correct type and speed.
The EtherChannel aggregates the traffic across all the available active interfaces in the channel. The interface
is selected using a proprietary hash algorithm, based on source or destination MAC addresses, IP addresses,
TCP and UDP port numbers and VLAN numbers.
Connecting to an EtherChannel on Another Device

The device to which you connect the FTD EtherChannel must also support 802.3ad EtherChannels; for
example, you can connect to the Catalyst 6500 switch or the Cisco Nexus 7000.
When the switch is part of a Virtual Switching System (VSS) or Virtual Port Channel (vPC), then you can
connect FTD interfaces within the same EtherChannel to separate switches in the VSS/vPC. The switch
interfaces are members of the same EtherChannel port-channel interface, because the separate switches act
like a single switch.

832
Link Aggregation Control Protocol
Figure 21: Connecting to a VSS/vPC
Note If the FTD is in transparent firewall mode, and you place the FTD between two sets of VSS/vPC switches,
then be sure to disable Unidirectional Link Detection (UDLD) on any switch ports connected to the FTD with
an EtherChannel. If you enable UDLD, then a switch port may receive UDLD packets sourced from both
switches in the other VSS/vPC pair. The receiving switch will place the receiving interface in a down state
with the reason "UDLD Neighbor mismatch".
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
Link Aggregation Control Protocol

The Link Aggregation Control Protocol (LACP) aggregates interfaces by exchanging the Link Aggregation
Control Protocol Data Units (LACPDUs) between two network devices.
You can configure each physical interface in an EtherChannel to be:

833
Load Balancing
• Active—Sends and receives LACP updates. An active EtherChannel can establish connectivity with
either an active or a passive EtherChannel. You should use the active mode unless you need to minimize
the amount of LACP traffic.
• Passive—Receives LACP updates. A passive EtherChannel can only establish connectivity with an active
EtherChannel. Not supported on Firepower hardware models.
• On—The EtherChannel is always on, and LACP is not used. An “on” EtherChannel can only establish
a connection with another “on” EtherChannel.
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.
EtherChannel MAC Address

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 the lowest numbered channel group interface MAC address as the port-channel
MAC address. Alternatively you can manually configure a MAC address for the port-channel interface. We
recommend manually 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.
Guidelines for EtherChannels and Redundant Interfaces

Bridge Group
In routed mode, FMC-defined EtherChannels are not supported as bridge group members. EtherChannels on
the Firepower 4100/9300 can be bridge group members.
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.

834
Guidelines for EtherChannels and Redundant Interfaces
• 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.
General Redundant Interface Guidelines

• You can configure up to 8 redundant interface pairs.
• All FTD configuration refers to the logical redundant 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.
• If you shut down the active interface, then the standby interface becomes active.
• Redundant interfaces do not support Diagnostic slot/port interfaces as members. You can, however, set
a redundant interface comprised of non-Diagnostic interfaces as management-only.
General EtherChannel Guidelines

• You can configure up to 48 EtherChannels, depending on how many interfaces are available on 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. For 16 active interfaces, be sure that your switch supports the
feature (for example, the Cisco Nexus 7000 with F2-Series 10 Gigabit Ethernet Module).

835
Configure a Redundant Interface (ASA Platform Only)
• All interfaces in the channel group must be the same media type and capacity, and must be set to the
same speed and duplex. 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.
• The device to which you connect the FTD EtherChannel must also support 802.3ad EtherChannels.
• The FTD does not support LACPDUs that are VLAN-tagged. If you enable native VLAN tagging on
the neighboring switch using the Cisco IOS vlan dot1Q tag native command, then the FTD will drop
the tagged LACPDUs. Be sure to disable native VLAN tagging on the neighboring switch.
• 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.
Configure a Redundant Interface (ASA Platform Only)

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.
Before you begin

• You cannot add a physical interface to the redundant interface if you configured a name for it. You must
first remove the name.

836
Configure an EtherChannel
Caution If you are using a physical interface already in your configuration, removing the
name will clear any configuration that refers to the interface.
Procedure
Step 2 Enable the member interfaces according to Enable the Physical Interface and Configure Ethernet Settings, on
page 815.
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.
Step 7 (Optional) Add a VLAN subinterface. See Add a Subinterface, on page 840.
Step 8 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on
page 844 or Configure Bridge Group Interfaces, on page 848.
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.

837
Note For the Firepower 4100/9300, you configure EtherChannels in FXOS. See Add an EtherChannel (Port Channel),
Before you begin

• You cannot add a physical interface to the channel group if you configured a name for it. You must first
remove the name.
Note If you are using a physical interface already in your configuration, removing the
name will clear any configuration that refers to the interface.
Procedure
Step 2 Enable the member interfaces according to Enable the Physical Interface and Configure Ethernet Settings, on
page 815.
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 834.
• 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.

838
Configure VLAN Subinterfaces and 802.1Q Trunking
• 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.
Step 10 (Optional) Add a VLAN subinterface. See Add a Subinterface, on page 840.
Configure VLAN Subinterfaces and 802.1Q Trunking

VLAN subinterfaces let you divide a physical, redundant, or EtherChannel interface into multiple logical
interfaces that are tagged with different VLAN IDs. An interface with one or more VLAN subinterfaces is
automatically configured as an 802.1Q trunk. Because VLANs let you keep traffic separate on a given physical
interface, you can increase the number of interfaces available to your network without adding additional
physical interfaces or devices.
Guidelines and Limitations for VLAN Subinterfaces

Model Support
• Firepower 1010—VLAN subinterfaces are not supported on switch ports or VLAN interfaces.
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.

839
Maximum Number of VLAN Subinterfaces by Device Model
• 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.
Maximum Number of VLAN Subinterfaces by Device Model

The device model limits the maximum number of VLAN subinterfaces that you can configure. Note that you
can configure subinterfaces on data interfaces only, you cannot configure them on the management interface.
The following table explains the limits for each device model.
Model Maximum VLAN Subinterfaces
Firepower 1010 60
Firepower 1120 512
Firepower 1140, 1150 1024
Firepower 2100 1024
Firepower 4100 1024
Firepower 9300 1024
Firepower Threat Defense Virtual 50
ASA 5508-X 50
ASA 5516-X 100
ISA 3000 100
Add a Subinterface
Add one or more subinterfaces to a physical, redundant, or port-channel interface.
For the Firepower 4100/9300, you can configure subinterfaces in FXOS for use with container instances; see
Add a VLAN Subinterface for Container Instances, on page 791. These subinterfaces appear in the the FMC
interface list. You can also add subinterfaces in FMC, but only on parent interfaces that do not already have
subinterfaces defined in FXOS.

840
Configure Routed and Transparent Mode Interfaces
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.
Procedure
Step 2 Enable the parent interface according to Enable the Physical Interface and Configure Ethernet Settings, on
page 815.
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 5 Click OK.

Step 6 Click Save.
Configure Routed and Transparent Mode Interfaces

This section includes tasks to complete the regular interface configuration for all models in routed or transparent
firewall mode.
About Routed and Transparent Mode Interfaces

Firewall mode interfaces subject traffic to firewall functions such as maintaining flows, tracking flow states
at both IP and TCP layers, IP defragmentation, and TCP normalization. You can also optionally configure
IPS functions for this traffic according to your security policy.
The types of firewall interfaces you can configure depends on the firewall mode set for the device: routed or
transparent mode. See Transparent or Routed Firewall Mode for Firepower Threat Defense, on page 747 for
more information.

841
Dual IP Stack (IPv4 and IPv6)
• Routed mode interfaces (routed firewall mode only)—Each interface that you want to route between is
on a different subnet.
• Bridge group interfaces (routed and transparent firewall mode)—You can group together multiple
between the interfaces. Each bridge group includes a Bridge Virtual Interface (BVI) to which you assign
an IP address on the network. In routed mode, the Firepower Threat Defense device routes between BVIs
and regular routed interfaces. In transparent mode, each bridge group is separate and cannot communicate
with each other.
Dual IP Stack (IPv4 and IPv6)

The Firepower Threat Defense device supports both IPv6 and IPv4 addresses on an interface. Make sure you
configure a default route for both IPv4 and IPv6.
31-Bit Subnet Mask

For routed interfaces, you can configure an IP address on a 31-bit subnet for point-to-point connections. The
31-bit subnet includes only 2 addresses; normally, the first and last address in the subnet is reserved for the
network and broadcast, so a 2-address subnet is not usable. However, if you have a point-to-point connection
and do not need network or broadcast addresses, a 31-bit subnet is a useful way to preserve addresses in IPv4.
For example, the failover link between 2 FTDs only requires 2 addresses; any packet that is transmitted by
one end of the link is always received by the other, and broadcasting is unnecessary. You can also have a
directly-connected management station running SNMP or Syslog.
31-Bit Subnet and Clustering

You can use a 31-bit subnet mask for cluster interfaces, excluding the management interface and the Cluster
Control Link.
31-Bit Subnet and Failover

For failover, when you use a 31-bit subnet for the FTD interface IP address, you cannot configure a standby
IP address for the interface because there are not enough addresses. Normally, an interface for failover should
have a standby IP address so the active unit can perform interface tests to ensure standby interface health.
Without a standby IP address, the FTD cannot perform any network tests; only the link state can be tracked.
For the failover and optional separate state link, which are point-to-point connections, you can also use a
31-bit subnet.
31-Bit Subnet and Management

If you have a directly-connected management station, you can use a point-to-point connection for SSH or
HTTP on the FTD, or for SNMP or Syslog on the management station.
31-Bit Subnet Unsupported Features

The following features do not support the 31-Bit subnet:
• BVI interfaces for bridge groups—The bridge group requires at least 3 host addresses: the BVI, and two
hosts connected to two bridge group member interfaces. you must use a /29 subnet or smaller.
• Multicast Routing

842
Guidelines and Limitations for Routed and Transparent Mode Interfaces
Guidelines and Limitations for Routed and Transparent Mode Interfaces

High Availability
• Do not configure failover links with the procedures in this chapter. See the High Availability chapter for
more information.
• When you use High Availability, you must set the IP address and standby address for data interfaces
manually; DHCP and PPPoE are not supported. Set the standby IP addresses on the Devices > Device
Management > High Availability tab in the Monitored Interfaces area. See the High Availability
chapter for more information.
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.
Transparent Mode and Bridge Group Guidelines

• You can create up to 250 bridge groups, with 64 interfaces per bridge group.
• Each directly-connected network must be on the same subnet.
• The Firepower Threat Defense device does not support traffic on secondary networks; only traffic on
the same network as the BVI IP address is supported.
• An IP address for the BVI is required for each bridge group for to-the-device and from-the-device
management traffic, as well as for data traffic to pass through the Firepower Threat Defense device. For
IPv4 traffic, specify an IPv4 address. For IPv6 traffic, specify an IPv6 address.
• You can only configure IPv6 addresses manually.
• The BVI IP address must be on the same subnet as the connected network. You cannot set the subnet to
a host subnet (255.255.255.255).
• Management interfaces are not supported as bridge group members.
• For the Firepower 1010, you cannot mix logical VLAN interfaces and physical firewall interfaces in the
same 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.

843
Configure Routed Mode Interfaces
• 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.
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.
Additional Guidelines and Requirements

• The FTD supports only one 802.1Q header in a packet and does not support multiple headers (known as
Q-in-Q support) for firewall interfaces.Note: For inline sets and passive interfaces, the FTD supports
Q-in-Q up to two 802.1Q headers in a packet, with the exception of the Firepower 4100/9300, which
only supports one 802.1Q header.

This procedure describes how to set the name, security zone, and IPv4 address.
Before you begin

• Firepower 4100/9300
1. Configure a Physical Interface, on page 788
2. (Optional) Configure any special interfaces.
• Add an EtherChannel (Port Channel), on page 789
• Add a VLAN Subinterface for Container Instances, on page 791 in FXOS
• Add a Subinterface, on page 840 in FMC
• (Optional) All other models:

• Configure a Redundant Interface (ASA Platform Only), on page 836
• Configure an EtherChannel, on page 837
• Add a Subinterface, on page 840

844
• Firepower 1010: Configure a VLAN Interface, on page 825
Procedure
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 5 (Optional) Set this interface to Management Only to limit traffic to management traffic; through-the-box
traffic is not allowed.
Step 7 In the Mode drop-down list, choose None.

Regular firewall interfaces have the mode set to None. The other modes are for IPS-only interface types.
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 861 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 point-to-point connections, you can specify
a 31-bit subnet mask (255.255.255.254 or /31). In this case, no IP addresses are reserved for the network
or broadcast addresses. You cannot set the standby IP address in this case. 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.

845
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 851 to configure IPv6 addressing on the IPv6 tab.
Step 12 (Optional) See Configure the MAC Address, on page 862 to manually configure the MAC address on the
Advanced tab.
for SFP interfaces.
Step 14 (Optional) Enable FMC management access on a data interface on the FMC Access page.
You can enable FMC access from a data interface when you first setup the FTD. If you want to enable or
disable FMC access after you added the FTD to the FMC, see:
• Enable FMC access: Change the FMC Access Interface from Management to Data, on page 361
Note You cannot enable FMC access unless you first initiate the management interface migration
from Management to a data interface. After you initiate the migration, you can enable FMC
access on the FMC Access page and save the configuration successfully.
• Disable FMC access: Change the FMC Access Interface from Data to Management, on page 364

846
If you want to change the FMC access interface from one data interface to another data interface, you must
disable FMC access on the original data interface, but do not disable the interface itself yet; the original data
interface must be used to perform the deployment. If you want to use the same IP address on the new FMC
access interface, you can delete or change the IP configuration on the original interface; this change should
not affect the deployment. If you use a different IP address for the new interface, then also change the device
IP address shown in FMC; see Update the Hostname or IP Address in FMC, on page 360. Be sure to also
update related configuration to use the new interface such as static routes, DDNS, and DNS settings.
FMC access from a data interface has the following limitations:
EtherChannel.
• PPPoE is not supported. If your ISP requires PPPoE, you will have to put a router with PPPoE support
between the FTD and the WAN modem.
Because the Management interface gateway will be changed to be the data interfaces, you also cannot
SSH to the Management interface from a remote network unless you add a static route for the Management
• Check Enable management on this interface for the Firepower Management Center to use this data
interface for management instead of the dedicated Management interface.

847
Configure Bridge Group Interfaces
• (Optional) In the Allowed Management Networks box, add the networks from which you want to allow
FMC access. By default, any networks are allowed.
Step 15 Click OK.

Step 16 Click Save.
Configure Bridge Group Interfaces

A bridge group is a group of interfaces that the Firepower Threat Defense device bridges instead of routes.
Bridge groups are supported in both transparent and routed firewall mode. For more information about bridge
groups, see About Bridge Groups, on page 749.
To configure bridge groups and associated interfaces, perform these steps.
Configure General Bridge Group Member Interface Parameters

This procedure describes how to set the name and security zone for each bridge group member interface. The
same bridge group can include different types of interfaces: physical interfaces, VLAN subinterfaces, Firepower
1010 VLAN interfaces, EtherChannels, and redundant interfaces. The Diagnostic interface is not supported.
In routed mode, EtherChannels are not supported. For the Firepower 4100/9300, data-sharing type interfaces
are not supported.
Before you begin

• Firepower 4100/9300
1. Configure a Physical Interface, on page 788
2. (Optional) Configure any special interfaces.
• Add an EtherChannel (Port Channel), on page 789
• Add a VLAN Subinterface for Container Instances, on page 791 in FXOS
• Add a Subinterface, on page 840 in FMC
• (Optional) All other models:

• Configure a Redundant Interface (ASA Platform Only), on page 836
• Configure an EtherChannel, on page 837
• Add a Subinterface, on page 840
• Firepower 1010: Configure a VLAN Interface, on page 825

848
Configure General Bridge Group Member Interface Parameters
Procedure
Step 5 (Optional) Set this interface to Management Only to limit traffic to management traffic; through-the-box
traffic is not allowed.

Regular firewall interfaces have the mode set to None. The other modes are for IPS-only interface types. After
you assign this interface to a bridge group, the mode will show as Switched.
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 861 for information about the MTU.
for SFP interfaces.
Step 11 (Optional) See Configure IPv6 Addressing, on page 851 to configure IPv6 addressing on the IPv6 tab.
Step 12 (Optional) See Configure the MAC Address, on page 862 to manually configure the MAC address on the
Advanced tab.
Step 13 Click OK.
Step 14 Click Save.

849
Configure the Bridge Virtual Interface (BVI)
Configure the Bridge Virtual Interface (BVI)

Each bridge group requires a BVI for which you configure an IP address. The FTD uses this IP address as
the source address for packets originating from the bridge group. The BVI IP address must be on the same
subnet as the connected network. For IPv4 traffic, the BVI IP address is required to pass any traffic. For IPv6
traffic, you must, at a minimum, configure the link-local addresses to pass traffic, but a global management
address is recommended for full functionality, including remote management and other management operations.
For routed mode, if you provide a name for the BVI, then the BVI participates in routing. Without a name,
the bridge group remains isolated as in transparent firewall mode.
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.
Before you begin

You cannot add the BVI to a security zone; therefore, you cannot apply Access Control policies to the BVI.
You must apply your policy to the bridge group member interfaces based on their zones.
Procedure
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.

850
Configure IPv6 Addressing
• 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 851 to configure IPv6 addressing.
Step 10 (Optional) See Add a Static ARP Entry, on page 863 and Add a Static MAC Address and Disable MAC
Learning for a Bridge Group, on page 864 (for transparent mode only) to configure the ARP and MAC settings.
Step 11 Click OK.
Step 12 Click Save.
Configure IPv6 Addressing

This section describes how to configure IPv6 addressing in routed and transparent mode.
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.

851
Modified EUI-64 Interface IDs
Modified EUI-64 Interface IDs

RFC 3513: Internet Protocol Version 6 (IPv6) Addressing Architecture requires that the interface identifier
portion of all unicast IPv6 addresses, except those that start with binary value 000, be 64 bits long and be
constructed in Modified EUI-64 format. The Firepower Threat Defense device can enforce this requirement
for hosts attached to the local link.
When this feature is enabled on an interface, the source addresses of IPv6 packets received on that interface
are verified against the source MAC addresses to ensure that the interface identifiers use the Modified EUI-64
format. If the IPv6 packets do not use the Modified EUI-64 format for the interface identifier, the packets are
dropped and the following system log message is generated:
325003: EUI-64 source address check failed.
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.
Configure a Global IPv6 Address

To configure a global IPv6 address for any routed mode interface and for the transparent or routed mode BVI,
perform the following steps.
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 862.
Before you begin

For IPv6 neighbor discovery for bridge groups, you must explicitly allow Neighbor Solicitation (ICMPv6
type 135) and Neighbor Advertisement (ICMPv6 type 136) packets through the FTD bridge group member
interfaces using a bidirectional access rule.
Procedure
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.
Step 4 On the Basic page, check Enable IPv6.

852
Configure a Global IPv6 Address
Step 5 Configure the global IPv6 address using one of the following methods.
• (Routed interface) Stateless autoconfiguration—Check the Autoconfiguration check box.
Enabling stateless autconfiguration on the interface configures IPv6 addresses based upon prefixes
received in Router Advertisement messages. A link-local address, based on the Modified EUI-64 interface
ID, is automatically generated for the interface when stateless autoconfiguration is enabled.
Although RFC 4862 specifies that hosts configured for stateless autoconfiguration do not send Router
Advertisement messages, the FTD device does send Router Advertisement messages in this case. Uncheck
the IPv6 > Settings > Enable RA check box to suppress messages.
• Manual configuration—To manually configure a global IPv6 address:
a. Click the Address page, and click Add Address.
The Add Address dialog box appears.
b. In the Address field, enter either a full global IPv6 address, including the interface ID, or enter the
IPv6 prefix, along with the IPv6 prefix length. (Routed Mode) If you only enter the prefix, then be
sure to check the Enforce EUI 64 check box to generate the interface ID using the Modified EUI-64
format. For example, 2001:0DB8::BA98:0:3210/48 (full address) or 2001:0DB8::/48 (prefix, with
EUI 64 checked).
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 854 to configure settings on the
Prefixes and Settings pages. For BVI interfaces, see the following parameters on the Settings page:

853
Configure IPv6 Neighbor Discovery
• 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.
Step 8 Click OK.

Step 9 Click Save.

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.
Before you begin

Supported in Routed mode only. For IPv6 neighbor settings supported in transparent mode, see Configure a
Global IPv6 Address, on page 852.
Procedure
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.

854
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:
325002: Duplicate address ipv6_address/MAC_address on interface
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.

855
Configure Advanced Interface Settings
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.
Step 10 Click OK.

Step 11 Click Save.
Configure Advanced Interface Settings

This section describes how to configure MAC addresses for regular firewall mode interfaces, how to set the
maximum transmission unit (MTU), and how to set other advanced parameters.
About Advanced Interface Configuration

This section describes advanced interface settings.
About MAC Addresses

You can manually assign MAC addresses to override the default. For container instances, the FXOS chassis
automatically generates unique MAC addresses for all interfaces.

856
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.

For native instances:
Default MAC address assignments depend on the type of interface.
• Physical interfaces—The physical interface uses the burned-in MAC address.
• VLAN interfaces (Firepower 1010)—Routed firewall mode: All VLAN interfaces share a MAC address.
Ensure that any connected switches can support this scenario. If the connected switches require unique
MAC addresses, you can manually assign MAC addresses. See Configure the MAC Address, on page
862.
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 862.
• 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.

857
About the MTU
For container instances:

• MAC addresses for all interfaces are taken from a MAC address pool. For subinterfaces, if you decide
to manually configure MAC addresses, make sure you use unique MAC addresses for all subinterfaces
on the same parent interface to ensure proper classification. See Automatic MAC Addresses for Container
Instance Interfaces, on page 779.
About the MTU

The MTU specifies the maximum frame payload size that the Firepower Threat Defense device can transmit
on a given Ethernet interface. The MTU value is the frame size without Ethernet headers, VLAN tagging, or
other overhead. For example, when you set the MTU to 1500, the expected frame size is 1518 bytes including
the headers, or 1522 when using VLAN. Do not set the MTU value higher to accommodate these headers.
Path MTU Discovery

The Firepower Threat Defense device supports Path MTU Discovery (as defined in RFC 1191), which lets
all devices in a network path between two hosts coordinate the MTU so they can standardize on the lowest
MTU in the path.
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.
MTU and Fragmentation

For IPv4, if an outgoing IP packet is larger than the specified MTU, it is fragmented into 2 or more frames.
Fragments are reassembled at the destination (and sometimes at intermediate hops), and fragmentation can
cause performance degradation. For IPv6, packets are typically not allowed to be fragmented at all. Therefore,
your IP packets should fit within the MTU size to avoid fragmentation.
For TCP packets, the endpoints typically use their MTU to determine the TCP maximum segment size (MTU
- 40, for example). If additional TCP headers are added along the way, for example for site-to-site VPN
tunnels, then the TCP MSS might need to be adjusted down by the tunneling entity. See About the TCP MSS,
on page 859.
For UDP or ICMP, the application should take the MTU into account to avoid fragmentation.
Note The Firepower Threat Defense device can receive frames larger than the configured MTU as long as there is
room in memory.
MTU and Jumbo Frames

A larger MTU lets you send larger packets. Larger packets might be more efficient for your network. See the
following guidelines:
• Matching MTUs on the traffic path—We recommend that you set the MTU on all FTD interfaces and
other device interfaces along the traffic path to be the same. Matching MTUs prevents intermediate
devices from fragmenting the packets.
• Accommodating jumbo frames—You can set the MTU up to 9198 bytes. The maximum is 9000 for the
Firepower Threat Defense Virtual and 9184 for the Firepower 4100/9300.

858
About the TCP MSS
About the TCP MSS

The TCP maximum segment size (MSS) is the size of the TCP payload before any TCP and IP headers are
added. UDP packets are not affected. The client and the server exchange TCP MSS values during the three-way
handshake when establishing the connection.
You can set the TCP MSS on the Firepower Threat Defense device for through traffic using the Sysopt_Basic
object in FlexConfig; see FlexConfig Policies for Firepower Threat Defense, on page 1277; by default, the
maximum TCP MSS is set to 1380 bytes. This setting is useful when the Firepower Threat Defense device
needs to add to the size of the packet for IPsec VPN encapsulation. However, for non-IPsec endpoints, you
should disable the maximum TCP MSS on the Firepower Threat Defense device.
If you set a maximum TCP MSS, if either endpoint of a connection requests a TCP MSS that is larger than
the value set on the Firepower Threat Defense device, then the Firepower Threat Defense device overwrites
the TCP MSS in the request packet with the Firepower Threat Defense device maximum. If the host or server
does not request a TCP MSS, then the Firepower Threat Defense device assumes the RFC 793-default value
of 536 bytes (IPv4) or 1220 bytes (IPv6), but does not modify the packet. For example, you leave the default
MTU as 1500 bytes. A host requests an MSS of 1500 minus the TCP and IP header length, which sets the
MSS to 1460. If the Firepower Threat Defense device maximum TCP MSS is 1380 (the default), then the
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).
Default TCP MSS

By default, the maximum TCP MSS on the Firepower Threat Defense device is 1380 bytes. This default
accommodates IPv4 IPsec VPN connections where the headers can equal up to 120 bytes; this value fits within
the default MTU of 1500 bytes.
Suggested Maximum TCP MSS Setting

The default TCP MSS assumes the Firepower Threat Defense device acts as an IPv4 IPsec VPN endpoint and
has an MTU of 1500. When the Firepower Threat Defense device acts as an IPv4 IPsec VPN endpoint, it
needs to accommodate up to 120 bytes for TCP and IP headers.
If you change the MTU value, use IPv6, or do not use the Firepower Threat Defense device as an IPsec VPN
endpoint, then you should change the TCP MSS setting using the Sysopt_Basic object in FlexConfig; see
FlexConfig Policies for Firepower Threat Defense, on page 1277. See the following guidelines:
• Normal traffic—Disable the TCP MSS limit and accept the value established between connection
endpoints. Because connection endpoints typically derive the TCP MSS from the MTU, non-IPsec packets
usually fit this TCP MSS.
• IPv4 IPsec endpoint traffic—Set the maximum TCP MSS to the MTU - 120. For example, if you use
jumbo frames and set the MTU to 9000, then you need to set the TCP MSS to 8880 to take advantage
of the new MTU.
• IPv6 IPsec endpoint traffic—Set the maximum TCP MSS to the MTU - 140.

859
ARP Inspection for Bridge Group Traffic
ARP Inspection for Bridge Group Traffic

By default, all ARP packets are allowed between bridge group members. You can control the flow of ARP
packets by enabling ARP inspection.
ARP inspection prevents malicious users from impersonating other hosts or routers (known as ARP spoofing).
ARP spoofing can enable a “man-in-the-middle” attack. For example, a host sends an ARP request to the
gateway router; the gateway router responds with the gateway router MAC address. The attacker, however,
sends another ARP response to the host with the attacker MAC address instead of the router MAC address.
The attacker can now intercept all the host traffic before forwarding it on to the router.
ARP inspection ensures that an attacker cannot send an ARP response with the attacker MAC address, so
long as the correct MAC address and the associated IP address are in the static ARP table.
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.
MAC Address Table

When you use bridge groups, the FTD learns and builds a MAC address table in a similar way as a normal
bridge or switch: when a device sends a packet through the bridge group, the FTD adds the MAC address to
its table. The table associates the MAC address with the source interface so that the FTD knows to send any
packets addressed to the device out the correct interface. Because traffic between bridge group members is
subject to the FTD security policy, if the destination MAC address of a packet is not in the table, the FTD
does not flood the original packet on all interfaces as a normal bridge does. Instead, it generates the following
packets for directly-connected devices or for remote devices:
• Packets for directly-connected devices—The FTD generates an ARP request for the destination IP address,
so that it can learn which interface receives the ARP response.
• Packets for remote devices—The FTD generates a ping to the destination IP address so that it can learn
which interface receives the ping reply.
The original packet is dropped.
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.

860
Guidelines for ARP Inspection and the MAC Address Table
• 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.
Note Firepower Threat Defense device generates a reset packet to reset a connection
that is denied by a stateful inspection engine. Here, the destination MAC address
of the packet is not determined based on the ARP table lookup but instead it is
taken directly from the packets (connections) that are being denied.
Guidelines for ARP Inspection and the MAC Address Table

• ARP inspection is only supported for bridge groups.
• MAC address table configuration is only supported for bridge groups.
Configure the MTU

Customize the MTU on the interface, for example, to allow jumbo frames.
Caution Changing the highest MTU value on the device for a data interface restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Inspection is interrupted on all data 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. This caution does not apply to the
Diagnostic interface or management-only interfaces. See Snort® Restart Traffic Behavior, on page 546 for
more information.
Before you begin

• Changing the MTU above 1500 bytes automatically enables jumbo frames; for ASA models, you must
reload the system before you can use jumbo frames.
• If you use an interface in an inline set, the MTU setting is not used. However, the jumbo frame setting
is relevant to inline sets; jumbo frames enable the inline interfaces to receive packets up to 9000 bytes.
To enable jumbo frames, you must set the MTU of any interface above 1500 bytes.
Procedure
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.

861
Configure the MAC Address
Step 4 Click OK.

Step 5 Click Save.
Step 6 For ASA models, if you set the MTU above 1500 bytes, reload the system to enable jumbo frames.
Configure the MAC Address

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.
Procedure
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.
Step 6 Click OK.

Step 7 Click Save.

862
Add a Static ARP Entry
Add a Static ARP Entry

packets by enabling ARP inspection (see Configure ARP Inspection, on page 1425). 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.
Before you begin

This screen is only available for named interfaces.
Procedure
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.

863
Add a Static MAC Address and Disable MAC Learning for a Bridge Group
Add a Static MAC Address and Disable MAC Learning for a Bridge Group
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 863), a static MAC address entry is automatically added to the
MAC address table.
Before you begin

Procedure
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.
Set Security Configuration Parameters

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.

864
Set Security Configuration Parameters
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.
Fragment per Packet

By default, the FTD device allows up to 24 fragments per IP packet, and up to 200 fragments awaiting
reassembly. You might need to let fragments on your network if you have an application that routinely
fragments packets, such as NFS over UDP. However, if you do not have an application that fragments traffic,
we recommend that you do not allow fragments through the FTD device. Fragmented packets are often used
as DoS attacks.
Fragment Reassembly
The FTD device performs the following fragment reassembly processes:
• IP fragments are collected until a fragment set is formed or until a timeout interval has elapsed.
• If a fragment set is formed, integrity checks are performed on the set. These checks include no overlapping,
no tail overflow, and no chain overflow.
• IP fragments that terminate at the FTD device are always fully reassembled.
• If Full Fragment Reassembly is disabled (the default), the fragment set is forwarded to the transport
layer for further processing.
• If Full Fragment Reassembly is enabled, the fragment set is first coalesced into a single IP packet. The
single IP packet is then forwarded to the transport layer for further processing.
Before you begin

Procedure
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.

865
History for Regular Firewall Interfaces for Firepower Threat Defense
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.
Step 7 Click OK.

Step 8 Click Save.
History for Regular Firewall Interfaces for Firepower Threat

Defense
31-bit Subnet Mask 7.0 For routed interfaces, you can configure an IP address on a 31-bit subnet for point-to-point
connections. The 31-bit subnet includes only 2 addresses; normally, the first and last address
in the subnet is reserved for the network and broadcast, so a 2-address subnet is not usable.
However, if you have a point-to-point connection and do not need network or broadcast
addresses, a 31-bit subnet is a useful way to preserve addresses in IPv4. For example, the failover
link between 2 FTDs only requires 2 addresses; any packet that is transmitted by one end of
the link is always received by the other, and broadcasting is unnecessary. You can also have a
directly-connected management station running SNMP or Syslog. This feature is not supported
for BVIs for bridge groups or with multicast routing.
Devices > Device Management > Interfaces

866
Synchronization 6.7 The Firepower 4100/9300 chassis can now synchronize the FTD operational link state with the
between the FTD physical link state for data interfaces. Currently, interfaces will be in an Up state as long as the
operational link state FXOS admin state is up and the physical link state is up. The FTD application interface admin
and the physical link state is not considered. Without synchronization from FTD, data interfaces can be in an Up
state for the Firepower state physically before the FTD application has completely come online, for example, or can
4100/9300 stay Up for a period of time after you initiate an FTD shutdown. For inline sets, this state
mismatch can result in dropped packets because external routers may start sending traffic to
the FTD before the FTD can handle it. This feature is disabled by default, and can be enabled
per logical device in FXOS.
Note This feature is not supported for clustering, container instances, or an FTD with a
Radware vDP decorator. It is also not supported for ASA.
New/Modified Firepower Chassis Manager screens: Logical Devices > Enable Link State
New/Modified FXOS commands: set link-state-sync enabled, show interface expand detail
Firepower 1010 6.5 The Firepower 1010 supports setting each Ethernet interface to be a switch port or a firewall
hardware switch support interface.
• 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
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
Interfaces > All Interfaces > Add New drop-down menu > Subinterface
New/Modified FXOS commands: create subinterface, set vlan, show interface,show
subinterface

867
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
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.
• 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

868
CHAPTER 31
Inline Sets and Passive Interfaces for Firepower
Threat Defense
You can configure IPS-only passive interfaces, passive ERSPAN interfaces, and inline sets. 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.
• About IPS Interfaces, on page 869
• Requirements and Prerequisites for Inline Sets, on page 871
• Guidelines for Inline Sets and Passive Interfaces, on page 872
• Configure a Passive Interface, on page 873
• Configure an Inline Set, on page 875
• History for Inline Sets and Passive Interfaces for Firepower Threat Defense, on page 878
About IPS Interfaces

This section describes IPS interfaces.
IPS Interface Types

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.
passive interfaces. IPS-only interfaces can be used in both firewall modes.
IPS-only interfaces can be deployed as the following types:

• Inline Set, with optional Tap mode—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 FTD 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.

869
About Hardware Bypass for Inline Sets
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 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.
About Hardware Bypass for Inline Sets

For certain interface modules on the Firepower 9300, 4100, and 2100 series (see Requirements and Prerequisites
for Inline Sets, on page 871), you can enable the Hardware Bypass feature. 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.
Hardware Bypass Triggers

Hardware Bypass can be triggered in the following scenarios:
• FTD application crash
• FTD application reboot
• Security Module reboot
• Firepower chassis crash
• Firepower chassis reboot or upgrade

870
Hardware Bypass Switchover
• 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.
Hardware Bypass Switchover

When switching from normal operation to hardware bypass or from hardware bypass back to normal operation,
traffic may be interrupted for several seconds. A number of factors can affect the length of the interruption;
for example, copper port auto-negotiation; behavior of the optical link partner such as how it handles link
faults and de-bounce timing; spanning tree protocol convergence; dynamic routing protocol convergence; and
so on. During this time, you may experience dropped connections.
You may also experience dropped connections due to application identification errors when analyzing
connections midstream after the return to normal operations.
Snort Fail Open vs. Hardware Bypass

For inline sets other than those in tap mode, you can use the Snort Fail Open option to either drop traffic or
allow traffic to pass without inspection when the Snort process is busy or down. Snort Fail Open is supported
on all inline sets except those in tap mode, not just on interfaces that support Hardware Bypass.
The Hardware Bypass functionality allows traffic to flow during a hardware failure, including a complete
power outage, and certain limited software failures. A software failure that triggers Snort Fail Open does not
trigger a Hardware Bypass.
Hardware Bypass Status

If the system has power, then the Bypass LED indicates the Hardware Bypass status. See the Firepower chassis
hardware installation guide for LED descriptions.
Requirements and Prerequisites for Inline Sets

Model Support
FTD
User Roles
• Admin
• Access Admin
• Network Admin

871
Guidelines for Inline Sets and Passive Interfaces
Hardware Bypass Support

The FTD supports Hardware Bypass for interface pairs on specific network modules on the following models:
• Firepower 9300
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 1277). 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)
Hardware Bypass can only use the following port pairs:

•1&2
•3&4
•5&6
•7&8
Guidelines for Inline Sets and Passive Interfaces

Firewall Mode
• ERSPAN interfaces are only allowed when the device is in routed firewall mode.
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.
inline sets. If there are two neighbors on either side of the FTD running BFD, then the FTD will drop

872
Configure a Passive Interface
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.
Hardware Bypass Guidelines

• Hardware Bypass ports are supported only for inline sets.
• Hardware Bypass ports cannot be part of an EtherChannel.
• Supported with intra-chassis clustering. Ports are placed in Hardware Bypass mode when the last unit
in the chassis fails. Inter-chassis clustering is not supported.
• If all units in the cluster fail, then Hardware Bypass is triggered on the final unit, and traffic continues
to pass. When units come back up, Hardware Bypass returns to standby mode. However, when you use
rules that match application traffic, those connections may be dropped and need to be reestablished.
Connections are dropped because state information is not retained on the cluster unit, and the unit cannot
identify the traffic as belonging to an allowed application. To avoid a traffic drop, use a port-based rule
instead of an application-based rule, if appropriate for your deployment.
• Hardware Bypass is not supported in high availability mode.
Unsupported Firewall Features on IPS Interfaces

• DHCP server
• DHCP relay
• DHCP client
• TCP Intercept
• Routing
• NAT
• VPN
• Application inspection
• QoS
• NetFlow
• VXLAN

This section describes how to:
• Enable the interface. By default, interfaces are disabled.

873
• 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 858.
• 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 788 for more information.
Procedure
Step 3 In the Mode drop-down list, choose Passive or Erspan.
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 9 For ERSPAN interfaces, set the following parameters:

• Flow Id—Configure the ID used by the source and destination sessions to identify the ERSPAN traffic,
between 1 and 1023. This ID must also be entered in the ERSPAN destination session configuration.
• Source IP—Configure the IP address used as the source of the ERSPAN traffic.
Step 10 For ERSPAN interfaces, set the IPv4 address and mask on IPv4.
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 12 Click OK.

Step 13 Click Save.

874
Configure an Inline Set

This section enables and names two physical interfaces that you can add to an inline set. You can also optionally
enable Hardware Bypass for supported interface pairs.
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 788 for more information.
Before you begin

• We recommend that you set STP PortFast for STP-enabled switches that connect to Firepower Threat
Defense inline pair interfaces. This setting is especially useful for Hardware Bypass configurations and
can reduce bypass times.
Procedure
After you add this interface to an inline set, this field will show Inline for the mode.

Do not set the security zone yet; you must set it after you create the inline set later in this procedure.

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 8 Click OK.

Do not set any other settings for this interface.

875
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 12 Click Add Inline Set.
The Add Inline Set dialog box appears with General selected.
Step 13 In the Name field, enter a name for the set.
Step 14 (Optional) Change the MTU to enable jumbo frames.
For inline sets, the MTU setting is not used. However, the jumbo frame setting is relevant to inline sets; jumbo
frames enable the inline interfaces to receive packets up to 9000 bytes. To enable jumbo frames, you must
set the MTU of any interface on the device above 1500 bytes.
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.
Step 17 (Optional) Click Advanced to set the following optional parameters:

• Tap Mode—Set to inline tap mode.
Note that you cannot enable this option and strict TCP enforcement on the same inline set.
• Propagate Link State—Configure link state propagation.

Link state propagation 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 device senses the change and updates the link state of the other interface to match it. Note that devices
require 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.
• Strict TCP Enforcement—To maximize TCP security, you can enable strict enforcement, which blocks
connections where the three-way handshake was not completed.
Strict enforcement also blocks:
• Non-SYN TCP packets for connections where the three-way handshake was not completed
• Non-SYN/RST packets from the initiator on a TCP connection before the responder sends the
SYN-ACK

876
• Non-SYN-ACK/RST packets from the responder on a TCP connection after the SYN but before
the session is established
• SYN packets on an established TCP connection from either the initiator or the responder
• 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 548.
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.
Step 18 Click Interfaces.

Step 19 Click Edit ( ) for one of the member interfaces.
You can only set the zone after you add the interface to the inline set; adding it to an inline set configures the
mode to Inline and lets you choose inline-type security zones.
Step 21 Click OK.

Step 22 Set the security zone for the second interface.
Step 23 Click Save.

877
History for Inline Sets and Passive Interfaces for Firepower Threat Defense
History for Inline Sets and Passive Interfaces for Firepower

Threat Defense
Synchronization between the FTD 6.7 The Firepower 4100/9300 chassis can now
operational link state and the physical link synchronize the FTD operational link state
state for the Firepower 4100/9300 with the physical link state for data
interfaces. Currently, interfaces will be in
an Up state as long as the FXOS admin
state is up and the physical link state is up.
The FTD application interface admin state
is not considered. Without synchronization
from FTD, data interfaces can be in an Up
state physically before the FTD application
has completely come online, for example,
or can stay Up for a period of time after you
initiate an FTD shutdown. For inline sets,
this state mismatch can result in dropped
packets because external routers may start
sending traffic to the FTD before the FTD
can handle it. This feature is disabled by
default, and can be enabled per logical
device in FXOS.
Note This feature is not supported for
clustering, container instances,
or an FTD with a Radware vDP
decorator. It is also not
supported for ASA.
New/Modified Firepower Chassis Manager

screens: Logical Devices > Enable Link
State
New/Modified FXOS commands: set
link-state-sync enabled, show interface
expand detail
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.
Devices > Device Management >
Interfaces > Edit Physical Interface
Supported platforms: Firepower 2100

878
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.
Devices > Device Management >
Interfaces > Edit Physical Interface
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)

879

880
CHAPTER 32
DHCP and DDNS Services for Threat Defense
The following topics explain DHCP and DDNS services and how to configure them on Threat Defense devices.
• About DHCP and DDNS Services, on page 881
• Requirements and Prerequisites for DHCP and DDNS, on page 882
• Guidelines for DHCP and DDNS Services, on page 882
• Configure the DHCP Server, on page 884
• Configure the DHCP Relay Agent, on page 885
• Configure Dynamic DNS, on page 886
About DHCP and DDNS Services

The following topics describe the DHCP server, DHCP relay agent, and DDNS update.
About the DHCPv4 Server

DHCP provides network configuration parameters, such as IP addresses, to DHCP clients. The Firepower
Threat Defense device can provide a DHCP server to DHCP clients attached to Firepower Threat Defense
device interfaces. The DHCP server provides network configuration parameters directly to DHCP clients.
An IPv4 DHCP client uses a broadcast rather than a multicast address to reach the server. The DHCP client
listens for messages on UDP port 68; the DHCP server listens for messages on UDP port 67.
The DHCP server for IPv6 is not supported; you can, however, enable DHCP relay for IPv6 traffic.
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.

881
About the DHCP Relay Agent
• DHCP option 3 sets the default route.
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.
About the DHCP Relay Agent

You can configure a DHCP relay agent to forward DHCP requests received on an interface to one or more
DHCP servers. DHCP clients use UDP broadcasts to send their initial DHCPDISCOVER messages because
they do not have information about the network to which they are attached. If the client is on a network
segment that does not include a server, UDP broadcasts normally are not forwarded by the Firepower Threat
Defense device because it does not forward broadcast traffic. The DHCP relay agent lets you configure the
interface of the Firepower Threat Defense device that is receiving the broadcasts to forward DHCP requests
to a DHCP server on another interface.
Requirements and Prerequisites for DHCP and DDNS

Model Support
FTD
User Roles
• Admin
• Access Admin
• Network Admin
Guidelines for DHCP and DDNS Services

This section includes guidelines and limitations that you should check before configuring DHCP and DDNS
services.

882
Guidelines for DHCP and DDNS Services
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.

883
Configure the DHCP 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).
Configure the DHCP Server

See the following steps to configure a DHCP server.
Procedure
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 4 To override auto-configured settings, do the following:

• Enter the domain name of the interface. For example, your device may be in the Your_Company domain.
• From the drop-down list, choose the DNS servers (primary and secondary) configured for the interface.
To add a new DNS server, see Creating Network Objects, on page 613.
• From the drop-down list, choose the WINS servers (primary and secondary) configured for the interface.
To add a new WINS server, see Creating Network Objects, on page 613.
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.

884
Configure the DHCP Relay Agent
• 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.
• Enable DHCP Server—Enables the DHCP server on the selected interface.
Step 6 Click OK to save the DHCP server configuration.

Step 7 (Optional) Select Advanced, click Add, and specify the type of information you want the option to return to
the DHCP client:
• Option Code—The Firepower Threat Defense device supports the DHCP options listed in RFC 2132,
RFC 2562, and RFC 5510 to send information. All DHCP options (1 through 255) are supported except
for 1, 12, 50–54, 58–59, 61, 67, and 82. See About the DHCPv4 Server, on page 881for more information
on DHCP option codes.
Note The Firepower Threat Defense device does not verify that the option type and value that you
provide match the expected type and value for the option code, as defined in RFC 2132. For
more information about option codes and their associated types and expected values, see RFC
2132.
• 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 613.
• 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 8 Click OK to save the option code configuration.

Step 9 Click Save on the DHCP page to save your changes.
Configure the DHCP Relay Agent

You can configure a DHCP relay agent to forward DHCP requests received on an interface to one or more
DHCP servers. DHCP clients use UDP broadcasts to send their initial DHCPDISCOVER messages because
they do not have information about the network to which they are attached. If the client is on a network
segment that does not include a server, UDP broadcasts normally are not forwarded by the Firepower Threat
Defense device because it does not forward broadcast traffic.
You can remedy this situation by configuring the interface of the Firepower Threat Defense device that is
receiving the broadcasts to forward DHCP requests to a DHCP server on another interface.
Note DHCP Relay is not supported in transparent firewall mode.

885
Configure Dynamic DNS
Procedure
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.
Step 5 Click OK to save the DHCP relay agent changes.

Step 6 On DHCP Servers, click Add, and configure the following options:
Add the IPv4 and IPv6 server addresses as separate entries, even if they belong to the same server.
• Server—The IP address of the DHCP server. Chose an IP address from the drop-down list. To add a
new one, see Creating Network Objects, on page 613
• Interface—The interface to which the specified DHCP server is attached. The DHCP Relay agent and
the DHCP server cannot be configured on the same interface.
Step 7 Click OK to save the DHCP server changes.

Step 8 Click Save on the DHCP page to save your changes.

When an interface uses DHCP IP addressing, the assigned IP address can change when the DHCP lease is
renewed. When the interface needs to be reachable using a fully qualified domain name (FQDN), the IP
address change can cause the DNS server resource records (RRs) to become stale. Dynamic DNS (DDNS)
provides a mechanism to update DNS RRs whenever the IP address or hostname changes. You can also use
DDNS for static or PPPoE IP addressing.
DDNS updates the following RRs on the DNS server: the A RR includes the name-to-IP address mapping,
while the PTR RR maps addresses to names.
The FTD supports the following DDNS update methods:
• Standard DDNS—The standard DDNS update method is defined by RFC 2136.

886
With this method, the FTD and the DHCP server use DNS requests to update the DNS RRs. The FTD
or DHCP server sends a DNS request to its local DNS server for information about the hostname and,
based on the response, determines the main DNS server that owns the RRs. The FTD or DHCP server
then sends an update request directly to the main DNS server. See the following typical scenarios.
• The FTD updates the A RR, and the DHCP server updates the PTR RR.
Typically, the FTD "owns" the A RR, while the DHCP server "owns" the PTR RR, so both entities
need to request updates separately. When the IP address or hostname changes, the FTD sends a
DHCP request (including the FQDN option) to the DHCP server to inform it that it needs to request
a PTR RR update.
• The DHCP server updates both the A and PTR RR.
Use this scenario if the FTD does not have the authority to update the A RR. When the IP address
or hostname changes, the FTD sends a DHCP request (including the FQDN option) to the DHCP
server to inform it that it needs to request an A and PTR RR update.
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.
• Web—The Web update method uses the DynDNS Remote API specification
(https://help.dyn.com/remote-access-api/).
With this method when the IP address or hostname changes, the FTD sends an HTTP request directly to
a DNS provider with which you have an account.
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.
Before you begin

• Configure a DNS server group on Objects > Object Management > DNS Server Group, and then
enable the group for the interface on Devices > Platform Settings > DNS. See Configure DNS, on page
1427.
• Configure the device hostname. You can configure the hostname when you perform the FTD initial setup,
or by using the configure network hostname command. If you do not specify the hostname per interface,
then the device hostname is used.
Procedure
Step 2 Choose DHCP > DDNS.
Step 3 Standard DDNS method: 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.

887
c) Click DDNS.
d) (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.
e) 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 5, on page 888.
• 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.
f) Click OK.
g) Assign this method to the interface in Step Step 5, on page 888.
Step 4 Web method: Configure a DDNS update method to enable HTTP update requests from the FTD.
a) On DDNS Update Methods, click Add.
b) Set the Method Name.
c) Click Web.
d) Set the Web Update Type to update IPv4, IPv6, or both types of addresses.
e) Set the Web URL. Specify the update URL. Check with your DNS provider for the URL required.
Use the following syntax:
https://username:password@provider-domain/path?hostname=<h>&myip=<a>
Example:
https://jcrichton:pa$$w0rd17@domains.example.com/nic/update?hostname=<h>&myip=<a>
f) (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.
g) Click OK.
h) Assign this method to the interface in Step Step 5, on page 888.
i) The web type method for DDNS also requires you to identify the DDNS server root CA to validate the
DDNS server certificate for the HTTPS connection. See step Step 9, on page 890.
Step 5 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.
(Standard DDNS method) 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.

888
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) Standard DDNS method: 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 6, on page 889 for more information.
Step 6 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 884). 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

889
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 7 (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.
Step 8 Click Save on the Device page to save your changes.

Step 9 The Web method for DDNS also requires you to identify the DDNS server root CA to validate the DDNS
server certificate for the HTTPS connection.
The following example shows how to add a DDNS server's CA as a trustpoint.
a) Obtain the DDNS server CA certificate. This procedure shows a manual import using PEM format, but
you can also use PKCS12.
b) In FMC, choose Devices > Certficates, and click Add.
c) Select a Device, and click Add ( ).
The Add Cert Enrollment dialog box appears.

d) Enter the following fields, and click Save:

890
• Enter a Name.
• Choose Enrollment Type > Manual.
• Click CA Only.
• Paste in the CA text from step 9.a, on page 890.
e) Click Save.

891

892
CHAPTER 33
SNMP for the Firepower 1000/2100
This chapter describes how to configure SNMP for the Firepower 1000/2100.
• About SNMP for the Firepower 1000/2100 Series, on page 893
• Enabling SNMP and Configuring SNMP Properties for Firepower 1000/2100, on page 893
• Creating an SNMP Trap for Firepower 1000/2100, on page 894
• Creating an SNMP User for Firepower 1000/2100, on page 896
About SNMP for the Firepower 1000/2100 Series

The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message
format for communication between SNMP managers and agents. SNMP provides a standardized framework
and a common language used for the monitoring and management of devices in a network.
The SNMP framework consists of three parts:
• An SNMP manager—The system used to control and monitor the activities of network devices using
SNMP.
• An SNMP agent—The software component within the Firepower 1000/2100 chassis that maintains the
data for the Firepower chassis and reports the data, as needed, to the SNMP manager. The Firepower
chassis includes the agent and a collection of MIBs. To enable the SNMP agent and create the relationship
between the manager and agent, enable and configure SNMP in the Firepower Management Center.
• A managed information base (MIB)—The collection of managed objects on the SNMP agent.
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.

893
Creating an SNMP Trap for Firepower 1000/2100
Procedure

Step 2 Click SNMP.
Step 3 Complete the following fields:
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.
Step 4 Click Save.
What to do next
Create SNMP traps and users.

894
Procedure

Step 2 Click SNMP.
Step 3 In the SNMP Traps Configuration area, click Add.
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
Step 5 Click OK to close the SNMP Trap Configuration dialog box.

895
Creating an SNMP User for Firepower 1000/2100
Step 6 Click Save.
Creating an SNMP User for Firepower 1000/2100
Procedure

Step 2 Click SNMP.
Step 3 In the SNMP Users Configuration area, click Add.
Step 4 In the SNMP User Configuration dialog box, complete the following fields:
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).
Auth Algorithm Type field The authorization type: SHA.
Use AES-128 checkbox If checked, this user uses AES-128 encryption.

Note SNMPv3 does not support DES. If you leave the AES-128
box unchecked, no privacy encryption will be done and any
configured privacy password will have no effect.
Authentication Password field The password for the user.
Confirm field The password again for confirmation purposes.
Encryption Password field The privacy password for the user.
Confirm field The privacy password again for confirmation purposes.
Step 5 Click OK to close the SNMP User Configuration dialog box.

Step 6 Click Save.

896
CHAPTER 34
Quality of Service (QoS) for Firepower Threat
Defense
The following topics describe how to use the Quality of Service (QoS) feature to police network traffic using
Firepower Threat Defense devices:
• Introduction to QoS, on page 897
• About QoS Policies, on page 897
• Requirements and Prerequisites for QoS, on page 898
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.
Logging Rate-Limited Connections

There are no logging configurations for QoS. A connection can be rate limited without being logged, and you
cannot log a connection simply because it was rate limited. To view QoS information in connection events,
you must independently log the ends of the appropriate connections to the Firepower Management Center
database; see Other Connections You Can Log, on page 2803.
Connection events for rate-limited connections contain information on how much traffic was dropped, and
which QoS configurations limited the traffic. You can view this information in event views (workflows),
dashboards, and reports.
About QoS Policies

QoS policies deployed to managed devices govern rate limiting. Each QoS policy can target multiple devices;
each device can have one deployed QoS policy at a time.
In a QoS policy, a maximum of 32 QoS rules handle network traffic. The system matches traffic to QoS rules
in the order you specify. The system rate limits traffic according to the first rule where all rule conditions
match the traffic. Traffic that does not match any of the rules is not rate limited.

897
Requirements and Prerequisites for QoS
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 1632.
QoS Policies and Multitenancy

in a lower domain, switch to that domain.
Administrators in ancestor domains can deploy the same QoS policy to devices in different descendant domains.
Administrators in those descendant domains can use this read-only ancestor-deployed QoS policy, or replace
it with a local policy.
Requirements and Prerequisites for QoS

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
Rate Limiting with QoS Policies

To perform policy-based rate limiting, configure and deploy QoS policies to managed devices. Each QoS
policy can target mutiple devices; each device can have one deployed QoS policy at a time.
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.

898
Creating a QoS Policy
Procedure
Step 1 Choose Devices > QoS.

Step 2 Click New Policy to create a new QoS policy and, optionally, assign target devices; see Creating a QoS Policy,
on page 899.
You can also Copy ( ) or Edit ( ) an exisiting policy.
Step 3 Configure QoS rules; see Configuring QoS Rules, on page 900 and Rule Management: Common Characteristics,
on page 561.
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 1610.
Step 4 Click Policy Assignments to identify the managed devices targeted by the policy; see Setting Target Devices
for a QoS Policy, on page 900.
If you identified target devices during policy creation, verify your choices.
Step 5 Save the QoS policy.

Step 6 Because this feature must allow some packets to pass, you must configure your system to examine those
packets. See Best Practices for Handling Packets That Pass Before Traffic Identification, on page 2162 and
Specify a Policy to Handle Packets That Pass Before Traffic Identification, on page 2162.
Creating a QoS Policy

A new QoS policy with no rules performs no rate limiting.
Procedure
Step 1 Choose Devices > QoS.

Step 3 Enter a Name and, optionally, a Description.
Step 4 (Optional) Choose the Available Devices where you want to deploy the policy, then click Add to Policy, or
drag and drop to the Selected Devices. To narrow the devices that appear, type a search string in the Search
field.

899
Setting Target Devices for a QoS Policy
You must assign devices before you deploy the policy.
Step 5 Click Save.
What to do next
• Configure and deploy the QoS policy; see Rate Limiting with QoS Policies, on page 898.
Setting Target Devices for a QoS Policy

Each QoS policy can target mutiple devices; each device can have one deployed QoS policy at a time.
Procedure
Step 1 In the QoS policy editor, click Policy Assignments.

Step 2 Build your target list:
• Add—Choose one or more Available Devices, then click Add to Policy or drag and drop into the list
of Selected Devices.
• Delete—Click Delete ( ) next to a single device, or choose multiple devices, right-click, then choose
Delete Selected.
• Search—Enter a search string in the search field. Click Clear ( ) to clear the search.
Step 3 Click OK to save policy assignments.

Step 4 Click Save to save the policy.
What to do next
Configuring QoS Rules

When you create or edit a rule, use the upper portion of the rule editor to configure general rule properties.
Use the lower portion of the rule editor to configure rule conditions and comments.
Procedure
Step 1 On Rules of the QoS policy editor:

• Add Rule—Click Add Rule.
• Edit Rule—Click Edit ( ).

Step 3 Configure rule components:

900
QoS Rule Components
• Enabled—Specify whether the rule is Enabled.

• Apply QoS On—Choose the interfaces you want to rate limit, either Interfaces in Destination Interface
Objects or Interfaces in Source Interface Objects. Your choice must correspond with a populated
interface constraint (not any).
• Traffic Limit Per Interface—Enter a Download Limit and an Upload Limit in Mbits/sec. The default
value of Unlimited prevent matching traffic from being rate limited in that direction.
• Conditions—Click the corresponding condition you want to add. You must configure a source or
destination interface condition, corresponding to your choice for Apply QoS On.
• 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 901.
Step 4 Save the rule.

Step 5 In the policy editor, set the rule position. Click and drag or use the right-click menu to cut and paste.
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. Proper rule order reduces the
resources required to process network traffic and prevents rule preemption.
What to do next
Related Topics
Best Practices for Access Control Rules, on page 1610
QoS Rule Components
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.
Interfaces (Apply QoS On)

You cannot save a QoS rule that rate limits all traffic. For each QoS rule, you must apply QoS on either:
• Interfaces in Source Interface Objects—Rate limits traffic through the rule's source interfaces. If you
choose this option, you must add at least one source interface constraint (cannot be any).
• Interfaces in Destination Interface Objects—Rate limits traffic through the rule's destination interfaces.
If you choose this option, you must add at least one destination interface constraint (cannot be any).
Traffic Limit Per Interface

A QoS rule enforces rate limiting independently on each of the interfaces you specify with the Apply QoS
On option. You cannot specify an aggregate rate limit for a set of interfaces.

901
History for QOS
You can rate limit traffic by Mbits per second. The default value of Unlimited prevents matching traffic from
being rate limited.
You can rate limit download and upload traffic independently. The system determines download and upload
directions based on the connection initiator.
If you specify a limit greater than the maximum throughput of an interface, the system does not rate limit
matching traffic. Maximum throughput may be affected by an interface’s hardware configuration, which you
specify in each device’s properties (Devices > Device Management).
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 566 (routed only; required)
• Network Conditions, on page 568
• Port and ICMP Code Conditions, on page 573
• Application Conditions (Application Control), on page 575
• URL Filtering, on page 1655
• User, Realm, and ISE Attribute Conditions (User Control), on page 585
• Custom SGT Conditions, on page 591
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.
History for QOS

Ability to specify handling of URLs 6.7 For details, see History for URL Filtering, on page 1675.
having unknown reputation
Rate limit increased 6.2.1 Raised the maximum rate limit from 1,000 Mbps to 100,000 Mbps.
Modified screen: QoS rule editor

902
History for QOS
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
QoS (rate limiting) 6.1 Feature introduced.

QoS rate limits (polices) network traffic that is allowed or trusted by access
control.
New screens: Devices > QoS

903
History for QOS

904
PA R T VIII
Firepower Threat Defense High Availability and
Scalability
• High Availability for Firepower Threat Defense, on page 907
• Clustering for the Firepower Threat Defense, on page 935
CHAPTER 35
High Availability for Firepower Threat Defense
The following topics describe how to configure Active/Standby failover to accomplish high availability of
the Cisco Firepower Threat Defense.
• About Firepower Threat Defense High Availability, on page 907
• Requirements and Prerequisites for High Availability, on page 921
• Guidelines for High Availability, on page 921
• Add a Firepower Threat Defense High Availability Pair, on page 923
• Configure Optional High Availability Parameters, on page 925
• Manage High Availability, on page 927
• Monitoring High Availability, on page 932
About Firepower Threat Defense High Availability

Configuring high availability, also called failover, requires two identical Firepower Threat Defense devices
connected to each other through a dedicated failover link and, optionally, a state link. Firepower Threat Defense
supports Active/Standby failover, where one unit is the active unit and passes traffic. The standby unit does
not actively pass traffic, but synchronizes configuration and other state information from the active unit. When
a failover occurs, the active unit fails over to the standby unit, which then becomes active.
The health of the active unit (hardware, interfaces, software, and environmental status) is monitored to
determine if specific failover conditions are met. If those conditions are met, failover occurs.
Note High availability is not supported on Firepower Threat Defense Virtual running in the public cloud.
High Availability System Requirements

This section describes the hardware, software, and license requirements for Firepower Threat Defense devices
in a High Availability configuration.
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.

907
Firepower Threat Defense High Availability and Scalability
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.
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 1467.
• 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.
License Requirements for FTD Devices in a High Availability Pair

Firepower Threat Defense devices in a high availability configuration must have the same licenses.
High availability configurations require two Smart License entitlements; one for each device in the pair.
Before high availability is established, it does not matter which licenses are assigned to the secondary/standby
device. During high availability configuration, the Firepower Management Center releases any unnecessary
licenses assigned to the standby device and replaces them with identical licenses assigned to the primary/active
device. For example, if the active device has a Base license and a Threat license, and the standby device has
only a Base license, the Firepower Management Center communicates with the Cisco Smart Software Manager
to obtain an available Threat license from your account for the standby device. If your Smart Licenses account
does not include enough purchased entitlements, your account becomes Out-of-Compliance until you purchase
the correct number of licenses.
In a virtual Firepower Management Center high availability configuration, each FTD to be registered requires
an additional Firepower MCv Device license.

908
Failover and Stateful Failover Links
Failover and Stateful Failover Links

The failover link and the optional stateful failover link are dedicated connections between the two units. Cisco
recommends to use the same interface between two devices in a failover link or a stateful failover link. For
example, in a failover link, if you have used eth0 in device 1, use the same interface (eth0) in device 2 as well.
Failover Link
The two units in a failover pair constantly communicate over a failover link to determine the operating status
of each unit.
Failover Link Data

The following information is communicated over the failover link:
• The unit state (active or standby)
• Hello messages (keep-alives)
• Network link status
• MAC address exchange
• Configuration replication and synchronization
Interface for the Failover Link

You can use an unused data interface (physical, redundant, or EtherChannel) as the failover link; however,
you cannot specify an interface that is currently configured with a name. You also cannot use a subinterface
with the exception of a subinterface defined on the Firepower 4100/9300 chassis for container instances. The
failover link interface is not configured as a normal networking interface; it exists for failover communication
only. This interface can only be used for the failover link (and also for the state link).
The FTD does not support sharing interfaces between user data and the failover link. You also cannot use
separate subinterfaces on the same parent for the failover link and for data (Firepower 4100/9300 chassis
subinterfaces only). If you use a Firepower 4100/9300 subinterface for the failover link, then all subinterfaces
on that parent, and the parent itself, are restricted for use as failover links.
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.
See the following guidelines for the failover link:

• Firepower 4100/9300—We recommend that you use a 10 GB data interface for the combined failover
and state link.
• All other models—1 GB interface is large enough for a combined failover and state link.
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.

909
Connecting the Failover Link
• If a failover unit stops receiving keepalive messages from its peer on one of the member interfaces, it
switches to the other member interface.
The alternation frequency is equal to the unit hold time.
Note If you have a large configuration and a low unit hold time, alternating between the member interfaces can
prevent the secondary unit from joining/re-joining. In this case, disable one of the member interfaces until
after the secondary unit joins.
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.
Connecting the Failover Link

Connect the failover link in one of the following two ways:
• Using a switch, with no other device on the same network segment (broadcast domain or VLAN) as the
failover interfaces of the Firepower Threat Defense device.
• Using an Ethernet cable to connect the units directly, without the need for an external switch.
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.
Stateful Failover Link

To use Stateful Failover, you must configure a Stateful Failover link (also known as the state link) to pass
connection state information.
Shared with the Failover Link

Sharing a failover link is the best way to conserve interfaces. However, you must consider a dedicated interface
for the state link and failover link, if you have a large configuration and a high traffic network.
Dedicated Interface for the Stateful Failover Link

You can use a dedicated data interface (physical, redundant, or EtherChannel) for the state link. See Interface
for the Failover Link, on page 909 for requirements for a dedicated state link, and Connecting the Failover
Link, on page 910 for information about connecting the state link as well.
For optimum performance when using long distance failover, the latency for the state link should be less than
10 milliseconds and no more than 250 milliseconds. If latency is more than 10 milliseconds, some performance
degradation occurs due to retransmission of failover messages.
Avoiding Interrupted Failover and Data Links

We recommend that failover links and data interfaces travel through different paths to decrease the chance
that all interfaces fail at the same time. If the failover link is down, the Firepower Threat Defense device can
use the data interfaces to determine if a failover is required. Subsequently, the failover operation is suspended
until the health of the failover link is restored.

910
Avoiding Interrupted Failover and Data Links
See the following connection scenarios to design a resilient failover network.
Scenario 1—Not Recommended

If a single switch or a set of switches are used to connect both failover and data interfaces between two
Firepower Threat Defense devices, then when a switch or inter-switch-link is down, both Firepower Threat
Defense devices become active. Therefore, the two connection methods shown in the following figures are
not recommended.
Figure 23: Connecting with a Single Switch—Not Recommended
Figure 24: Connecting with a Double-Switch—Not Recommended
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
Figure 26: Connecting with a Cable
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.

911
MAC Addresses and IP Addresses in High Availability
Figure 27: Connecting with a Secure Switch
The most reliable failover configurations use a redundant interface on the failover link, as shown in the
following figures.
Figure 28: Connecting with Redundant Interfaces
Figure 29: Connecting with Inter-switch Links
MAC Addresses and IP Addresses in High Availability

When you configure your interfaces, you can specify an active IP address and a standby IP address on the
same network. Generally, when a failover occurs, the new active unit takes over the active IP addresses and

912
Stateful Failover
MAC addresses. Because network devices see no change in the MAC to IP address pairing, no ARP entries
change or time out anywhere on the network.
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.
Active/Standby IP Addresses and MAC Addresses

For Active/Standby High Availability, see the following for IP address and MAC address usage during a
failover event:
1. The active unit always uses the primary unit's IP addresses and MAC addresses.
2. When the active unit fails over, the standby unit assumes the IP addresses and MAC addresses of the
failed unit and begins passing traffic.
3. When the failed unit comes back online, it is now in a standby state and takes over the standby IP addresses
and MAC addresses.
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.
Virtual MAC Addresses

The Firepower Threat Defense device has multiple methods to configure virtual MAC addresses. We
recommend using only one method. If you set the MAC address using multiple methods, the MAC address
used depends on many variables, and might not be predictable.
For multi-instance capability, the FXOS chassis autogenerates only primary MAC addresses for all interfaces.
You can overwrite the generated MAC address with a virtual MAC address with both the primary and secondary
MAC addresses, but predefining the secondary MAC address is not essential; setting the secondary MAC
address does ensure that to-the-box management traffic is not interrupted in the case of new secondary unit
hardware.
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.

913
Supported Features
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.
• The ARP table
• The Layer 2 bridge table (for bridge groups)
• The ISAKMP and IPsec SA table
• GTP PDP connection database
• SIP signaling sessions and pin holes.
• Static and dynamic routing tables—Stateful Failover participates in dynamic routing protocols, like OSPF
and EIGRP, so routes that are learned through dynamic routing protocols on the active unit are maintained
in a Routing Information Base (RIB) table on the standby unit. Upon a failover event, packets travel
normally with minimal disruption to traffic because the active secondary unit initially has rules that
mirror the primary unit. Immediately after failover, the re-convergence timer starts on the newly active
unit. Then the epoch number for the RIB table increments. During re-convergence, OSPF and EIGRP
routes become updated with a new epoch number. Once the timer is expired, stale route entries (determined
by the epoch number) are removed from the table. The RIB then contains the newest routing protocol
forwarding information on the newly active unit.
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.

914
Unsupported Features
• 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 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 in plaintext tunnels other than GREv0 and IPv4-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 (in other words, those that match a TLS/SSL Do Not
Decrypt rule action) are not affected and are replicated correctly.
• TCP state bypass connections
• Multicast routing.

915
Bridge Group Requirements for High Availability
Bridge Group Requirements for High Availability

There are special considerations for high availability when using bridge groups.
When the active unit fails over to the standby unit, the 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 on the
bridge group member interfaces while the port is in a blocking state, you can configure one of the following
workarounds:
• Switch port is in Access mode—Enable the STP PortFast feature on the switch:
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.
Failover Health Monitoring

The Firepower Threat Defense device monitors each unit for overall health and for interface health. This
section includes information about how the Firepower Threat Defense device performs tests to determine the
state of each unit.
Unit Health Monitoring

The Firepower Threat Defense device determines the health of the other unit by monitoring the failover link
with hello messages. When a unit does not receive three consecutive hello messages on the failover link, the
unit sends LANTEST messages on each data interface, including the failover link, to validate whether or not
the peer is responsive. The action that the Firepower Threat Defense device takes depends on the response
from the other unit. See the following possible actions:
• If the Firepower Threat Defense device receives a response on the failover link, then it does not fail over.
• If the Firepower Threat Defense device does not receive a response on the failover link, but it does receive
a response on a data interface, then the unit does not failover. The failover link is marked as failed. You
should restore the failover link as soon as possible because the unit cannot fail over to the standby while
the failover link is down.
• If the Firepower Threat Defense device does not receive a response on any interface, then the standby
unit switches to active mode and classifies the other unit as failed.

916
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.

917
Failover Triggers and Detection Timing
• 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.
Failover Triggers and Detection Timing

The following events trigger failover in a Firepower high availability pair:
• More than 50% of the Snort instances on the active unit are down.
• Disk space on the active unit is more than 90% full.
• The no failover active command is run on the active unit or the failover active command is run on the
standby unit.
• The active unit has more failed interfaces than the standby unit.
• Interface failure on the active device exceeds the threshold configured.
By default, failure of a single interface causes failover. You can change the default value by configuring
a threshold for the number of interfaces or a percentage of monitored interfaces that must fail for the
failover to occur. If the threshold breaches on the active device, failover occurs. If the threshold breaches
on the standby device, the unit moves to Fail state.
To change the default failover criteria, enter the following command in global configuration mode:

918
About Active/Standby Failover
Table 98:
Command Purpose
failover interface-policy num [%] Changes the default failover criteria.

hostname (config)# failover When specifying a specific number of interfaces,
interface-policy 20% the num argument can be from 1 to 250.
When specifying a percentage of interfaces, the
num argument can be from 1 to 100.
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.
Table 99: Firepower Threat Defense Failover Times
Failover Triggering Event Minimum Default Maximum
Active unit loses power, 800 milliseconds 15 seconds 45 seconds

hardware goes down, or the
software reloads or crashes.
When any of these occur, the
monitored interfaces or failover
link do not receives any hello
message.
Active unit interface physical 500 milliseconds 5 seconds 15 seconds

link down.
Active unit interface up, but 5 seconds 25 seconds 75 seconds

connection problem causes
interface testing.
About Active/Standby Failover

Active/Standby failover lets you use a standby Firepower Threat Defense device to take over the functionality
of a failed unit. When the active unit fails, the standby unit becomes the active unit.
Primary/Secondary Roles and Active/Standby Status

When setting up Active/Standby failover, you configure one unit to be primary and the other to be secondary.
During configuration, the primary unit's policies are synchronized to the secondary unit. At this point, the two
units act as a single device for device and policy configuration. However, for events, dashboards, reports and
health monitoring, they continue to display as separate devices.
The main differences between the two units in a failover pair are related to which unit is active and which
unit is standby, namely which IP addresses to use and which unit actively passes traffic.

919
Active Unit Determination at Startup
However, a few differences exist between the units based on which unit is primary (as specified in the
configuration) and which unit is secondary:
• The primary unit always becomes the active unit if both units start up at the same time (and are of equal
operational health).
• The primary unit MAC addresses are always coupled with the active IP addresses. The exception to this
rule occurs when the secondary unit becomes active and cannot obtain the primary unit MAC addresses
over the failover link. In this case, the secondary unit MAC addresses are used.
Active Unit Determination at Startup

The active unit is determined by the following:
• If a unit boots and detects a peer already running as active, it becomes the standby unit.
• If a unit boots and does not detect a peer, it becomes the active unit.
• 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.
Table 100: Failover Events
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.
Formerly active unit No failover Become standby No action None.

recovers
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.

920
Failure Event Policy Active Unit Action Standby Unit Action Notes
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
State link failed No failover No action No action State information

becomes out of date, and
sessions are terminated if
a failover occurs.
Interface failure on active Failover Mark active as failed Become active None.
unit above threshold
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.

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Network Admin
Guidelines for High Availability

Model Support
• Firepower 1010:
• You should not use the switch port functionality when using High Availability. Because the switch
ports operate in hardware, they continue to pass traffic on both the active and the standby units.
High Availability is designed to prevent traffic from passing through the standby unit, but this
feature does not extend to switch ports. In a normal High Availability network setup, active switch
ports on both units will lead to network loops. We suggest that you use external switches for any

921
Guidelines for High Availability
switching capability. Note that VLAN interfaces can be monitored by failover, while switch ports
cannot. Theoretically, you can put a single switch port on a VLAN and successfully use High
Availability, but a simpler setup is to use physical firewall interfaces instead.
• You can only use a firewall interface as the failover link.
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.
• Firepower 9300—Intra-chassis High Availability is not supported.

• The Firepower Threat Defense Virtual on public cloud networks such as Microsoft Azure and Amazon
Web Services are not supported with High Availability because Layer 2 connectivity is required.
• 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.
• Configuring port security on the switches 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.
• Both the peer devices go into unknown state and High Availability configuration fails if you run clish
in any of the peer devices while creating a High Availability pair.
• Immediately after failover, the source address of syslog messages will be the failover interface address
for a few seconds.
• If you configure HA failover encryption in evaluation mode, the systems use DES for the encryption. If
you then register the devices using an export-compliant account, the devices will use AES after a reboot.
Thus, if a system reboots for any reason, including after installing an upgrade, the peers will be unable

922
Add a Firepower Threat Defense High Availability Pair
to communicate and both units will become the active unit. We recommend that you do not configure
encryption until after you register the devices. If you do configure this in evaluation mode, we recommend
you remove the encryption before registering the devices.
• When using SNMPv3 with failover, if you replace a failover unit, then SNMPv3 users are not replicated
to the new unit.You must remove the users, re-add them, and then redeploy your configuration to force
the users to replicate to the new unit.
• The FTD does not share SNMP client engine data with its peer.

When establishing an Active/Standby High Availability pair, you designate one of the devices as primary and
the other as secondary. The system applies a merged configuration to the paired devices. If there is a conflict,
the system applies the configuration from the device you designated as primary.
In a multidomain deployment, devices in a high availability pair must belong to the same domain.
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 546 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.
Before you begin

Confirm that both devices:
• Are the same model.
• Have the same number and type of interfaces.
• Are in the same domain and group.
• Have normal health status and are running the same software.
• Are either in routed or transparent mode.
• Have the same NTP configuration. See Configure NTP Time Synchronization for Threat Defense, on
page 1467.
• Are fully deployed with no uncommitted changes.

923
• Do not have DHCP or PPPoE configured in any of their interfaces.
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.
Procedure
Step 1 Add both devices to the Firepower Management Center according to Add a Device to the FMC, on page 355.
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 10 Type any identifying Logical Name.

Step 11 Type a Primary IP address for the failover link on the active unit.
This address should be on an unused subnet. This subnet can be 31-bits (255.255.255.254 or /31) with only
two IP addresses.
Note 169.254.1.0/24 and fd00:0:0:*::/64 are internally used subnets and cannot be used for the failover
or state links.
Step 12 Optionally, choose Use IPv6 Address.

Step 13 Type a Secondary IP address for the failover link on the standby unit. This IP address must be in the same
subnet as the primary IP address.
Step 14 If IPv4 addresses are used, type a Subnet Mask that applies to both the primary and secondary IP addresses.
Step 15 Optionally, under Stateful Failover Link, choose the same Interface, or choose a different interface and enter
the high availability configuration information.
This subnet can be 31-bits (255.255.255.254 or /31) with only two IP addresses.
Note 169.254.1.0/24 and fd00:0:0:*::/64 are internally used subnets and cannot be used for the failover
or state links.
Step 16 Optionally, choose Enabled and choose the Key Generation method for IPsec Encryption between the
failover links.

924
Configure Optional High Availability Parameters
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 257.
Configure Optional High Availability Parameters

You can view the initial High Availability Configuration on the Firepower Management Center. You cannot
edit these settings without breaking the high availability pair and then re-establishing it.
You can edit the Failover Trigger Criteria to improve failover results. Interface Monitoring allows you to
determine which interfaces are better suited for failover.
Configure Standby IP Addresses and Interface Monitoring

For each interface, set a standby IP address. 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.
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.
Procedure

Step 2 Next to the device high-availability pair you want to edit, click the Edit ( ).
Step 3 Click the High Availability tab.

Step 4 In the Monitored Interfaces area, click the Edit ( ) next to the interface you want to edit.
Step 5 Check the Monitor this interface for failures check box.
Step 6 On the IPv4 tab, enter the Standby IP Address.
This address must be a free address on the same network as the active IP address.
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.
Step 8 Click OK.

925
Edit High Availability Failover Criteria
Edit High Availability Failover Criteria

You can customize failover criteria based on your network deployment.
Procedure

Step 2 Next to the device high-availability pair you want to edit, click the Edit ( ).

Step 4 Next to Failover Trigger Criteria, click the Edit ( ).
Step 5 Under Interface Failure Threshold, choose the number or percentage of interfaces that must fail before the
device fails over.
Step 6 Under Hello packet Intervals, choose how often hello packets are sent over the failover link.
Note If you use remote access VPN on the Firepower 2100, use the default hello packet intervals.
Otherwise, you might see high CPU usage that can cause a failover to occur.
Step 7 Click OK.
Configure Virtual MAC addresses

You can configure active and standby MAC addresses for failover in two places on the Firepower Management
Center:
• The Advanced tab of the Edit Interface page during interface configuration; see Configure the MAC
• The Add Interface MAC Address page accessed from the High Availability page; see
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.
Procedure

Step 2 Next to the device high-availability pair you want to edit, click Edit ( ).
Step 4 Choose Add ( )next to Interface Mac Addresses.

926
Manage High Availability
Step 5 Choose a Physical Interface.

Step 6 Type an Active Interface Mac Address.
Step 7 Type a Standby Interface Mac Address.
Step 8 Click OK.
Manage High Availability

This section describes how to manage High Availability units after you enable High Availability, including
how to change the High Availability setup and how to force failover from one unit to another.
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.
Before you begin

Refresh Node Status in a Firepower Threat Defense High Availability Pair, on page 927. This ensures that the
status on the Firepower Threat Defense high availability device pair is in sync with the status on the Firepower
Management Center.
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.
Refresh Node Status in a Firepower Threat Defense High Availability Pair

Whenever active or standby devices in a Firepower Threat Defense high availability pair are rebooted, the
Firepower Management Center may not display accurate high availability status for either device. This is
because when the device reboots, the high availability status is immediately updated on the device and its
corresponding event is sent to the FMC. However, the status may not be updated on the FMC because the
communication between the device and the FMC is yet to be established.
Communication failures or weak communication channels between the FMC and devices may result in out
of sync data. When you switch the active and standby devices in a high availability pair, the change may not
be reflected in the FMC even after a significant time duration.

927
Suspend and Resume High Availability
In these scenarios, you can refresh the high availability node status to obtain accurate information about the
active and standby device in a high availability pair.
Procedure

Step 2 Next to the high availability pair where you want to refresh the node status, click the Refresh HA Node
Status.
Step 3 Click Yes to refresh the node status.
Suspend and Resume High Availability

You can suspend a unit in a high availability pair. This is useful when:
• Both units are in an active-active situation and fixing the communication on the failover link does not
correct the problem.
• You want to troubleshoot an active or standby unit and do not want the units to fail over during that time.
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.
> configure high-availability suspend

Please ensure that no deployment operation is in progress before suspending
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.
> configure high-availability resume

Successfully resumed high-availablity.
You can resume a unit only if it is in Suspended state. The unit will negotiate active/standby status with the
peer unit.

928
Replace a Unit in an FTD High Availability Pair
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.
Replace a Unit in an FTD High Availability Pair

To replace a failed unit in a Firepower Threat Defense high availability pair using a backup file, see Restoring
FMCs and Managed Devices, on page 269.
If you do not have a backup of the failed device, you must break high availability. Then, register the replacement
device to the Firepower Management Center and reestablish high availability. The process varies depending
on whether the device is primary or secondary:
• Replace a Primary FTD HA Unit with no Backup, on page 929
• Replace a Secondary FTD HA Unit with no Backup, on page 930
Replace a Primary FTD HA Unit with no Backup

Follow the steps below to replace a failed primary unit in a Firepower Threat Defense high availability pair.
Failing to follow these steps can overwrite the existing high availability configuration.
Procedure
Step 1 Choose Force Break to separate the high availability pair; see Separate Units in a High Availability Pair, on
page 930.
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 358.
Step 3 Register the replacement Firepower Threat Defense to the Firepower Management Center; see Add a Device
to the FMC, on page 355.

929
Replace a Secondary FTD HA Unit with no Backup
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
Replace a Secondary FTD HA Unit with no Backup

Follow the steps below to replace a failed secondary unit in a Firepower Threat Defense high availability pair.
Procedure
Step 1 Choose Force Break to separate the high availability pair; see Separate Units in a High Availability Pair, on
page 930.
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 358.
Step 3 Register the replacement Firepower Threat Defense to the Firepower Management Center; see Add a Device
to the FMC, on page 355.
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
Separate Units in a High Availability Pair

When you break a high availability pair, the active device retains full deployed functionality. The standby
device loses its failover and interface configurations, and becomes a standalone device.
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.

930
Unregister a High Availability Pair
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.
Before you begin

Refresh Node Status in a Firepower Threat Defense High Availability Pair, on page 927. This ensures that the
status on the Firepower Threat Defense high availability device pair is in sync with the status on the Firepower
Management Center.
Procedure

Step 2 Next to the high-availability pair you want to break, click the Break HA.
Step 3 Optionally, check the check box to force break, if the standby peer does not respond.
Step 4 Click Yes. The device high-availability pair is separated.
The Break operation removes the failover configuration from the active and standby 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.
Unregister a High Availability Pair

You can delete the pair from the Firepower Management Center and disable High Availability on each unit
using the CLI.
Before you begin

This procedure requires CLI access.
Procedure
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.

931
Monitoring High Availability
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.
Monitoring High Availability

This section lets you monitor the High Availability status.
View Failover History

You can view the failover history of both high availability devices in a single view. The history displays in
chronological order and includes the reason for any failover.
Procedure

Step 3 Choose Summary.

Step 4 Under General, click View ( ).
View Stateful Failover Statistics

You can view the stateful failover link statistics of both the primary and secondary devices in the high
availability pair.
Procedure


Step 4 Under Stateful Failover Link, click View ( ).

932
Step 5 Choose a device to view statistics.

933

934
CHAPTER 36
Clustering for the Firepower Threat Defense
Clustering lets you group multiple FTD units together as a single logical device. Clustering is only supported
for the FTD device on the Firepower 9300 and the Firepower 4100 series. A cluster provides all the convenience
of a single device (management, integration into a network) while achieving the increased throughput and
redundancy of multiple devices.
Note Some features are not supported when using clustering. See Unsupported Features with Clustering, on page
976.
• About Clustering on the Firepower 4100/9300 Chassis, on page 935

• Licenses for Clustering, on page 940
• Requirements and Prerequisites for Clustering, on page 941
• Clustering Guidelines and Limitations, on page 944
• Configure Clustering, on page 948
• FXOS: Remove a Cluster Unit, on page 967
• FMC: Manage Cluster Members, on page 969
• FMC: Monitoring the Cluster, on page 974
• Reference for Clustering, on page 976
• History for Clustering, on page 986
About Clustering on the Firepower 4100/9300 Chassis

The cluster consists of multiple devices acting as a single logical unit. When you deploy a cluster on the
Firepower 4100/9300 chassis, it does the following:
• For native instance clustering: Creates a cluster-control link (by default, port-channel 48) for unit-to-unit
communication.
For multi-instance clustering: You should pre-configure subinterfaces on one or more cluster-type
EtherChannels; each instance needs its own cluster control link.
For intra-chassis clustering (Firepower 9300 only), this link utilizes the Firepower 9300 backplane for
cluster communications.
For inter-chassis clustering, you need to manually assign physical interface(s) to this EtherChannel for
communications between chassis.

935
Bootstrap Configuration
• Creates the cluster bootstrap configuration within the application.

When you deploy the cluster, the chassis supervisor pushes a minimal bootstrap configuration to each
unit that includes the cluster name, cluster control link interface, and other cluster settings.
• Assigns data interfaces to the cluster as Spanned interfaces.
For intra-chassis clustering, spanned interfaces are not limited to EtherChannels, like it is for inter-chassis
clustering.The Firepower 9300 supervisor uses EtherChannel technology internally to load-balance traffic
to multiple modules on a shared interface, so any data interface type works for Spanned mode. For
inter-chassis clustering, you must use Spanned EtherChannels for all data interfaces.
Note Individual interfaces are not supported, with the exception of a management
interface.
• Assigns a management interface to all units in the cluster.
The following sections provide more detail about clustering concepts and implementation. See also Reference
for Clustering, on page 976.
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 976.
Cluster Control Link

For native instance clustering: The cluster control link is automatically created using the Port-channel 48
interface.
For multi-instance clustering: You should pre-configure subinterfaces on one or more cluster-type
EtherChannels; each instance needs its own cluster control link.
For intra-chassis clustering, this interface has no member interfaces. This Cluster type EtherChannel utilizes
the Firepower 9300 backplane for cluster communications for intra-chassis clustering. For inter-chassis
clustering, you must add one or more interfaces to the EtherChannel.

936
Size the Cluster Control Link for Inter-Chassis Clustering
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.
Size the Cluster Control Link for Inter-Chassis Clustering

If possible, you should size the cluster control link to match the expected throughput of each chassis so the
cluster-control link can handle the worst-case scenarios.
Cluster control link traffic is comprised mainly of state update and forwarded packets. The amount of traffic
at any given time on the cluster control link varies. The amount of forwarded traffic depends on the
load-balancing efficacy or whether there is a lot of traffic for centralized features. For example:
• NAT results in poor load balancing of connections, and the need to rebalance all returning traffic to the
correct units.
• When membership changes, the cluster needs to rebalance a large number of connections, thus temporarily
using a large amount of cluster control link bandwidth.
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.
Cluster Control Link Redundancy for Inter-Chassis Clustering

The following diagram shows how to use an EtherChannel as a cluster control link in a Virtual Switching
System (VSS) or Virtual Port Channel (vPC) environment. All links in the EtherChannel are active. When
the switch is part of a VSS or vPC, then you can connect Firepower 9300 chassis interfaces within the same
EtherChannel to separate switches in the VSS or vPC. The switch interfaces are members of the same
EtherChannel port-channel interface, because the separate switches act like a single switch. Note that this
EtherChannel is device-local, not a Spanned EtherChannel.

937
Cluster Control Link Reliability for Inter-Chassis Clustering
Cluster Control Link Reliability for Inter-Chassis Clustering

To ensure cluster control link functionality, be sure the round-trip time (RTT) between units is less than 20
ms. This maximum latency enhances compatibility with cluster members installed at different geographical
sites. To check your latency, perform a ping on the cluster control link between units.
The cluster control link must be reliable, with no out-of-order or dropped packets; for example, for inter-site
deployment, you should use a dedicated link.
Cluster Control Link Network

The Firepower 4100/9300 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. For multi-instance clusters, which typically use
different VLAN subinterfaces of the same EtherChannel, the same IP address can be used for different clusters
because of VLAN separation. The cluster control link network cannot include any routers between units; only
Layer 2 switching is allowed.
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.

938
Cluster Interfaces
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.

939
Connecting to a VSS or vPC
Connecting to a VSS or vPC

We recommend connecting EtherChannels to a VSS or vPC to provide redundancy for your interfaces.
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.
Licenses for Clustering

The FTD uses Smart Licensing. You assign licenses to the cluster as a whole, not to individual units. However,
each unit of the cluster consumes a separate license for each feature. The clustering feature itself does not
require any licenses.
When you add a cluster member to the FMC, you can specify the feature licenses you want to use for the
cluster. You can modify licenses for the cluster in the Devices > Device Management > Cluster > License
area.

940
Requirements and Prerequisites for Clustering
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.

Cluster Model Support
The FTD supports clustering on the following models:
• Firepower 9300—You can include up to 6 units in the cluster. 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. Supports
intra-chassis and inter-chassis clustering.
• Firepower 4100 series—Supported for up to 6 units using inter-chassis clustering.
User Roles
• Admin
• Access Admin
• Network Admin
Inter-Chassis Clustering Hardware and Software Requirements

All chassis in a cluster:
• Native instance clustering—For the Firepower 4100 series: All chassis must be the same model. For the
Firepower 9300: All security modules must be the same type. For example, if you use clustering, all
modules in the Firepower 9300 must be SM-40s. You can have different quantities of installed security
modules in each chassis, although all modules present in the chassis must belong to the cluster including
any empty slots.
• Container instance clustering—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.

941
• 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.
Multi-Instance Clustering Requirements

• No intra-security-module/engine clustering—For a given cluster, you can only use a single container
instance per security module/engine. You cannot add 2 container instances to the same cluster if they
are running on the same module.
• 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.

942
• 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.
• No subinterfaces—A multi-instance cluster cannot use FXOS-defined VLAN subinterfaces. An exception
is made for the cluster control link, which can use a subinterface of the Cluster EtherChannel.
• 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

943
Clustering Guidelines and Limitations
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.
• Maximum 6 units—You can use up to six container instances in a cluster.
Switch Requirements for Inter-Chassis Clustering

• Be sure to complete the switch configuration and successfully connect all the EtherChannels from the
chassis to the switch(es) before you configure clustering on the Firepower 4100/9300 chassis.
• For supported switch characteristics, see Cisco FXOS Compatibility.

Switches for Inter-Chassis Clustering
• Make sure connected switches match the MTU for both cluster data interfaces and the cluster control
link interface. You should configure the cluster control link interface MTU to be at least 100 bytes higher
than the data interface MTU, so make sure to configure the cluster control link connecting switch
appropriately. 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.
• For Cisco IOS XR systems, if you want to set a non-default MTU, set the IOS interface MTU to be 14
bytes higher than the cluster device MTU. Otherwise, OSPF adjacency peering attempts may fail unless
the mtu-ignore option is used. Note that the cluster device MTU should match the IOS IPv4 MTU. This
adjustment is not required for Cisco Catalyst and Cisco Nexus switches.
• On the switch(es) for the cluster control link interfaces, you can optionally enable Spanning Tree PortFast
on the switch ports connected to the cluster unit to speed up the join process for new units.

944
• On the switch, we recommend that you use one of the following EtherChannel load-balancing algorithms:
source-dest-ip or source-dest-ip-port (see the Cisco Nexus OS and Cisco IOS port-channel load-balance
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.
EtherChannels for Inter-Chassis Clustering

• In Catalyst 3750-X Cisco IOS software versions earlier than 15.1(1)S2, the cluster unit did not support
connecting an EtherChannel to a switch stack. With default switch settings, if the cluster unit EtherChannel
is connected cross stack, and if the control unit 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.
• Spanned vs. Device-Local EtherChannel Configuration—Be sure to configure the switch appropriately
for Spanned EtherChannels vs. Device-local EtherChannels.
• Spanned EtherChannels—For cluster unit Spanned EtherChannels, which span across all members
of the cluster, the interfaces are combined into a single EtherChannel on the switch. Make sure each
interface is in the same channel group on the switch.

945
• Device-local EtherChannels—For cluster unit Device-local EtherChannels including any

EtherChannels configured for the cluster control link, be sure to configure discrete EtherChannels
on the switch; do not combine multiple cluster unit EtherChannels into one EtherChannel on the
switch.

946
• 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

947
Configure Clustering
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.
FXOS: Add a Firepower Threat Defense Cluster

In native mode: You can add a single Firepower 9300 chassis as an intra-chassis cluster, or add multiple
chassis for inter-chassis clustering.
In multi-instance mode: You can add one or more clusters on a single Firepower 9300 chassis as intra-chassis
clusters (you must include an instance on each module), or add one or more clusters on multiple chassis for
inter-chassis clustering.
For inter-chassis clustering, you must configure each chassis separately. Add the cluster on one chassis; you
can then copy the bootstrap configuration from the first chassis to the next chassis for ease of deployment
Create a Firepower Threat Defense Cluster

You can easily deploy the cluster from the Firepower 4100/9300 chassis supervisor. All initial configuration
is automatically generated for each unit.
For inter-chassis clustering, you must configure each chassis separately. Deploy the cluster on one chassis;
you can then copy the bootstrap configuration from the first chassis to the next chassis for ease of deployment.
In a Firepower 9300 chassis, you must enable clustering for all 3 module slots, or for container instances, a
container instance in each slot, even if you do not have a module installed. If you do not configure all 3
modules, the cluster will not come up.
Before you begin

• Download the application image you want to use for the logical device from Cisco.com, and then upload
that image to the Firepower 4100/9300 chassis.
• 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 792.

948
• 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
Procedure
Step 1 Configure interfaces.

a) Add at least one Data type interface or EtherChannel (also known as a port-channel) before you deploy
the cluster. See Add an EtherChannel (Port Channel), on page 789 or Configure a Physical Interface, on
page 788.
For inter-chassis clustering, all data interfaces must be Spanned EtherChannels with at least one member
interface. Add the same EtherChannels on each chassis. Combine the member interfaces from all cluster
units into a single EtherChannel on the switch. See Clustering Guidelines and Limitations, on page 944
for more information about EtherChannels for inter-chassis clustering.
For multi-instance clustering, you cannot use FXOS-defined VLAN subinterfaces or data-sharing interfaces
in the cluster. Only application-defined subinterfaces are supported. See FXOS Interfaces vs. Application
Interfaces, on page 761 for more information.
b) Add a Management type interface or EtherChannel. See Add an EtherChannel (Port Channel), on page
789 or Configure a Physical Interface, on page 788.
The management interface is required. Note that this management interface is not the same as the chassis
management interface that is used only for chassis management (in FXOS, you might see the chassis
management interface displayed as MGMT, management0, or other similar names).
For inter-chassis clustering, add the same Management interface on each chassis.
For multi-instance clustering, you can share the same management interface across multiple clusters on
the same chassis, or with standalone instances.
c) For inter-chassis clustering, add a member interface to the cluster control link EtherChannel (by default,
port-channel 48). See Add an EtherChannel (Port Channel), on page 789.
Do not add a member interface for intra-chassis clustering. If you add a member, the chassis assumes this
cluster will be inter-chassis, and will only allow you to use Spanned EtherChannels, for example.

949
On the Interfaces tab, the port-channel 48 cluster type interface shows the Operation State as failed if
it does not include any member interfaces. For intra-chassis clustering, this EtherChannel does not require
any member interfaces, and you can ignore this Operational State.
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 944 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 791.
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 789 or
Configure a Physical Interface, on page 788.
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.
Step 2 Choose Logical Devices.

Step 3 Click Add > Cluster, and set the following parameters:
Figure 30: Native Cluster

950
Figure 31: Multi-Instance Cluster
a) Choose I want to: > Create New Cluster

b) Provide a Device Name.
This name is used internally by the chassis supervisor to configure management settings and to assign
interfaces; it is not the device name used in the application configuration.
c) For the Template, choose Cisco Firepower Threat Defense.
d) Choose the Image Version.
e) For the Instance Type, choose either Native or Container.
A native instance uses all of the resources (CPU, RAM, and disk space) of the security module/engine,
so you can only install one native instance. A container instance uses a subset of resources of the security
module/engine, so you can install multiple container instances.
f) (Container Instance only) For the Resource Type, choose one of the resource profiles from the drop-down
list.
For the Firepower 9300, this profile will be applied to each instance on each security module. You can
set different profiles per security module later in this procedure; for example, if you are using different
security module types, and you want to use more CPUs on a lower-end model. We recommend choosing
the correct profile before you create the cluster. If you need to create a new profile, cancel out of the
cluster creation, and add one using Add a Resource Profile for Container Instances, on page 792.
g) Click OK.
You see the Provisioning - device name window.
Step 4 Choose the interfaces you want to assign to this cluster.

951
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.
Step 5 Click the device icon in the center of the screen.

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.
Step 6 On the Cluster Information page, complete the following.

952
Figure 32: Native Cluster

953
Figure 33: Multi-Instance Cluster
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.

954
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), multicast (224.0.0.0/4), and internal (169.254.0.0/16)
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.
Step 7 On the Settings page, complete the following.
a) In the Registration Key field, enter the key to be shared between the Firepower Management Center and
the cluster members during registration.
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.

955
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.
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.

956
a) In the Management IP field, configure an IP address.

Specify a unique IP address on the same network for each module.
b) Enter a Network Mask or Prefix Length.
c) Enter a Network Gateway address.
Step 9 On the Agreement tab, read and accept the end user license agreement (EULA).
Step 10 Click OK to close the configuration dialog box.
Step 11 Click Save.
for the status of the new logical device. When the logical device shows its Status as online, you can add the
remaining cluster chassis, or for intra-chassis clusteringstart 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.

957
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.

958
Add More Cluster Units
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.
Add More Cluster Units

Add or replace a FTD cluster unit in an existing cluster.
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.
Before you begin

• In the case of a replacement, you must delete the old cluster unit from the Firepower Management Center.
When you replace it with a new unit, it is considered to be a new device on the Firepower Management
Center.
• The interface configuration must be the same on the new chassis. You can export and import FXOS
chassis configuration to make this process easier.
Procedure
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.

959
FMC: Add a Cluster
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.
Step 8 Click Save.

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.
FMC: Add a Cluster

Add one of the cluster units as a new device to the Firepower Management Center; the FMC auto-detects all
other cluster members.

960
FMC: Add a Cluster
Before you begin

• This method for adding a cluster requires Firepower Threat Defense Version 6.2 or later. If you need to
manage an earlier version device, then refer to the Firepower Management Center configuration guide
for that version.
• 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.
Procedure
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 346.

961
FMC: Add a Cluster
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.
g) Choose licenses to apply to the device.

h) If you used a NAT ID during device setup, expand the Advanced section and enter the same NAT ID in
the Unique NAT ID field.
i) Check the Transfer Packets check box to allow the device to transfer packets to the FMC.
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.
j) Click Register.
The FMC identifies and registers the control unit, and then registers all data units. If the control unit does
not successfully register, then the cluster is not added. A registration failure can occur if the cluster was
not up on the chassis, or because of other connectivity issues. In this case, we recommend that you try
re-adding the cluster unit.
The cluster name shows on the Devices > Device Management page; expand the cluster to see the cluster
units.

962
FMC: Add a Cluster
A unit that is currently registering shows the loading icon.
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 974.
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.
See the following cluster-specific items:
• General > Name—Change the cluster display name by clicking the Edit ( ).

963
FMC: Add a Cluster
Then set the Name field.
• 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.

964
FMC: Add a Cluster
• License—Click Edit ( ) to set license entitlements.
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 ( ).
Then set the Name field.
• 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.

965
FMC: Configure Cluster, Data, and Diagnostic Interfaces
FMC: Configure Cluster, Data, and Diagnostic Interfaces

This procedure configures basic parameters for each data interface that you assigned to the cluster when you
deployed it in FXOS. For inter-chassis clustering, data interfaces are always Spanned EtherChannel interfaces.
For the cluster control link interface for inter-chassis clustering, you must increase the MTU from the default.
You can also configure the Diagnostic interface, which is the only interface that can run as an individual
interface.
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.
Procedure
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.
a) Click Edit ( ) for the cluster control link interface.

b) On the General page, in the MTU field, enter a value between 1400 and 9184. We suggest using the
maximum, 9184.
c) Click OK.
Step 4 Configure data interfaces.
a) (Optional) Configure VLAN subinterfaces on the data interface. The rest of this procedure applies to the
subinterfaces. See Add a Subinterface, on page 840.
b) Click Edit ( ) for the data interface.
c) Configure the name, IP address, and other parameters according to Configure Routed Mode Interfaces,
on page 844 or Configure Bridge Group Interfaces, on page 848.

966
FXOS: Remove a Cluster Unit
Note If the cluster control link interface MTU is not at least 100 bytes higher than the data interface
MTU, you will see an error that you must reduce the MTU of the data interface. See step Step 3,
on page 966 to increase the cluster control link MTU, after which you can continue configuring
the data interfaces.
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 708.
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.

The following sections describe how to remove units temporarily or permanently from the cluster.

967
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.

968
FMC: Manage Cluster Members
• 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.
FMC: Manage Cluster Members

After you deploy the cluster, you can change the configuration and manage cluster members.
Add a New Cluster Member

When you add a new cluster member in FXOS, the Firepower Management Center adds the member
automatically.
Before you begin

• Make sure the interface configuration is the same on the replacement unit as for the other chassis.
Procedure
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 (which is available from the Devices > Device Management More ( ) icon
or from the Devices > Device Management > Cluster tab > General area > Cluster Live Status 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.

969
Replace a Cluster Member
Replace a Cluster Member

You can replace a cluster member in an existing cluster. The FMC auto-detects the replacement unit. However,
you must manually delete the old cluster member in the FMC. This procedure also applies to a unit that was
reinitialized; in this case, although the hardware remains the same, it appears to be a new member.
Before you begin

• Make sure the interface configuration is the same on the replacement unit as for other chassis.
Procedure
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 969.
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 FMC for the old unit, choose Devices > Device Management > More ( ) > Delete .
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 > More ( ) icon or Devices > Device
Management > Cluster page > General area > Cluster Live Status 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 All.
• System ( ) > Tasks—The FMC shows all registration events and failures.

970
Deactivate a Member
• 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.
Deactivate a Member
You may want to deactivate a member in preparation for deleting the unit, or temporarily for maintenance.
This procedure is meant to temporarily deactivate a member; the unit will still appear 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.
Procedure
Step 1 For the unit you want to deactivate, choose Devices > Device Management > More ( ) > Disable Clustering.
You can also deactivate a unit from the Cluster Status dialog box (Devices > Device Management > More
( ) > Cluster Live Status).
Step 2 Confirm that you want to disable clustering on the unit.

The unit will show (Disabled) next to its name in the Devices > Device Management list.
Step 3 To reenable clustering, see Rejoin the Cluster, on page 972.

971
Rejoin the Cluster
Rejoin the Cluster

If a unit was removed from the cluster, for example for a failed interface or if you manually disabled clustering,
you must manually rejoin the cluster. Make sure the failure is resolved before you try to rejoin the cluster.
See Rejoining the Cluster, on page 983 for more information about why a unit can be removed from a cluster.
Procedure
Step 1 For the unit you want to reactivate, choose Devices > Device Management > More ( ) > Enable Clustering.
You can also reactivate a unit from the Cluster Status dialog box (Devices > Device Management > More
( ) > Cluster Live Status).
Step 2 Confirm that you want to enable clustering on the unit.
Delete a Data Unit

If you need to permanently remove a cluster member (for example, if you remove a module on the Firepower
9300, or remove a chassis), then you should delete it from the FMC.
Do not delete the member if it is still a healthy part of the cluster, or if you only want to disable the member
temporarily. To delete it permanently from the cluster in FXOS, see FXOS: Remove a Cluster Unit, on page
967. If you remove it from the FMC, and it is still part of the cluster, it will continue to pass traffic, and could
even become the control unit—a control unit that the FMC can no longer manage.
Before you begin

To manually deactivate the unit, see Deactivate a Member, on page 971. Before you delete a unit, the unit must
be inactive, either manually or because of a health failure.
Procedure
Step 1 Make sure the unit is ready to be deleted from the FMC. On Devices > Device Management, make sure the
unit shows (Disabled).

972
Change the Control Unit
You can also view each unit's status on the Cluster Status dialog box available from More ( ). If the status
is stale, click Reconcile All on the Cluster Status dialog box to force an update.
Step 2 In the FMC for the data unit you want to delete, choose Devices > Device Management > More ( ) > Delete
.
Step 3 Confirm that you want to delete the unit.

The unit is removed from the cluster and from the FMC devices list.
Change the Control Unit
Caution The best method to change the control unit is to disable clustering on the control unit, wait for a new control
election, and then re-enable clustering. If you must specify the exact unit you want to become the control unit,
use the procedure in this section. Note, however, that for centralized features, if you force a control unit change
using this procedure, then all connections are dropped, and you have to re-establish the connections on the
new control unit.
To change the control unit, perform the following steps.
Procedure
Step 1 Open the Cluster Status dialog box by choosing Devices > Device Management > More ( ) > Cluster Live
Status.

973
Reconcile Cluster Members
You can also access the Cluster Status dialog box from Devices > Device Management > Cluster page >
General area > Cluster Live Status link.
Step 2 For the unit you want to become the control unit, choose More ( ) > Change Role to Control.
Step 3 You are prompted to confirm the role change. Check the checkbox, and click OK.
Reconcile Cluster Members

If a cluster member fails to register, you can reconcile the cluster membership from the chassis to the Firepower
Management Center. For example, a data unit might fail to register if the FMC is occupied with certain
processes, or if there is a network issue.
Procedure
Step 1 Choose Devices > Device Management > More ( ) for the cluster, and then choose Cluster Live Status to
open the Cluster Status dialog box.
You can also open the Cluster Status dialog box from the Devices > Device Management > Cluster page
> General area > Cluster Live Status link.
Step 2 Click Reconcile All.

For more information about the cluster status, see FMC: Monitoring the Cluster, on page 974.
FMC: Monitoring the Cluster

You can monitor the cluster in Firepower Management Center and at the FTD CLI.
• Cluster Status dialog box, which is available from the Devices > Device Management > More ( ) icon
or from the Devices > Device Management > Cluster page > General area > Cluster Live Status link.

974
FMC: Monitoring the Cluster
The Control unit has a graphic indicator identifying its role.

Cluster member Status includes the following states:
• In Sync.—The unit is registered with the FMC.
• Pending Registration—The unit is part of the cluster, but has not yet registered with the FMC. If a
unit fails to register, you can retry registration by clicking Reconcile All.
• Clustering is disabled—The unit is registered with the FMC, but is an inactive member of the cluster.
The clustering configuration remains intact if you intend to later re-enable it, or you can delete the
unit from the cluster.
• Joining cluster...—The unit is joining the cluster on the chassis, but has not completed joining. After
it joins, it will register with the FMC.
For each unit, you can view the Summary or the History.
For each unit from the More ( ) menu , you can perform the following status changes:
• Disable Clustering
• Enable Clustering
• Change Role to Control
• System ( ) > Tasks page.

The Tasks page shows updates of the Cluster Registration task as each unit registers.
• Devices > Device Management > cluster_name.

975
Reference for Clustering
When you expand the cluster on the devices listing page, you can see all member units, including the
control unit shown with its role next to the IP address. For units that are still registering, you can see the
loading icon.
• show cluster {access-list [acl_name] | conn [count] | cpu [usage] | history | interface-mode | memory
| resource usage | service-policy | traffic | xlate count}
To view aggregated data for the entire cluster or other information, use the show cluster command.
• show cluster info [auto-join | clients | conn-distribution | flow-mobility counters | goid [options] |
health | incompatible-config | loadbalance | old-members | packet-distribution | trace [options] |
transport { asp | cp}]
To view cluster information, use the show cluster info command.
Reference for Clustering

This section includes more information about how clustering operates.
Firepower Threat Defense Features and Clustering

Some FTD features are not supported with clustering, and some are only supported on the control unit. Other
features might have caveats for proper usage.
Unsupported Features with Clustering

These features cannot be configured with clustering enabled, and the commands will be rejected.
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 1277.
• Remote access VPN (SSL VPN and IPsec VPN)

• DHCP client, server, and proxy. DHCP relay is supported.
• High Availability
• Integrated Routing and Bridging
• FMC UCAPL/CC mode
Centralized Features for Clustering

The following features are only supported on the control unit, and are not scaled for the cluster.

976
Dynamic Routing and Clustering
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.
• The following application inspections:

• DCERPC
• NetBIOS
• RSH
• SUNRPC
• TFTP
• XDMCP
• Dynamic routing
• Static route monitoring
Dynamic Routing and Clustering

The routing process only runs on the control unit, and routes are learned through the control unit and replicated
to secondaries. If a routing packet arrives at a data unit, it is redirected to the control unit.
Figure 34: Dynamic Routing

977
Connection Settings
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.
FTP and Clustering

• If FTP data channel and control channel flows are owned by different cluster members, then the data
channel owner will periodically send idle timeout updates to the control channel owner and update the
idle timeout value. However, if the control flow owner is reloaded, and the control flow is re-hosted, the
parent/child flow relationship will not longer be maintained; the control flow idle timeout will not be
updated.
NAT and Clustering

NAT can affect the overall throughput of the cluster. Inbound and outbound NAT packets can be sent to
different FTDs in the cluster, because the load balancing algorithm relies on IP addresses and ports, and NAT
causes inbound and outbound packets to have different IP addresses and/or ports. When a packet arrives at
the FTD that is not the NAT owner, it is forwarded over the cluster control link to the owner, causing large
amounts of traffic on the cluster control link. Note that the receiving unit does not create a forwarding flow
to the owner, because the NAT owner may not end up creating a connection for the packet depending on the
results of security and policy checks.
If you still want to use NAT in clustering, then consider the following guidelines:
• PAT with Port Block Allocation—See the following guidelines for this feature:
• Maximum-per-host limit is not a cluster-wide limit, and is enforced on each unit individually. Thus,
in a 3-node cluster with the maximum-per-host limit configured as 1, if the traffic from a host is
load-balanced across all 3 units, then it can get allocated 3 blocks with 1 in each unit.
• Port blocks created on the backup unit from the backup pools are not accounted for when enforcing
the maximum-per-host limit.
• On-the-fly PAT rule modifications, where the PAT pool is modified with a completely new range
of IP addresses, will result in xlate backup creation failures for the xlate backup requests that were
still in transit while the new pool became effective. This behavior is not specific to the port block
allocation feature, and is a transient PAT pool issue seen only in cluster deployments where the
pool is distributed and traffic is load-balanced across the cluster units.
• When operating in a cluster, you cannot simply change the block allocation size. The new size is
effective only after you reload each device in the cluster. To avoid having to reload each device,

978
SIP Inspection and Clustering
we recommend that you delete all block allocation rules and clear all xlates related to those rules.
You can then change the block size and recreate the block allocation rules.
• NAT pool address distribution for dynamic PAT—When you configure a PAT pool, the cluster divides
each IP address in the pool into port blocks. By default, each block is 512 ports, but if you configure port
block allocation rules, your block setting is used instead. These blocks are distributed evenly among the
units in the cluster, so that each unit has one or more blocks for each IP address in the PAT pool. Thus,
you could have as few as one IP address in a PAT pool for a cluster, if that is sufficient for the number
of PAT’ed connections you expect. Port blocks cover the 1024-65535 port range, unless you configure
the option to include the reserved ports, 1-1023, on the PAT pool NAT rule.
• 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.
• No round-robin—Round-robin for a PAT pool is not supported with clustering.
• No extended PAT—Extended PAT is not supported with clustering.
• Dynamic NAT xlates managed by the control unit—The control unit maintains and replicates the xlate
table to data units. When a data unit receives a connection that requires dynamic NAT, and the xlate is
not in the table, it requests the xlate from the control unit. The data unit owns the connection.
• Stale xlates—The xlate idle time on the connection owner does not get updated. Thus, the idle time might
exceed the idle timeout. An idle timer value higher than the configured timeout with a refcnt of 0 is an
indication of a stale xlate.
• No static PAT for the following inspections—
• FTP
• RSH
• SQLNET
• TFTP
• XDMCP
• SIP
• If you have an extremely large number of NAT rules, over ten thousand, you should enable the
transactional commit model using the asp rule-engine transactional-commit nat command in the device
CLI. Otherwise, the unit might not be able to join the cluster.
SIP Inspection and Clustering

A control flow can be created on any unit (due to load balancing); its child data flows must reside on the same
unit.
SNMP and Clustering

An SNMP agent polls each individual FTD by its Diagnostic interface Local IP address. You cannot poll
consolidated data for the cluster.

979
Syslog and Clustering
When using SNMPv3 with clustering, if you add a new cluster unit after the initial cluster formation, then
SNMPv3 users are not replicated to the new unit. You must remove the users, and re-add them, and then
redeploy your configuration to force the users to replicate to the new unit.
Syslog and Clustering

• Each unit in the cluster generates its own syslog messages. You can configure logging so that each unit
uses either the same or a different device ID in the syslog message header field. For example, the hostname
configuration is replicated and shared by all units in the cluster. If you configure logging to use the
hostname as the device ID, syslog messages generated by all units look as if they come from a single
unit. If you configure logging to use the local-unit name that is assigned in the cluster bootstrap
configuration as the device ID, syslog messages look as if they come from different units.
TLS/SSL Connections and Clustering

The decryption states of TLS/SSL connections are not synchronized, and if the connection owner fails, then
the 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.
Cisco TrustSec and Clustering

Only the control unit learns security group tag (SGT) information. The control unit then populates the SGT
to data units, and data units can make a match decision for SGT based on the security policy.
VPN and Clustering

Site-to-site VPN is a centralized feature; only the control unit supports VPN connections.
Note Remote access VPN is not supported with clustering.
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.
Performance Scaling Factor

When you combine multiple units into a cluster, you can expect the total cluster performance to be
approximately:
• 80% of the combined TCP or CPS throughput
• 90% of the combined UDP throughput
• 60% of the combined Ethernet MIX (EMIX) throughput, depending on the traffic mix.

980
Control Unit Election
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.
Control Unit Election

Members of the cluster communicate over the cluster control link to elect a control unit as follows:
1. When you deploy the cluster, each unit broadcasts an election request every 3 seconds.
2. Any other units with a higher priority respond to the election request; the priority is set when you deploy
the cluster and is not configurable.
3. If after 45 seconds, a unit does not receive a response from another unit with a higher priority, then it
becomes the control unit.
Note If multiple units tie for the highest priority, the cluster unit name and then the serial number is used to determine
the control unit.
4. If a unit later joins the cluster with a higher priority, it does not automatically become the control unit;
the existing control unit always remains as the control unit unless it stops responding, at which point a
new control unit is elected.
5. In a "split brain" scenario when there are temporarily multiple control units, then the unit with highest
priority retains the role while the other units return to data unit roles.
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.
High Availability Within the Cluster

Clustering provides high availability by monitoring chassis, unit, and interface health and by replicating
connection states between units.
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.

981

Each unit periodically sends a broadcast keepaliveheartbeat packet over the cluster control link. If the control
unit does not receive any keepaliveheartbeat packets or other packets from a data unit within the timeout
period, then the control unit removes the data unit from the cluster. If the data units do not receive packets
from the control unit, then a new control unit is elected from the remaining members.
If units cannot reach each other over the cluster control link because of a network failure and not because a
unit has actually failed, then the cluster may go into a "split brain" scenario where isolated data units will
elect their own control units. For example, if a router fails between two cluster locations, then the original
control unit at location 1 will remove the location 2 data units from the cluster. Meanwhile, the units at location
2 will elect their own control unit and form their own cluster. Note that asymmetric traffic may fail in this
scenario. After the cluster control link is restored, then the control unit that has the higher priority will keep
the control unit’s role. See Control Unit Election, on page 981 for more information.
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.
Decorator Application Monitoring

When you install a decorator application on an interface, such as the Radware DefensePro application, then
both the Firepower Threat Defense device and the decorator application must be operational to remain in the
cluster. The unit does not join the cluster until both applications are operational. Once in the cluster, the unit
monitors the decorator application health every 3 seconds. If the decorator application is down, the unit is
removed from the cluster.
Status After Failure

When a unit in the cluster fails, the connections hosted by that unit are seamlessly transferred to other units;
state information for traffic flows is shared over the control unit's cluster control link.
If the control unit fails, then another member of the cluster with the highest priority (lowest number) becomes
the control unit.
The FTD automatically tries to rejoin the cluster, depending on the failure event.

982
Rejoining the Cluster
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.
Rejoining the Cluster

After a cluster member is removed from the cluster, how it can rejoin the cluster depends on why it was
removed:
• Failed cluster control link when initially joining—After you resolve the problem with the cluster control
link, you must manually rejoin the cluster by re-enabling clustering.
• Failed cluster control link after joining the cluster—The FTD automatically tries to rejoin every 5 minutes,
indefinitely.
• Failed data interface—The FTD automatically tries to rejoin at 5 minutes, then at 10 minutes, and finally
at 20 minutes. If the join is not successful after 20 minutes, then the FTD application disables clustering.
After you resolve the problem with the data interface, you have to manually enable clustering.
• Failed unit—If the unit was removed from the cluster because of a unit health check failure, then rejoining
the cluster depends on the source of the failure. For example, a temporary power failure means the unit
will rejoin the cluster when it starts up again as long as the cluster control link is up. The FTD application
attempts to rejoin the cluster every 5 seconds.
• Failed Chassis-Application Communication—When the FTD application detects that the
chassis-application health has recovered, it tries to rejoin the cluster automatically.
• Internal error—Internal failures include: application sync timeout; inconsistent application statuses; and
so on.
• Failed configuration deployment—If you deploy a new configuration from FMC, and the deployment
fails on some cluster members but succeeds on others, then the units that failed are removed from the
cluster. You must manually rejoin the cluster by re-enabling clustering. If the deployment fails on the
control unit, then the deployment is rolled back, and no members are removed. If the deployment fails
on all data units, then the deployment is rolled back, and no members are removed.
Data Path Connection State Replication

Every connection has one owner and at least one backup owner in the cluster. The backup owner does not
take over the connection in the event of a failure; instead, it stores TCP/UDP state information, so that the
connection can be seamlessly transferred to a new owner in case of a failure. The backup owner is usually
also the director.
Some traffic requires state information above the TCP or UDP layer. See the following table for clustering
support or lack of support for this kind of traffic.
Table 101: Features Replicated Across the Cluster
Traffic State Support Notes
Up time Yes Keeps track of the system up time.
ARP Table Yes —

983
How the Cluster Manages Connections
Traffic State Support Notes
MAC address table Yes —
User Identity Yes —
IPv6 Neighbor database Yes —
Dynamic routing Yes —
SNMP Engine ID No —
Centralized VPN (Site-to-Site) No VPN sessions will be disconnected

if the control unit fails.
How the Cluster Manages Connections

Connections can be load-balanced to multiple members of the cluster. Connection roles determine how
connections are handled in both normal operation and in a high availability situation.
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

984
New Connection Ownership
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.
Note We do not recommend disabling TCP sequence randomization when using

clustering. There is a small chance that some TCP sessions won't be established,
because the SYN/ACK packet might be dropped.
• Fragment Owner—For fragmented packets, cluster units that receive a fragment determine a fragment
owner using a hash of the fragment source IP address, destination IP address, and the packet ID. 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.
New Connection Ownership

When a new connection is directed to a member of the cluster via load balancing, that unit owns both directions
of the connection. If any connection packets arrive at a different unit, they are forwarded to the owner unit
over the cluster control link. If a reverse flow arrives at a different unit, it is redirected back to the original
unit.
Sample Data Flow

The following example shows the establishment of a new connection.

985
History for Clustering
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.

Cluster deployment completes faster, 6.7 Cluster deployment now completes faster. Also, when a cluster has an
and fails faster when there is an event event that causes an FMC deployment to fail, the failure now occurs
more quickly.
New/Modified screens: none.

986
Improved cluster management in FMC 6.7 FMC has improved cluster management functionality that formerly
you could only accomplish using the CLI, including:
• Enable and disable cluster units
• Show cluster status from the Device Management page, including
History and Summary per unit
• Change the role to the control unit
• Devices > Device Management > More menu
• Devices > Device Management > Cluster > General area >
Cluster Live Status link Cluster Status
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
• Logical Devices > Add Cluster
• Interfaces > All Interfaces > Add New drop-down menu >
Subinterface > Type field
Supported platforms: Firepower Threat Defense on the Firepower

4100/9300
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.
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

987
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).
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.
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
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.
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
4100/9300

988
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.
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.
Devices > Device Management > Add > Add Cluster
Devices > Device Management > Cluster
Supported platforms: Firepower Threat Defense on the Firepower 9300

989

990
PA R T IX
Firepower Threat Defense Routing
• Routing Overview for Firepower Threat Defense, on page 993
• Virtual Routing for Firepower Threat Defense, on page 1003
• Static and Default Routes for Firepower Threat Defense, on page 1047
• OSPF for Firepower Threat Defense, on page 1053
• BGP for Firepower Threat Defense, on page 1081
• RIP for Firepower Threat Defense, on page 1097
• Multicast Routing for Firepower Threat Defense, on page 1103
CHAPTER 37
Routing Overview for Firepower Threat Defense
This chapter describes underlying concepts of how routing behaves within the Firepower Threat Defense.
• Path Determination, on page 993
• Supported Route Types, on page 994
• Supported Internet Protocols for Routing, on page 995
• Routing Table, on page 996
• Routing Table for Management Traffic, on page 999
• Equal-Cost Multi-Path (ECMP) Routing, on page 999
• About Route Maps, on page 1000
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.

993
Supported Route Types
Supported Route Types

There are several route types that a router can use. The Firepower Threat Defense device uses the following
route types:
• Static Versus Dynamic
• Single-Path Versus Multipath
• Flat Versus Hierarchical
• Link-State Versus Distance Vector
Static Versus Dynamic

Static routing algorithms are actually table mappings established by the network administrator. These mappings
do not change unless the network administrator alters them. Algorithms that use static routes are simple to
design and work well in environments where network traffic is relatively predictable and where network
design is relatively simple.
Because static routing systems cannot react to network changes, they generally are considered unsuitable for
large, constantly changing networks. Most of the dominant routing algorithms are dynamic routing algorithms,
which adjust to changing network circumstances by analyzing incoming routing update messages. If the
message indicates that a network change has occurred, the routing software recalculates routes and sends out
new routing update messages. These messages permeate the network, stimulating routers to rerun their
algorithms and change their routing tables accordingly.
Dynamic routing algorithms can be supplemented with static routes where appropriate. A router of last resort
(a default route for a router to which all unroutable packets are sent), for example, can be designated to act
as a repository for all unroutable packets, ensuring that all messages are at least handled in some way.
Single-Path Versus Multipath

Some sophisticated routing protocols support multiple paths to the same destination. Unlike single-path
algorithms, these multipath algorithms permit traffic multiplexing over multiple lines. The advantages of
multipath algorithms are substantially better throughput and reliability, which is generally called load sharing.
Flat Versus Hierarchical

Some routing algorithms operate in a flat space, while others use routing hierarchies. In a flat routing system,
the routers are peers of all others. In a hierarchical routing system, some routers form what amounts to a
routing backbone. Packets from non-backbone routers travel to the backbone routers, where they are sent
through the backbone until they reach the general area of the destination. At this point, they travel from the
last backbone router through one or more non-backbone routers to the final destination.
Routing systems often designate logical groups of nodes, called domains, autonomous systems, or areas. In
hierarchical systems, some routers in a domain can communicate with routers in other domains, while others
can communicate only with routers within their domain. In very large networks, additional hierarchical levels
may exist, with routers at the highest hierarchical level forming the routing backbone.

994
Link-State Versus Distance Vector
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.
Link-State Versus Distance Vector

Link-state algorithms (also known as shortest path first algorithms) flood routing information to all nodes in
the internetwork. Each router, however, sends only the portion of the routing table that describes the state of
its own links. In link-state algorithms, each router builds a picture of the entire network in its routing tables.
Distance vector algorithms (also known as Bellman-Ford algorithms) call for each router to send all or some
portion of its routing table, but only to its neighbors. In essence, link-state algorithms send small updates
everywhere, while distance vector algorithms send larger updates only to neighboring routers. Distance vector
algorithms know only about their neighbors. Typically, link-state algorithms are used in conjunction with
OSPF routing protocols.
Supported Internet Protocols for Routing

The Firepower Threat Defense device supports several Internet protocols for routing. Each protocol is briefly
described in this section.
• Enhanced Interior Gateway Routing Protocol (EIGRP)
EIGRP is a Cisco proprietary protocol that provides compatibility and seamless interoperation with IGRP
routers. An automatic-redistribution mechanism allows IGRP routes to be imported into Enhanced IGRP,
and vice versa, so it is possible to add Enhanced IGRP gradually into an existing IGRP network.
• Open Shortest Path First (OSPF)
OSPF is a routing protocol developed for Internet Protocol (IP) networks by the interior gateway protocol
(IGP) working group of the Internet Engineering Task Force (IETF). OSPF uses a link-state algorithm
to build and calculate the shortest path to all known destinations. Each router in an OSPF area includes
an identical link-state database, which is a list of each of the router usable interfaces and reachable
neighbors.
• Routing Information Protocol (RIP)
RIP is a distance-vector protocol that uses hop count as its metric. RIP is widely used for routing traffic
in the global Internet and is an interior gateway protocol (IGP), which means that it performs routing
within a single autonomous system.
• Border Gateway Protocol (BGP)
BGP is an interautonomous system routing protocol. BGP is used to exchange routing information for
the Internet and is the protocol used between Internet service providers (ISP). Customers connect to ISPs,
and ISPs use BGP to exchange customer and ISP routes. When BGP is used between autonomous systems
(AS), the protocol is referred to as External BGP (EBGP). If a service provider is using BGP to exchange
routes within an AS, then the protocol is referred to as Interior BGP (IBGP).

995
Routing Table
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 999.
How the Routing Table Is Populated

The FTD routing table can be populated by statically defined routes, directly connected routes, and routes
discovered by the dynamic routing protocols. Because the FTD can run multiple routing protocols in addition
to having static and connected routes in the routing table, it is possible that the same route is discovered or
entered in more than one manner. When two routes to the same destination are put into the routing table, the
one that remains in the routing table is determined as follows:
• If the two routes have different network prefix lengths (network masks), then both routes are considered
unique and are entered into the routing table. The packet forwarding logic then determines which of the
two to use.
For example, if the RIP and OSPF processes discovered the following routes:
• RIP: 192.168.32.0/24
• OSPF: 192.168.32.0/19
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.
Administrative Distances for Routes

You can change the administrative distances for routes discovered by or redistributed into a routing protocol.
If two routes from two different routing protocols have the same administrative distance, then the route with
the lower default administrative distance is entered into the routing table. In the case of EIGRP and OSPF
routes, if the EIGRP route and the OSPF route have the same administrative distance, then the EIGRP route
is chosen by default.
Administrative distance is a route parameter that the Firepower Threat Defense device uses to select the best
path when there are two or more different routes to the same destination from two different routing protocols.
Because the routing protocols have metrics based on algorithms that are different from the other protocols, it

996
Backup Dynamic and Floating Static Routes
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.
Table 102: Default Administrative Distance for Supported Routing Protocols
Route Source Default Administrative Distance
Connected interface 0
Static route 1
EIGRP Summary Route 5
External BGP 20
Internal EIGRP 90
OSPF 110
IS-IS 115
RIP 120
EIGRP external route 170
Internal and local BGP 200
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.
Backup Dynamic and Floating Static Routes

A backup route is registered when the initial attempt to install the route in the routing table fails because
another route was installed instead. If the route that was installed in the routing table fails, the routing table

997
How Forwarding Decisions Are Made
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.
How Forwarding Decisions Are Made

Forwarding decisions are made as follows:
• If the destination does not match an entry in the routing table, the packet is forwarded through the interface
specified for the default route. If a default route has not been configured, the packet is discarded.
• If the destination matches a single entry in the routing table, the packet is forwarded through the interface
associated with that route.
• If the destination matches more than one entry in the routing table, then the packet is forwarded out of
the interface associated with the route that has the longer network prefix length.
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.
Dynamic Routing and High Availability

Dynamic routes are synchronized on the standby unit when the routing table changes on the active unit. This
means that all additions, deletions, or changes on the active unit are immediately propagated to the standby
unit. If the standby unit becomes active in an active/standby ready High Availability pair, it will already have
an identical routing table as that of the former active unit because routes are synchronized as a part of the
High Availability bulk synchronization and continuous replication processes.
Dynamic Routing in Clustering

The routing process only runs on the control unit, and routes are learned through the control unit and replicated
to data units. If a routing packet arrives at a data unit, it is redirected to the control unit.

998
Routing Table for Management Traffic
Figure 35: Dynamic Routing in Clustering
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.
Routing Table for Management Traffic
Equal-Cost Multi-Path (ECMP) Routing

The Firepower Threat Defense device supports Equal-Cost Multi-Path (ECMP) routing.
You can have up to 8 equal cost static or dynamic routes per interface. For example, you can configure multiple
default routes on the outside interface that specify different gateways.
route for 0.0.0.0 0.0.0.0 through outside to 10.1.1.2


999
About Route Maps
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.
ECMP Across Multiple Interfaces Using Traffic Zones
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:
route for 0.0.0.0 0.0.0.0 through outside1 to 10.1.1.2

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.
About Route Maps

Route maps are used when redistributing routes into an OSPF, RIP, EIGRP or BGP routing process. They are
also used when generating a default route into an OSPF 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.
Route maps have many features in common with widely known ACLs. These are some of the traits common
to both:
• They are an ordered sequence of individual statements, and each has a permit or deny result. Evaluation
of an ACL or a route map consists of a list scan, in a predetermined order, and an evaluation of the criteria
of each statement that matches. A list scan is aborted once the first statement match is found and an
action associated with the statement match is performed.
• They are generic mechanisms. Criteria matches and match interpretation are dictated by the way that
they are applied and the feature that uses them. The same route map applied to different features might
be interpreted differently.
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.

1000
Permit and Deny Clauses
Permit and Deny Clauses

Route maps can have permit and deny clauses. The deny clause rejects route matches from redistribution.
You can use an ACL as the matching criterion in the route map. Because ACLs also have permit and deny
clauses, the following rules apply when a packet matches the ACL:
• ACL permit + route map permit: routes are redistributed.
• ACL permit + route map deny: routes are not redistributed.
• ACL deny + route map permit or deny: the route map clause is not matched, and the next route-map
clause is evaluated.
Match and Set Clause Values

Each route map clause has two types of values:
• A match value selects routes to which this clause should be applied.
• A set value modifies information that will be redistributed into the target protocol.
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).

1001
Match and Set Clause Values

1002
CHAPTER 38
Virtual Routing for Firepower Threat Defense
This chapter describes underlying concepts about virtual routers and on how virtual routing behaves within
the Firepower Threat Defense.
• About Virtual Routers and Virtual Routing and Forwarding (VRF), on page 1003
• Maximum Number of Virtual Routers By Device Model, on page 1008
• Requirements and Prerequisites for Virtual Routers, on page 1009
• Guidelines and Limitations for Virtual Routers, on page 1009
• Modifications to FMC Web Interface - Routing Page, on page 1011
• Manage Virtual Routers Page, on page 1011
• Create a Virtual Router, on page 1011
• Configuration Examples for Virtual Routers, on page 1015
• History for Virtual Routers in Firepower Threat Defense, on page 1045
About Virtual Routers and Virtual Routing and Forwarding (VRF)

You can create multiple virtual routers to maintain separate routing tables for groups of interfaces. Because
each virtual router has its own routing table, you can provide clean separation in the traffic flowing through
the device.
Thus, you can provide support to two or more distinct customers over a common set of networking equipment.
You can also use virtual routers to provide more separation for elements of your own network, for example,
by isolating a development network from your general purpose corporate network.
Virtual routers implement the “light” version of Virtual Routing and Forwarding, or VRF-Lite, which does
not support Multiprotocol Extensions for BGP (MBGP).
When you create a virtual router, you assign interfaces to the router. You can assign a given interface to one,
and only one, virtual router. You would then define static routes, and configure routing protocols such as
OSPF or BGP, for each virtual router. You would also configure separate routing processes over your entire
network, so that routing tables on all participating devices are using the same per-virtual-router routing process
and tables. Using virtual routers, you create logically-separated networks over the same physical network to
ensure the privacy of the traffic that runs through each virtual router.
Because the routing tables are separate, you can use the same, or overlapping, address spaces across the virtual
routers. For example, you could use the 192.168.1.0/24 address space for two separate virtual routers, supported
by two separate physical interfaces.

1003
Applications of Virtual Routers
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.
Applications of Virtual Routers

You can use virtual routers to isolate network on shared resources and/or to isolate networks with common
security policy. Thus, virtual routers help you to achieve:
• Traffic separation for customers through dedicated routing tables for each customer or for different
departments.
• Common security policy management for different departments or networks.
• Shared internet access for different departments or network.
Global and User-Defined Virtual Routers

Global Virtual Routers
For a device with virtual routing capability, system creates a global virtual router by default. The system
assigns all interfaces in your network to the global virtual router. A routed interface can belong to either a
user-defined virtual router or a global virtual router. When you upgrade an FTD device to a version which
has virtual router capability, all its existing routing configuration becomes part of the global virtual router.
User-Defined Virtual Routers

A user-defined virtual router is the one defined by you. You can create more than one virtual router on a
device. However, anytime, an interface can be assigned to only one user-defined virtual router. While some
of the device features are supported on user-defined virtual routers, few of the features are supported only on
the global virtual routers.
Supported Features and Monitoring Policies

You can configure the following features on the global virtual router only:
• OSPFv3
• RIP
• EIGRP
• IS-IS
• BGPv6
• Multicast Routing
• Policy Based Routing (PBR)
• VPN
EIGRP, ISIS, and PBR are supported through Flex Config in FMC (see Predefined FlexConfig Objects, on
page 1288). Configure only global virtual router interfaces for these features.

1004
Configuring Policies to be Virtual-Router-Aware
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)
• SNMP
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.
Configuring Policies to be Virtual-Router-Aware

When you create a virtual router, the routing table for that virtual router is automatically separated from the
global virtual router or any other virtual router. However, security policies are not automatically
virtual-router-aware.
For example, if you write an access control rule that applies to “any” source or destination security zone, then
the rule will apply to all interfaces across all virtual routers. This might in fact be exactly what you want. For
example, all of your customers might want to block access to the same list of objectionable URL categories.
But, if you need to apply a policy to one of the virtual routers but not others, you need to create security zones
that contain interfaces from that single virtual router only. Then, use the virtual-router-constrained security
zones in the source and destination criteria of the security policy.
By using security zones whose memberships are constrained to the interfaces assigned to a single virtual
router, you can write virtual-router-aware rules in the following policies:
• Access control policy.
• Intrusion and file policies.
• SSL decryption policy.
• Identity policy and user-to-IP address mappings. If you use overlapping address spaces in virtual routers,
ensure that you create separate realms for each virtual router and apply them correctly in the identity
policy rules.

1005
Interconnecting Virtual Routers
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.
Interconnecting Virtual Routers

You can configure static routes to route traffic between virtual routers.
For example, if you have the outside interface in the global virtual router, you can set up static default routes
in each of the other virtual routers to send traffic to the outside interface. Then, any traffic that cannot be
routed within a given virtual router gets sent to the global router for subsequent routing.
Static routes between virtual routers are known as route leaks, because you are leaking traffic to a different
virtual router. When you are leaking routes, say, VR1 routes to VR2, you can initiate connections from VR2
to VR1 only. For traffic to flow from VR1 to VR2, you must configure the reverse route. When you create a
static route to an interface in another virtual router, you do not need to specify a gateway address. Simply
select the destination interface.
For inter-virtual-router routes, the system does destination interface look-up in the source virtual router. Then,
it looks up the MAC address of the next hop in the destination virtual router. Thus, the destination virtual
router must have either a dynamic (learned) or static route for the selected interface for the destination address.
Configuring NAT rules that use source and destination interfaces in different virtual routers can also allow
traffic to route between virtual routers. If you do not select the option for NAT to do a route lookup, the rule
will simply send traffic out the destination interface with a NATed address whenever destination translation
happens. However, the destination virtual router should have a route for the translated destination IP address
so that next-hop lookup can succeed.
Though NAT rule leaks traffic from one virtual router to another, to ensure correct routing, we recommend
that you configure a static route leak between these virtual routers for the translated traffic. Without the route
leak, sometimes the rule may not match the traffic you expect it to match, and the translation may not be
applied.
Virtual routing does not support a cascading or chain of route leaks. For example, assume that your FTD has
VR1, VR2, and VR3 virtual routers; VR3 is directly connected to a network - 10.1.1.0/24. Now, assume you
configure a route leak in VR1 for network 10.1.1.0/24 through interface in VR2 and in VR2 define a route
leak for 10.1.1.0/24 through VR3. This chain of route leaks will not allow traffic to hop from VR1 to VR2
and then exit from VR3. In case of route leaks, the route lookups first determine egress interface from input
Virtual Router’s routing table and then looks at the output of Virtual Router’s routing table for next hop
lookup. From both the lookups, egress interface should match. In our example, the egress interfaces will not
be the same and hence the traffic does not pass through.
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.

1006
Configuring SNMP on User-Defined Virtual Routers
Limitations with Overlapping IP Addresses

When using an overlapping IP address in multiple virtual routers, to ensure proper application of the policy,
you have to modify policies or rules for some of the features. Such features require you to use more specific
interface either by splitting existing security zone or using new interface group as the need be.
Following features need modification for its proper functioning with an overlapping IP address:
• Network Map—Modify the network discovery policy to exclude some overlapping IP segments to ensure
that there is no overlapping IP address being mapped.
• Identity Policy—The identity feed source cannot differentiate among virtual routers; to overcome this
limitation, map overlapping address spaces or virtual routers in different realms.
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
Unsupported Features with Overlapping IP Addresses

• ISE SGT-based Rule in AC Policy—The static security group tag (SGT) to IP address mappings
downloaded from Cisco Identity Services Engine (ISE) are not virtual-router-aware. Set up separate ISE
systems per virtual router if you need to create different SGT mappings per virtual router. This is not
necessary if you intend to map the same IP addresses to the same SGT number in each virtual router.
• Overlapping DHCP server pools are not supported across virtual routers.
• Events and Analytics—Many of the FMC analytics are dependent on network map and identity mappings
which cannot differentiate if the same IP address belongs to two different end hosts. Hence, these analytics
are not accurate when there are overlapping IP segments existing in same device but different virtual
routers.
Configuring SNMP on User-Defined Virtual Routers

In addition to supporting SNMP on the management interface and Global virtual router data interfaces,
Firepower Threat Defense now allows you to configure SNMP host on user-defined virtual routers.
Configuring an SNMP host on user-defined virtual routers includes the following process:
1. Enable the Physical Interface and Configure Ethernet Settings
2. Create a Virtual Router
3. Add SNMP Hosts
Note SNMP is not virtual router-aware. Hence, while configuring SNMP server on the user-defined virtual router,
ensure that the network address is not an Overlapping IP Addresses.

1007
Maximum Number of Virtual Routers By Device Model
4. Deploy Configuration Changes. On successful deployment, the-SNMP polling and traps are sent to the
Network Management Station through the virtual router interface.
Maximum Number of Virtual Routers By Device Model

The maximum number of virtual routers you can create depends on the device model. The following table
provides the maximum limits. You can double-check on your system by entering the show vrf counters
command, which shows the maximum number of user-defined virtual routers for that platform not including
the global virtual router. The numbers in the table below include user and global routers. For the Firepower
4100/9300, these numbers apply to native mode.
For platforms that support multi-instance capability, such as the Firepower 4100/9300, determine the maximum
number of virtual routers per container instance by dividing the maximum virtual routers by the number of
cores on the device, and then multiplying by the number of cores assigned to the instance, rounding down to
the nearest whole number. For example, if the platform supports a maximum of 100 virtual routers, and it has
70 cores, then each core would support a maximum of 1.43 virtual routers (rounded). Thus, an instance
assigned 6 cores would support 8.58 virtual routers, which rounds down to 8, and an instance assigned 10
cores would support 14.3 virtual routers (rounding down, 14).
Device Model Maximum Virtual Routers
ASA 5508-X 10
ASA 5516-X
Firepower 1010 Virtual routers are not supported on this model.
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
Firepower 4125 100
Firepower 4140 100
Firepower 4145 100

1008
Requirements and Prerequisites for Virtual Routers
Device Model Maximum Virtual Routers
Firepower 4150 100
Firepower 9300 appliance, all 100

models
Firepower Threat Defense Virtual, 30

all platforms
ISA 3000 10
Related Topics
Requirements and Prerequisites for Container Instances, on page 783
Requirements and Prerequisites for Virtual Routers

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Network Admin
Security Approver
Guidelines and Limitations for Virtual Routers

Firewall Mode Guidelines
Virtual routers are supported on routed firewall mode only.
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.
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.

1009
Guidelines and Limitations for Virtual Routers
• 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.
Global Virtual Router Guidelines

• The interfaces which are named and not part of other virtual routers, are part of the global virtual router.
• You cannot remove routed interfaces from global virtual router.
• You cannot modify global virtual router.
• Generally, after configuring interfaces, if you un-register and register back to same or another FMC,
interface configuration is imported back from device. With virtual router support, there is a restriction—the
IP address for only global virtual router interfaces is retained.
• 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.
• DHCP Relay—Interconnecting virtual routers for DHCP relay is not supported. For example, if DHCP
client is enabled on VR1 interface and DHCP relay server is enabled on VR2 interface, interconnecting
VR1 and VR2 results in DHCP forwards within the virtual routers.
• Recreating a deleted virtual router—When you recreate a virtual router that was deleted less than 10
seconds earlier, an error message appears stating that deletion of the virtual router is in progress. If you
want to recreate a deleted virtual router successively, use a different name for the new virtual router.

1010
Modifications to FMC Web Interface - Routing Page
Modifications to FMC Web Interface - Routing Page

Devices earlier to FTD 6.6 and few device models are not supported with virtual routing capability. The FMC
web interface displays the same Routing page of FMC 6.5 or earlier version for such nonsupported devices.
To know the supported devices and platform for virtual routing, see Maximum Number of Virtual Routers
By Device Model.
You can configure virtual routers in the routing page of a supported device:
1. Navigate to Devices > Device Management and edit the virtual-router-aware device.
2. Click Routing to enter the virtual routers page.
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 .
Manage Virtual Routers Page

When you click Manage Virtual Routers on the Virtual Routers pane, the Manage Virtual Routers page
appears. This page displays the existing virtual routers on the device and the associated interfaces. In this
page, you can Add Virtual Router ( ) to the device. You can also Edit ( ) and Delete ( ) user-defined
virtual routers. You cannot edit or remove a global virtual router. You can only View ( ) the details of a
global virtual router.
Create a Virtual Router

Procedure
Step 2 Click Routing.
Step 3 Click Manage Virtual Routers.
Step 4 Click Add Virtual Router ( ).

Step 5 In the Add Virtual Router box, enter a name and description for the virtual router.
Note If you are creating a virtual router that was deleted less than 10 seconds earlier, an error message
appears stating that deletion of the virtual router is in progress. If you want to create a deleted virtual
router successively, use a different name for the new virtual router.

1011
Configure a Virtual Router
Step 6 Click Ok.

The Routing page appears, displaying the newly created virtual router page.
What to do next
• Configure a Virtual Router.
Configure a Virtual Router

Smart Classic Supported Supported Access
License License Devices Domains
Any N/A FTD and FTDv Any Admin/Network Admin/Security
Approver
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.
Before you begin

• To configure routing policies for a user-defined virtual router, add a router. See Create a Virtual Router,
on page 1011.
• All routing configuration settings of a non-VRF capable device are also available for a global virtual
router. For information on the settings, see Routing Overview for Firepower Threat Defense.
• Only limited routing protocols are supported for a user-defined virtual router.
Procedure
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 1011.
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.
Step 5 To save the settings, click Save.

1012
Modify a Virtual Router
Step 6 To configure the routing policy for the virtual router, click the respective names to open the corresponding
settings page:
• OSPF—Only OSPFv2 is supported on the user-defined virtual router. All other settings for OSPFv2 are
as applicable as for a non-virtual-router-aware interface, except that Interface allows you to select only
the interfaces of the virtual router that you are configuring. You can define the OSPFv3 and OSPFv2
routing policies for a global virtual router. For information on the OSPF settings, see OSPF for Firepower
Threat Defense, on page 1053.
• RIP—You can configure RIP routing policies only for a global virtual router. For information on RIP
settings, see RIP for Firepower Threat Defense, on page 1097.
• BGP—This page displays the BGP general settings that you have configured in Settings:
• You cannot modify any of those general settings on this page, except for the router ID settings. You
can override the router ID settings that were defined in the Settings page by editing them on this
page.
• To configure other BGP IPv4 or IPv6 settings, you must enable the BGP option in BGP page under
General Settings.
• Only BGP configuration with an IPv4 address family is supported for a user-defined virtual router.
For information on configuring BGP settings, see BGP for Firepower Threat Defense, on page 1081.
• 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 1047.
• 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 1103.
Step 7 To save the settings, click Save.
What to do next
• Modify a Virtual Router.
• Remove Virtual Routers.
Modify a Virtual Router

You can modify the description and other routing policies of a virtual router.

1013
Remove Virtual Routers
Procedure
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.
Step 5 To save the changes, click Save.
What to do next
• Remove Virtual Routers.
Remove Virtual Routers

Before you begin
• You cannot delete the Global virtual router. Hence, the delete option is not available for the Global virtual
router.
• You can remove multiple virtual routers at a time.
• All the routing policies of the deleted virtual router are also deleted.
• All the interfaces of the deleted virtual router move to the global virtual router.
• If there are any restrictions on the movement of interfaces, such as overlapping IPs, route conflicts, and
so on, you can remove the router only after resolving the conflicts.
Procedure
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 remove multiple routers, holding the CTRL key, click the virtual routers that you want to delete. Right-click,
and then click Delete.

1014
Configuration Examples for Virtual Routers
Step 6 To save the changes, click Save.
Configuration Examples for Virtual Routers

How to Route to a Distant Server through Virtual Routers
In virtual routing, you can create multiple virtual routers to maintain separate routing tables for groups of
interfaces, thereby achieve network separation. In some scenarios, you may need to access a server that is
reachable only through a separate virtual router. This example provides the procedure that interconnects virtual
routers to reach to a host that is multiple hops away.
Consider an example, where a member of the sales department of a garment company wants to look up at the
stock maintained by the warehousing department of its factory unit. In a virtual routing environment, you
need to leak route between virtual routers where destination (warehousing department) is multiple hops away
from sales department. This route leaking is done by adding multihop route leak, where, you configure a static
route in Sales virtual router(source) to an interface in Warehouse virtual router (destination). As the destination
network is multi-hop away, you also need to configure the Warehouse virtual router with the route to the
destination network, namely 10.50.0.0/24.
Figure 36: Interconnecting Two Virtual Routers - An Example
Before you begin

This example assumes that you have already configured Sales_Router1 to route traffic from 10.20.0.1/30
interface to 10.50.0.5/24.

1015
Procedure
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:
b) Edit the Gi0/2 interface:
• Name—For this example, VR-Warehouse.
• IP Address—Leave it blank. The system does not allow you to configure interfaces with same IP
address (10.30.0.1/24), as you are yet to create user-defined virtual routers.
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:
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.

1016
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:
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.

1017
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.

1018
How to Provide Internet Access with Overlapping Address Spaces
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:

When using virtual routers, you can have the same network address for interfaces that reside in separate
routers. However, because the IP addresses routed in these separate virtual routers are the same, apply NAT/PAT
rules for each interface with separate NAT/PAT pools to ensure that return traffic goes to the correct destination.
This example provides the procedure to configure the virtual routers and NAT/PAT rules to manage the
overlapping address spaces.
For example, interfaces vr1-inside and vr2-inside on FTD is defined to use the IP address 192.168.1.1/24,
managing endpoints on their segment in the 192.168.1.0/24 network. To allow Internet access from two virtual
routers that use the same address space, you need to apply NAT rules separately to the interfaces within each
virtual router, ideally using separate NAT or PAT pools. You could use PAT to translate the source addresses
in VR1 to 10.100.10.1, and for those in VR2, to 10.100.10.2. The following illustration shows this setup,
where the Internet-facing outside interface is part of the global router. You must define the NAT/PAT rules
with the source interface (vr1-inside and vr2-inside) explicitly selected—using “any” as the source interface
makes it impossible for the system to identify the correct source because the same IP address could exist on
two different interfaces.
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.

1019
Procedure
Step 1 Configure the inside interface of the device for VR1:

b) Edit the interfaces that you want to assign to VR1:
• Name—For this example, vr1-inside.
c) Click Ok.
d) Click Save.
Step 2 Configure the inside interface of the device for VR2:
b) Edit the interfaces that you want to assign to VR2:
• Name—For this example, vr2-inside.
• IP Address—Leave it blank. The system does not allow you to configure interfaces with same IP
address, as you are yet to create user-defined virtual routers.
c) Click Ok.
d) Click Save.
Step 3 Configure VR1 and the static default route leak to the outside interface:
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.

1020
f) Click Ok.
g) Click Save.
Step 4 Configure VR2 and the static default route leak to the outside interface:
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.
• 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.

1021
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:
b) Choose Routing and edit global router properties.
c) Click Static Route.
• 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.

1022
e) Click Ok.
f) Click Save.
Step 6 Revisit the vr2-inside interface configuration:
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.

1023
• 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:
• 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:

1024
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:

1025
How to Allow RA VPN Access to Internal Networks in Virtual Routing

On virtual routing-enabled devices, RA VPN is supported only on global virtual router interfaces. This example
provides the procedure that allows your AnyConnect client user to connect to user-defined virtual router
networks.
In the following example, the RA VPN (AnyConnect client) user connects to the outside interface of FTD at
172.16.3.1, and is given an IP address within the pool of 192.168.80.0/24. The user can access the inside
network of only the global virtual router. To allow traffic flow through the network of the user-defined virtual
router VR1, namely 192.168.1.0/24, leak the route by configuring the static routes on global and VR1.

1026
Before you begin

This example assumes that you have already configured the RA VPN, defined the virtual routers, and configured
and assigned the interfaces to the appropriate virtual routers.
Procedure
Step 1 Configure route leak from Global virtual router to the user-defined VR1:
b) Click Routing. By default, the Global routing properties page appears.
• 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.

1027
Step 2 Configure the route leak from VR1 to the Global virtual router:
b) Click Routing and from the drop-down, select VR1.
• Network—Select the global virtual router network object.
• Gateway—Leave it blank. When leaking a route into another virtual router, does not select the
gateway.
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.

1028
How to Secure Traffic from Networks in Multiple Virtual Routers over a Site-to-Site VPN
How to Secure Traffic from Networks in Multiple Virtual Routers over a

Site-to-Site VPN
On virtual routing-enabled devices, Site-to-Site VPN is supported only on global virtual router interfaces.
You cannot configure it on an interface that belongs to a user-defined virtual router. This example provides
the procedure that allows you to secure the connections from or to networks hosted within user-defined virtual
routers over the site-to-site VPN. You also need to update the site-to-site VPN connection to include the
user-defined virtual routing networks.
Let us consider a scenario, where, a site-to-site VPN is configured between a branch office network to a
company headquaters network; the FTD in the branch office having virtual routers. In this case, the site-to-site
VPN is defined on the outside interface of the branch office at 172.16.3.1. This VPN includes the inside
network 192.168.2.0/24 without extra configuration, because the inside interface is also part of the global
virtual router. But, to provide site-to-site VPN services to the 192.168.1.0/24 network, which is part of the
VR1 virtual router, you must leak the route by configuring the static routes on global and VR1, and add the
VR1 network to the site-to-site VPN configuration.
Before you begin

This example assumes that you have already configured the site-to-site VPN between the 192.168.2.0/24 local
network and the 172.16.20.0/24 external network, defined the virtual routers, and configured and assigned
the interfaces to the appropriate virtual routers.
Procedure
Step 1 Configure route leak from the Global virtual router to the user-defined VR1:
b) Click Routing. By default, the Global routing properties page appears.
• Interface—Select the VR1 inside interface.
• Network—Select the VR1 virtual router network object. You can create one using the Add Object
option.

1029
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:
b) Click Routing and from the drop-down, select VR1.
• Network—Select the global virtual router network object.

1030
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:

1031
How to Route Traffic between Two Overlapping Network Host in Virtual Routing
e) Click Ok and save the configuration.
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.
Before you begin

This example assumes that you have already configured:

1032
• 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.
Procedure
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:
• 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:

1033
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
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 5 Click Ok.

Step 6 Click Save.
The NAT rule looks like this:
When you deploy the configuration, a warning message appears:

1034
How to Manage Overlapping Segments in Routed Firewall Mode with BVI Interfaces
How to Manage Overlapping Segments in Routed Firewall Mode with BVI

Interfaces
You can deploy single FTD between multiple overlapping networks transparently and/or deploy the firewall
between the hosts of same network. To achieve this deployment, configure BVI per virtual router. The
procedure to configure the BVIs in virtual router is explained here.
BVI is a virtual interface within a router that acts like a normal routed interface. It does not support bridging,
but represents the comparable bridge group to routed interfaces within the router. All the packets coming in
or going out of these bridged interfaces, pass through the BVI interface. The interface number of the BVI is
the number of the bridge group that the virtual interface represents.
In the following example, BVI-G is configured in VRG and Bridge Group 1 is the routed interface for interfaces
G0/1 and G0/2. Similarly, BVI-B is configured in VRB and Bridge Group 2 is the routed interface for interfaces
G0/3 and G0/4. Consider that both BVIs have the same IP subnet address, say 10.10.10.5/24. Because of
virtual routers, the network is isolated on the shared resources.

1035
Procedure
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.

1036
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.
• 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.

1037
b) Click Ok.
c) Click Save.
Step 3 Create virtual router, say VRG, and select BVI-G as its network:
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:
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.

1038
How to Configure User Authentication with Overlapping Networks
d) In Virtual Routing Properties, select BVI-B and click Add.
e) Click Save.
Step 5 Revisit the BVI-B configuration:
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.

In virtual routing, you can configure multiple virtual routers with overlapping IP and overlapping users. In
the example, VRG, and VRB are the virtual routers with overlapping IP - 192.168.1.1/24. The users on two
different domains are also on overlapping network IP 192.168.1.20. For VRG and VRB users to access the
shared server 172.16.10.X, leak routes to the global virtual router. Use source NAT to handle the overlapping
IP. For controlling the access from VRG and VRB users, you must set user authentication in FMC. FMC uses
realms, Active Directories, Identity source, and Identity rules and policies for authenticating user identity.
Because FTD does not have direct role in authenticating users, user access is managed only through the access
control policy. For controlling traffic from the overlapping users, use Identity policy and rules to create access
control policy.

1039
Before you begin

This example assumes that you have:
• Two AD servers for the VRG and VRB users.
• ISE with the two AD servers added.
Procedure
Step 1 Configure the inside interface of the device for VRG:

b) Edit the interfaces that you want to assign to VRG:
• Name—For this example, VRG-inside.
c) Click Ok.
d) Click Save.
Step 2 Configure the inside interface of the device for VRB:
b) Edit the interfaces that you want to assign to VRB:
• Name—For this example, VRB-inside.

1040

• 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:
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.

• Interface—Select the inside interface of the global router.
• Network—Select the any-ipv4 object.
• Gateway—Leave it blank. When leaking a route into another virtual router, do not select a gateway.
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:
b) Choose Routing > Manage Virtual Routers. Click Add Virtual Router and create VRB.

1041
c) For VRB, in Virtual Router Properties, assign VRB-inside and save.

• Interface—Select the inside interface of the global router.
• Network—Select the any-ipv4 object.
• Gateway—Leave it blank. When leaking a route into another virtual router, do not select a gateway.
f) Click Ok.
g) Click Save.
Step 5 Revisit the VRB-inside interface configuration:
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:

1042
• 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.
• 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 10 Click Ok.

Step 11 In the NAT page, click Add Rule and define the following source NAT for VRB:
• Click Enabled.

1043
• In Interface Objects, select VRB-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.
• Original Source, select VRB-Users.
• Translated Source, click Add and define object, VRB-NAT with 20.1.1.1. Select VRB-NAT as
shown in the following figure:
Step 12 Click Save.

The NAT rule looks like this:

1044
History for Virtual Routers in Firepower Threat Defense
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
2420.
Step 15 For controlling the access from VRG and VRB users, define 2 Active Directories, see Realm Directory and
Synchronize fields, on page 2423.
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 2453.
Step 18 Create Identity policy, rules, and then define access control policy for controlling access of overlapping users
from VRG and VRB.

Virtual router support for the 7.0 You can configure up to 10 virtual routers on an ISA 3000 device.
ISA 3000
New/modified screens: None
Virtual routers for Snort 3 7.0 Snort3 enabled devices now support virtual router features. Hence, you do not have to
enabled devices remove Snort 2 device from virtual routers before proceeding to switch to a Snort3
engine.
SNMP support on user-defined 7.0 Firepower Threat Defense now supports configuring SNMP on user-defined virtual
virtual routers routers.

1045
Bulk removal of virtual routers 6.7 You can remove multiple virtual routers from Firepower Threat Defense at a time.
New/modified screens: Devices > Device Management > Routing > Manage Virtual
Routers page.
Virtual Routers for Firepower 6.6 Virtual routers for Firepower Threat Defense were introduced.
Threat Defense
New/modified screens: Virtual routers can be created and Threat Defense interfaces
can be assigned to the virtual routers in the Devices > Device Management > Routing
page.

1046
CHAPTER 39
Static and Default Routes for Firepower Threat
Defense
This chapter describes how to configure static and default routes on the FTD.
• About Static and Default Routes, on page 1047
• Requirements and Prerequisites for Static Routes, on page 1049
• Guidelines for Static and Default Routes, on page 1050
• Add a Static Route, on page 1050
About Static and Default Routes

To route traffic to a non-connected host or network, you must define a route to the host or network, either
using static or dynamic routing. Generally, you must configure at least one static route: a default route for all
traffic that is not routed by other means to a default network gateway, typically the next hop router.
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-only or data routing table by default depending on the
type (see Routing Table for Management Traffic, on page 999), 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. The Diagnostic interface is included in the management-only table. The special
Management interface uses a separate Linux routing table, and has its own default route. See the configure
network commands.

1047
Static Routes
Static Routes
You might want to use static routes in the following cases:
• Your networks use an unsupported router discovery protocol.
• Your network is small and you can easily manage static routes.
• You do not want the traffic or CPU overhead associated with routing protocols.
• In some cases, a default route is not enough. The default gateway might not be able to reach the destination
network, so you must also configure more specific static routes. For example, if the default gateway is
outside, then the default route cannot direct traffic to any inside networks that are not directly connected
to the FTD device.
• You are using a feature that does not support dynamic routing protocols.
• Virtual routers use static routes to create route leaks. Route leaks enable flow of traffic from an interface
of a virtual router to another interface in another virtual router. For more information, see Interconnecting
Virtual Routers, on page 1006.
Route to null0 Interface to Drop Unwanted Traffic

Access rules let you filter packets based on the information contained in their headers. A static route to the
null0 interface is a complementary solution to access rules. You can use a null0 route to forward unwanted
or undesirable traffic so the traffic is dropped.
Static null0 routes have a favorable performance profile. You can also use static null0 routes to prevent routing
loops. BGP can leverage the static null0 route for Remotely Triggered Black Hole routing.
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 999.
• For traffic emerging from a tunnel with the Tunneled option, this route overrides any other configured
or learned default routes.
Transparent Firewall Mode and Bridge Group Routes

For traffic that originates on the Firepower Threat Defense device and is destined through a bridge group
member interface for a non-directly connected network, you need to configure either a default route or static
routes so the Firepower Threat Defense device knows out of which bridge group member interface to send
traffic. Traffic that originates on the Firepower Threat Defense device might include communications to a
syslog server or SNMP server. If you have servers that cannot all be reached through a single default route,
then you must configure static routes. For transparent mode, you cannot specify the BVI as the gateway

1048
Static Route Tracking
interface; only member interfaces can be used. For bridge groups in routed mode, you must specify the BVI
in a static route; you cannot specify a member interface. See #unique_1376 for more information.
Static Route Tracking

One of the problems with static routes is that there is no inherent mechanism for determining if the route is
up or down. They remain in the routing table even if the next hop gateway becomes unavailable. Static routes
are only removed from the routing table if the associated interface on the Firepower Threat Defense device
goes down.
The static route tracking feature provides a method for tracking the availability of a static route and installing
a backup route if the primary route should fail. For example, you can define a default route to an ISP gateway
and a backup default route to a secondary ISP in case the primary ISP becomes unavailable.
The Firepower Threat Defense device implements static route tracking by associating a static route with a
monitoring target host on the destination network that the Firepower Threat Defense device monitors using
ICMP echo requests. If an echo reply is not received within a specified time period, the host is considered
down, and the associated route is removed from the routing table. An untracked backup route with a higher
metric is used in place of the removed route.
When selecting a monitoring target, you need to make sure that it can respond to ICMP echo requests. The
target can be any network object that you choose, but you should consider using the following:
• The ISP gateway (for dual ISP support) address
• The next hop gateway address (if you are concerned about the availability of the gateway)
• A server on the target network, such as a syslog server, that the Firepower Threat Defense device needs
to communicate with
• A persistent network object on the destination network
Note A PC that may be shut down at night is not a good choice.
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.
Requirements and Prerequisites for Static Routes

Model Support
FTD
Supported Domains
Any
User Roles
Admin

1049
Guidelines for Static and Default Routes
Network Admin
Guidelines for Static and Default Routes

Firewall Mode and Bridge Groups
• In transparent mode, static routes must use the bridge group member interface as the gateway; you cannot
specify the BVI.
• In routed mode, you must specify the BVI as the gateway; you cannot specify the member interface.
• Static route tracking is not supported for bridge group member interfaces or on the BVI.
IPv6
• Static route tracking is not supported for IPv6.
Clustering and Multiple Context Mode

• In clustering, static route tracking is only supported on the primary unit.
• Static route tracking is not supported in multiple context mode.
Network Object Group

You cannot use a range of network objects or a network object group having a range of IP addresses while
configuring a static route.
Add a Static Route

A static route defines where to send traffic for specific destination networks. You should at a minimum define
a default route. A default route is simply a static route with 0.0.0.0/0 as the destination IP address.
Procedure
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.

1050
Add a Static Route
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 1006.
Step 8 In the Available Network list, choose the destination network.

To define a default route, create an object with the address 0.0.0.0/0 and select it here.
Note Though you can create and choose a Network Object Group containing a range of IP addresses,
FMC does not support using range of network objects while configuring a static route.
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 679.
Step 13 Click Ok.

1051
Add a Static Route

1052
CHAPTER 40
OSPF for Firepower Threat Defense
This chapter describes how to configure the FTD to route data, perform authentication, and redistribute routing
information using the Open Shortest Path First (OSPF) routing protocol.
• OSPF for Firepower Threat Defense, on page 1053
• Requirements and Prerequisites for OSPF, on page 1056
• Guidelines for OSPF, on page 1056
• Configure OSPFv2, on page 1058
• Configure OSPFv3, on page 1070
OSPF for Firepower Threat Defense

information using the Open Shortest Path First (OSPF) routing protocol.
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

1053
About OSPF
(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.

1054
OSPF Support for Fast Hello Packets
OSPF Support for Fast Hello Packets

The OSPF Support for Fast Hello Packets feature provides a way to configure the sending of hello packets in
intervals less than one second. Such a configuration would result in faster convergence in an Open Shortest
Path First (OSPF) network.
Prerequisites for OSPF Support for Fast Hello Packets

OSPF must be configured in the network already or configured at the same time as the OSPF Support for Fast
Hello Packets feature.
OSPF Hello Interval and Dead Interval

OSPF hello packets are packets that an OSPF process sends to its OSPF neighbors to maintain connectivity
with those neighbors. The hello packets are sent at a configurable interval (in seconds). The defaults are 10
seconds for an Ethernet link and 30 seconds for a non broadcast link. Hello packets include a list of all neighbors
for which a hello packet has been received within the dead interval. The dead interval is also a configurable
interval (in seconds), and defaults to four times the value of the hello interval. The value of all hello intervals
must be the same within a network. Likewise, the value of all dead intervals must be the same within a network.
These two intervals work together to maintain connectivity by indicating that the link is operational. If a router
does not receive a hello packet from a neighbor within the dead interval, it will declare that neighbor to be
down.
OSPF Fast Hello Packets

OSPF fast hello packets refer to hello packets being sent at intervals of less than 1 second. To understand fast
hello packets, you should already understand the relationship between OSPF hello packets and the dead
interval. See OSPF Hello Interval and Dead Interval, on page 1055.
OSPF fast hello packets are achieved by using the ospf dead-interval command. The dead interval is set to 1
second, and the hello-multiplier value is set to the number of hello packets you want sent during that 1 second,
thus providing subsecond or "fast" hello packets.
When fast hello packets are configured on the interface, the hello interval advertised in the hello packets that
are sent out this interface is set to 0. The hello interval in the hello packets received over this interface is
ignored.
The dead interval must be consistent on a segment, whether it is set to 1 second (for fast hello packets) or set
to any other value. The hello multiplier need not be the same for the entire segment as long as at least one
hello packet is sent within the dead interval.
Benefits of OSPF Fast Hello Packets

The benefit of the OSPF Fast Hello Packets feature is that your OSPF network will experience faster
convergence time than it would without fast hello packets. This feature allows you to detect lost neighbors
within 1 second. It is especially useful in LAN segments, where neighbor loss might not be detected by the
Open System Interconnection (OSI) physical layer and data-link layer.

1055
Implementation Differences Between OSPFv2 and OSPFv3
Implementation Differences Between OSPFv2 and OSPFv3

OSPFv3 is not backward compatible with OSPFv2. To use OSPF to route both IPv4 and IPv6 traffic, you
must run both OSPFv2 and OSPFv3 at the same time. They coexist with each other, but do not interact with
each other.
The additional features that OSPFv3 provides include the following:
• Protocol processing per link.
• Removal of addressing semantics.
• Addition of flooding scope.
• Support for multiple instances per link.
• Use of the IPv6 link-local address for neighbor discovery and other features.
• LSAs expressed as prefix and prefix length.
• Addition of two LSA types.
• Handling of unknown LSA types.
• Authentication support using the IPsec ESP standard for OSPFv3 routing protocol traffic, as specified
by RFC-4552.
Requirements and Prerequisites for OSPF

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Network Admin
Guidelines for OSPF

OSPF supports routed firewall mode only. OSPF does not support transparent firewall mode.
High Availability Guidelines

OSPFv2 and OSPFv3 support Stateful High Availability.

1056
Guidelines for OSPF
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.
OSPFv3 Hello Packets and GRE

Typically, OSPF traffic does not pass through GRE tunnel. When OSPFv3 on IPv6 is encapsulated inside
GRE, the IPv6 header validation for security check such as Multicast Destination fails. The packet is dropped
due to the implicit security check validation, as this packet has destination IPv6 multicast.
You may define a pre-filter rule to bypass GRE traffic. However, with pre-filter rule, inner packets would not
be interrogated by the inspection engine.
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.
Multiprotocol Label Switching (MPLS) and OSPF Guidelines

When a MPLS-configured router sends Link State (LS) update packets containing opaque Type-10 link-state
advertisements (LSAs) that include an MPLS header, authentication fails and the appliance silently drops the
update packets, rather than acknowledging them. Eventually the peer router will terminate the neighbor
relationship because it has not received any acknowledgments.
Make sure that non-stop forwarding (NSF) is disabled on the appliance to ensure that the neighbor relationship
remains stable:
• Navigate to the Non Stop Forwarding page in Firepower Management Center (Devices > Device
Management (select the desired device) > Routing > OSPF > Advanced > Non Stop Forwarding).
Ensure the Non Stop Forwarding Capability boxes are not checked.
Route Redistribution Guidelines

Redistribution of route maps with IPv4 or IPv6 prefix list on OSPFv2 or OSPFv3 is not supported. Use
connected routes on OSPF for redistribution.

1057
Configure OSPFv2
• 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.
• To avoid adjacency flaps due to route updates being dropped if the route update is larger than the minimum
MTU on the link, ensure that you configure the same MTU on the interfaces on both sides of the link.
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.
Configure OSPF Areas, Ranges, and Virtual Links

You can configure several OSPF area parameters, which include setting authentication, defining stub areas,
and assigning specific costs to the default summary route. You can enable up to two OSPF process instances.
Each OSPF process has its own associated areas and networks. Authentication provides password-based
protection against unauthorized access to an area.
Stub areas are areas into which information on external routes is not sent. Instead, there is a default external
route generated by the ABR into the stub area for destinations outside the autonomous system. To take
advantage of the OSPF stub area support, default routing must be used in the stub area.
Procedure
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.

1058
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 1053 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.
• Area ID—Designation of the area for which routes are to be summarized.
• Area Type—Choose one of the following:
• Normal—(Default) Standard OSPF area.
• Stub—A stub area does not have any routers or areas beyond it. Stub areas prevent Autonomous
System (AS) External LSAs (Type 5 LSAs) from being flooded into the stub area. When you create
a stub area, you can prevent summary LSAs (Types 3 and 4) from being flooded into the area by
NOT checking the Summary Stub check box.
• NSSA—Makes the area a not-so-stubby area (NSSA). NSSAs accept Type 7 LSAs. You can disable
route redistribution by NOT checking the Redistribute check box and checking the Default
Information Originate check box. You can prevent summary LSAs from being flooded into the
area by NOT checking the Summary NSSA check box.
• 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 612 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.
Step 9 Click OK to save the area configuration.

Step 10 Select Range > Add.

1059
• Choose one of the available networks and whether to advertise, or,
• Click Add ( ) to add a new network object. See Network Objects, on page 612 for the procedure for
adding networks.
Step 11 Click OK to save the range configuration.

Step 12 Select Virtual Link, click Add, and configure the following options for each OSPF process:
• Peer Router—Choose the IP address of the peer router. To add a new peer router, click Add ( ). See
Network Objects, on page 612 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
• 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.

1060
Configure OSPF Redistribution
• 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 677. Use the same
authentication type (MD5 or Key Chain) and key ID for the peers to establish a successful adjacency.
Step 13 Click OK to save the virtual link configuration.

Step 14 Click Save on the Routing page to save your changes.
What to do next
Continue with Configure OSPF Redistribution.
Configure OSPF Redistribution

The Firepower Threat Defense device can control the redistribution of routes between the OSPF routing
processes. The rules for redistributing routes from one routing process into an OSPF routing process are
displayed. You can redistribute routes discovered by RIP and BGP into the OSPF routing process. You can
also redistribute static and connected routes into the OSPF routing process.
Procedure
Step 4 Click OSPF.
Step 5 Select Distribution > Add.
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.

1061
Configure OSPF Inter-Area Filtering
• 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.
• 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.
Step 7 Click OK to save the redistribution configuration.

What to do next
Continue with Configure OSPF Inter-Area Filtering, on page 1062.

ABR type 3 LSA filtering extends the capability of an ABR that is running OSPF to filter type 3 LSAs between
different OSPF areas. Once a prefix list is configured, only the specified prefixes are sent from one OSPF
area to another OSPF area. All other prefixes are restricted to their OSPF area. You can apply this type of
area filtering to traffic going into or coming out of an OSPF area, or to both the incoming and outgoing traffic
for that area.
When multiple entries of a prefix list match a given prefix, the entry with the lowest sequence number is used.
For efficiency, you may want to put the most common matches or denials near the top of the list by manually
assigning them a lower sequence number. By default, sequence numbers are automatically generated in
increments of 5, beginning with 5.

1062
Procedure
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.
Step 9 Click OK to save the inter-area filtering configuration.

What to do next
Continue with Configure OSPF Filter Rules, on page 1064.

1063
Configure OSPF Filter Rules
Configure OSPF Filter Rules

You can configure ABR Type 3 LSA filters for each OSPF process. ABR Type 3 LSA filters allow only
specified prefixes to be sent from one area to another area and restrict all other prefixes. You can apply this
type of area filtering out of a specific OSPF area, into a specific OSPF area, or into and out of the same OSPF
area at the same time. OSPF ABR Type 3 LSA filtering improves your control of route distribution between
OSPF areas.
Procedure
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
• 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 687.
• 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.
• Interface—The interface for this filter rule.
Step 7 Click OK to save the filter rule configuration.

What to do next
Continue with Configure OSPF Summary Addresses, on page 1064.
Configure OSPF Summary Addresses

When routes from other protocols are redistributed into OSPF, each route is advertised individually in an
external LSA. However, you can configure the Firepower Threat Defense device to advertise a single route
for all the redistributed routes that are included for a specified network address and mask. This configuration
decreases the size of the OSPF link-state database. Routes that match the specified IP address mask pair can
be suppressed. The tag value can be used as a match value for controlling redistribution through route maps.

1064
Configure OSPF Interfaces and Neighbors
Routes learned from other routing protocols can be summarized. The metric used to advertise the summary
is the smallest metric of all the more specific routes. Summary routes help reduce the size of the routing table.
Using summary routes for OSPF causes an OSPF ASBR to advertise one external route as an aggregate for
all redistributed routes that are covered by the address. Only routes from other routing protocols that are being
redistributed into OSPF can be summarized.
Procedure
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
• 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 612 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.
Step 7 Click OK to save the summary address configuration.

What to do next
Continue with Configure OSPF Interfaces and Neighbors, on page 1065.

You can change some interface-specific OSPFv2 parameters, if necessary. You are not required to change
any of these parameters, but the following interface parameters must be consistent across all routers in an
attached network: the hello interval, the dead interval, and the authentication key. If you configure any of
these parameters, be sure that the configurations for all routers on your network have compatible values.

1065
You need to define static OSPFv2 neighbors to advertise OSPFv2 routes over a point-to-point, non-broadcast
network. This feature lets you broadcast OSPFv2 advertisements across an existing VPN connection without
having to encapsulate the advertisements in a GRE tunnel.
Procedure
Step 4 Click OSPF.
Step 5 Select Interface > Add.
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

1066
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.
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
• 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 677. 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.
Step 7 Select Neighbor > Add.
Step 8 Configure the following parameters for each OSPF process:

• OSPF Process—Choose 1 or 2.
• 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.
Step 9 Click OK to save the neighbor configuration.

1067
Configure OSPF Advanced Properties

The Advanced Properties allows you to configure options, such as syslog message generation, administrative
route distances, an LSA timer, and graceful restarts.
Graceful Restarts
The Firepower Threat Defense device may experience some known failure situations that should not
affect packet forwarding across the switching platform. The Non-Stop Forwarding (NSF) capability
allows data forwarding to continue along known routes, while the routing protocol information is being
restored. This capability is useful when there is a scheduled hitless software upgrade. You can configure
graceful restart on OSPFv2 by using either using NSF Cisco (RFC 4811 and RFC 4812) or NSF IETF
(RFC 3623).
Note NSF capability is also useful in HA mode and clustering.
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.
Procedure
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.

1068
• 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.
Step 6 Click OK to save the general configuration.

Step 7 Select Non Stop Forwarding, and configure Cisco NSF graceful restart for OSPFv2, for an NSF-capable or
NSF-aware device:
Note There are two graceful restart mechanisms for OSPFv2, Cisco NSF and IETF NSF. Only one of
these graceful restart mechanisms can be configured at a time for an OSPF instance. An NSF-aware
device can be configured as both Cisco NSF helper and IETF NSF helper but a NSF-capable device
can be configured in either Cisco NSF or IETF NSF mode at a time for an OSPF instance.
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:

1069
Configure OSPFv3
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.
Configure OSPFv3 Areas, Route Summaries, and Virtual Links

To enable OSPFv3, you need to create an OSPFv3 routing process, create an area for OSPFv3, enable an
interface for OSPFv3, and then redistribute the route into the targeted OSPFv3 routing process.
Procedure
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 1053 for descriptions of the OSPFv3 roles.
Step 5 Select Area > Add.
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.

1070
Configure OSPFv3 Areas, Route Summaries, and Virtual Links
• 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.
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.

Step 8 Select Route Summary > Add Route Summary.
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 612 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.
Step 10 Click OK to save the route summary configuration.

Step 11 Select Virtual Link, click Add Virtual Link, and configure the following options for each OSPF process:
• Peer RouterID—Choose the IP address of the peer router. To add a new network object, click Add
( ). See Network Objects, on page 612 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.

1071
Configure OSPFv3 Redistribution
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.
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.
Step 12 Click OK to save the virtual link configuration.

Step 13 Click Save on the Router page to save your changes.
What to do next
Continue with Configure OSPFv3 Redistribution.

The Firepower Threat Defense device can control the redistribution of routes between the OSPF routing
processes. The rules for redistributing routes from one routing process into an OSPF routing process are
displayed. You can redistribute routes discovered by RIP and BGP into the OSPF routing process. You can
also redistribute static and connected routes into the OSPF routing process.
Procedure
Step 2 Select Routing > OSPF.
Step 3 Select Redistribution, and click Add.

1072
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.
• 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 682 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.
• Match—Enables OSPF routes to be redistributed into other routing domains:

• Internal for routes that are internal to a specific autonomous system.
• External 1 for routes that are external to the autonomous system, but are imported into OSPFv3 as
Type 1 external routes.
• External 2 for routes that are external to the autonomous system, but are imported into OSPFv3 as
Type 2 external routes.
• NSSA External 1 for routes that are external to the autonomous system, but are imported into
OSPFv3 in an NSSA for IPv6 as Type 1 external routes.
• NSSA External 2 for routes that are external to the autonomous system, but are imported into
OSPFv3 in an NSSA for IPv6 as Type 2 external routes.
Step 5 Click OK to save the redistribution configuration.

What to do next
Continue with Configure OSPFv3 Summary Prefixes, on page 1074.

1073
Configure OSPFv3 Summary Prefixes
Configure OSPFv3 Summary Prefixes

You can configure the Firepower Threat Defense device to advertise routes that match a specified IPv6 prefix
and mask pair.
Procedure
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 612 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.
Step 5 Click OK to save the summary prefix configuration.

What to do next
Continue with Configure OSPFv3 Interfaces, Authentication, and Neighbors, on page 1074.
Configure OSPFv3 Interfaces, Authentication, and Neighbors

You can change certain interface-specific OSPFv3 parameters, if necessary. You are not required to change
any of these parameters, but the following interface parameters must be consistent across all routers in an
attached network: the hello interval and the dead interval. If you configure any of these parameters, be sure
that the configurations for all routers on your network have compatible values.
Procedure
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:

1074
• 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.

1075
• 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.
Step 6 Click OK to save the properties configuration.

Step 7 Select Authentication, and configure the following options for each OSPFv3 process:
• 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.
Step 8 Click OK to save the authentication configuration.

Step 9 Select Neighbor, click Add, and configure the following options for each OSPFv3 process:
• Link Local Address—The IPv6 address of the static neighbor.
• Cost—Enables cost. Enter the cost in the Cost field, and check the Filter Outgoing Link State
Advertisements if you want to advertise.
• (Optional) Poll Interval—Enables the poll interval. Enter the Priority level and the Poll Interval in
seconds.
Step 10 Click Add to add the neighbor.

1076
Configure OSPFv3 Advanced Properties
Step 11 Click OK to save the Interface configuration.

The Advanced Properties allows you to configure options, such as syslog message generation, administrative
route distances, passive OSPFv3 routing, LSA timers, and graceful restarts.
Graceful Restarts
The Firepower Threat Defense device may experience some known failure situations that should not
affect packet forwarding across the switching platform. The Non-Stop Forwarding (NSF) capability
allows data forwarding to continue along known routes, while the routing protocol information is being
restored. This capability is useful when there is a scheduled hitless software upgrade. You can configure
graceful restart on OSPFv3 using graceful-restart (RFC 5187).
Note NSF capability is also useful in HA mode and clustering.
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.
Procedure
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.

1077
• 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 682 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.
Step 8 Click OK to save the passive interface configuration.

Step 9 Select Timer, and configure the following LSA pacing and SPF calculation timers:
• Arrival—Specifies the minimum delay in milliseconds that must pass between acceptance of the same
LSA arriving from neighbors. The range is from 0 to 6000,000 milliseconds. The default is 1000
milliseconds.
• Flood Pacing—Specifies the time in milliseconds at which LSAs in the flooding queue are paced in
between updates. The configurable range is from 5 to 100 milliseconds. The default value is 33
milliseconds.
• 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.
• Retransmission Pacing—Specifies the time in milliseconds at which LSAs in the retransmission queue
are paced. The configurable range is from 5 to 200 milliseconds. The default value is 66 milliseconds.
• LSA Throttle—Specifics the delay in milliseconds to generate the first occurrence of the LSA. The
default value is 0 millisecond. The minimum specifies the minimum delay in milliseconds to originate
the same LSA. The default value is 5000 milliseconds. The maximum specifies the maximum delay in
milliseconds to originate the same LSA. The default value is 5000 milliseconds.

1078
Note For LSA 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.
• 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 10 Click OK to save the LSA timer configuration.

Step 11 Select Non Stop Forwarding, and check the Enable graceful-restart helper check box. This is checked by
default. Uncheck this to disable the graceful-restart helper mode on an NSF-aware device.
Step 12 Check the Enable link state advertisement check box to 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.
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.

1079

1080
CHAPTER 41
BGP for Firepower Threat Defense
This section describes how to configure the FTD to route data, perform authentication, and redistribute routing
information using the Border Gateway Protocol (BGP).
• About BGP, on page 1081
• Requirements and Prerequisites for BGP, on page 1084
• Guidelines for BGP, on page 1084
• Configure BGP, on page 1085
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).
Routing Table Changes

BGP neighbors exchange full routing information when the TCP connection between neighbors is first
established. When changes to the routing table are detected, the BGP routers send to their neighbors only
those routes that have changed. BGP routers do not send periodic routing updates, and BGP routing updates
advertise only the optimal path to a destination network.
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.

1081
When to Use BGP
• 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.
When to Use BGP

Customer networks, such as universities and corporations, usually employ an Interior Gateway Protocol (IGP)
such as OSPF for the exchange of routing information within their networks. Customers connect to ISPs, and
ISPs use BGP to exchange customer and ISP routes. When BGP is used between autonomous systems (AS),
the protocol is referred to as External BGP (EBGP). If a service provider is using BGP to exchange routes
within an AS, then the protocol is referred to as Interior BGP (IBGP).
BGP can also be used for carrying routing information for IPv6 prefix over IPv6 networks.
BGP Path Selection

BGP may receive multiple advertisements for the same route from different sources. BGP selects only one
path as the best path. When this path is selected, BGP puts the selected path in the IP routing table and

1082
BGP Multipath
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 1083.
• 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)

1083
Requirements and Prerequisites for BGP
Some BGP Multipath features put additional requirements on multipath candidates:

• The path should be learned from an external or confederation-external neighbor (eBGP).
• The IGP metric to the BGP next hop should be equal to the best-path IGP metric.
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.
Requirements and Prerequisites for BGP

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Network Admin
Guidelines for BGP

Does not support transparent firewall mode. BGP is supported only in routed mode.
IPv6 Guidelines
Supports IPv6. Graceful restart is not supported for IPv6 address family.

1084
Configure BGP
Virtual Router Guidelines

BGP IPv4 is supported both on global and user-defined virtual routers. However, only BGP IPv6 configuration
is supported on a global virtual router.
• The system 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.
• To avoid adjacency flaps due to route updates being dropped if the route update is larger than the minimum
MTU on the link, ensure that you configure the same MTU on the interfaces on both sides of the link.
Configure BGP
To configure BGP, see the following topics:
Procedure
Step 1 Configure BGP Basic Settings, on page 1085

Step 2 Configure BGP General Settings, on page 1087
Step 3 Configure BGP Neighbor Settings, on page 1089
Step 4 Configure BGP Aggregate Address Settings, on page 1092
Step 5 Configure BGPv4 Filtering Settings, on page 1093
Note The Filtering section is applicable only to IPv4 settings
Step 6 Configure BGP Network Settings, on page 1094

Step 7 Configure BGP Redistribution Settings, on page 1094
Step 8 Configure BGP Route Injection Settings, on page 1095
Configure BGP Basic Settings

You can set many basic settings for BGP.
For a device using virtual routing, the basic settings described in this section must be configured in the BGP
page under General Settings. For more information, see Modifications to FMC Web Interface - Routing
Page, on page 1011.
Procedure
Step 2 Select Routing.

1085
Configure BGP Basic Settings
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.

1086
Configure BGP General Settings
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.
Step 9 (Optional) Edit the Graceful Restart section:
Note This section is available only when the Firepower Threat Defensedevice is in failover or spanned
cluster mode. This is done so that there is no drop in packets in the traffic flow, when one of the
devices in the failover setup fails.
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.

Configure Route maps, Administrative Route Distances, Synchronisation, Next-hop, and packet forwarding.
The defaults for these settings are appropriate in most cases, but you can adjust them to fit the needs of your
network.

1087
Procedure
Step 1 On the Device Management page, click Routing.

Step 2 (For a virtual-router-aware device) From the virtual routers drop-down, select the virtual router for which you
are configuring BGP.
Step 3 Choose BGP > IPv4 or IPv6.
Note BGP configuration with IPv6 address family is not supported on a user-defined virtual router. Hence,
if you select a user-defined virtual router, only IPv4 settings are available.
Step 4 Click General.

Step 5 In General, update the following sections:
a) In the Settings section, enter or select a Route Map object and enter a Scanning Interval for BGP routers
for next-hop validation. Valid values are from 5 to 60 seconds. The default value is 60. Click OK.
Note The Route Map field is applicable only to IPv4 settings
b) In the Routes and Synchronization section, update the following as required, and click OK :
• (Optional) Generate Default Routes— Select this option to configure default-information originate.
• (Optional) Summarize subnet routes into network-level routes— Select this to configure automatic
summarization of subnet routes into network-level routes. This check box 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.
• 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.

1088
Configure BGP Neighbor Settings
d) In the Next Hop section, optionally select the Enable address tracking check box 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 6 Click Save.

A BGP router must connect with each of its peers before exchanging updates. These peers are called BGP
neighbors. Use Neighbor to define BGP IPv4 or IPv6 neighbors and neighbor settings. If you have enabled
virtual router on the device, you can define only BGP IPv4 neighbors for user-defined virtual router. However,
for a global virtual router, you can define the BGP IPv6 as well.
Procedure

Step 2 (For a virtual-router-aware device) From the virtual routers drop-down, choose the virtual router for which
you are configuring BGP.
Step 4 Click Neighbor.

Step 5 Click Add to define BGP neighbors and neighbor settings.
Step 6 Enter the BGP neighbor IP address. This IP address is added to the BGP neighbor table.
Step 7 Choose the BGP neighbor Interface.
Note The Interface field is only applicable to IPv6 settings. For a device using virtual routing, this field
appears only for a global virtual router. Also, only the interfaces belonging to the router are listed
in the drop-down.
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.

1089
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.

1090
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.
Step 17 In Advanced, update the following:

a) (Optional) Select Enable Authentication to enable MD5 authentication on a TCP connection between
two BGP peers.
1. Choose an encryption type from the Enable Encryption drop-down list.
2. Enter a password in the Password field. Reenter the password in the Confirm field. The password
is case-sensitive and can be up to 25 characters long when the service password-encryption command
is enabled and up to 81 characters long when the service password-encryption command is not enabled.
The string can contain any alphanumeric characters, including spaces.
Note You cannot specify a password in the format number-space-anything. The space after the
number can cause authentication to fail.
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.

1091
Configure BGP Aggregate Address Settings
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.
Configure BGP Aggregate Address Settings

BGP neighbors store and exchange routing information and the amount of routing information increases as
more BGP speakers are configured. Route aggregation is the process of combining the attributes of several
different routes so that only a single route is advertised. Aggregate prefixes use the classless interdomain
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.
Procedure
Step 1 When editing a Firepower Threat Defense device, click Routingf.


1092
Configure BGPv4 Filtering Settings
Step 4 Click Add Aggregate Address.

Step 5 Enter a value for the aggregate timer (in seconds) in the Aggregate Timer field. Valid values are 0 or any
value between 6 and 60. The default value is 30.
Step 6 Click Add and update the Add Aggregate Address dialog:
a) Network — Enter an IPv4 address or select the desired network/hosts objects.
b) Attribute Map — (Optional) Enter or select the route map used to set the attribute of the aggregate route.
c) Advertise Map — (Optional) Enter or select the route map used to select the routes to create AS_SET
origin communities.
d) Suppress Map — (Optional) Enter or select the route map used to select the routes to be suppressed.
e) Generate AS set path Information— (Optional) Select the check box to enable generation of autonomous
system set path information.
f) Filter all routes from updates— (Optional) Select the check box to filter all more-specific routes from
updates.
g) Click OK.
What to do next
• For BGPv4 settings, proceed to Configure BGPv4 Filtering Settings, on page 1093
• For BGPv6 settings, proceed to Configure BGP Network Settings, on page 1094
Configure BGPv4 Filtering Settings

Filtering settings are used to filter routes or networks received in incoming BGP updates. Filtering is used to
restrict routing information that the router learns or advertises.
Before you begin

Filtering is only applicable for a BGP IPv4 routing policy.
Procedure

Step 3 Choose BGP > IPv4.
Step 4 Click Filtering.
Step 5 Click Add and update the Add Filter dialog:
a) Access List— Select an access control list that defines which networks are to be received and which are
to be suppressed in routing updates.
b) Direction— (Optional) Select a direction that specifies if the filter should be applied to inbound updates
or outbound updates.
c) Protocol— (Optional) Select the routing process for which you want to filter: None, BGP, Connected,
OSPF, RIP, or Static.
d) Process ID— (Optional) Enter the process ID for the OSPF routing protocol.

1093
Configure BGP Network Settings
e) Click OK.
Step 6 Click Save.
Configure BGP Network Settings

Network settings are used to add networks that will be advertised by the BGP routing process and route maps
that will be examined to filter the networks to be advertised.
Procedure

Step 4 Click Networks.

Step 5 Click Add and update the Add Networks dialog:
a) Network— Enter the network to be advertised by the BGP routing processes.
b) (Optional) Route Map— Enter or select a route map that should be examined to filter the networks to be
advertised. If not specified, all networks are redistributed.
c) Click OK.
Step 6 Click Save.
Configure BGP Redistribution Settings

Redistribution settings allow you to define the conditions for redistributing routes from another routing domain
into BGP.
Procedure

Step 4 Click Redistribution.

1094
Configure BGP Route Injection Settings
Step 5 Click Add and update the Add Redistribution dialog:

a) Source Protocol— Select the protocol from which you want to redistribute routes into the BGP domain
from the Source Protocol drop-down list.
Note User-defined virtual routers does not support redistributing traffic from RIP.
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.

Route Injection settings allow you to define the routes to be conditionally injected into the BGP routing table.
Procedure

Step 4 Click Route Injection.

Step 5 Click Add and update the Add Route Injection dialog:
a) Inject Map— Enter or select the route map that specifies the prefixes to inject into the local BGP routing
table.
b) Exist Map— Enter or select the route map containing the prefixes that the BGP speaker will track.

1095
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.

1096
CHAPTER 42
RIP for Firepower Threat Defense
information, using the Routing Information Protocol (RIP). For a device using virtual routing, you can configure
RIP only for its global virtual router and not for its user-defined virtual router.
• About RIP, on page 1097
• Requirements and Prerequisites for RIP, on page 1099
• Guidelines for RIP, on page 1099
• Configure RIP, on page 1100
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.
Routing Update Process

RIP sends routing-update messages at regular intervals and when the network topology changes. When a
router receives a routing update that includes changes to an entry, it updates its routing table to reflect the
new route. The metric value for the path is increased by 1, and the sender is indicated as the next hop. RIP

1097
RIP Routing Metric
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 Routing Metric

RIP uses a single routing metric (hop count) to measure the distance between the source and a destination
network. Each hop in a path from source to destination is assigned a hop count value, which is typically 1.
When a router receives a routing update that contains a new or changed destination network entry, the router
adds 1 to the metric value indicated in the update and enters the network in the routing table. The IP address
of the sender is used as the next hop.
RIP Stability Features

RIP prevents routing loops from continuing indefinitely by implementing a limit on the number of hops
allowed in a path from the source to a destination. The maximum number of hops in a path is 15. If a router
receives a routing update that contains a new or changed entry, and if increasing the metric value by 1 causes
the metric to be infinity (that is, 16), the network destination is considered unreachable. The downside of this
stability feature is that it limits the maximum diameter of a RIP network to less than 16 hops.
RIP includes a number of other stability features that are common to many routing protocols. These features
are designed to provide stability despite potentially rapid changes in network topology. For example, RIP
implements the split horizon and hold-down mechanisms to prevent incorrect routing information from being
propagated.
RIP Timers
RIP uses numerous timers to regulate its performance. Following are the timer stages for RIP:
• Update—The routing-update timer is the interval between periodic routing updates. This is how often
the device sends 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.
• Invalid—Each routing table entry has a route-timeout timer associated with it. This is the number of
seconds since the device received the last valid update. When the route-timeout timer expires, the route
is marked invalid but is retained in the table until the route-flush timer expires. Once this timer expires,
the route goes into holddown. The default is 180 seconds (3 minutes).
• Holddown—The holddown period is the number of seconds the system waits before accepting any new
updates for the route that is in holddown (that is, routes that have been marked invalid). The default is
180 seconds (3 minutes).
• Flush—The route-flush timer is the number of seconds since the system received the last valid update
until the route is discarded and removed from the routing table. The default is 240 seconds (4 minutes).
As an example, when the interface on an adjacent router goes down, the system no longer receives routing
updates from the adjacent router. At this time, the Invalid and Flush timers start increasing. In the first 180
seconds, nothing will happen. After 180 seconds, the invalid timer expires, making the route invalid, and the
Holddown timer starts and holds the route for another 60 seconds. If there is still no update regarding the
interface status on the adjacent router (that is, it is still down), then the route enters into the Flush state where
in total the system has waited for 240 seconds from the last update (180 seconds for the Invalid timer and 60

1098
Requirements and Prerequisites for RIP
seconds for Holddown timer), and the system flushes the route. Even if the adjacent routers interface comes
up immediately, the system does not accept a routing update until the Holddown timer completes the remaining
120 seconds.
Requirements and Prerequisites for RIP

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Network Admin
Guidelines for RIP

IPv6 Guidelines
Does not support IPv6.
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.

1099
Configure RIP
Configure RIP
RIP is a distance-vector routing protocol that uses hop count as the metric for path selection.
Procedure
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:

1100
Configure RIP
• 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
Note The default is match Internal, External 1, and External 2
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.

1101
Configure RIP
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.

1102
CHAPTER 43
Multicast Routing for Firepower Threat Defense
This chapter describes how to configure the Firepower Threat Defense device to use the multicast routing
protocol. For a device using virtual routing, you can configure RIP only for its global virtual router and not
for its user-defined virtual router.
• About Multicast Routing, on page 1103
• Requirements and Prerequisites for Multicast Routing, on page 1107
• Guidelines for Multicast Routing, on page 1107
• Configure IGMP Features, on page 1108
• Configure PIM Features, on page 1112
• Configure Multicast Routes, on page 1119
• Configure Multicast Boundary Filters, on page 1119
About Multicast Routing

Multicast routing is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a
single stream of information to thousands of corporate recipients and homes. Applications that take advantage
of multicast routing include videoconferencing, corporate communications, distance learning, and distribution
of software, stock quotes, and news.
Multicast routing protocols deliver source traffic to multiple receivers without adding any additional burden
on the source or the receivers while using the least network bandwidth of any competing technology. Multicast
packets are replicated in the network by Firepower Threat Defense device enabled with Protocol Independent
Multicast (PIM) and other supporting multicast protocols, which results in the most efficient delivery of data
to multiple receivers possible.
The Firepower Threat Defense device supports both stub multicast routing and PIM multicast routing. However,
you cannot configure both concurrently on a single Firepower Threat Defense device.
Note The UDP and non-UDP transports are both supported for multicast routing. However, the non-UDP transport
has no FastPath optimization.

1103
IGMP Protocol
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.
Query Messages to Multicast Groups

The Firepower Threat Defense device sends query messages to discover which multicast groups have
members on the networks attached to the interfaces. Members respond with IGMP report messages
indicating that they want to receive multicast packets for specific groups. Query messages are addressed
to the all-systems multicast group, which has an address of 224.0.0.1, with a time-to-live value of 1.
These messages are sent periodically to refresh the membership information stored on the Firepower
Threat Defense device. If the Firepower Threat Defense device discovers that there are no local members
of a multicast group still attached to an interface, it stops forwarding multicast packets for that group to
the attached network, and it sends a prune message back to the source of the packets.
By default, the PIM designated router on the subnet is responsible for sending the query messages. By
default, they are sent once every 125 seconds.
When changing the query response time, by default, the maximum query response time advertised in
IGMP queries is 10 seconds. If the Firepower Threat Defense device does not receive a response to a
host query within this amount of time, it deletes the group.
Stub Multicast Routing

Stub multicast routing provides dynamic host registration and facilitates multicast routing. When configured
for stub multicast routing, the Firepower Threat Defense device acts as an IGMP proxy agent. Instead of fully
participating in multicast routing, the Firepower Threat Defense device forwards IGMP messages to an
upstream multicast router, which sets up delivery of the multicast data. When configured for stub multicast
routing, the Firepower Threat Defense device cannot be configured for PIM sparse or bidirectional mode.
You must enable PIM on the interfaces participating in IGMP stub multicast routing.
The Firepower Threat Defense device supports both PIM-SM and bidirectional PIM. PIM-SM is a multicast
routing protocol that uses the underlying unicast routing information base or a separate multicast-capable
routing information base. It builds unidirectional shared trees rooted at a single Rendezvous Point (RP) per
multicast group and optionally creates shortest-path trees per multicast source.

1104
PIM Multicast Routing
PIM Multicast Routing

Bidirectional PIM is a variant of PIM-SM that builds bidirectional shared trees connecting multicast sources
and receivers. Bidirectional trees are built using a Designated Forwarder (DF) election process operating on
each link of the multicast topology. With the assistance of the DF, multicast data is forwarded from sources
to the Rendezvous Point (RP), and therefore along the shared tree to receivers, without requiring source-specific
state. The DF election takes place during RP discovery and provides a default route to the RP.
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.
PIM Source Specific Multicast Support

The Firepower Threat Defense device does not support PIM Source Specific Multicast (SSM) functionality
and related configuration. However, the Firepower Threat Defense device allows SSM-related packets to pass
through unless it is placed as a last-hop router.
SSM is classified as a data delivery mechanism for one-to-many applications such as IPTV. The SSM model
uses a concept of "channels" denoted by an (S,G) pair, where S is a source address and G is an SSM destination
address. Subscribing to a channel is achieved by using a group management protocol such as IGMPv3. SSM
enables a receiving client, once it has learned about a particular multicast source, to receive multicast streams
directly from the source rather than receiving it from a shared Rendezvous Point (RP). Access control
mechanisms are introduced within SSM providing a security enhancement not available with current sparse
or sparse-dense mode implementations.
PIM-SSM differs from PIM-SM in that it does not use an RP or shared trees. Instead, information on source
addresses for a multicast group is provided by the receivers through the local receivership protocol (IGMPv3)
and is used to directly build source-specific trees.
Multicast Bidirectional PIM

Multicast bidirectional PIM is useful for networks that have many sources and receivers talking to each other
simultaneously and where each participant can become both the source and receiver of multicast traffic, such
as in videoconferencing, Webex meetings, and group chat. When PIM bidirectional mode is used, the RP only
creates the (*,G) entry for the shared tree. There is no (S,G) entry. This conserves resources on the RP because
state tables for each (S,G) entry are not maintained.
In PIM sparse mode, traffic only flows down the shared tree. In PIM bidirectional mode, traffic flows up and
down the shared tree.
PIM bidirectional mode also does not use the PIM register/register-stop mechanism to register sources to the
RP. Each source can begin sending to the source at any time. When the multicast packets arrive at the RP,
they are forwarded down the shared tree (if there are receivers) or dropped (when there are no receivers).
However, there is no way for the RP to tell the source to stop sending multicast traffic.
Design-wise you must think about where to place the RP in your network because it should be somewhere in
the middle between the sources and receivers in the network.
PIM bidirectional mode has no Reverse Path Forwarding (RPF) check. Instead it uses the concept of a
Designated Forwarder (DF) to prevent loops. This DF is the only router on the segment that is allowed to

1105
PIM Bootstrap Router (BSR)
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.
PIM Bootstrap Router (BSR)

PIM Bootstrap Router (BSR) is a dynamic Rendezvous Point (RP) selection model that uses candidate routers
for RP function and for relaying the RP information for a group. The RP function includes RP discovery and
provides a default route to the RP. It does this by configuring a set of devices as candidate BSRs (C-BSR)
which participate in a BSR election process to choose a BSR amongst themselves. Once the BSR is chosen,
devices that are configured as candidate Rendezvous Points (C-RP) start sending their group mapping to the
elected BSR. The BSR then distributes the group-to-RP mapping information to all the other devices down
the multicast tree through BSR messages that travel from PIM router to PIM router on a per-hop basis.
This feature provides a means of dynamically learning RPs, which is very essential in large complex networks
where an RP can periodically go down and come up.
PIM Bootstrap Router (BSR) Terminology

The following terms are frequently referenced in the PIM BSR configuration:
• Bootstrap Router (BSR) — A BSR advertises Rendezvous Point (RP) information to other routers with
PIM on a hop-by-hop basis. Among multiple Candidate-BSRs, a single BSR is chosen after an election
process. The primary purpose of this Bootstrap router is to collect all Candidate-RP (C-RP) announcements
in to a database called the RP-set and to periodically send this out to all other routers in the network as
BSR messages (every 60 seconds).
• Bootstrap Router (BSR) messages — BSR messages are multicast to the All-PIM-Routers group with a
TTL of 1. All PIM neighbors that receive these messages retransmit them (again with a TTL of 1) out
of all interfaces except the one in which the messages were received. BSR messages contain the RP-set
and the IP address of the currently active BSR. This is how C-RPs know where to unicast their C-RP
messages.
• Candidate Bootstrap Router (C-BSR) — A device that is configured as a candidate-BSR participates in
the BSR election mechanism. A C-BSR with highest priority is elected as the BSR. The highest IP address
of the C-BSR is used as a tiebreaker. The BSR election process is preemptive, for example if a new
C-BSR with a higher priority comes up, it triggers a new election process.
• Candidate Rendezvous Point (C-RP) — An RP acts as a meeting place for sources and receivers of
multicast data. A device that is configured as a C-RP periodically advertises the multicast group mapping
information directly to the elected BSR through unicast. These messages contain the Group-range, C-RP
address, and a hold time. The IP address of the current BSR is learned from the periodic BSR messages
that are received by all routers in the network. In this way, the BSR learns about possible RPs that are
currently up and reachable.
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.

1106
Multicast Group Concept
• 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 Group Concept

Multicast is based on the concept of a group. An arbitrary group of receivers expresses an interest in receiving
a particular data stream. This group does not have any physical or geographical boundaries—the hosts can
be located anywhere on the Internet. Hosts that are interested in receiving data flowing to a particular group
must join the group using IGMP. Hosts must be a member of the group to receive the data stream.
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.
Requirements and Prerequisites for Multicast Routing

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Network Admin
Guidelines for Multicast Routing

Firewall Mode
Supported only in routed firewall mode. Transparent firewall mode is not supported.

1107
Configure IGMP Features
IPv6
Does not support IPv6.
Multicast Group
The range of addresses between 224.0.0.0 and 224.0.0.255 is reserved for the use of routing protocols and
other topology discovery or maintenance protocols, such as gateway discovery and group membership reporting.
Hence, Internet multicast routing from address range 224.0.0/24 is not supported; IGMP group is not created
when enabling multicast routing for the reserved addressess.
Clustering
In clustering, for IGMP and PIM, this feature is only supported on the primary unit.
• 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 1113), 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.
Configure IGMP Features

IP hosts use 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.
This section describes how to configure optional IGMP settings on a per-interface basis.
Procedure
Step 1 Enable Multicast Routing, on page 1109

Step 2 Configure IGMP Protocol, on page 1109.
Step 3 Configure IGMP Access Groups, on page 1111.
Step 4 Configure IGMP Static Groups, on page 1111.
Step 5 Configure IGMP Join Groups, on page 1112.

1108
Enable Multicast Routing
Enable Multicast Routing

Enabling multicast routing on the Firepower Threat Defense device, enables IGMP and PIM on all interfaces
by default. IGMP is used to learn whether members of a group are present on directly attached subnets. Hosts
join multicast groups by sending IGMP report messages. PIM is used to maintain forwarding tables to forward
multicast datagrams.
Note Only the UDP transport layer is supported for multicast routing.
The following list shows the maximum number of entries for specific multicast tables. Once these limits are
reached, any new entries are discarded.
• MFIB—30,000
• IGMP Groups—30,000
• PIM Routes—72,000
Procedure
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.
Configure IGMP Protocol

You can configure IGMP parameters per interface, such as the forward interface, query messages, and time
intervals.
Procedure
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.

1109
Configure IGMP Protocol
Step 4 Configure the following options:

• 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
Step 5 Click OK to save the IGMP protocol configuration.

1110
Configure IGMP Access Groups
Configure IGMP Access Groups

You can control access to multicast groups by using access control lists.
Procedure
Step 2 Choose Routing > Multicast Routing > Access Group.
Step 3 On Access Group, click Add or Edit.
Use the Add IGMP Access Group parameters dialog box to add new IGMP access groups to the Access
Group table. Use the Edit IGMP Access Group parameters dialog box to change existing parameters.

a) From the Interface drop-down list, select the interface with which the access group is associated. You
cannot change the associated interface when you are editing an existing access group.
b) Click one of the following:
• Standard Access List— From the Standard Access List drop-down list, select the standard ACL
or click Add ( ) to create a new standard ACL. See Configure Standard ACL Objects, on page 687
for the procedure.
• Extended Access List—From the Extended Access List drop-down list, select the extended ACL
or click Add ( ) to create a new extended ACL. See Configure Extended ACL Objects, on page
686 for the procedure.
Step 5 Click OK to save the access group configuration.
Configure IGMP Static Groups

Sometimes a group member cannot report its membership in the group or there may be no members of a group
on the network segment, but you still want multicast traffic for that group to be sent to that network segment.
You can have multicast traffic for that group sent to the segment by configuring a statically joined IGMP
group. With this method, the Firepower Threat Defense device does not accept the packets itself, but only
forwards them. Therefore, this method allows fast switching. The outgoing interface appears in the IGMP
cache, but this interface is not a member of the multicast group.
Procedure
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.

1111
Configure IGMP Join Groups

• From the Interface drop-down list, select the interface to which you want to statically assign a multicast
group. If you are editing an existing entry, you cannot change the value.
• From the Multicast Groups drop-down list, select the multicast group to which you want to assign the
interface, or click Add ( ) to create a new multicast group. See Creating Network Objects for the
procedure.
Step 5 Click OK to save the static group configuration.
Configure IGMP Join Groups

You can configure an interface to be a member of a multicast group. Configuring the Firepower Threat Defense
device to join a multicast group causes upstream routers to maintain multicast routing table information for
that group and keep the paths for that group active.
Note See Configure IGMP Static Groups, on page 1111 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.
Procedure
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.

• From the Interface drop-down list, select the interface you want to be a member of a multicast group.
If you are editing an existing entry, you cannot change the value.
• From the Join Group drop-down list, select the multicast group to which you want to assign the interface,
or click Plus to create a new multicast group. See Creating Network Objects for the procedure.
Configure PIM Features

Routers use PIM to maintain forwarding tables to use for forwarding multicast diagrams. When you enable
multicast routing on the Firepower Threat Defense device, PIM and IGMP are automatically enabled on all
interfaces.

1112
Configure PIM Protocol
Note PIM is not supported with PAT. The PIM protocol does not use ports, and PAT only works with protocols
that use ports.
This section describes how to configure optional PIM settings.
Procedure
Step 1 Configure PIM Protocol, on page 1113

Step 2 Configure PIM Neighbor Filters, on page 1114
Step 3 Configure PIM Bidirectional Neighbor Filters, on page 1115
Step 4 Configure PIM Rendezvous Points, on page 1115
Step 5 Configure PIM Route Trees, on page 1116
Step 6 Configure PIM Request Filters, on page 1117
Step 7 Configure Multicast Boundary Filters, on page 1119
Configure PIM Protocol

You can enable or disable PIM on a specific interface.
You can also configure the Designated Router (DR) priority. The DR is responsible for sending PIM register,
join, and prune messages to the RP. When there is more than one multicast router on a network segment,
choosing the DR is based on the DR priority. If multiple devices have the same DR priority, then the device
with the highest IP address becomes the DR. By default, the Firepower Threat Defense device has a DR
priority of 1.
Router query messages are used to choose the PIM DR. The PIM DR is responsible for sending router query
messages. By default, router query messages are sent every 30 seconds. Additionally, every 60 seconds, the
Firepower Threat Defense device sends PIM join or prune messages.
Procedure
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.

• Interface—From the drop-down list, select the interface for which you want to configure PIM protocol.
• Enable PIM—Check the check box to enable PIM.

1113
Configure PIM Neighbor Filters
• DR Priority—The value for the DR for the selected interface. The router with the highest DR priority
on the subnet becomes the designated router. Valid values range from 0 to 4294967294. The default DR
priority is 1. Setting this value to 0 makes the Firepower Threat Defense device interface ineligible to
become the default router.
• Hello Interval—The interval in seconds at which the interface sends PIM hello messages. The range is
1 to 3600. The default is 30.
• Join Prune Interval—The interval in seconds at which the interface sends PIM join and prune
advertisements. The range is 10 to 600. The default is 60.
Step 5 Click OK to save the PIM protocol configuration.
Configure PIM Neighbor Filters

You can define the routers that can become PIM neighbors. By filtering the routers that can become PIM
neighbors, you can do the following:
• Prevent unauthorized routers from becoming PIM neighbors.
• Prevent attached stub routers from participating in PIM.
Procedure
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.

• From the Interface drop-down list, select the interface to which you want to add a PIM neighbor filter.
• 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 687 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 5 Click OK to save the PIM neighbor filter configuration.

1114
Configure PIM Bidirectional Neighbor Filters
Configure PIM Bidirectional Neighbor Filters

A PIM bidirectional neighbor filter is an ACL that defines the neighbor devices that can participate in the
Designated Forwarder (DF) election. If a PIM bidirectional neighbor filter is not configured for an interface,
there are no restrictions. If a PIM bidirectional neighbor filter is configured, only those neighbors permitted
by the ACL can participate in the DF election process.
Bidirectional PIM allows multicast routers to keep reduced state information. All of the multicast routers in
a segment must be bidirectionally enabled to elect a DF.
When a PIM bidirectional neighbor filter is enabled, the routers that are permitted by the ACL are considered
to be bidirectionally capable. Therefore, the following is true:
• If a permitted neighbor does not support bidirectional mode, then the DF election does not occur.
• If a denied neighbor supports bidirectional mode, then the DF election does not occur.
• If a denied neighbor does not support bidirectional mode, the DF election can occur.
Procedure
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 687 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 5 Click OK to save the PIM bidirectional neighbor filter configuration.
Configure PIM Rendezvous Points

You can configure the Firepower Threat Defense device to serve as a RP to more than one group. The group
range specified in the ACL determines the PIM RP group mapping. If an ACL is not specified, then the RP
for the group is applied to the entire multicast group range (224.0.0.0/4). See Multicast Bidirectional PIM,
on page 1105 for more information about bidirectional PIM.

1115
Configure PIM Route Trees
The following restrictions apply to RPs:

• You cannot use the same RP address twice.
• You cannot specify All Groups for more than one RP.
Procedure
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.

• From the Rendezvous Point IP address drop-down list, select the IP address that you want to add as
an RP or click Add ( ) to create a new network object. See Creating Network Objects for the procedure.
• Check the Use bi-directional forwarding check box if the specified multicast groups are to operate in
bidirectional mode. In bidirectional mode, if the Firepower Threat Defense device receives a multicast
packet and has no directly connected members or PIM neighbors present, it sends a prune message back
to the source.
• Choose Use this RP for all Multicast Groups to to use the specified RP for all multicast groups on the
interface.
• Choose the Use this RP for all Multicast Groups as specified below to designate the multicast groups
to use with the specified RP and then from the Standard Access List drop-down list, choose a standard
ACL or click Add ( ) to create a new standard ACL. See Configure Standard ACL Objects, on page
687 for the procedure.
Step 5 Click OK to save the rendezvous point configuration.
Configure PIM Route Trees

By default, PIM leaf routers join the shortest-path tree immediately after the first packet arrives from a new
source. This method reduces delay, but requires more memory than the shared tree. You can configure whether
or not the Firepower Threat Defense device should join the shortest-path tree or use the shared tree, either for
all multicast groups or only for specific multicast addresses.
The shortest-path tree is used for any group that is not specified in the Multicast Groups table. The Multicast
Groups table displays the multicast groups to use with the shared tree. The table entries are processed from
the top down. You can create an entry that includes a range of multicast groups, but excludes specific groups
within that range by placing deny rules for the specific groups at the top of the table and the permit rule for
the range of multicast groups below the deny statements.

1116
Configure PIM Request Filters
Note This behavior is known as Shortest Path Switchover (SPT). We recommend that you always use the Shared
Tree option.
Procedure
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 687 for the procedure.
Step 4 Click OK to save the route tree configuration.
Configure PIM Request Filters

When the Firepower Threat Defense device is acting as an RP, you can restrict specific multicast sources from
registering with it to prevent unauthorized sources from registering with the RP. You can define the multicast
sources from which the Firepower Threat Defense device will accept PIM register messages.
Procedure
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 686 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.

1117
Configure the Firepower Threat Defense Device as a Candidate Bootstrap Router
• 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 4 Click OK to save the request filter configuration.
Configure the Firepower Threat Defense Device as a Candidate Bootstrap

Router
You can configure the Firepower Threat Defense device as a candidate BSR.
Procedure
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.
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 5 Click OK to save the bootstrap router configuration.

1118
Configure Multicast Routes
Configure Multicast Routes

Configuring static multicast routes lets you separate multicast traffic from unicast traffic. For example, when
a path between a source and destination does not support multicast routing, the solution is to configure two
multicast devices with a GRE tunnel between them and to send the multicast packets over the tunnel.
When using PIM, the Firepower Threat Defense device expects to receive packets on the same interface where
it sends unicast packets back to the source. In some cases, such as bypassing a route that does not support
multicast routing, you may want unicast packets to take one path and multicast packets to take another.
Static multicast routes are not advertised or redistributed.
Procedure
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.
Step 6 Click OK to save the multicast routes configuration.
Configure Multicast Boundary Filters

Address scoping defines domain boundary filters so that domains with RPs that have the same IP address do
not leak into each other. Scoping is performed on the subnet boundaries within large domains and on the
boundaries between the domain and the Internet.
You can set up an administratively scoped boundary filter on an interface for multicast group addresses. IANA
has designated the multicast address range from 239.0.0.0 to 239.255.255.255 as the administratively scoped

1119
Configure Multicast Boundary Filters
addresses. This range of addresses can be reused in domains administered by different organizations. The
addresses would be considered local, not globally unique.
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.
Procedure
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 687 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.

1120
PA R T X
Firepower Threat Defense VPN
• VPN Overview for Firepower Threat Defense, on page 1123
• Site-to-Site VPNs for Firepower Threat Defense, on page 1135
• Remote Access VPNs for Firepower Threat Defense, on page 1159
• Firepower Threat Defense Dynamic Access Policies Overview , on page 1231
• VPN Monitoring for Firepower Threat Defense, on page 1243
• VPN Troubleshooting for Firepower Threat Defense, on page 1247
CHAPTER 44
VPN Overview for Firepower Threat Defense
A virtual private network (VPN) connection establishes a secure tunnel between endpoints over a public
network such as the Internet.
This chapter applies to Remote Access and Site-to-site VPNs on Firepower Threat Defense devices. It describes
the Internet Protocol Security (IPsec), the Internet Security Association and Key Management Protocol
(ISAKMP, or IKE) and SSL standards that are used to build site-to-site and remote access VPNs.
• VPN Types, on page 1123
• VPN Basics, on page 1124
• VPN Packet Flow, on page 1126
• VPN Licensing, on page 1126
• How Secure Should a VPN Connection Be?, on page 1126
• Removed or Deprecated Hash Algorithms, Encryption Algorithms, and Diffie-Hellman Modulus Groups,
on page 1131
• VPN Topology Options, on page 1131
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.

1123
VPN Basics
• 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.
Internet Key Exchange (IKE)

and distribute IPsec encryption keys, and to automatically establish IPsec security associations (SAs).
The IKE negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers,
which enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes
SAs for other applications, such as IPsec. Both phases use proposals when they negotiate a connection.
An IKE policy is a set of algorithms that two peers use to secure the IKE negotiation between them. IKE
negotiation begins by each peer agreeing on a common (shared) IKE policy. This policy states which security
parameters protect subsequent IKE negotiations. For IKE version 1 (IKEv1), IKE policies contain a single

1124
IPsec
set of algorithms and a modulus group. Unlike IKEv1, in an IKEv2 policy, you can select multiple algorithms
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

1125
VPN Packet Flow
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 Packet Flow

On a FTD device, by default no traffic is allowed to pass through access-control without explicit permission.
VPN tunnel traffic as well, is not relayed to the endpoints until it has passed through Snort. Incoming tunnel
packets are decrypted before being sent to the Snort process. Snort processes outgoing packets before encryption.
Access Control identifying the protected networks for each endpoint node of a VPN tunnel determines which
traffic is allowed to pass through the FTD device and reach the endpoints. For Remote Access VPN traffic,
a Group Policy filter or an Access Control rule must be configured to permit VPN traffic flow.
In addition, the system does not send tunnel traffic to the public source when the tunnel is down.
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.
If you have created your VPN configurations with evaluation license, and upgrade your license from evaluation
to smart license with export-controlled functionality, check and update your encryption algorithms for stronger
encryption and for the VPNs to work properly. DES based encryptions are no longer supported.
How Secure Should a VPN Connection Be?

Because a VPN tunnel typically traverses a public network, most likely the Internet, you need to encrypt the
connection to protect the traffic. You define the encryption and other security techniques to apply using IKE
polices and IPsec proposals.
If your device license allows you to apply strong encryption, there is a wide range of encryption and hash
algorithms, and Diffie-Hellman groups, from which to choose. However, as a general rule, the stronger the

1126
Complying with Security Certification Requirements
encryption that you apply to the tunnel, the worse the system performance. Find a balance between security
and performance that provides sufficient protection without compromising efficiency.
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.
Complying with Security Certification Requirements

Many VPN settings have options that allow you to comply with various security certification standards.
Review your certification requirements and the available options to plan your VPN configuration. See Security
Certifications Compliance, on page 1473 for additional system information related to compliance.
Deciding Which Encryption Algorithm to Use

When deciding which encryption algorithms to use for the IKE policy or IPsec proposal, your choice is limited
to algorithms supported by the devices in the VPN.
For IKEv2, you can configure multiple encryption 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.
For IPsec proposals, the algorithm is used by the Encapsulating Security Protocol (ESP), which provides
authentication, encryption, and anti-replay services. ESP is IP protocol type 50. In IKEv1 IPsec proposals,
the algorithm name is prefixed with ESP-.
If your device license qualifies for strong encryption, you can choose from the following encryption algorithms.
If you are not qualified for strong encryption, you can select DES only.
Note If you are qualified for strong encryption, before upgrading from the evaluation license to a smart license,
check and update your encryption algorithms for stronger encryption so that the VPN configuration works
properly. Choose AES-based algorithms. DES is not supported if you are registered using an account that
supports strong encryption. After registration, you cannot deploy changes until you remove all uses of DES.
• AES-GCM—(IKEv2 only.) Advanced Encryption Standard in Galois/Counter Mode is a block cipher

mode of operation providing confidentiality and data-origin authentication, and provides greater security
than AES. AES-GCM offers three different key strengths: 128-, 192-, and 256-bit keys. A longer key
provides higher security but a reduction in performance. GCM is a mode of AES that is required to
support NSA Suite B. NSA Suite B is a set of cryptographic algorithms that devices must support to
meet federal standards for cryptographic strength. .
• AES—Advanced Encryption Standard is a symmetric cipher algorithm that provides greater security
than DES and is computationally more efficient than 3DES. AES offers three different key strengths:
128-, 192-, and 256-bit keys. A longer key provides higher security but a reduction in performance.
• DES—Data Encryption Standard, which encrypts using 56-bit keys, is a symmetric secret-key block
algorithm. If your license account does not meet the requirements for export controls, this is your only
option.

1127
Deciding Which Hash Algorithms to Use
• Null, ESP-Null—Do not use. A null encryption algorithm provides authentication without encryption.
This is typically used for testing purposes only. However, it does not work at all on many platforms,
including virtual and the Firepower 2100.
Deciding Which Hash Algorithms to Use

In IKE policies, the hash algorithm creates a message digest, which is used to ensure message integrity. In
IKEv2, the hash algorithm is separated into two options, one for the integrity algorithm, and one for the
pseudo-random function (PRF).
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.
• 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.
Deciding Which Diffie-Hellman Modulus Group to Use

You can use the following Diffie-Hellman key derivation algorithms to generate IPsec security association
(SA) keys. Each group has a different size modulus. A larger modulus provides higher security, but requires
more processing time. You must have a matching modulus group on both peers.
If you select AES encryption, to support the large key sizes required by AES, you should use Diffie-Hellman
(DH) Group 5 or higher. IKEv1 policies do not support all of the groups listed below.
To implement the NSA Suite B cryptography specification, use IKEv2 and select one of the elliptic curve
Diffie-Hellman (ECDH) options: 19, 20, or 21. Elliptic curve options and groups that use 2048-bit modulus
are less exposed to attacks such as Logjam.
For IKEv2, you can configure multiple groups. 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.
• 14—Diffie-Hellman Group 14: 2048-bit modular exponential (MODP) group. Considered good protection
for 192-bit keys.

1128
Deciding Which Authentication Method to Use
• 15—Diffie-Hellman Group 15: 3072-bit MODP group.

• 16—Diffie-Hellman Group 16: 4096-bit MODP group.
• 19—Diffie-Hellman Group 19: National Institute of Standards and Technology (NIST) 256-bit elliptic
curve modulo a prime (ECP) group.
• 20—Diffie-Hellman Group 20: NIST 384-bit ECP group.
• 21—Diffie-Hellman Group 21: NIST 521-bit ECP group.
• 31—Diffie-Hellman Group 31: Curve25519 256-bit EC Group.
Deciding Which Authentication Method to Use

Preshared keys and digital certificates are the methods of authentication available for VPNs.
Site-to-site, IKEv1 and IKEv2 VPN connections can use both options.
Remote Access, which uses SSL and IPsec IKEv2 only, supports digital certificate authentication only.
Preshared keys allow for a secret key to be shared between two peers and used by IKE during the authentication
phase. The same shared key must be configured at each peer or the IKE SA cannot be established.
Digital certificates use RSA key pairs to sign and encrypt IKE key management messages. Certificates provide
non-repudiation of communication between two peers, meaning that it can be proved that the communication
actually took place. When using this authentication method, you need a Public Key Infrastructure (PKI)
defined where peers can obtain digital certificates from a Certification Authority (CA). CAs manage certificate
requests and issue certificates to participating network devicesproviding centralized key management for all
of the participating devices.
Preshared keys do not scale well, using a CA improves the manageability and scalability of your IPsec network.
With a CA, you do not need to configure keys between all encrypting devices. Instead, each participating
device is registered with the CA, and requests a certificate from the CA. Each device that has its own certificate
and the public key of the CA can authenticate every other device within a given CA’s domain.
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.
PKI Infrastructure and Digital Certificates
Public Key Infrastructure

A PKI provides centralized key management for participating network devices. It is a defined set of policies,
procedures, and roles that support public key cryptography by generating, verifying, and revoking public key
certificates commonly known as digital certificates.
In public key cryptography, each endpoint of a connection has a key pair consisting of both a public and a
private key. The key pairs are used by the VPN endpoints to sign and encrypt messages. The keys act as

1129
PKI Infrastructure and Digital Certificates
complements, and anything encrypted with one of the keys can be decrypted with the other, securing the data
flowing over the connection.
Generate a general purpose RSA, ECDSA, or EDDSA key pair, used for both signing and encryption, or you
generate separate key pairs for each purpose. Separate signing and encryption keys help to reduce exposure
of the keys. SSL uses a key for encryption but not signing, however, IKE uses a key for signing but not
encryption. By using separate keys for each, exposure of the keys is minimized.
Digital Certificates or Identify 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 668for details on enrolling FTD devices.
Certificate Authority Certificates

In order to validate a peer’s certificate, each participating device must retrieve the CA's certificate from the
server. A CA certificate is used to sign other certificates. It is self-signed and called a root certificate. This
certificate contains the public key of the CA, used to decrypt and validate the CA's digital signature and the
contents of the received peer's certificate. The CA certificate may be obtained by:
• Using the Simple Certificate Enrollment Protocol (SCEP) or Enrollment over Secure Transport (EST)
to retrieve the CA’s certificate from the CA server
• Manually copying the CA's certificate from another participating device
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.

1130
Removed or Deprecated Hash Algorithms, Encryption Algorithms, and Diffie-Hellman Modulus Groups
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.
Removed or Deprecated Hash Algorithms, Encryption

Algorithms, and Diffie-Hellman Modulus Groups
Support has been removed for less secure ciphers. We recommend that you update your VPN configuration
before you upgrade to FTD 6.70 to supported DH and encryption algorithms to ensure the VPN works correctly.
Update your IKE proposals and IPSec policies to match the ones supported in FTD 6.70 and then deploy the
configuration changes.
The following less secure ciphers have been removed or deprecated in FTD 6.70 onwards:
• Diffie-Hellman GROUP 5 is deprecated for IKEv1 and removed for IKEv2
• Diffie-Hellman groups 2 and 24 have been removed.
• Encryption algorithms: 3DES, AES-GMAC, AES-GMAC-192, AES-GMAC-256 have been removed.
Note DES continues to be supported in evaluation mode or for users who do not satisfy
export controls for strong encryption.
NULL is removed in IKEv2 policy, but supported in both IKEv1 and IKEv2
IPsec transform-sets.
VPN Topology Options

When you create a new VPN topology you must, at minimum, give it a unique name, specify a topology type,
and select the IKE version. You can select from three types of topologies, each containing a group of VPN
tunnels:
• Point-to-point (PTP) topologies establish a VPN tunnel between two endpoints.
• Hub and Spoke topologies establish a group of VPN tunnels connecting a hub endpoint to a group of
spoke endpoints.
• Full Mesh topologies establish a group of VPN tunnels among a set of endpoints.

1131
Point-to-Point VPN Topology
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.
Point-to-Point VPN Topology

In a point-to-point VPN topology, two endpoints communicate directly with each other. You configure the
two endpoints as peer devices, and either device can start the secured connection.
The following diagram displays a typical point-to-point VPN topology.
Hub and Spoke VPN Topology

In a Hub and Spoke VPN topology, a central endpoint (hub node) connects with multiple remote endpoints
(spoke nodes). Each connection between the hub node and an individual spoke endpoint is a separate VPN
tunnel. The hosts behind any of the spoke nodes can communicate with each other through the hub node.
The Hub and Spoke topology commonly represent a VPN that connects an organization’s main and branch
office locations using secure connections over the Internet or other third-party network. These deployments
provide all employees with controlled access to the organization’s network. Typically, the hub node is located
at the main office. Spoke nodes are located at branch offices and start most of the traffic.
The following diagram displays a typical Hub and Spoke VPN topology.

1132
Full Mesh VPN Topology
Full Mesh VPN Topology

In a Full Mesh VPN topology, all endpoints can communicate with every other endpoint by an individual
VPN tunnel. This topology offers redundancy so that when one endpoint fails, the remaining endpoints can
still communicate with each other. It commonly represents a VPN that connects a group of decentralized
branch office locations. The number of VPN-enabled managed devices you deploy in this configuration
depends on the level of redundancy you require.
The following diagram displays a typical Full Mesh VPN topology.

1133
Implicit Topologies
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.

1134
CHAPTER 45
Site-to-Site VPNs for Firepower Threat Defense
• About Firepower Threat Defense Site-to-site VPNs, on page 1135
• Requirements and Prerequisites for Site-to-Site VPN, on page 1137
• Managing Firepower Threat Defense Site-to-site VPNs, on page 1138
• Configuring Firepower Threat Defense Site-to-site VPNs, on page 1138
• About Virtual Tunnel Interfaces, on page 1149
• Guidelines and Limitations for Virtual Tunnel Interfaces, on page 1150
• Add a VTI Interface, on page 1152
• Create a Route-based Site-to-Site VPN, on page 1153
• Additional Configurations for VTI, on page 1155
• History for Site-to-Site VPNs, on page 1156
About Firepower Threat Defense Site-to-site VPNs

Firepower Threat Defense site-to-site VPN supports the following features:
• Both IPsec IKEv1 & IKEv2 protocols are supported.
• Certificates and automatic or manual preshared keys for authentication.
• IPv4 & IPv6. All combinations of inside and outside are supported.
• IPsec IKEv2 Site-to-Site VPN topologies provide configuration settings to comply with Security
Certifications.
• Static and Dynamic Interfaces.
• Support for both Firepower Management Center and FTD HA environments.
• VPN alerts when the tunnel goes down.
• Tunnel statistics available using the FTD Unified CLI.
• Support for IKEv1 and IKEv2 back-up peer configuration for point-to-point extranet and hub-and-spoke
VPNs.
• Support for extranet device as hub in 'Hub and Spokes' deployments.
• Support for dynamic IP address for a managed endpoint pairing with extranet device in 'Point to Point'
deployments.

1135
Firepower Threat Defense Site-to-site VPN Guidelines and Limitations
• Support for dynamic IP address for extranet device as an endpoint.

• Support for hub as extranet in 'Hub and Spokes' deployments.
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.
IPsec and IKE

In the Firepower Management Center, site-to-site VPNs are configured based on IKE policies and IPsec
proposals that are assigned to VPN topologies. Policies and proposals are sets of parameters that define the
characteristics of a site-to-site VPN, such as the security protocols and algorithms that are used to secure
traffic in an IPsec tunnel. Several policy types may be required to define a full configuration image that can
be assigned to a VPN topology.
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 Site-to-site VPN Guidelines and Limitations

• A VPN connection can only be made across domains by using an extranet peer for the endpoint not in
the current domain.

1136
Requirements and Prerequisites for Site-to-Site VPN
• A VPN topology cannot be moved between domains.

• Network objects with a 'range' option are not supported in VPN
• 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.
Requirements and Prerequisites for Site-to-Site VPN

Model Support
FTD
Supported Domains
Leaf
User Roles
Admin

1137
Managing Firepower Threat Defense Site-to-site VPNs
Managing Firepower Threat Defense Site-to-site VPNs

Procedure
Step 1 For certificate authentication for your VPNs, you must prepare the devices by allocating trustpoints as described
in Firepower Threat Defense Certificate-Based Authentication, on page 717.
Step 2 Select Devices > VPN > Site To Site to manage your Firepower Threat Defense Site-to-site VPN configurations
and deployments. Choose from the following:
• 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 1138:
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.
• Delete—To delete a VPN deployment, click Delete ( ).

• View VPN status—This status applies to Firepower VPNs ONLY. Currently, no status is displayed for
FTD VPNs. To determine the status of the FTD VPNs, see VPN Monitoring for Firepower Threat Defense,
on page 1243.
• Deploy—Choose Deploy > Deployment; see Deploy Configuration Changes, on page 535.
Note Some VPN settings are validated only during deployment. Be sure to verify that your deployment
was successful.
Configuring Firepower Threat Defense Site-to-site VPNs

Procedure
Step 1 Choose Devices > VPN > Site To Site.Then Add VPN > Firepower Threat Defense Device, or edit a listed
VPN Topology. .
Step 2 Enter a unique Topology Name. We recommend naming your topology to indicate that it is a FTD VPN, and
its topology type.
Step 3 Click Policy Based (Crypto Map) to configre a site-to-site VPN.

1138
FTD VPN Endpoint Options
Step 4 Choose the Network Topology for this VPN.

Step 5 Choose the IKE versions to use during IKE negotiations. IKEv1 or IKEv2.
Default is IKEv2. Select either or both options as appropriate; select IKEv1 if any device in the topology does
not support IKEv2.
For IKEv1, you can configure backup peer for point-to-point extranet VPN. For more information, see FTD
VPN Endpoint Options, on page 1139.
Step 6 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 1139.
• 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 7 (Optional) Specify non-default IKE options for this deployment as described in FTD VPN IKE Options, on
page 1142
Step 8 (Optional) Specify non-default IPsec options for this deployment as described in FTD VPN IPsec Options,
on page 1145
Step 9 (Optional) Specify non-default Advanced options for this deployment as described in FTD Advanced Site-to-site
VPN Deployment Options, on page 1147.
Step 10 Click Save.
The endpoints are added to your configuration.
What to do next
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 1243 and VPN Troubleshooting for Firepower Threat Defense, on page
1247.

Navigation Path
Devices > VPN > Site To Site. Then Add VPN > Firepower Threat Defense Device, or edit a listed VPN
Topology. Open the Endpoint tab.

1139
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).
Note Use this option only when the peer is managed by the same Firepower Management Center and do not
use this option if peer is from extranet.

1140
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:
Table 103: Connection Type Supported Combinations
Remote Node Central Node
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 705 for details.
Protected Networks
Caution In the Hub and Spoke topology, for a dynamic crypto map, ensure that you do not select the protected
network any for both the endpoints to avoid traffic drop.
If the protected networks is configured as any, on both the endpoints, the crypto ACL that works upon
the tunnel is NOT generated.
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 613. 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.

1141
FTD VPN IKE Options
Note Reverse Route Injection is enabled by default in Firepower Management Center.

Subnet/IP Address (Network) remains the default selection.
When you have selected Protected Networks as Any and observe default route
traffic being dropped, disable the Reverse Route Injection under VPN> Site to
Site > edit a VPN > IPsec > Enable Reverse Route Injection. Deploy the
configuration changes; this will remove set reverse-route (Reverse Route Injection)
from the crypto map configuration and remove the VPN-advertised reverse route
that causes the reverse tunnel traffic to be dropped.
• 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.
Advanced Settings
Enable Dynamic Reverse Route Injection— Reverse Route Injection (RRI) is the ability for routes to
be automatically inserted into the routing process for those networks and hosts protected by a remote
tunnel endpoint. Dynamic RRI routes are created only upon the successful establishment of IPsec security
associations (SA’s)
Note • Dynamic RRI is supported only on IKEv2, and not supported on IKEv1 or IKEv1 + IKEv2.
• Dynamic RRI is not supported on: originate-only peer, Full Mesh topology, and Extranet peer.
• In Point-to-Point, only one peer can have dynamic RRI enabled.
• Between Hub and Spoke, only one of the endpoints can have dynamic RRI enabled.
• Dynamic RRI cannot be combined with a dynamic crypto map.
FTD VPN IKE Options

For the versions of IKE you have chosen for this topology, specify the IKEv1/IKEv2 Settings.
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.

1142
FTD VPN IKE Options
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 691
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 1129.
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 669, 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 720
• Installing a Certificate using EST Enrollment, on page 721

1143
FTD VPN IKE Options
• Installing a Certificate Using SCEP Enrollment, on page 720

• Installing a Certificate Using Manual Enrollment, on page 722
• Installing a Certificate Using a PKCS12 File, on page 723
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 610 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
Manual No override required Override required Override required
EST No override required Override required Override required
SCEP No override required Override required Override required
PKCS Override required Override required Override required
Self-signed Not applicable Not applicable Not applicable
• Understand the VPN certificate limitations mentioned in Firepower Threat Defense VPN
Certificate Guidelines and Limitations, on page 718.
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.

1144
FTD VPN IPsec Options
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.

1145
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 695 and Configure IKEv2 IPsec Proposal Objects, on
page 695 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.
Enable Reverse Route Injection
Reverse Route Injection (RRI) enables static routes to be automatically inserted into the routing process
for those networks and hosts protected by a remote tunnel endpoint.
Enable Perfect Forward Secrecy
Whether to 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
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. For a full explanation of the options,
see Deciding Which Diffie-Hellman Modulus Group to Use, on page 1128.
Lifetime Duration
The number of seconds a security association exists before expiring. The default is 28,800 seconds.
Lifetime Size
The volume of traffic (in kilobytes) that can pass between IPsec peers using a given security association
before it expires. The default is 4,608,000 kilobytes. Infinite data is not allowed.
ESPv3 Settings
Validate incoming ICMP error messages
Choose whether to validate ICMP error messages received through an IPsec tunnel and destined
for an interior host on the private network.
Enable 'Do Not Fragment' Policy
Define how the IPsec subsystem handles large packets that have the do-not-fragment (DF) bit set
in the IP header.
Policy
• Copy DF bit—Maintains the DF bit.
• Clear DF bit—Ignores the DF bit.
• Set DF bit—Sets and uses the DF bit.
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.

1146
FTD Advanced Site-to-site VPN Deployment Options
FTD Advanced Site-to-site VPN Deployment Options

The following sections describes the advanced options you can specify in your S2S VPN deployment. These
settings apply to the entire topology, all tunnels, and all managed devices.
FTD VPN Advanced IKE Options
Advanced > IKE > ISAKAMP Settings

IKE Keepalive
Enable or disables IKE Keepalives. Or set to EnableInfinite specifying that the device never starts
keepalive monitoring itself.
Threshold
Specifies the IKE keep alive confidence interval. This is the number of seconds allowing a peer to
idle before beginning keepalive monitoring. The minimum and default is 10 seconds; the maximum
is 3600 seconds.
Retry Interval
Specifies number of seconds to wait between IKE keep alive retries. The default is 2 seconds, the
maximum is 10 seconds.
Identity Sent to Peers:
Choose the identity that the peers will use to identify themselves during IKE negotiations:
• autoOrDN(default)—Determines IKE negotiation by connection type: IP address for preshared
key, or Cert DN for certificate authentication (not supported).
• ipAddress—Uses the IP addresses of the hosts exchanging ISAKMP identity information.
• hostname—Uses the fully qualified domain name of the hosts exchanging ISAKMP identity
information. This name comprises the hostname and the domain name.
Note Enable or disable this option for all your VPN connections.
Enable Aggressive Mode

Available only in a hub-and-spoke VPN topology. Select this negotiation method for exchanging key
information if the IP address is not known and DNS resolution might not be available on the devices.
Negotiation is based on hostname and domain name.
Advanced > IKE > IVEv2 Security Association (SA) Settings

More session controls are available for IKE v2 that limit the number of open SAs. By default, there is no limit
to the number of open SAs:
Cookie Challenge
Whether to send cookie challenges to peer devices in response to SA initiate 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:
• Never (default)

1147
FTD VPN Advanced IPsec Options
• Always
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%.
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.
Maximum number of SAs Allowed
Limits the number of allowed IKEv2 connections. Default is unlimited.
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.
FTD VPN Advanced IPsec Options
Advanced > IPsec > IPsec Settings

Enable Fragmentation Before Encryption
This option lets traffic travel across NAT devices that do not support IP fragmentation. It does not impede
the operation of NAT devices that do support IP fragmentation.
Path Maximum Transmission Unit Aging
Check to enable PMTU (Path Maximum Transmission Unit) Aging, the interval to Reset PMTU of an
SA (Security Association)
Value Reset Interval
Enter the number of minutes at which the PMTU value of an SA (Security Association) is reset to its
original value. Valid range is 10 to 30 minutes, default is unlimited.
FTD Advanced Site-to-site VPN Tunnel Options
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.

1148
About Virtual Tunnel Interfaces
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.
Access Control for VPN Traffic

• Bypass Access Control policy for decrypted traffic (sysopt permit-vpn) — Decrypted traffic is
subjected to access control policy inspection by default. Enable this option to bypasses the ACL inspection;
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.
Certificate Map Settings

• Use the certificate map configured in the Endpoints to determine the tunnel—If this option is enabled
(checked), the tunnel will be determined by matching the contents of the received certificate to the
certificate map objects configured in the endpoint nodes.
• Use the certificate OU field to determine the tunnel—Indicates that if a node is not determined based
on the configured mapping (the above option) if selected, then use the value of the organizational unit
(OU) in the subject distinguished name (DN) of the received certificate to determine the tunnel.
• Use the IKE identity to determine the tunnel—Indicates that if a node is not determined based on a
rule matching or taken from the OU (the above options) if selected, then the certificate-based IKE sessions
are mapped to a tunnel based on the content of the phase1 IKE ID.
• Use the peer IP address to determine the tunnel—Indicates that if a tunnel is not determined based
on a rule matching or taken from the OU or IKE ID methods (the above options) if selected, then use the
established peer IP address.
About Virtual Tunnel Interfaces

Firepower Management Center supports a logical interface called Virtual Tunnel Interface (VTI). As an
alternative to policy based VPN, a VPN tunnel can be created between peers with Virtual Tunnel Interfaces
configured. This supports route-based VPN with IPsec profiles attached to the end of each tunnel. This allows
dynamic or static routes to be used. Egressing traffic from the VTI is encrypted and sent to the peer, and the
associated SA decrypts the ingress traffic to the VTI.
Using VTI does away with the requirement of configuring static crypto map access lists and mapping them
to interfaces. You no longer have to track all remote subnets and include them in the crypto map access list.
Deployments become easier, and having static VTI which supports route based VPN with dynamic routing
protocol also satisfies many requirements of a virtual private cloud. FMC enables you to easily migrate from
crypto-map based VPN configuration to VTI-based VPN.
You can configure route-based VPN in FMC, FTD Device REST API, and FDM by configuring a static
Virtual Tunnel Interface. FMC supports a site-to-site VPN wizard with defaults to configure VTI or route-based
VPN. Traffic is encrypted using static route or BGP.
You can create a routed security zone, add VTI interfaces to it, and define access control rules for the decrypted
traffic control over the VTI tunnel.

1149
Backup Tunnel for VTI
VTI-based VPNs can be created between:

• Two FTD devices
• FTD and public cloud
• FTD and another FTD with service provider redundancy
• FTD and any other device with VTI interfaces configured
Backup Tunnel for VTI

Firepower Threat Defense supports configuration of a backup tunnel for the route-based (VTI) VPN. When
the primary VTI is unable to route the traffic, the traffic in the VPN is tunneled through the backup VTI.
You can deploy the backup tunnel in the following scenarios:
• Both peers having service provider redundancy backup. In this case, there are two physical interfaces,
acting as the tunnel sources for the two VTIs of the peers.
• Only one of the peers having service provider redundancy backup. In this case, there is an interface
backup on only one side of the peer and on the other end, there is only one tunnel source interface.
Configuring Backup Interface

To configure backup VTIs:
• Create the VTI interfaces as described in Add a VTI Interface, on page 1152.
• Configure the backup interfaces on the peers in the Create New VPN Topology window. Use the Add
Backup VTI option for each peer to configure the respective backup interface. For detailed procedure,
see Create a Route-based Site-to-Site VPN, on page 1153.
• If one of the peers is not managed in FMC (an Extranet peer), you can still specify the backup interfaces
tunnel source IP address and configure the tunnel destination IP on the managed peer. You can specify
the backup peer IP address in the Endpoint IP Address field. For detailed procedure, see Step 11.
• After you configure the backup interfaces, configure the routing policy and access control policy for
routing traffic. Though primary and backup VTIs are always available, traffic would be flowing only
through the tunnel that is configured in the routing policy. For detailed information, see Additional
Configurations for VTI, on page 1155.
Guidelines and Limitations for Virtual Tunnel Interfaces

Limitations
• Only 20 unique IPSec profiles are supported.
• Dynamic VTI, OSPF, and QoS are not supported.
• Site-to-site VPN tunnels created with VTIs do not generate health alerts when the tunnel goes down. If
you experience packet loss over a VPN with VTIs, check your VPN configuration.

1150
Guidelines and Limitations for Virtual Tunnel Interfaces
General Configuration Guidelines

• VTIs are only configurable in IPsec mode.
• You can use dynamic or static routes for traffic using the tunnel interface.
• You can configure a maximum of 1024 VTIs on a device. While calculating the VTI count, consider the
following:
• Include nameif subinterfaces to derive the total number of VTIs that can be configured on the device.
• You cannot configure nameif on member interfaces of a portchannel. Therefore, the tunnel count
is reduced by the count of actual main portchannel interfaces alone and not any of its member
interfaces.
• The VTI count on a platform is limited to the number of VLANs configurable on that platform. For
example, Firepower 1120 supports 512 VLANs, the tunnel count would be 512 minus the number
of physical interfaces configured.
• If you are configuring more than 400 VTIs on a device in a high-availability setup, you must configure
45 seconds as the Unit holdtime for the FTD-HA.
• The MTU for VTIs is automatically set, according to the underlying physical interface.
• VTI supports IKE versions v1, v2, and uses IPsec for sending and receiving data between the tunnel's
source and destination.
• If Network Address Translation has to be applied, the IKE and ESP packets will be encapsulated in the
UDP header.
• IKE and IPsec security associations will be re-keyed continuously regardless of data traffic in the tunnel.
This ensures that VTI tunnels are always up.
• Tunnel group name must match what the peer will send as its IKEv1 or IKEv2 identity.
• For IKEv1 in LAN-to-LAN tunnel groups, you can use names which are not IP addresses, if the tunnel
authentication method is digital certificates and/or the peer is configured to use aggressive mode.
• VTI and crypto map configurations can co-exist on the same physical interface, provided the peer address
configured in the crypto map and the tunnel destination for the VTI are different.
• By default, all traffic sent through a VTI is encrypted.
• There are no security level configurations for VTI interfaces.
• Access list can be applied on a VTI interface to control traffic through VTI.
IPv6 Support
• IPv6 addressed VTIs can be configured.
• The tunnel source interface can have an IPv6 address and the same address can be used as the tunnel
endpoint.
• Following combinations of VTI IP (or internal networks IP version) over public IP versions are supported:
• IPv6 over IPv6
• IPv4 over IPv6

1151
Add a VTI Interface
• IPv4 over IPv4

• IPv6 over IPv4
• Only static IPv6 address is supported as the tunnel source and destination.
• IPv6 BGP is not supported over VTI.
• The tunnel source interface can have IPv6 addresses and you can specify which address to be used as
the tunnel endpoint. If you do not specify, by default, the first IPv6 global address in the list is used as
the tunnel endpoint.
• You can specify IPv4 or IPv6 as tunnel mode for a single VTI. If IPv6 is specified, the IPv6 traffic can
be tunneled through the VTI.
Multi-instance
VTI is supported in multi-instance.
Firewall Mode
VTI is supported in routed mode only.
Backup VTI Guidelines and Limitations

• Flow resilency across tunnel failovers is not supported. For example, the clear text TCP connection gets
lost after a tunnel failover, and you need to re-initiate any FTP transfer that took place during the failover.
• Certificate authentication is not supported in backup VTI.
Add a VTI Interface

For configuring a route-based site-to-site VPN, you must create a Virtual Tunnel Interface on the devices at
both the nodes of the VTI tunnel. To create a new VTI interface, perform the following steps:
Procedure

Step 2 Click the Edit icon next to the device on which you want to create a VTI interface.
Step 3 From the Add Interfaces drop-down menu, choose Virtual Tunnel Interface.
Step 4 In the Name field, enter a name for the new VTI.
Step 5 Keep the Enabled checkbox checked (default) to enable the interface once you finish creating it.
Step 6 (Optional) Enter a description for the new VTI.
Step 7 (Optional) In the Security Zone drop-down menu, select a security zone to add the VTI interface to that zone.
If you want to do traffic inspection based on security zone, you can add the VTI to the security zone and
configure an access control rule. To permit the VPN traffic over the tunnel, you need to add an AC rule with
this security zone as the source zone.
Step 8 In the Tunnel ID field, enter a unique tunnel ID in the range of 0-10413.

1152
Create a Route-based Site-to-Site VPN
Step 9 Under IPSec Tunnel Mode, click IPv4 or IPv6 to specify the IPsec tunnel mode. You can only select one
mode per VTI:
a) If you have selected IPv4, the IPv4 Address field is enabled. Enter the IPv4 address and subnet to use
for the tunnel endpoint. The VTI IP addresses of both endpoints of a route-based VPN must be in the
same subnet.
Note Cisco recommends you to use IP from 169.254.x.x/16 range excluding the FTD reserved range
(169.254.1.x/24). Also, use /30 as net-mask to optimally use only two addresses for two ends
of the VTI tunnel. For example, 169.254.100.1/30
b) If you have selected IPv6, the IPv6 Address field is enabled. Enter the IPv6 address and subnet to use
for the tunnel endpoint. The VTI IP addresses of both endpoints of a route-based VPN must be in the
same subnet.
Step 10 In the Tunnel Source drop-down menu, select the tunnel source interface. When you select the tunnel source
interface, the IP addresses configured on the interface are listed in the drop-down. You can select the desired
IPv4 or IPv6 address irrespective of the IPsec tunnel mode. In case of multiple IPv6 addresses, select the
address that you want to use as the tunnel endpoint.
Step 11 Click OK.

You can configure a route-based site-to-site VPN between two nodes. You need virtual tunnel interfaces at
both the nodes of the tunnel in order to configure a VTI-based VPN.
For more information on VTI, see About Virtual Tunnel Interfaces, on page 1149
Procedure
Step 1 Choose Devices > Site To Site.

Step 2 In the Add VPN drop-down menu, choose Firepower Threat Defense Device.
Step 3 In the Topology Name field, enter a name for the VPN topology that you are creating.
Step 4 Choose Route Based (VTI) as the topology type. Network topology is selected as Point to Point and IKE
protocol version is selected as IKEv2 by default for the site-to-site configuration.
Step 5 Under Node A in the Endpoints tab, in the Device drop-down menu, select the name of the registered device
(FTD) or Extranet to be used as the first endpoint of your VTI tunnel.
Step 6 For a registered device, you can specify the interface for Node A:
• In the Virtual Tunnel Interface drop-down menu, select the VTI interface, which you had created on
FTD device that you have selected as Node A.
• If you want to create a new interface on Node A, click the + icon and fill the fields as described in Add
a VTI Interface, on page 1152.
• If you want to edit the configuration of an existing VTI, select the VTI in the Virtual Tunnel Interface
drop-down field and click Edit VTI.

1153
Note The selected tunnel interface is the source interface for Node A and it becomes the tunnel
destination for Node B.
Step 7 If your Node A device is behind a NAT device, check the Tunnel Source IP is Private checkbox . In the
Tunnel Source Public IP Address field, enter the tunnel source public IP address.
Step 8 (Optional) Click Add Backup VTI to specify an additional VTI as the backup interface.
Note Ensure that both peers of the topology does not have backup VTI configured on the same tunnel
source. For instance, if Peer A is having 2 VTIs (primary and a backup) configured with a single
tunnel source interface, say, 10.10.10.1/30, then Peer B also cannot have its 2 VTIs with a single
tunnel source IP, say 20.20.20.1/30.
Note Though the virtual tunnel interface is specified under Backup VTI, the routing configuration
determines which tunnel to be used as primary or backup.
You can do the following:

• To create a new backup interface, use the + icon.
• To edit the configuration of an existing Backup VTI, use Edit VTI.
Note If your Node A device is behind a NAT device, check the Tunnel Source IP is Private checkbox
. In the Tunnel Source Public IP Address field, enter the tunnel source public IP address.
Step 9 In the Connection Type drop-down menu, select Answer Only or Birectional. If you have selected IKE
protocol version as IKEv1, one of the nodes must be Answer Only.
Step 10 Under Additional Configuration, do the following:
• To route traffic to the VTI, click Routing Policy. FMC displays the Devices > Routing page. You can
configure the Static or BGP routing for the VPN traffic.
• To permit VPN traffic, click AC Policy. FMC displays the access control policy page of the device.
Proceed to add allow/block rule specifying the security zone of the VTI. If a backup VTI is being
configured, ensure to include the backup tunnel to the same security zone as that of the primary VTI. No
specific settings is required for the backup VTI in the AC policy page.
Step 11 For an extranet peer, specify the following parameters:

a) In the Device Name, enter the name of the device.
b) In the Endpoint IP address, enter the primary IP address. If you are configuring a backup VTI, enter a
comma and then specify the backup IP address.
c) Click IKE tab and specify the pre-shared key provided on the extranet.
Note The AWS VPC has AES-SHA-SHA-LATEST as the default policy. Therefore, if the remote
peer connects to AWS VPC, from the Policy drop-down list, select AES-SHA-SHA-LATEST
to establish the VPN connection without the need to change the default value in AWS .
Step 12 Repeat the above procedure for Node B.

1154
Additional Configurations for VTI
Additional Configurations for VTI

After you configure VTI interfaces and VTI tunnel on both the devices, you must configure a routing policy
to route VTI traffic between the devices over the VTI tunnel. You must also configure an access control rule
to allow encrypted traffic.
Routing Configuration for VTI

Static Route
Configure static routing on both the devices (both the ends) to route the traffic flow between the devices over
the VTI tunnel.
If backup tunnel is configured for the VPN, configure a static route with a different metric to handle the
failover of the traffic flow over the backup tunnel.
Ensure that you configure the following when you configure a static route:
• Interface—Select the VTI interface used in the VPN. In case of backup tunnel, select the backup VTI
interface used in the VPN.
• Selected Network—Select the remote peer’s protected network (added as a network object).
• Gateway—Select the remote peer’s tunnel interface IP address as the gateway. In case of backup tunnel,
select the remote peer’s backup tunnel interface IP address as the gateway.
For more information about static routing, see Add a Static Route, on page 1050.
Border Gateway Protocol (BGP)
Note IPv6 BGP is not supported over VTI.
Configure BGP on both the devices to share routing information and to route traffic flow between the devices
over the tunnel with the following settings:
• Under General Settings > BGP, enable BGP, provide the AS number of the local device, and add Router
Id (if you choose Manual).
• Under BGP, enable IPv4 and configure neighbors on the Neighbor tab.
• IP Address—Specify the remote peer’s VTI interface IP address as the neighbor's IP address. If
backup tunnel is configured for the VPN, add a neighbor with the remote peer's backup VTI interface
IP address as well.
• Remote AS—Specify the remote peer’s AS number.
For more information about BGP configuration, see Configure BGP, on page 1085.
AC Policy Rule
Add an access control rule to the access control policy on the device to allow encrypted traffic between the
VTI tunnels with the following settings:

1155
History for Site-to-Site VPNs
• Create the rule with the Allow action.

• Select the VTI security zone of the local device as the Source Zone and the VTI security zone of the
remote peer as the Destination Zone.
• Select the VTI security zone of the remote peer as the Source Zone and the VTI security zone of the local
device as the Destination Zone.
For more information about configuring an access control rule, see Create and Edit Access Control Rules, on
page 1643.
Note If backup VTI is configured, ensure to include the backup tunnel to the same security zone as that of the
primary VTI. No specific settings are required for the backup VTI in the AC policy page.

Backup virtual tunnel interfaces 7.0 When you configure a site-to-site

(VTI) for route-based site-to-site VPN that uses virtual tunnel
VPN. interfaces, you can select a backup
VTI for the tunnel. Specifying a
backup VTI provides resiliency, so
that if the primary connection goes
down, the backup connection might
still be functional. For example,
you could point the primary VTI to
the endpoint of one service
provider, and the backup VTI to the
endpoint of a different service
provider.
You can add a backup VTI in the
site-to-site VPN wizard by selecting
Route-Based as the VPN type for
a point-to-point connection.
Enhnace the number of VTI from 7.0 Support for maximum number of
100 per interface to 1024 per device VTIs is enhanced from 100 per
physical interface to 1024 VTIs per
device.
IPv6 Support 7.0 You can configure IPv6 addressed

VTIs. While only static IPv6
address is supported as the tunnel
source and destination, IPv6 BGP
is not supported over VTI.

1156
Removal and deprecation of weak 6.7 Support has been removed for less
ciphers secure ciphers. We recommend that
you update your VPN configuration
before you upgrade to FTD 6.70 to
supported DH and encryption
algorithms to ensure the VPN
works correctly.
Update your IKE proposals and
IPSec policies to match the ones
supported in FTD 6.70 and then
deploy the configuration changes.
The following less secure ciphers
have been removed or deprecated
in FTD 6.70 onwards:
• Diffie-Hellman GROUP 5 is
deprecated for IKEv1 and
removed for IKEv2
• Diffie-Hellman groups 2 and
24 have been removed.
• Encryption algorithms:
3DES, AES-GMAC,
AES-GMAC-192,
AES-GMAC-256 have been
removed.
Note DES continues to
be supported in
evaluation mode or
for users who do
not satisfy export
controls for strong
encryption.
NULL is removed
in IKEv2 policy,
but supported in
both IKEv1 and
IKEv2 IPsec
transform-sets.
Dynamic RRI support 6.7 Dynamic Reverse Route Injection

is supported with IKEv2 based
static crypto maps.

1157
Backup peer for site-to-site VPN 6.6 You can use the FMC to add a
backup peer to a site-to-site VPN
connection. For example, if you
have two ISPs, you can configure
the VPN connection to fail over to
the backup ISP if the connection to
the first ISP becomes unavailable.

1158
CHAPTER 46
Remote Access VPNs for Firepower Threat
Defense
• Firepower Threat Defense Remote Access VPN Overview, on page 1159
• License Requirements for Remote Access VPN, on page 1165
• Requirements and Prerequisites for Remote Access VPN, on page 1165
• Guidelines and Limitations for Remote Access VPNs, on page 1166
• Configuring a New Remote Access VPN Connection, on page 1168
• Setting Target Devices for a Remote Access VPN Policy, on page 1175
• Additional Remote Access VPN Configurations, on page 1175
• Customizing Remote Access VPN AAA Settings, on page 1205
• Remote Access VPN Examples, on page 1224
• History for Remote Access VPNs, on page 1229
Firepower Threat Defense Remote Access VPN Overview

Firepower Threat Defense provides secure gateway capabilities that support remote access SSL and IPsec-IKEv2
VPNs. The full tunnel client, AnyConnect Secure Mobility Client, provides secure SSL and IPsec-IKEv2
connections to the security gateway for remote users. AnyConnect is the only client supported on endpoint
devices for remote VPN connectivity to Firepower Threat Defense devices. The client gives remote users the
benefits of an SSL or IPsec-IKEv2 VPN client without the need for network administrators to install and
configure clients on remote computers. The AnyConnect mobile client for Windows, Mac, and Linux is
deployed from the secure gateway upon connectivity. The AnyConnect apps for Apple iOS and Android
devices are installed from the platform app store.
Use the Remote Access VPN Policy wizard in the Firepower Management Center to quickly and easily set
up SSL and IPsec-IKEv2 remote access VPNs with basic capabilities. Then, enhance the policy configuration
if desired and deploy it to your Firepower Threat Defense secure gateway devices.
You can configure the following settings using the remote access VPN policy:
• Two-Factor Authentication, on page 1215
• Secondary Authentication, on page 1218
• Manage Password Changes over VPN Sessions, on page 1208
• Send Accounting Records to the RADIUS Server, on page 1209

1159
Remote Access VPN Features
• Override the Selection of Group Policy or Other Attributes by the Authorization Server , on page 1211
• Deny VPN Access to a User Group, on page 1211
• Restrict Connection Profile Selection for a User Group, on page 1212
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 1224
• How to Use VPN Identity for User-id Based Access Control Rules, on page 1226
Remote Access VPN Features

The following section describes the features of Firepower Threat Defense remote access VPN:
• SSL and IPsec-IKEv2 remote access using the Cisco AnyConnect Secure Mobility Client.
• Firepower Management Center supports all combinations such as IPv6 over an IPv4 tunnel.
• Configuration support on both FMC and FDM. Device-specific overrides.
• Support for both Firepower Management Center and FTD HA environments.
• Support for multiple interfaces and multiple AAA servers.
• Rapid Threat Containment support using RADIUS CoA or RADIUS dynamic authorization.
• Support for DTLS v1.2 protocol with Cisco AnyConnect Secure Mobility Client version 4.7 or higher.
• AnyConnect client modules support for additional security services for RA VPN connections.
• VPN load balancing.
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.
• LDAP or AD authorization attributes using Firepower Management Center web interface.
• Suport for single sign-on using SAML 2.0.
VPN Tunneling
• Address assignment
• Split tunneling

1160
AnyConnect Components
• Split DNS
• Client Firewall ACLs
• Session Timeouts for maximum connect and idle time
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.
AnyConnect Secure Mobility Client Operation

When the client negotiates a connection with the security appliance, the client connects using Transport Layer
Security (TLS), and optionally, Datagram Transport Layer Security (DTLS). DTLS avoids latency and
bandwidth problems associated with some SSL connections and improves the performance of real-time
applications that are sensitive to packet delays.
When an IPsec-IKEv2 VPN client initiates a connection to the secure gateway, negotiation consists of
authenticating the device through Internet Key Exchange (IKE), followed by user authentication using IKE
Extended Authentication (Xauth). The group profile is pushed to the VPN client and an IPsec security
association (SA) is created to complete the VPN.
AnyConnect Client Profile and Editor

An AnyConnect client profile is a group of configuration parameters, stored in an XML file that the VPN
client uses to configure its operation and appearance. These parameters (XML tags) include the names and
addresses of host computers and settings to enable more client features.

1161
Remote Access VPN Authentication
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.
Remote Access VPN Authentication

Remote Access VPN Server Authentication
Firepower Threat Defense secure gateways always use certificates to identify and authenticate themselves to
the VPN client endpoint.
While setting up the remote access VPN configuration using the wizard, you can enroll the selected certificate
on the targeted Firepower Threat Defense device. In the wizard, under Access & Certificate phase, select
“Enroll the selected certificate object on the target devices” option. The certificate enrollment gets automatically
initiated on the specified devices. As you complete the Remote Access VPN configuration, you can view the
status of the enrolled certificate under the device certificate homepage. The status provides a clear standing
as to whether the certificate enrollment was successful or not. Your Remote Access VPN configuration is
now fully completed and ready for deployment.
Obtaining a certificate for the secure gateway, also known as PKI enrollment, is explained in Firepower Threat
Defense Certificate-Based Authentication, on page 717. This chapter contains a full description of configuring,
enrolling, and maintaining gateway certificates.
Remote Access VPN Client AAA

For both SSL and IPsec-IKEv2, remote user authentication is done using usernames and passwords only,
certificates only, or both.
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.
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 and Realm Directory, on page 2418 and
RADIUS Server Groups, on page 710.
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.

1162
Understanding Policy Enforcement of Permissions and Attributes
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 2487 and Access Control Policies, on page 1617
sections.
Related Topics
Understanding Policy Enforcement of Permissions and Attributes

The Firepower Threat Defense device supports applying user authorization attributes (also called user
entitlements or permissions) to VPN connections from an external authentication server and/or authorization
AAA server (RADIUS) or from a group policy on the Firepower Threat Defense device. If the Firepower
Threat Defense device receives attributes from the external AAA server that conflicts with those configured
on the group policy, then attributes from the AAA server always take the precedence.
The Firepower Threat Defense device applies attributes in the following order:
1. User attributes on the external AAA server—The server returns these attributes after successful user
authentication and/or authorization.
2. Group policy configured on the Firepower Threat Defense device—If a RADIUS server returns the
value of the RADIUS Class attribute IETF-Class-25 (OU= group-policy) for the user, the Firepower
Threat Defense device places the user in the group policy of the same name and enforces any attributes
in the group policy that are not returned by the server.
3. Group policy assigned by the Connection Profile (also known as Tunnel Group)—The Connection
Profile has the preliminary settings for the connection, and includes a default group policy applied to the
user before authentication.
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

1163
Understanding AAA Server Connectivity
Understanding AAA Server Connectivity

LDAP, AD, and RADIUS AAA servers must be reachable from the Firepower Threat Defense device for
your intended purposes: user-identity handling only, VPN authentication only, or both activities. AAA servers
are used in remote access VPN for the following activities:
• User-identity handling— the servers must be reachable over the Management interface.
On the Firepower Threat Defense device, the Management interface has a separate routing process and
configuration from the regular interfaces used by VPN.
• VPN authentication—the servers must be reachable over one of the regular interfaces: the Diagnostic
interface or a data interface.
For regular interfaces, two routing tables are used. A management-only routing table for the Diagnostic
interface as well as any other interfaces configured for management-only, and a data routing table used
for data interfaces. When a route-lookup is done, the management-only routing table is checked first,
and then the data routing table. The first match is chosen to reach the AAA server.
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 821.
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.

1164
License Requirements for Remote Access VPN
• show network and show network-static-routes ro view the Management interface default route and
static routes.
• show route to view data traffic routing table entries.
• ping system and traceroute system to verify the path to the AAA server through the Management
interface.
• ping interface ifname and traceroute destination to verify the path to the AAA server through the
Diagnostic and data interfaces.
• test aaa-server authentication and test aaa-server authorization to test authentication and authorization
on the AAA server.
• clear aaa-server statistics groupname or clear aaa-server statistics protocol protocol to clear AAA
server statistics by group or protocol.
• aaa-server groupname active host hostname to activate a failed AAA server, or aaa-server
groupname fail host hostname to fail a AAA server.
• debug ldap level, debug aaa authentication, debug aaa authorization, and debug aaa accounting.
License Requirements for Remote Access VPN

FTD License
FTD remote access VPN requires Strong Encryption and one of the following licenses for AnyConnect:
• AnyConnect Plus
• AnyConnect Apex
Requirements and Prerequisites for Remote Access VPN

Model Support
FTD
Supported Domains
Any
User Roles
Admin

1165
Guidelines and Limitations for Remote Access VPNs

Remote Access VPN Policy Configuration
• You can add a new remote access VPN policy only by using the wizard. You must proceed through the
entire wizard to create a new policy; the policy will not be saved if you cancel before completing the
wizard.
• Two users must not edit a remote access VPN policy at the same time; however, the web interface does
not prevent simultaneous editing. If this occurs, the last saved configuration persists.
• Moving a Firepower Threat Defense device from one domain to another domain is not possible if a
remote access VPN policy is assigned to that device.
• Firepower 9300 and 4100 series in cluster mode do not support remote access VPN configuration.
• Remote access VPN connectivity could fail if there is an FTD NAT rule is misconfigured.
• Whenever IKE ports 500/4500 or SSL port 443 is in use or when there are some PAT translations that
are active, the AnyConnect IPSec-IKEv2 or SSL remote access VPN cannot be configured on the same
port as it fails to start the service on those ports. These ports must not be used on the Firepower Threat
Defense device before configuring Remote Access VPN.
• While configuring remote access VPNs using the wizard, you can create in-line certificate enrollment
objects, but you cannot use them to install the identity certificate. Certificate enrollment objects are used
for generating the identity certificate on the Firepower Threat Defense device being configured as the
remote access VPN gateway. Install the identity certificate on the device before deploying the remote
access VPN policy to the device. For more information about how to install the identity certificate based
on the certificate enrollment object, see The Object Manager, on page 602.
• After you change the remote access VPN policy configurations, re-deploy the changes to the Firepower
Threat Defense devices. The time it takes to deploy configuration changes depends on multiple factors
such as complexity of the policies and rules, type and volume of configurations you send to the device,
and memory and device model. Before deploying remote access VPN policy changes, review the Best
Practices for Deploying Configuration Changes, on page 526.
Concurrent VPN Sessions Capacity Planning

The maximum concurrent VPN sessions are governed by platform-specific limits and have no dependency
on the license. There is a maximum limit to the number of concurrent remote access VPN sessions allowed
on a device based on the device model. This limit is designed so that system performance does not degrade
to unacceptable levels. Use these limits for capacity planning.
Device Model Maximum Concurrent Remote Access VPN Sessions
Firepower 2110 1500
Firepower 2120 3500
Firepower 2130 7500
Firepower 2140 10000

1166
For capacity of other hardware models, contact your sales representative.
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
Controlling Cipher Usage for VPN

To prevent use of ciphers greater than DES, pre-deployment checks are available at the following locations
in the Firepower Management Center:
Devices > Platform Settings > SSL Settings
Devices > VPN > Remote Access > Advanced > IPsec
For more information about SSL settings and IPsec, see Configure SSL Settings , on page 1437 and Configure
Remote Access VPN IPsec/IKEv2 Parameters, on page 1199.
Authentication, Authorization, and Accounting

• Firepower Threat Defense device supports authentication of remote access VPN users using
system-integrated authentication servers only; a local user database is not supported.
• Configure DNS on each device in the topology in to use remote access VPN. Without DNS, the device
cannot resolve AAA server names, named URLs, and CA Servers with FQDN or Hostnames; it can only
resolve IP addresses.
You can configure DNS using the Platform Settings. For more information, see Configure DNS, on page
1427 and DNS Server Group Objects, on page 678.
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.
Unsupported Features of AnyConnect

The only supported VPN client is the Cisco AnyConnect Secure Mobility Client. No other clients or native
VPNs are supported. Clientless VPN is not supported for VPN connectivity; it is only used to deploy the
AnyConnect client using a web browser.
The following AnyConnect features are not supported when connecting to an FTD secure gateway:
• AnyConnect Customization and Localization support. The FTD device does not configure or deploy the
files necessary to configure AnyConnect for these capabilities.
• TACACS, Kerberos (KCD Authentication and RSA SDI).
• Browser Proxy.

1167
Configuring a New Remote Access VPN Connection
Configuring a New Remote Access VPN Connection

This section provides instructions to configure a new remote access VPN policy with Firepower Threat Defense
devices as VPN gateways and Cisco AnyConnect as the VPN client.
Do This More Info
Step Review the guidelines and prerequisites. Guidelines and Limitations for Remote Access VPNs,
1 on page 1166
Prerequisites for Configuring Remote Access VPN, on
page 1168
Step Create a new remote access VPN policy Create a New Remote Access VPN Policy, on page 1169
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 1171
Step (Optional) Configure a NAT exemption (Optional) Configure NAT Exemption, on page 1172
4 rule if NAT is configured on the device.
Step Configure DNS. Configure DNS, on page 1173

5
Step Add an AnyConnect Client Profile. Add an AnyConnect Client Profile XML File, on page
6 1173
Step Deploy the remote access VPN policy. Deploy Configuration Changes, on page 535
7
Step (Optional) Verify the remote access VPN Verify the Configuration, on page 1174
8 policy configuration.
Prerequisites for Configuring Remote Access VPN

• Deploy Firepower Threat Defense devices and configure Firepower Management Center to manage the
device with required licenses with export-controlled features enabled. For more information, see VPN
Licensing, on page 1126.
• Configure the certificate enrollment object that is used to obtain the identity certificate for each Firepower
Threat Defense device that act as a remote access VPN gateway.
• Configure the RADIUS server group object and any AD or LDAP realms being used by remote access
VPN policies.
• Ensure that the AAA Server is reachable from the Firepower Threat Defense device for the remote access
VPN configuration to work. Configure routing (at Devices > Device Management > Edit Device >
Routing) to ensure connectivity to the AAA servers.
For remote access VPN double authentication, ensure that both the primary and secondary authentication
servers are reachable from the Firepower Threat Defense device for the double authentication configuration
to work.

1168
Create a New Remote Access VPN Policy
• Purchase and enable one of the following Cisco AnyConnect licenses: AnyConnect Plus, AnyConnect
Apex, or AnyConnect VPN Only to enable the Firepower Threat Defense Remote Access VPN.
• Download the latest AnyConnect image files from Cisco Software Download Center.
On your Firepower Management Center web interface, go to Objects > Object Management > VPN >
AnyConnect File and add the new AnyConnect client image files.
• Create a security zone or interface group that contains the network interfaces that users will access for
VPN connections. See Interface Objects: Interface Groups and Security Zones, on page 620.
• Download the AnyConnect Profile Editor from Cisco Software Download Center to create an AnyConnect
client profile. You can use the standalone profile editor to create a new or modify an existing AnyConnect
profile.

You can add a new remote access VPN Policy only by using the Remote Access VPN Policy wizard. The
wizard guides you to quickly and easily set up remote access VPNs with basic capabilities. Further, you can
enhance the policy configuration by specifying additional attributes as desired and deploy it to your Firepower
Threat Defense secure gateway devices.
Before you begin

• Ensure that you complete all the prerequisites listed in Prerequisites for Configuring Remote Access
VPN, on page 1168.
Procedure
Step 1 Choose Devices > VPN > Remote Access.
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 3 Select the Target Devices and Protocols.

The Firepower Threat Defense devices selected here will function as your remote access VPN gateways for
the VPN client users. You can select the devices from the list or add a new device.
You can select Firepower Threat Defense devices when you create a remote access VPN policy or change
them later. See Setting Target Devices for a Remote Access VPN Policy, on page 1175.
You can select SSL or IPSec-IKEv2, or both the VPN protocols. Firepower Threat Defense supports both
the protocols to establish secure connections over a public network through VPN tunnels.
Note Firepower Threat Defense does not support IPSec tunnels with NULL encryption. If you have
selected IPSec-IKEv2, make sure that you do not choose NULL encryption for IPSec IKEv2 proposal.
See Configure IKEv2 IPsec Proposal Objects, on page 695.
For SSL settings, see Configure SSL Settings , on page 1437.

1169
Step 4 Configure the Connection Profile and Group Policy settings.

A connection profile specifies a set of parameters that define how the remote users connect to the VPN device.
The parameters include settings and attributes for authentication, address assignments to VPN clients, and
group policies. Firepower Threat Defense device provides a default connection profile named
DefaultWEBVPNGroup when you configure a remote access VPN policy.
For more information, see Configure Connection Profile Settings, on page 1175.
For information about configuring,
• AAA settings, see Configure AAA Settings for Remote Access VPN, on page 1178
• LDAP attribute maps, see Configuring LDAP Attribute Mapping, on page 1191
• SAML 2.0 single sign-on authentication, see Configuring a SAML Single Sign-on Authentication, on
page 1221
access VPN experience for VPN users. You configure attributes such as user authorization profile, IP addresses,
AnyConnect settings, VLAN mapping, and user session settings and so on using the group policy. The RADIUS
For more information, see Configuring Group Policies, on page 1190.
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.
For information about configuring AnyConnect client profile and client modules, see Group Policy AnyConnect
Options, on page 699.
Step 6 Select the Network Interface and Identity Certificate.

Interface objects segment your network to help you manage and classify traffic flow. A security zone object
simply groups interfaces. These groups may span multiple devices; you can also configure multiple zones
interface objects on a single device. There are two types of interface objects:
• Security zones—An interface can belong to only one security zone.
• Interface groups—An interface can belong to multiple interface groups (and to one security zone).
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

1170
Update the Access Control Policy on the Firepower Threat Defense Device
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 1185.
Before you begin

Complete the remote access VPN policy configuration using the Remote Access VPN Policy wizard.
Procedure
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.

1171
(Optional) Configure NAT Exemption
(Optional) Configure NAT Exemption

NAT exemption exempts addresses from translation and allows both translated and remote hosts to initiate
connections with your protected hosts. Like identity NAT, you do not limit translation for a host on specific
interfaces; you must use NAT exemption for connections through all interfaces. However, NAT exemption
enables you to specify the real and destination addresses when determining the real addresses to translate
(similar to policy NAT). Use static identity NAT to consider ports in the access list.
Before you begin

Check if NAT is configured on the targeted devices where remote access VPN policy is deployed. If NAT is
enabled on the targeted devices, you must define a NAT policy to exempt VPN traffic.
Procedure
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 1185.
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.
Step 6 Click OK.

1172
Configure DNS
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.
Procedure
Step 1 Configure DNS server details and domain-lookup interfaces using the Platform Settings. For more information,
see Configure DNS, on page 1427 and DNS Server Group Objects, on page 678.
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 696.
Add an AnyConnect Client Profile XML File

An AnyConnect client profile is a group of configuration parameters stored in an XML file that the client uses
to configure its operation and appearance. These parameters (XML tags) include the names and addresses of
host computers and settings to enable more client features.
You can create an AnyConnect client profile using the AnyConnect Profile Editor. This editor is a 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. For more information about AnyConnect Profile
Editor, see Cisco AnyConnect Secure Mobility Client Administrator Guide.
Before you begin

A Firepower Threat Defense remote access VPN policy requires an AnyConnect client profile to be assigned
to the VPN clients. The client profile is attached to a group policy.
Download the AnyConnect Profile Editor from Cisco Software Download Center.
Procedure

Step 2 Select a remote access VPN policy and click Edit.
The connection profiles configured for the remote access VPN policy are listed.
Step 3 Select a connection profile on which you want to update the AnyConnect client profile and click Edit.
Step 4 Click Add to add a group policy or click Edit Group Policy > General > AnyConnect.
Step 5 Select a Client Profile from the list or click the Add icon to add a new one:
a) Specify the AnyConnect profile Name.
b) Click Browse and select an AnyConnect profile XML file.
Note For two-factor authentication, make sure that the timeout is updated to 60 seconds or more in
the AnyConnect client profile XML file.

1173
(Optional) Configure Split Tunneling
c) Click Save.
(Optional) Configure Split Tunneling

Split tunnel allows VPN connectivity to a remote network across a secure tunnel, and it also allows connectivity
to a network outside VPN tunnel. You can configure split tunnel if you want to allow your VPN users to
access an outside network while they are connected to a remote access VPN. To configure a split-tunnel list,
you must create a Standard Access List or Extended Access List.
For more information, see Configuring Group Policies, on page 1190.
Procedure

Step 2 Select a Remote Access policy and click Edit.
Step 3 Select a connection profile and click Edit.
Step 4 Click Add to add a group policy, or click Edit Group Policy > General > Split Tunneling.
Step 5 From the IPv4 Split Tunneling or IPv6 Split Tunneling list, select Exclude networks specified below;
and then select the networks to be excluded from VPN traffic.
If the split tunneling option is left as is, all traffic from the endpoint goes over the VPN connection.
Step 6 Click Standard Access List or Extended Access List, and select an access list from the drop-down or add
a new one.
Step 7 If you chose to add a new standard or extended access list, do the following:
a) Specify the Name for the new access list and click Add.
b) Select Allow from the Action drop-down.
c) Select the network traffic to be allowed over the VPN tunnel and click Add.
Step 8 Click Save.
Related Topics
Access List, on page 685
Verify the Configuration

Procedure
Step 1 Open a web browser on a machine on the outside network.

Step 2 Enter the URL of an FTD device configured as a remote access VPN gateway.
Step 3 Enter the username and password when prompted, and click Logon.
Note If AnyConnect is installed on the system, you will be connected to the VPN automatically.
If AnyConnect is not installed, you will be prompted to download the AnyConnect client.

1174
Setting Target Devices for a Remote Access VPN Policy
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.
Setting Target Devices for a Remote Access VPN Policy

You can add targeted devices while you create a new remote access VPN policy, or change them later.
Procedure

Step 2 Click Edit ( ) next to the remote access VPN policy that you want to edit.
Step 3 Click Policy Assignment.
Step 4 Do any of the following:
• To assign a device, high-availability pair, or device group to the policy, select it in the Available Devices
list and click Add. You can also drag and drop the available devices to select.
• To remove a device assignment, click Delete ( ) next to a device, high-availability pair, or device group
in the Selected Devices list.
Step 5 Click OK.
What to do next
Additional Remote Access VPN Configurations

Configure Connection Profile Settings
Remote Access VPN policy contains the connection profiles targeted for specific devices. These policies
pertain to creating the tunnel itself, such as, how AAA is accomplished, and how addresses are assigned
(DHCP or Address Pools) to VPN clients. They also include user attributes, which are identified in group
policies configured on the Firepower Threat Defense device or obtained from a AAA server. A device also
provides a default connection profile named DefaultWEBVPNGroup. The connection profile that is configured
using the wizard appears in the list.
Procedure

1175
Configure Multiple Connection Profiles
Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
Step 3 Select a Connection Profile and click Edit.
The edit connection profile page is displayed.
Step 4 (Optional) Add multiple connection profiles.
Configure Multiple Connection Profiles, on page 1176
Step 5 Configure IP Addresses for VPN Clients.
Configure IP Addresses for VPN Clients, on page 1177
Step 6 (Optional) Update AAA Settings for remote access VPNs.
Step 7 (Optional) Create or update Aliases.
Create or Update Aliases for a Connection Profile, on page 1184
Step 8 Save the connection profile.
Configure Multiple Connection Profiles

If you decide to grant different rights to different groups of VPN users, then you can configure specific
connection profiles or group policies for each of the user groups. For example, you might allow a finance
group to access one part of a private network, a customer support group to access another part, and an MIS
group to access other parts. In addition, you might allow specific users within MIS to access systems that
other MIS users cannot access. Connection profiles and group policies provide the flexibility to do so securely.
You can configure only one connection profile when you create a VPN policy using the Remote Access Policy
wizard. You can add more connection profiles later. A device also provides a default connection profile named
DefaultWEBVPNGroup.
Before you begin

Ensure that you have configured remote access VPN using the Remote Access Policy wizard with a connection
profile.
Procedure
Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Existing remote access policies are listed.
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.

1176
Configure IP Addresses for VPN Clients
Step 4 Click Save.
Related Topics
Configure Connection Profile Settings, on page 1175
Configure IP Addresses for VPN Clients

Client address assignment provides a means of assigning IP addresses for the remote access VPN users.
You can configure to assign IP Address for remote VPN clients from the local IP Address pools, DHCP
Servers, and AAA servers. The AAA servers are assigned first, followed by others. Configure the Client
Address Assignment policy in the Advanced tab to define the assignment criteria. The IP pool(s) defined
in this connection profile will only be used if no IP pools are defined in group policy associated with the
connection profile, or the system default group policy DfltGrpPolicy.
IPv4 Address Pools—SSL VPN clients receive new IP addresses when they connect to the Firepower Threat
Defense device. Address Pools define a range of addresses that remote clients can receive. Select an existing
IP address pool. You can add a maximum of six pools for IPv4 and IPv6 addresses each.
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 708.
Procedure
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 708.
c) Click OK.
Step 5 Select the following for DHCP Servers:
Note The DHCP server address can be configured only with IPv4 address.

1177
Configure AAA Settings for Remote Access VPN
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 613 and Allowing Object Overrides, on page 610.
c) Click OK.
Step 6 Click Save.
Related Topics
Procedure

Step 3 Select a connection profile to update AAA settings, click Edit > AAA.
Step 4 Select the following for Authentication:
• Authentication Method— Determines how a user is identified before being allowed access to the
network and network services. It controls access by requiring valid user credentials, which are typically
a username and password. It may also include the certificate from the client. Supported authentication
methods are AAA only, Client Certificate only, and AAA + Client Certificate.
When you select the Authentication Method as:
• AAA Only—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.
• Client Certificate Only— Each user is authenticated with a client certificate. The client certificate
must be configured on VPN client endpoints. By default, the user name is derived from the client
certificate fields CN and OU. If the user name is specified in other fields in the client certificate,
use 'Primary' and 'Secondary' field to map appropriate fields.
Select Enable multiple certificate authentication to authenticate the VPN client using the machine
and user certificates.
If have enabled multiple certificate authentication, you can select one of the following certificates
to map the username and authenticate the VPN user:
• First Certificate— Select this option to map the username from the machine certificate sent
from the VPN client.
• Second Certificate— Select this option to map the username from the user certificate sent
from the client.
Note If you do not enable multiple certificate authenticateion, the user certificate (second
certificate) is used for authentication by default.

1178
If you select the 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 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.
The primary and Secondary fields pertaining to the Map specific field option contain 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)
• Client Certificate & AAA— Each user is authenticated with both a client certificate and AAA
server. Select the required certificate and AAA configurations for authentication.
Whichever authentication method you choose, select or deselect Allow connection only if user
exists in authorization database.
• SAML— Each user is authenticated using the SAML single sign-on server. For more information,
see Single Sign-on Authentication with SAML 2.0, on page 1221.
• 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 authentication server from the list if you have added a server already or else create an
authentication server:

1179
• LOCAL—Use a local database from the FTD for user authentication.

• Local Realm—Select a local realm or click Add to configure a realm. See Create a Realm
and Realm Directory, on page 2418.
• Realm—Configure an LDAP or AD realm. See Create a Realm and Realm Directory, on page 2418.
• RADIUS Server Group—Add a RADIUS server group object with RADIUS servers. See RADIUS
Server Groups, on page 710.
• Single Sign-On Server—Create a single sign-on server object for SAML authentication. See Add
a Single Sign-on Server, on page 712.
Fallback to LOCAL Authentication— The user is authenticated using the local database and the VPN tunnel
can be established even if the AAA server group is unavailable, provided that the local database is configured.
• 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.
• Fallback to LOCAL Authentication— This user is authenticated using the local database and the
VPN tunnel can be established even if the AAA server group is unavailable, provided that the local
database is configured.
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 have enabled multiple certificate authentication, you can select one of the following certificates:
• First Certificate— Select this option to map the username from the machine certificate sent
from the VPN client.
• Second Certificate— Select this option to map the username from the user certificate sent
from the client.

1180
• 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.
Step 5 Select the following for Authorization:

• Authorization Server—After authentication is complete, authorization controls the services and
commands available to each authenticated user. Authorization works by assembling a set of attributes
that describe what the user is authorized to perform, their actual capabilities, and restrictions. When you
do not use authorization, authentication alone provides the same access to all authenticated users.
Authorization requires authentication.
To know more about how remote access VPN authorization works, see Understanding Policy Enforcement
of Permissions and Attributes, on page 1163.
When a RADIUS Server is configured for user authorization in the connection profile, the Remote Access
VPN system administrator can configure multiple authorization attributes for users or user-groups. The
authorization attributes that are configured on the RADIUS server can be specific for a user or a user-group.
Once users are authenticated, these specific authorization attributes are pushed to the Firepower Threat
Defense device.
Note The AAA server attributes obtained from the authorization server override the attribute values
that may have been previously configured on the group policy or the connection profile.
• Check Allow connection only if user exists in authorization database if desired.

When enabled, the system checks the username of the client must exist in the authorization database to
allow a successful connection. If the username does not exist in the authorization database, then the
connection is denied.
• When you select a realm as the Authorization Server, you must configure an LDAP attribute map. You
can choose a single server for authentication and authorization or a different servers. Click Configure
LDAP Attribute Map to add LDAP attribute maps for authorization.

1181
RADIUS Server Attributes for Firepower Threat Defense
Note Firepower Threat Defense does not support SAML Identity Provider as the Authorization
server. If the Active Directory behind the SAML Identity Provider is reachable via FMC and
FTD, you can configure authorization following these steps:
• Add realm for the AD Server. See Create a Realm and Realm Directory, on page 2418.
• Select the realm object as the Authorization Server in remote access VPN connection
profile.
• Configure LDAP attribute map for the selected realm.
For information about configuring LDAP attribute maps, see Configuring LDAP Attribute Mapping, on
page 1191.
Step 6 Select the following for Accounting:

• Accounting Server—Accounting is used to track the services that users are accessing and the amount
of network resources they are consuming. When AAA accounting is activated, the network access server
reports user activity to the RADIUS server. Accounting information includes when sessions start and
stop, usernames, the number of bytes that pass through the device for each session, the services used,
and the duration of each session. This data can then be analyzed for network management, client billing,
or auditing. You can use accounting alone or together with authentication and authorization.
Specify the RADIUS Server Group object that will be used to account for the Remote Access VPN
session.
Step 7 Select the following Advanced Settings:

• Strip Realm from username—Select to remove the realm from the username before passing the username
on to the AAA server. For example, if you select this option and provide domain\username, the domain
is stripped off from the username and sent to AAA server for authentication. By default this option is
unchecked.
• Strip Group from username—Select to remove the group name from the username before passing the
username on to the AAA server. By default this option is unchecked.
Note A realm is an administrative domain. Enabling these options allows the authentication to be
based on the username alone. You can enable any combination of these options. However, you
must select both check boxes if your server cannot parse delimiters.
• Password Management—Enable managing the password for the Remote Access VPN users. Select to
notify ahead of the password expiry or on the day the password expires.
Step 8 Click Save.
Related Topics
Understanding Policy Enforcement of Permissions and Attributes, on page 1163
Manage a Realm, on page 2437

The Firepower Threat Defense device supports applying user authorization attributes (also called user
entitlements or permissions) to VPN connections from the external RADIUS server that are configured for
authentication and/or authorization in the remote access VPN policy.

1182
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 104: RADIUS Attributes Sent from Firepower Threat Defense to RADIUS Server
Attribute Single or
Attribute Number Syntax, Type Multi-valued Description or Value
Connection Profile Name 146 String Single 1-253 characters

or Tunnel Group Name
Client Type 150 Integer Single 2 = AnyConnect Client SSL VPN, 6 = AnyConnect
Client IPsec VPN (IKEv2)
Session Type 151 Integer Single 1 = AnyConnect Client SSL VPN, 2 = AnyConnect
Client IPsec VPN (IKEv2)
Table 105: RADIUS Attributes Sent to Firepower Threat Defense
Attribute Single or
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.

1183
Create or Update Aliases for a Connection Profile
Attribute Single or
Downloadable ACLs Cisco-AV-Pair merge-dacl Supported via Cisco-AV-Pair configuration.

{before-avpair
|
after-avpair}
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;
Simultaneous-Logins 2 Integer Single The number of separate simultaneous connections the

user is allowed to establish, 0 - 2147483647.
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.
Create or Update Aliases for a Connection Profile

Aliases contain alternate names or URLs for a specific 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. Aliases names for all connections configured on this device
can be turned on or off for display. You can also configure the list of Alias URLs, which your endpoints can
select while initiating the Remote Access VPN connection. If users connect using the Alias URL, system will
automatically log them using the connection profile that matches the Alias URL.
Procedure

Step 2 From the list of available VPN policies, select the policy for which you want to modify the settings.
Step 3 Select a Connection Profile and click Edit.
Step 4 Click Aliases.

1184
Configure Access Interfaces for Remote Access VPN
Step 5 To add an Alias name, do the following:

a) Click Add under Alias Names.
b) Specify the Alias Name.
c) Select the Enabled check box in each window to enable the aliases.
d) Click OK.
Step 6 To add an Alias URL, do the following:
a) Click Add under Alias URLs.
b) Select the Alias URL from the list or create a new URL object. For more information see Creating URL
Objects, on page 619.
c) Select the Enabled check box in each window to enable the aliases.
d) Click OK.
• Click Edit to edit the Alias name or the Alias URL.
• To delete an Alias name or the Alias URL, click Delete in that row.
Step 7 Click Save.
Related Topics

The Access Interface table lists the interface groups and security zones that contain the device interfaces.
These are configured for remote access SSL or IPsec IKEv2 VPN connections. The table displays the name
of each interface group or security-zone, the interface trustpoints used by the interface, and whether Datagram
Transport Layer Security (DTLS) is enabled.
Procedure

Step 3 Click Access Interface.
Step 4 To add an access interface, select Add and specify values for the following in the Add Access Interface
window:
a) Access Interface—Select the interface group or security zone to which the interface belongs.
The interface group or security zone must be a Routed type. Other interface types are not supported for
Remote Access VPN connectivity.
b) Associate the Protocol object with the access interface by selecting the following options:
• Enable IPSet-IKEv2—Select this option to enable IKEv2 settings.
• Enable SSL—Select this option to enable SSL settings.
• Select Enable Datagram Transport Layer Security.

1185
When selected, it enables Datagram Transport Layer Security (DTLS) on the interface and
allows an AnyConnect VPN client to establish an SSL VPN connection using two simultaneous
tunnels—an SSL tunnel and a DTLS tunnel.
Enabling DTLS avoids the latency and bandwidth problems associated with certain SSL
connections and improves the performance of real-time applications that are sensitive to packet
delays.
To configure SSL settings, and TLS and DTLS versions, see About SSL Settings, on page 1438.
To configure SSL settings for the AnyConnect VPN client, see Group Policy AnyConnect
Options, on page 699.
• Select the Configure Interface Specific Identity Certificate check box and select Interface
Identity Certificate from the drop-down list.
If you do not select the Interface Identity Certificate, the Trustpoint will be used by default.
If you do not select the Interface Identity Certificate or Trustpoint, the SSL Global Identity
Certificate will be used by default.
c) Click OK to save the changes.

Step 5 Select the following under Access Settings:
• Allow Users to select connection profile while logging in—If you have multiple connection profiles,
selecting this option allows the user to select the correct connection profile during login. You must select
this option for IPsec-IKEv2 VPNs.
Step 6 Use the following options to configure SSL Settings:

• Web Access Port Number—The port to use for VPN sessions. The default port is 443.
• 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 1171.
Step 9 Click Save to save the access interface changes.
Related Topics
Interface Objects: Interface Groups and Security Zones, on page 620

1186
Configuring Remote Access VPN Advanced Options
Configuring Remote Access VPN Advanced Options

Cisco AnyConnect Secure Mobility Client Image
Cisco AnyConnect Secure Mobility Client Image

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. Without a
previously-installed client, remote users can enter the IP address of an interface configured to accept clientless
VPN connections in their browser to download and install the AnyConnect client. The Firepower Threat
Defense device downloads the client that matches the operating system of the remote computer. After
downloading, the client installs and establishes a secure connection. In case of a previously installed client,
when the user authenticates, the Firepower Threat Defense device, examines the version of the client, and
upgrades the client if necessary.
The Remote Access VPN administrator associates any new or additional AnyConnect client images to the
VPN policy. The administrator can unassociate the unsupported or end of life client packages that are no
longer required.
The Firepower Management Center determines the type of operating system by using the file package name.
If the user renamed the file without indicating the operating system information, the valid operating system
type must be selected from the list box.
Download the AnyConnect client image file by visiting Cisco Software Download Center.
Related Topics
Adding a Cisco AnyConnect Mobility Client Image to the Firepower Management Center, on page 1187
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 703. For more information
about the client image, see Cisco AnyConnect Secure Mobility Client Image, on page 1187.
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.
Procedure
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.

1187
Update AnyConnect Images for Remote Access VPN Clients
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 1187
Update AnyConnect Images for Remote Access VPN Clients

When new AnyConnect client updates are available in Cisco Software Download Center, you can download
the packages manually and add them to the remote access VPN policy so that the new AnyConnect packages
are upgraded on the VPN client systems according to their operating systems.
Before you begin

Instructions in this section help you update new AnyConnect client images to remote access VPN clients
connecting to Firepower Threat Defense VPN gateway. Ensure that the following configurations are complete
before updating your AnyConnect images:
• Download the latest AnyConnect image files from Cisco Software Download Center.
• On your Firepower Management Center web interface, go to Objects > Object Management > VPN >
AnyConnect File and add the new AnyConnect client image files.
Procedure
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.
Step 5 Save the remote access VPN policy.

After the remote access VPN policy changes are deployed, the new AnyConnect client images are updated
on the Firepower Threat Defense device that is configured as the remote access VPN gateway. When a new
VPN user connects to the VPN gateway, the user will get the new AnyConnect client image to download
depending on the operating system of the client system. For existing VPN users, the AnyConnect client image
will be updated in their next VPN session.
Related Topics
Remote Access VPN Connection Profile Options
Remote Access VPN Address Assignment Policy

The Firepower Threat Defense device can use an IPv4 or IPv6 policy for assigning IP addresses to Remote
Access VPN clients. If you configure more than one address assignment method, the Firepower Threat Defense
device tries each of the options until it finds an IP address.
IPv4 or IPv6 Policy

1188
Configure Certificate Maps
You can use the IPv4 or IPv6 policy to address an IP address to Remote Access VPN clients. Firstly, you
must try with the IPv4 policy and later followed by IPv6 policy.
• Use Authorization Server—Retrieves address from an external authorization server on a per-user basis.
If you are using an authorization server that has IP address configured, we recommend using this method.
Address assignment is supported by RADIUS-based authorization server only. It is not supported for
AD/LDAP. This method is available for both IPv4 and IPv6 assignment policies.
• Use DHCP—Obtains IP addresses from a DHCP server configured in a connection profile. You can also
define the range of IP addresses that the DHCP server can use by configuring DHCP network scope in
the group policy. If you use DHCP, configure the server in the Objects > Object Management >
Network pane. This method is available for IPv4 assignment policies.
For more information about DHCP network scope configuration, see Group Policy General Options, on
page 697.
• Use an internal address pool—Internally configured address pools are the easiest method of address
pool assignment to configure. If you use this method, create the IP address pools in the Objects > Object
Management >Address Pools pane and select the same in the connection profile. This method is available
for both IPv4 and IPv6 assignment policies.
• 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
Remote Access VPN Authentication, on page 1162
Configure Certificate Maps

Certificate maps let you define rules matching a user certificate to a connection profile based on the contents
of the certificate fields. Certificate maps are used for certificate authentication on secure gateways.
The rules or the certificate maps are defined in FTD Certificate Map Objects, on page 705.
Procedure

Step 3 Click Advanced > Certificate Maps.
Step 4 Select the following options under the General Settings for Certificate Group Matching pane:
Selections are priority-based, if a match is not found for the first selection matching continues down the list
of options. When the rules are satisfied, the mapping is done. If the rules are not satisfied, the default connection
profile (listed at the bottom) is used for this connection. Select any, or all, of the following options to establish
authentication and to determine which connection profile (tunnel group) that should be mapped to the client.
• Use Group URL if Group URL and Certificate Map match different Connection profiles

1189
Configuring Group Policies
• Use the configured rules to match a certificate to a Connection Profile—Enable this to use the rules
defined here in the Connection Profile Maps.
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.
Configuring Group Policies

access VPN experience. For example, in the group policy object, you configure general attributes such as
addresses, protocols, and connection settings.
The group policy applied to a user is determined when the VPN tunnel is being established. The RADIUS
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.
Procedure

Step 3 Click Advanced > Group Policies.
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

1190
Configuring LDAP Attribute Mapping
Configuring LDAP Attribute Mapping

An LDAP attribute name maps LDAP user or group Attribute name to a Cisco-understandable name. The
attribute map equates attributes that exist in the Active Directory (AD) or LDAP server with Cisco attribute
names. Any standard LDAP attribute can be mapped to a well-known vendor specific attribute (VSA). One
or more LDAP attribute(s) can be mapped to one or more Cisco LDAP attributes. When the AD or LDAP
server returns authentication to the FTD device during remote access VPN connection establishment, the FTD
device can use the information to adjust how the AnyConnect VPN client completes the connection.
When you want to provide VPN users with different access permissions or VPN content, you can configure
different VPN policies on the VPN server and assign these policy-sets to each user based on their credentials.
You can achieve this in FTD by configuring LDAP authorization, with LDAP attribute maps. In order to use
LDAP to assign a group policy to a user, you need to configure a map that maps an LDAP attribute, such as
the Active Directory (AD) attribute memberOf, to the VPN-Group attribute that is understood by the VPN
headend.
An LDAP attribute map consists of three components:
• Name—Specifies the name for the LDAP attribute map; the name is generated based on the selected
realm.
• Attribute Name Mapping — Maps the LDAP user or group attribute name to Cisco-understandable
name.
• Attribute Value Mapping — Maps value in the LDAP user or group attribute to the value of a Cisco
attribute for the selected name mapping.
When a user connects to FTD remote access VPN, if the memberOf field matches the configured value, then
group policy VPN-Group is applied to the user's VPN Session.
The group policies used in an LDAP attribute map are added to the list of group policies in a remote access
VPN configuration. When a group policy is removed from a remote access VPN configuration, the associated
LDAP attribute mapping is also removed.
Procedure

Step 3 Click Advanced > LDAP Attribute Mapping.
Step 4 Click Add.
Step 5 On the Configure LDAP Attribute Map page, select a Realm to configure the attribute map.
The name for the LDAP attribute map is generated based on the selected realm. If you change the realm, the
LDAP attribute name is also changed.
Step 6 Click Add.

You can configure multiple attribute maps. Each attribute map requires that you configure a name map and
value maps.

1191
Configuring VPN Load Balancing
Note Ensure that you follow these guidelines while creating an LDAP attribute map:
• You must configure one mapping for an LDAP attribute; multiple mappings with same LDAP
attribute name is not allowed.
• Configuring a minimum of one Name map is mandatory to create an LDAP attribute map.
• Remove any LDAP attribute map if the attribute map is not associated with any connection
profile in a remote access VPN configuration.
• Use the correct spelling and capitalization in the LDAP attribute map for both the Cisco and
LDAP attribute names and values.
a) Specify the LDAP Attribute Name and then select the required Cisco Attribute Name from the list.
b) Click Add Value Map and Specify the LDAP Attribute Value and Cisco Attribute Value.
Repeat this step to add more value maps.
You can click the respective Delete icon to delete an LDAP attribute map, a name map, or a value map.
Step 7 Click OK to complete LDAP attribute map configuration.

Step 8 Click Save to save the changes to the LDAP attribute mapping.
Related Topics
Understanding Policy Enforcement of Permissions and Attributes, on page 1163
Configuring VPN Load Balancing
About VPN Load Balancing

VPN load balancing in FTD allows you group two or more devices logically and distribute remote access
VPN sessions among the devices equally. VPN load balancing shares AnyConnect VPN sessions among the
devices in a load balancing group.
VPN load balancing is based on simple distribution of traffic without taking into account throughput or other
factors. A VPN load-balancing group consists of two or more FTD devices. One device acts as the director,
and the other devices are member devices. Devices in a group do not need to be of the exact same type, or
have identical software versions or configurations. Any FTD device that supports remote access VPN can
participate in a load balancing group.
All active devices in a VPN load-balancing group carry session loads. VPN load balancing directs traffic to
the least-loaded device in the group, distributing the load among all devices. It makes efficient use of system
resources and provides increased performance and high availability.
Components of VPN Load Balancing

Following are the components of VPN load balancing:
• Load-balancing group—A virtual group of two or more FTD devices to share the VPN sessions.
A VPN load-balancing group can consist of FTD devices of the same release or of mixed releases; but
the device must support remote access VPN configuration.

1192
Configure Group Settings for VPN Load Balancing
See Configure Group Settings for VPN Load Balancing, on page 1193 and Configure Additional Settings
for Load Balancing, on page 1194.
• Director—One device from the group acts a director. It distributes the load among other members in
the group and participate is serving the VPN sessions.
The director monitors all devices in the group, keeps track of how loaded each device is, and distributes
the session load accordingly. The role of director is not tied to a physical device; it can shift among
devices. For example, if the current director fails, one of the member devices in the group takes over that
role and immediately becomes the new director.
• Members—Devices other than the director in a group are called members. They participate in load
balancing and share the remote access VPN connections.
Configure Settings for Participating Devices, on page 1195.
Prerequisites for VPN Load Balancing

• Certificates—FTD’s certificate must contain the IP addresses or FQDN of the director and members to
which the connection is redirected. Or else, the certificate will be deemed untrusted. The certificate must
use Subject Alternate Name (SAN) or wildcard certificate
• Group URL—Add the group URL for VPN load-balancing group IP address to the connection profiles.
Specify a group URL to eliminate the need for the user to select a group at login.
• IP Address Pool—Choose unique IP address pool for member devices, and override the IP pool in FMC
for each of the member devices.
• Devices that are behind Network Address Translation (NAT) can also be part of a load balancing group.
Guidelines and Limitations for VPN Load Balancing

• VPN load balancing is disabled by default. You must explicitly enable VPN load balancing.
• Only the FTD devices that are co-located can be added to a load-balancing group.
• A load-balancing group must have a minimum of two FTD devices.
• Devices in an FTD high availability can participate in a load-balancing group.
• Devices that are behind Network Address Translation (NAT) can also be part of a load balancing group.
• When a member or a director device goes down, remote access VPN connections that are served by that
device will be dropped. You must initiate the VPN connection again.
• Identity certificate on each device must have Subject Alternate Name (SAN) or wildcard.
• SAML single sign-on authentication with VPN load balancing is not supported.
Configure Group Settings for VPN Load Balancing

You must enable VPN load balancing and configure group settings that are applicable to all the members of
the load-balancing group. Once the group is created, you can configure participation settings for load balancing.

1193
Configure Additional Settings for Load Balancing
Procedure

Step 2 Select an existing remote access VPN policy or create a new one, and then edit the remote access VPN policy
Step 3 Click Advanced > Load Balancing.
Step 4 Click the Enable Load balancing between member devices toggle button to enable load balancing.
The Edit Group Configuration page opens. Group parameters apply to all devices under the load-balancing
group.
Step 5 Specify the Group IPv4 address and Group IPv6 address as applicable.
The IP address specified here is for the entire load-balancing group and the director will open up this IP
address for incoming VPN connections.
Step 6 Select the Communication Interface for the load balancing group. Or click Add to add an interface group
or security zone.
This is a private interface through which director and members share information about their load.
Step 7 Enter the UDP port for communication between the director and members in a group. The default port is
9023.
Step 8 Click the Enable toggle button to activate IPsec Encryption for the communication between the director and
members.
Enabling the encryption establishes IKEv1/IPsec tunnel between the director and members using a pre-shared
key.
Step 9 Enter Encryption Key for IPsec encryption and re-enter the key to Confirm Key.
Step 10 Click OK.
Configure Additional Settings for Load Balancing

The additional settings for VPN load balancing include FQDN and IKEv2 redirection.
Procedure

Step 2 Select an existing remote access VPN policy or create a new one, and then edit the remote access VPN policy
Step 4 Click the Enable Load balancing between member devices toggle button to enable load balancing if not
done already.
Step 5 Click Settings.
Step 6 Click Send FQDN to peer devices instead of IP to enable redirection using a fully qualified domain name.
By default, FTD sends only IP addresses in VPN load balancing redirection to a client.
Step 7 Select one of the IKEv2 Redirect phase:

• Redirect during SA authentication

1194
Configure Settings for Participating Devices
• Redirect during SA initialisation
Step 8 Click OK.
Configure Settings for Participating Devices

The device participation settings determines how the devices share load in VPN load balancing. Configure a
participating device by enabling VPN load balancing on the device and defining device-specific properties.
These values vary from device to device. You can provide a priority number for the devices participating in
load balancing; a higher priority number gives a device a better chance of becoming the director over other
devices. But you cannot select a device to be the director of the group.
Procedure

Step 2 Select an existing remote access VPN policy or create a new one.
Step 3 Edit a remote access VPN policy.
Step 5 Click the Enable Load balancing between member devices toggle button to enable load balancing if you
have not enabled already.
Step 6 Configure Device Participation settings:
The Device Participation section lists all the devices that are added to the selected remote access VPN
configuration. These devices can be configured to share the load of the incoming VPN sessions.
a) Enable load balancing for a device by clicking the Enable button, and then edit the device.
b) Enter the device Priority.
By default, the device priority is set to 5. You can choose a number between 1 and 10.
c) Specify the IPv4 NAT or IPv6 NAT address for VPN interface IP address if the device is behind NAT.
d) Click OK.
Step 7 Click Save to save the remote access VPN policy settings.
Configuring IPsec Settings for Remote Access VPNs

The IPsec settings are applicable only if you selected IPsec as the VPN protocol while configuring your remote
access VPN policy. If not, you can enable IKEv2 using the Edit Access Interface dialog box. See Configure
Access Interfaces for Remote Access VPN, on page 1185 for more information.
Procedure


1195
Configure Remote Access VPN Crypto Maps
The list of IPsec settings appears in a navigation pane on the left of the screen.
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 1196. 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 1185 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 1198 for more information. To add a new IKE policy, see Configure IKEv2 Policy Objects , on
page 693. 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 1199 for more information.
Step 5 Click Save.

Crypto maps are automatically generated for the interfaces on which IPsec-IKEv2 protocol has been enabled.
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 1185 for more information.
Procedure

Step 3 Click the Advanced > Crypto Maps, and select a row in the table and click Edit to edit the Crypto map
options.
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.

1196
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).
• 24—Diffie-Hellman Group 24 (2048-bit modulus and 256-bit prime order subgroup).
Step 8 Specify the Lifetime Duration (seconds).

The lifetime of the security association (SA), in seconds. 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 will be. However, with longer lifetimes, future IPsec security associations can be set
up more quickly than with shorter lifetimes.
You can specify a value from 120 to 2147483647 seconds. The default is 28800 seconds.
Step 9 Specify the Lifetime Size (kbytes).

The volume of traffic (in kilobytes) that can pass between IPsec peers using a given security association before
it expires.
You can specify a value from 10 to 2147483647 kbytes. The default is 4,608,000 kilobytes. No specification
allows infinite data.
Step 10 Select the following ESPv3 Settings:

• Validate incoming ICMP error messages—Choose whether to validate ICMP error messages received
through an IPsec tunnel and destined for an interior host on the private network.
• Enable 'Do Not Fragment' Policy—Define how the IPsec subsystem handles large packets that have
the do-not-fragment (DF) bit set in the IP header, and select one of the following from the Policy list:
• Copy—Maintains the DF bit.
• Clear—Ignores the DF bit.
• Set—Sets and uses the DF bit.

1197
IKE Policies in Remote Access VPNs
• 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.
Step 11 Click OK.
Related Topics
IKE Policies in Remote Access VPNs

and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs). The IKE
negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which
enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes SAs for
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.
Note FTD supports only IKEv2 for remote access VPNs.
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.
Configuring Remote Access VPN IKE Policies

The IKE Policy table specifies all the IKE policy objects applicable for the selected VPN configuration when
AnyConnect endpoints connect using the IPsec protocol. For more information, see IKE Policies in Remote
Access VPNs, on page 1198.
Note FTD supports only IKEv2 for remote access VPNs.
Procedure


1198
Configure Remote Access VPN IPsec/IKEv2 Parameters
Step 3 Click Advanced > IKE Policy.

Step 4 Click Add to select from the available IKEv2 policies, or add a new IKEv2 policy and specify the following:
• Name—Name of the IKEv2 policy.
• Description—Optional description of the IKEv2 policy
• Priority—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).
• Lifetime— Lifetime of the security association (SA), in seconds
• Integrity—The Integrity Algorithms portion of the Hash Algorithm used in the IKEv2 policy.
• Encryption—The Encryption Algorithm used to establish the Phase 1 SA for protecting Phase 2
negotiations.
• PRF Hash—The pseudorandom function (PRF) portion of the Hash Algorithm used in the IKE policy.
In IKEv2, you can specify different algorithms for these elements.
• DH Group—The Diffie-Hellman group used for encryption.
Step 5 Click Save.
Related Topics
Remote Access VPN Access Interface Options
Configure Remote Access VPN IPsec/IKEv2 Parameters
Procedure

Step 3 Click Advanced > IPsec> IPsec/IKEv2 Parameters.
Step 4 Select the following for IKEv2 Session Settings:
• Identity Sent to Peers—Choose the identity that the peers will use to identify themselves during IKE
negotiations:
• Auto—Determines the IKE negotiation by connection type: IP address for preshared key, or Cert
DN for certificate authentication (not supported).
• IP address—Uses the IP addresses of the hosts exchanging ISAKMP identity information.
• 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.

1199
Configure AnyConnect Management VPN Tunnel
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 6 Select the following for IPsec Settings:

• Enable Fragmentation Before Encryption—This option lets traffic travel across NAT devices that do
not support IP fragmentation. It does not impede the operation of NAT devices that do support IP
fragmentation.
• Path Maximum Transmission Unit Aging—Check to enable PMTU (Path Maximum Transmission
Unit) Aging, the interval to Reset PMTU of an SA (Security Association).
• Value Reset Interval—Enter the number of minutes at which the PMTU value of an SA (Security
Association) is reset to its original value. Valid range is 10 to 30 minutes, default is unlimited.
Step 7 Select the following for NAT Settings:

• Keepalive Messages Traversal—Select 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 10
to 3600 seconds. The default is 20 seconds.
• Interval—Sets the NAT keepalive interval, from 10 to 3600 seconds. The default is 20 seconds.
Step 8 Click Save.
Configure AnyConnect Management VPN Tunnel

A management VPN tunnel provides connectivity to the corporate network whenever a client system is
powered up, without the VPN users having to connect to the VPN. This helps organizations keep their endpoints
up-to-date with software patches and updates. Management tunnel disconnects when the user-initiated VPN
tunnel is established.

1200
Requirements and Prerequisites for AnyConnect Management VPN Tunnel
This section provides information about configuring AnyConnect management VPN tunnel on FTD. Configuring
an AnyConnect management tunnel on FTD using the FMC web interface requires the following settings:
• A Connection profile with certificate-based authentication and a group URL.
• AnyConnect management VPN profile file, configured a server with group URL and backup servers
if required.
• A Group policy with the management VPN profile, split tunneling with explicitly included networks,
client bypass protocol, and no banner.
For detailed instructions to configure an AnyConnect Management VPN tunnel, see Configuring AnyConnect
Management VPN Tunnel on FTD, on page 1202.
Requirements and Prerequisites for AnyConnect Management VPN Tunnel
Software and Configuration Requirements

Ensure that you have the following before you configure the AnyConnect Management tunnel on using the
FTD using the FMC web interface:
• Ensure that you are using FTD and FMC versions 6.7.0 or above.
• Download the AnyConnect VPN Webdeploy package 4.7 or above and upload it to FTD remote access
VPN.
• Ensure that the certificate authentication is configured in the connection profile.
• Ensure that no banner is configured in the group policy.
• Check the split tunneling configuration in the management tunnel-group policy.
Certificate Requirements
• FTD must have a valid identity certificate for remote access VPN and the root certificate from the local
certifying authority (CA) must be present on the FTD.
• Endpoints connecting to the management VPN tunnel must have a valid identity certificate
• CA certificate for FTD's identity certificate must be installed on the endpoints and the CA certificate for
the endpoints must be installed on the FTD.
• The identity certificate issued by the same local CA must be present in the Machine store.
Certificate Store (For Windows) and/or in System Keychain (For macOS).
Limitations of AnyConnect Management VPN Tunnel

• AnyConnect Management VPN Tunnel supports only certificate authentication, it does not support
AAA-based authentication.
• Public or private proxy settings are not supported.
• AnyConnect client upgrade and AnyConnect module download are not supported when the management
VPN tunnel is connected.

1201
Configuring AnyConnect Management VPN Tunnel on FTD
Procedure
Step 1 Create a remote access VPN policy configuration using the wizard:
For information about configuring a remote access VPN, see Configuring a New Remote Access VPN
Connection, on page 1168.
Step 2 Configure connection profile settings for management VPN tunnel:

Note It is advisable to create a new connection profile to be used only for AnyConnect management VPN
tunnel.
a) Edit the remote access VPN policy you have created.

b) Select and edit the connection profile that will be used for management VPN tunnel.
c) Click AAA > Authentication Method and select Client Certificate Only. Configure the authorization
and accounting settings as required.
d) Click the Aliases tab of the connection profile.
e) Click Add (+) under URL Aliases and URL Alias for the connection profile.
f) Click Enabled to enable the URL.
g) Click OK and then click Save to save the connection profile settings.
For more information about connection profile settings, see Configure Connection Profile Settings, on page
1175.
Step 3 Create a management tunnel profile using the AnyConnect profile editor:
a) Download the AnyConnect VPN Management Tunnel Standalone Profile Editor from Cisco Software
Download Center if you have not done already.
b) Create a management tunnel profile with the required settings for your VPN users and save the file.
c) Configure a server in the Server List with the group URL you have configured in the connection profile.
For information about creating a management profile using the Profile Editor, see the Cisco AnyConnect
Secure Mobility Client Administrator Guide.
Step 4 Create a management tunnel object:

a) On your Firepower Management Center web interface, navigate to Object > Object Management >
VPN > AnyConnect File
b) Click Add AnyConnect File.
c) Specify the Name for the AnyConnect file.
d) Click Browse and select the management tunnel profile file you have saved.
e) Click the File Type drop-down and select AnyConnect Management VPN Profile.
f) Click Save.
Note You an also create the management tunnel object when you create or update AnyConnect settings
for a group policy. See Group Policy AnyConnect Options, on page 699.
Step 5 Associate a management profile with a group policy and configure group policy settings:
You must add the management VPN profile to the group policy associated with the connection profile used
for the management tunnel VPN connection. When the user connects, the management VPN profile is

1202
downloaded along with the user VPN profile already mapped to the group policy, enabling the management
VPN tunnel feature.
Caution No Banner: Check and ensure that no banner is configured in the group policy settings. You can
check the banner settings under Group Policy > General Settings > Banner.
a) Edit the connect profile you have created for management VPN tunnel.
b) Click Edit Group Policy > AnyConnect > Management Profile.
c) Click the Management VPN Profile drop-down and select the management profile file object you have
created.
Note You can also click + and add a new AnyConnect Management VPN Profile object.
d) Click Save.
Step 6 Configure split tunneling in group policy:
a) Click Edit Group Policy > General > Split Tunneling.
b) From the IPv4 or IPv6 split tunneling drop-down, select Tunnel networks specified below.
c) Select the Split Tunnel Network List Type: Standard Access List or Extended Access List, and then
select the required access list to allow the traffic over the management VPN tunnel.
d) Click Save to save the split tunnel settings.
AnyConnect Custom Attribute
AnyConnect Management VPN tunnel requires split include tunneling configuration by default. If you are
configuring AnyConnect custom attribute in the group policy to deploy the management VPN tunnel with
split tunneling to tunnel all, you can do so using FlexConfig because FMC 6.7 web interface does not support
AnyConnect custom attribute.
The following is an example command for AnyConnect custom attribute:
webvpn
anyconnect-custom-attr ManagementTunnelAllAllowed description ManagementTunnelAllAllowed
anyconnect-custom-data ManagementTunnelAllAllowed true true
group-policy MGMT_Tunnel attributes
anyconnect-custom ManagementTunnelAllAllowed value true
Step 7 Deploy, verify, and monitor the remote access VPN policy:
a) Deploy the management VPN tunnel configuration to FTD.
Note Client systems must connect to the FTD remote access VPN once to download the management
tunnel VPN profile to the client machines.
b) You can verify the AnyConnect management VPN tunnel at AnyConnect Secure Mobility Client >
VPN > Statistics.
You can also check the management VPN session details on the FTD command prompt using the show
vpn-sessiondb anyconnect command.
c) On you FMC web interface, click Analysis to view the management tunnel session information.
Related Topics
FTD Group Policy Objects, on page 696

1203
Multiple Certificate Authentication
Multiple Certificate Authentication

Multiple certificate based authentication gives the ability to have the FTD validate the machine or device
certificate, to ensure the device is a corporate-issued device, in addition to authenticating the user’s identity
certificate to allow VPN access using the AnyConnect client during SSL or IKEv2 EAP phase.
The multiple certificates option allows certificate authentication of both the machine and user via certificates.
Without this option, you could only do certificate authentication of either machine or the user, but not both.
Limitations of Multiple Certificate Authentication

• Multiple certificate authentication currently limits the number of certificates to two.
• AnyConnect client must indicate support for multiple certificate authentication. If that is not the case
then the gateway uses one of the legacy authentication methods or fails the connection. AnyConnect
version 4.4.04030 or later supports Multi-Certificate based authentication.
• Anyconnect supports only RSA-based certificates.
• Only SHA256, SHA384, and SHA512 based certificate are supported during the AnyConnect aggregate
authentication.
• Certificate authentication cannot be combined with SAML authentication.
Configuring Multiple Certificate Authentication
Before you begin

Before you configure multiple certificate authentication, ensure that you have configured the certificate
enrollment object that is used to obtain the identity certificate for each Firepower Threat Defense device. For
more information, see FTD Certificate Map Objects, on page 705.
Procedure

Step 2 Select the remote access VPN policy and click Edit.
Note If you have not configured a remote access VPN, click Add to create a new remote access VPN
policy.
Step 3 Select and Edit a connection profile to configure multiple certificate authentication.
Step 4 Click AAA settings and select Authentication Method > Client Certificate Only or Client Certificate &
AAA.
Note Select the Authentication Server if you have selected the Client Certificate & AAA authentication
method
Step 5 Select the Enable multiple certificate authentication checkbox.

Step 6 Choose one of the certificates to Map username from client certificate:
• First Certificate— Select this option to map the username from the machine certificate sent from the
VPN client.

1204
Customizing Remote Access VPN AAA Settings
• Second Certificate— Select this option to map the username from the user certificate sent from the
client.
The username sent from the client is used as the VPN session username when certificate only authentication
is enabled. When AAA and certificate authentication is enabled, VPN session username will be based on
prefill option.
Note If you select the 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. 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.
If you have selected the Client Certificate & AAA authentication, select the Prefill username from
certificate on user login window option to prefill the secondary username from the client certificate
when the user connects via AnyConnect VPN client.
Step 7 Configure the required AAA settings and connection profile settings for the remote access VPN.
Step 8 Save the connection profile and remote access VPN configuration and deploy it on your Firepower Threat
Defense device.
Related Topics
Customizing Remote Access VPN AAA Settings

This section provides information about customizing your AAA preferences for remote access VPNs. For
more information, see Configure AAA Settings for Remote Access VPN, on page 1178.
Authenticate VPN Users via Client Certificates

You can configure remote access VPN authentication using client certificate when you create a new remote
access VPN policy using the wizard or by editing the policy later.
Before you begin

Configure the certificate enrollment object that is used to obtain the identity certificate for each Firepower
Threat Defense device that acts as a VPN gateway.
Procedure

1205
Authenticate VPN Users via Client Certificates
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
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)
• DNQ (DN Qualifier
• GN (Given Name)
• I (Initial)
• L (Locality)
• N (Name)
• SN (Surname)
• T (Title)
• UID (User ID)
• 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 1178.

1206
Configure Remote Access VPN Login via Client Certificate and AAA Server
Related Topics
Adding Certificate Enrollment Objects, on page 669
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.
Before you begin

• Configure the certificate enrollment object that is used to obtain the identity certificate for each Firepower
Threat Defense device that acts as a VPN gateway.
• Configure the RADIUS server group object and any AD or LDAP realms being used by this remote
access VPN policy.
• Ensure that the AAA Server is reachable from the Firepower Threat Defense device for the remote access
VPN configuration to work.
Procedure
Step 2 Select a existing remote access policy and click Edit; or click Add to create a new remote access VPN policy.
Step 4 Click AAA > Authentication Method, Client Certificate & AAA.
• When you select the Authentication Method as:
Client Certificate & AAA—Both types of authentication are done.
• 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
• Client Certificate—User is authenticated using client certificate. Client certificate must be configured
on VPN client endpoints. By default, user name is derived from client certificate fields CN & OU
respectively. In case, 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.
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:

1207
Manage Password Changes over VPN Sessions
• C (Country)
• DNQ (DN Qualifier
• GN (Given Name)
• I (Initial)
• L (Locality)
• N (Name)
• SN (Surname)
• T (Title)
• UID (User ID)
• Whichever authentication method you choose, select or deselect Allow connection only if user
Related Topics
Adding Certificate Enrollment Objects, on page 669
Manage Password Changes over VPN Sessions

Password management allows a remote access VPN administrator to configure the notification settings for
the remote access VPN users on their password expiry. Password management is available in AAA settings
with authentication methods AAA Only and Client Certificate & AAA. For more information, see Configure
AAA Settings for Remote Access VPN, on page 1178.
Procedure

1208
Send Accounting Records to the RADIUS Server
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.
Step 6 Click Save.
Related Topics
Send Accounting Records to the RADIUS Server

Accounting records in remote access VPN help the VPN administrator track the services that users access
and the amount of network resources they consume. Accounting information includes when users sessions
start and stop, usernames, the number of bytes that pass through the device for each session, the service used,
and the duration of each session. This data can then be analyzed for network management, client billing, or
auditing.
You can use accounting alone or together with authentication and authorization. When you activate AAA
accounting, the network access server reports user activity to the configured accounting server. You can
configure a RADIUS server as the accounting server so that all the user activity information is sent from
Firepower Management Center to the RADIUS server.
Note You can use the same RADIUS server or separate RADIUS servers for authentication, authorization, and
accounting in remote access VPN AAA settings.
Before you begin

Configure a RADIUS group object with RADIUS servers to which authentication requests or accounting
records will be sent. See RADIUS Server Group Options, on page 710.
Ensure that the RADIUS servers are reachable from the Firepower Threat Defense device. Configure routing
on your Firepower Management Center at Devices > Device Management > Edit Device > Routing to ensure
connectivity to the RADIUS server.
Procedure
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.

1209
Delegating Group Policy Selection to Authorization Server
Step 5 Click Save.
Related Topics
Delegating Group Policy Selection to Authorization Server

The group policy applied to a user is determined when the VPN tunnel is being established. You can select a
group policy for a connection profile while creating a remote access VPN policy using the wizard or update
the connection policy for connection profiles later. However, you can configure the AAA (RADIUS) server
to assign the group policy or it is obtained from the current connection profile. If the Firepower Threat Defense
device receives attributes from the external AAA server that conflicts with those configured on the connection
profile, then attributes from the AAA server always take the precedence.
You can configure ISE or the RADIUS Server to set the Authorization Profile for a user or user-group by
sending IETF RADIUS Attribute 25 and map to the corresponding group policy name. You can configure
specific group policy to a user or user group to push a Downloadable ACL, set a banner, Restrict VLAN, and
configure the advanced option of applying an SGT to the session. These attributes are applied to all users that
are part of that group when the VPN connection is established.
For more information, see the Configure Standard Authorization Policies section of Cisco Identity Services
Engine Administrator Guide and RADIUS Server Attributes for Firepower Threat Defense, on page 1182.
Figure 37: Remote Access VPN Group Policy Selection by AAA Server
Related Topics

1210
Override the Selection of Group Policy or Other Attributes by the Authorization Server
Override the Selection of Group Policy or Other Attributes by the Authorization Server
When a remote access VPN user connects to the VPN, the group policy and other attributes configured in the
connection profile are assigned to the user. However, the remote access VPN system administrator can delegate
the selection of group policy and other attributes to the authorization server by configuring ISE or the RADIUS
Server to set the Authorization Profile for a user or user-group. Once users are authenticated, these specific
authorization attributes are pushed to the Firepower Threat Defense device.
Before you begin

Ensure that you configure a remote access VPN policy with RADIUS as the authentication server.
Procedure
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 696.
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
Deny VPN Access to a User Group

When you do not want an authenticated user or user group to be able to use VPN, you can configure a group
policy to deny VPN access. You can configure a group policy in a remote access VPN policy and reference
it in the ISE or RADIUS server configuration for authorization.
Before you begin

Ensure that you have configured remote access VPN using the Remote Access Policy wizard and configured
authentication settings for the remote access VPN policy.

1211
Restrict Connection Profile Selection for a User Group
Procedure
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
Restrict Connection Profile Selection for a User Group

When you want to enforce a single connection profile on a user or user group, you can choose to disable the
connection profile so that the group alias or URLs are not available for the users to select when they connect
using the AnyConnect VPN client.
For example, if your organization wants to use specific configurations for different VPN user groups such as
mobile users, corporate-issued laptop users, or personal laptop users, you can configure connection a profile
specific to each of these user groups and apply the appropriate connection profile when the user connects to
the VPN.
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.
Before you begin

• On your Firepower Management Center web interface, configure remote access VPN using the remote
access VPN policy wizard with Authentication Method as 'Client Certificate Only' or 'Client Certificate
+ AAA'. Choose the username fields from the certificate.
• Configure ISE or RADIUS server for authorization and associate the group policy with the authorization
server.
Procedure
Step 3 Select Access Interfaces and disable Allow users to select connection profile while logging in.

1212
Update the AnyConnect Client Profile for Remote Access VPN Clients
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
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.
Before you begin

• Ensure that you have configured remote access VPN using the Remote Access Policy wizard and deployed
the configuration on Firepower Threat Defense device. See Create a New Remote Access VPN Policy,
on page 1169.
• On your Firepower Management Center web interface, go to Objects > Object Management > VPN >
AnyConnect File and add the new AnyConnect client image.
Procedure
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

1213
RADIUS Dynamic Authorization
RADIUS Dynamic Authorization

Firepower Threat Defense has the capability to use RADIUS servers for user authorization of VPN remote
access and firewall cut-through-proxy sessions using dynamic access control lists (ACLs) or ACL names per
user. To implement dynamic ACLs for dynamic authorization or RADIUS Change of Authorization (RADIUS
CoA), you must configure the RADIUS server to support them. When the user tries to authenticate, the
RADIUS server sends a downloadable ACL or ACL name to the Firepower Threat Defense. Access to a given
service is either permitted or denied by the ACL. Firepower Threat Defense deletes the ACL when the
authentication session expires.
Related Topics
Configuring RADIUS Dynamic Authorization, on page 1214
RADIUS Server Attributes for Firepower Threat Defense, on page 1182
Configuring RADIUS Dynamic Authorization
Before you begin:

• Only one interface can be configured in the security zone or interface group if it is referred in a RADIUS
Server.
• A dynamic authorization enabled RADIUS server requires Firepower Threat Defense 6.3 or later for the
dynamic authorization to work.
• Interface selection in RADIUS server is not supported on Firepower Threat Defense 6.2.3 or earlier
versions. The interface option will be ignored during deployment.
Table 106: Procedure
Do This More Info
Step Log on to your Firepower Management

1 Center web interface.
Step Configure a RADIUS server object with RADIUS Server Group Options, on page 710
2 dynamic authorization.
Step Configure a route to ISE server through an RADIUS Server Group Options, on page 710
3 interface enabled for change of
Configure ISE/ISE-PIC for User Control, on page 2458
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 1169
4 select the RADIUS server group object that
you have created with dynamic
authorization.

1214
Two-Factor Authentication
Do This More Info
Step Configure the DNS server details and Configure DNS, on page 1173
5 domain-lookup interfaces using the
DNS Server Group Objects, on page 678
Platform Settings.
Step Configure a split-tunnel in group policy to Configure Group Policy Objects, on page 696
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 535
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.
Configuring RSA Two-Factor Authentication
About this task:

You can configure the RADIUS or AD server as the authentication agent in the RSA server, and use the server
in Firepower Management Center as the primary authentication source in the remote access VPN.
When using this approach, the user must authenticate using a username that is configured in the RADIUS or
AD server, and concatenate the password with the one-time temporary RSA token, separating the password
and token with a comma: password,token.
In this configuration, it is typical to use a separate RADIUS server (such as one supplied in Cisco ISE) to
provide authorization services. You would configure the second RADIUS server as the authorization and,
optionally, accounting server.
Before you begin:

Ensure that the following configurations are complete before configuring RADIUS two-factor authentication
on Firepower Threat Defense:
On the RSA Server
• Configure RADIUS or Active Directory server as an authentication agent.
• Generate and download the configuration (sdconf.rec) file.
• Create a token profile, assign the token to the user, and distribute the token to the user. Download and
install the token on the remote access VPN client system.

1215
Configuring Duo Two-Factor Authentication
For more information, see RSA SecureID Suite documentation.

On the ISE Server
• Import the configuration (sdconf.rec) file generated on the RSA server.
• Add the RSA server as the external identity source and specify the shared secret.
Do This More Info

Step Create a RADIUS server group. RADIUS Server Group Options, on page 710
2
Step Create a RADIUS Server object within the RADIUS Server Options, on page 711
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 1169
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 1178
server group as the authentication server.
7
About this task:

You can configure the Duo RADIUS server as the primary authentication source. This approach uses the Duo
RADIUS Authentication Proxy. (You cannot use a direct connection with the Duo Cloud Service over LDAPS.)
For the detailed steps to configure Duo, see https://duo.com/docs/cisco-firepower.
You would then configure Duo to forward authentication requests directed to the proxy server to use another
RADIUS server, or an AD server, as the first authentication factor, and the Duo Cloud Service as the second
factor.

1216
When using this approach, the user must authenticate using a username that is configured on both the Duo
Cloud or web server, and the associated RADIUS server. The user must enter the password configured in the
RADIUS server, followed by one of the following Duo codes:
• Duo-passcode. For example, my-password,123456.
• push. For example, my-password,push. Use push to tell Duo to send a push authentication to the Duo
Mobile app, which the user must have already installed and registered.
• sms. For example, my-password,sms. Use sms to tell Duo to send an SMS message with a new batch of
passcodes to the user’s mobile device. The user’s authentication attempt will fail when using sms. The
user must then re-authenticate and enter the new passcode as the secondary factor.
• phone. For example, my-password,phone. Use phone to authenticate using phone callback.
For more information on login options with examples, see https://guide.duo.com/anyconnect.
Before you begin:

Before configuring two-factor authentication with Duo Authentication Proxy on Firepower Threat Defense,
ensure that you complete the following configurations:
• Configure a working primary authentication (RADIUS or AD) for your remote access VPN users before
you begin to deploy Duo.
• Install Duo proxy service on a Windows or Linux machine within your network to integrate Duo with
Firepower Threat Defense remote access VPN. This Duo proxy server also acts as a RADIUS server.
Download and install the most recent Duo authentication proxy from the following location:
• 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.
• Configure Duo authentication file authproxy.cfg. Follow instructions on the https://duo.com/docs/

cisco-firepower#configure-the-proxy page to configure the authentication configuration settings.
The authproxy.cfg configuration file must contain the details for RADIUS or ISE server, Firepower
Threat Defense device, Duo proxy server details, Integration Key, Secret key, and API host details.
• Ensure that you have the right API host information in the authproxy.cfg file.
• Configure other required settings such as secondary authentication factor in the newly installed Duo
proxy server at Duo Security Server > Duo Admin Panel > Applications > CISCO RADIUS VPN.
Do This More Info

Step Create a RADIUS server group. RADIUS Server Group Options, on page 710
2

1217
Secondary Authentication
Do This More Info
Step Create a RADIUS Server object within the RADIUS Server Options, on page 711
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 1169
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 1178
created with the Duo proxy server as the
authentication server.
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.

1218
Configure Remote Access VPN Secondary Authentication
Figure 38: Remote Access VPN Secondary or Double Authentication
Related Topics
Configure Remote Access VPN Secondary Authentication, on page 1219

When remote access VPN authentication is configured to use both client certificate and authentication sever,
VPN client authentication is done using both the client certificate validation and AAA server.
Before you begin

• Configure two authentication (AAA) servers— the primary and secondary authentication servers, and
required identity certificates. The authentication servers can be RADIUS server, and AD or LDAP realms.
• Ensure that the AAA servers are reachable from the Firepower Threat Defense device for the remote
access VPN configuration to work. Configure routing (at Devices > Device Management > Edit Device
> Routing) to ensure connectivity to the AAA servers.
Procedure
Step 2 Select a remote access policy and click Edit; or click Add to create a new remote access VPN policy.
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.

1219
• 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
• Whichever authentication method you choose, select or deselect Allow connection only if user
• 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.
(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.
• Use secondary username for VPN session: The secondary username is used for reporting user
activity during a VPN session.

1220
Single Sign-on Authentication with SAML 2.0
Related Topics
Single Sign-on Authentication with SAML 2.0

About SAML Single Sign-on Authentication
Security Assertion Markup Language (SAML) is an open standard for logging users into applications based
on their sessions in another context. Organizations already know the identity of users when users are logged
in to their Active Directory (AD) domain or the intranet. They use this identity information to log users in to
other applications, such as web-based applications by using SAML. Individual applications do not need to
store credentials and users do not have to remember and manage different sets of credentials for individual
applications. SAML sing sign-on (SSO) works by transferring the user’s identity from one place (the identity
provider) to another (the service provider).
SAML Single Sign-on with Firepower Threat Defense

The Firepower Threat Defense device supports SAML 2.0 single sign-on (SSO) authentication for remote
access VPN connections using the AnyConnect Secure Mobility Client. You need the following to configure
SAML 2.0 SSO on Firepower Threat Defense:
• Identity Provider (IdP)—The Duo Access Gateway acts as the identity provider to perform user
authentication and issues assertions.
• Service Provider (SP)—The FTD device acts as the service provider and obtains the authentication
assertion from the identity provider.
• VPN Client—The AnyConnect Security Mobility Client performs SAML 2.0 authentication via embedded
browser.
Configuring a SAML Single Sign-on Authentication
Before you begin

Ensure that you have done the following before you configure SAML single sign-on with FTD remote access
VPN:
• Create an account with Duo
• Download and install the Duo Access Gateway
• Obtain the following from your SAML identity provider (Duo)
• Identity Provider Entity ID URL
• Sign-in URL
• Sign-out URL
• Identity provider certificate
• Create a SAML single sign-on server object under Object > Object Management > AAA Server >
Single Sign-on Server

1221
Configuring SAML Authorization
Note You can also create a single sign-on server object in the connection profile settings
when you create a new remote access VPN configuration using the wizard.
Procedure

Step 2 Click Add to create a new remote access VPN or edit an existing VPN configuration.
Step 3 Configure the Connection Profile > AAA settings and select Authentication Method > SAML.
Step 4 Select the required SAML single sign-on server as the Authentication Server.
Note For a new remote access VPN configuration: when you configure the Connection Profile settings,
you can click + next to the Authentication Server list to create a new SAML single sign-on server
object.
For more information about creating a single sign-on server object, see Add a Single Sign-on Server,
on page 712.
Step 5 Configure the required settings for the remote access VPN.
Step 6 Save the remote access VPN configuration and deploy it on your Firepower Threat Defense device.
Related Topics
Configuring SAML Authorization

About SAML Authorization
SAML authorization supports user attributes delivered in SAML assertions within the AAA and Dynamic
Access Policy (DAP) frameworks. The SAML assertion attributes can be configured on the Identity Provider
as name-value pairs and they will be parsed as strings. The attributes received are made available to DAP so
that they can be used when defining selection criteria within a DAP record. The SAML assertion
cisco_group_policy is used to determine the Group Policy to be applied to the VPN session.
Dynamic Access Policy Attribute Representation

In the DAP table, the DAP attributes are represented in the following format:
aaa.saml.name = "value”
Example, aaa.saml.department = ”finance"

This attribute can be used in DAP selection as follows:
<attr>
<name>aaa.saml.department</name>
<value>finance</value>
<operation>EQ</operation>
</attr>

1222
Configure SAML Authorization
Multi-Valued Attributes
Multi-valued attributes are also supported in DAP and the DAP table is indexed :
aaa.saml.name.1 = "value”
aaa.saml.name.2 = "value"
Active Directory memberOf Attributes

The Active Directory (AD) memberOf attribute receives a special processing that is consistent with the way
it is handled through an LDAP query.
Group names are represented by the CN attribute of the DN.
Example Attributes received from the authorization server:
memberOf = "CN=FTD-VPN-Group,OU=Users,OU=TechspotUsers,DC=techspot,DC=us"
memberOf = "CN=Domain Admins,OU=Users,DC=techspot,DC=us”
Dynamic Access Policy attributes:

aaa.saml.memberOf.1 = "FTD-VPN-Group”
aaa.saml.memberOf.2 = "Domain Admins"
Interpretation of the cisco_group_policy Attribute

A group-policy can be specified by a SAML assertion attribute. When an attribute "cisco_group_policy" is
received by the FTD, the corresponding value is used to select the connection group-policy
Configure SAML Authorization
Before you begin

Ensure that you have configured a single-sign on server like DUO and completed the required Identity
Provider(IdP) and Service Provider(SP) settings.
For more information, see Single Sign-on Authentication with SAML 2.0, on page 1221.
Procedure
Step 1 Configure a single-sign-on server object if not configured already.

a) On the Firepower Management Center web interface, go to Object > Object Management > AAA
Server > Single Sign-on Server
b) Click Add Single Sign-on Server.
c) Enter the sing sign-on server details and click Save.
For more information, see Add a Single Sign-on Server, on page 712.
Step 2 Configure SAML authentication in the remote access VPN connection profile.
a) Select Devices > VPN > Remote Access.
b) Create a new remote access VPN or edit an existing VPN configuration.
c) Edit the required connection profile and select AAA.
d) Select the SSO server object from available list of Authentication Server.
e) Save the remote access VPN configuration.
Step 3 Match a SAML criteria in DAP policy.

1223
Remote Access VPN Examples
a) Select Devices > VPN > Dynamic Access Policy.

b) Create a new DAP or edit an existing one.
c) Create a DAP record or edit and existing record.
d) Click AAA Criteria > SAML Criteria > Add SAML Criteria.
e) Create a SAML criteria based on the SAML assertions returned by the SSO server.
Step 4 Deploy the remote access VPN configuration.
Related Topics
FTD Group Policy Objects, on page 696
Remote Access VPN Examples

How to Limit AnyConnect Bandwidth Per User
This section provides instructions to limit the maximum bandwidth consumed by VPN users when the users
connect using the Cisco AnyConnect VPN client to Firepower Threat Defense remote access VPN gateway.
You can limit the maximum bandwidth by using a Quality of service (QoS) policy in Firepower Threat Defense,
to ensure that a single user or group or users do not take over the entire resource. This configuration lets you
give priority to critical traffic, prevent bandwidth hogging, and manage network. If a When traffic exceeds
the maximum rate, the Firepower Threat Defense drops the excess traffic.
Do This More Info
Step Create and set up a realm. Create and Set up an Active Directory Realm, on page
1 1224.
Step Create a QoS policy and QoS rule for the Create a QoS Policy and Rule, on page 1225
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 1226
authentication.
4
Create and Set up an Active Directory Realm

This section provides instructions to create a realm and specify the VPN users and user groups whose activity
you want to monitor.
Procedure
Step 1 On your Firepower Management Center web interface, choose System > Integration > Realms.

1224
Create a QoS Policy and Rule
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 Create a Realm and Realm Directory, on page 2418
• 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
2437.
Step 5 Click download to download users and user groups to Firepower Management Center. See Synchronize Users
and Groups, on page 2428.
Step 6 Click Save.
Related Topics
Create a Realm and Realm Directory, on page 2418
Create a QoS Policy and Rule

QoS policies deployed to managed devices govern rate limiting. You can create a QoS policy by selecting a
realm to limit the VPN bandwidth a user or user group can consume. Each QoS policy can target multiple
devices; each device can have one deployed QoS policy at a time.
Procedure
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.
Step 4 On QoS policy Rules, click Add Rule.

Step 6 Configure rule components:
• Enabled—Specify whether the rule is Enabled.
• Apply QoS On—Choose the interfaces you want to rate limit, either Interfaces in Destination Interface
Objects or Interfaces in Source Interface Objects. Your choice must correspond with a populated interface
constraint (not any).
• Traffic Limit Per Interface—Enter a Download Limit and an Upload Limit in Mbits/sec. The default
value of Unlimited prevents matching traffic from being rate limited in that direction.

1225
Create or Update a Remote Access VPN Policy
• Users—Click the Users tab, and select the newly-created realm and users to limit the VPN traffic. Click
other tabs corresponding to the conditions you want to add. You must configure a source or destination
interface condition, corresponding to your choice for Apply QoS On.
• Comments—Click the Comments tab, add a comment, and click OK.
Step 7 Save the rule.

In the policy editor, set the rule position. Click and drag or use the right-click menu to cut and paste. 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. Proper rule order reduces the resources
required to process network traffic and prevents rule preemption.
Related Topics
Creating a QoS Policy, on page 899
Rate Limiting with QoS Policies, on page 898
Procedure
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 1168
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 1224.
Step Create an identity policy and add an Create an Identity Policy and an Identity Rule, on page
2 identity rule. 1227.

1226
Do This More Info
Step Associate the identity policy with an access Associate an Identity Policy with an Access Control
3 control policy. Policy, on page 1228
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 1226
authentication.
5

This section provides instructions to create a realm and specify the VPN users and user groups whose activity
you want to monitor.
Procedure
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 Create a Realm and Realm Directory, on page 2418
• 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
2437.
Step 5 Click download to download users and user groups to Firepower Management Center. See Synchronize Users
and Groups, on page 2428.
Step 6 Click Save.
Related Topics
Create a Realm and Realm Directory, on page 2418
Create an Identity Policy and an Identity Rule

Identity policies contain identity rules to perform user authentication based on the realm and authentication
method associated with the traffic. Identity rules associate sets of traffic with a realm and an authentication
method: passive authentication, active authentication, or no authentication. You must fully configure the
realms and authentication methods you plan to use before you can invoke them in your identity rules.

1227
Associate an Identity Policy with an Access Control Policy
Procedure
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 2487
Associate an Identity Policy with an Access Control Policy

You must associate an identity policy with an access control policy that is deployed on the Firepower Threat
Defense device where the remote access VPN policy will be deployed.
Procedure
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.
Step 5 Choose an identity policy from the drop-down list.

You can click edit in edit the identity policy.
Step 6 Click OK.

Step 7 Click Save to save the access control policy.
Related Topics
Create and Manage Identity Policies, on page 2487

1228
Procedure
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 1168
History for Remote Access VPNs

Multi-Certificate Authentication 7.0 Firepower Management Center now

supports multiple certificate-based
authentication for FTD to validate
the machine or device certificate,
to ensure that the device is a
corporate-issued device in addition
to authenticating the user’s identity
certificate to allow RAVPN access
using AnyConnect client.
VPN Load balancing 7.0 VPN load balancing logically group

two or more devices and distributes
Remote access VPN sessions
among the grouped devices equally
without considering throughput and
other traffic parameters.
AnyConnect Custom Attributes 7.0 Firepower Management Center now

supported AnyConnect custom
attributes and provides an
infrastructure to configure
AnyConnect client feature without
adding hard-coded support for these
features on FTD.

1229
History for Remote Access VPNs
Local user authentication 7.0 You can now configure and manage
users locally on FTD using the
Firepower Management Center web
interface, and configure the local
users for primary and secondary
remote access VPN authentication.
Selective policy deployment 7.0 You can now choose to include or

exclude changes to remote access
VPN and site-to-site VPN
configurations during the
deployment.
Support for AnyConnect Modules 6.7 Firepower Management Center now

Configuration supports configuring AnyConnect
modules and profiles for additional
security.
Support for LDAP Authorization 6.7 You can configure LDAP

authorization for remote access
VPN using the Firepower
Management Center.
SAML single sign-on support for 6.7 You can configure a SAML 2.0
remote access VPN server as the single sign-on
authentication server for remote
access VPNs.
AnyConnect Management VPN 6.7 FTD remote access VPN supports

tunnel support configuring AnyConnect
Management VPN tunnel that
allows VPN connectivity to
endpoints when the corporate
endpoints are powered on, without
the VPN users connecting to the
VPN.
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.

1230
CHAPTER 47
Firepower Threat Defense Dynamic Access
Policies Overview
Dynamic access policies (DAP) enable you to configure authorization that addresses the dynamics of VPN
environments. You create a dynamic access policy by setting a collection of access control attributes that you
associate with a specific user tunnel or session. These attributes address issues of multiple group membership
and endpoint security.
• About Firepower Threat Defense Dynamic Access Policy, on page 1231
• Licensing for Dynamic Access Policies, on page 1233
• Prerequisites for Dynamic Access Policy , on page 1233
• Guidelines and Limitations for Dynamic Access Policies, on page 1233
• Configure a Dynamic Access Policy (DAP), on page 1234
• Associate a DAP with a Remote Access VPN, on page 1241
• History for Dynamic Access Policy, on page 1242
About Firepower Threat Defense Dynamic Access Policy

VPN gateways operate in dynamic environments. Multiple variables can affect each VPN connection, for
example, intranet configurations that frequently change, the various roles each user may inhabit within an
organization, and logins from remote access sites with different configurations and levels of security. The
task of authorizing users is much more complicated in a VPN environment than it is in a network with a static
configuration.
You create a dynamic access policy by setting a collection of access control attributes that you associate with
a specific user tunnel or session. These attributes address issues of multiple group membership and endpoint
security. That is, the FTD grants access to a particular user for a particular session based on the policies you
define. It generates a DAP during user authentication by selecting or aggregating attributes from one or more
DAP records. It selects these DAP records based on the endpoint security information of the remote device
and AAA authorization information for the authenticated user. It then applies the DAP record to the user
tunnel or session.
Hierarchy of Policy Enforcement of Permissions and Attributes in FTD

The FTD device supports applying user authorization attributes, also called user entitlements or permissions,
to VPN connections. The attributes are applied from a DAP on the FTD, external authentication server and/or
authorization AAA server (RADIUS) or from a group policy on the FTD device.

1231
Hierarchy of Policy Enforcement of Permissions and Attributes in FTD
If the FTD device receives attributes from all sources, the attributes are evaluated, merged, and applied to the
user policy. If there are conflicts between attributes coming from the DAP, the AAA server, or the group
policy, the attributes obtained from the DAP always take precedence.
The FTD device applies attributes in the following order:
Figure 39: Policy Enforcement Flow
1. DAP attributes on the FTD—The DAP attributes take precedence over all others.
2. User attributes on the external AAA server—The server returns these attributes after successful user
authentication and/or authorization.
3. Group policy configured on the FTD —If a RADIUS server returns the value of the RADIUS Class
attribute IETF-Class-25 (OU= group-policy) for the user, the FTD device places the user in the group
policy of the same name and enforces any attributes in the group policy that are not returned by the server.
4. Group policy assigned by the Connection Profile (also known as Tunnel Group)—The Connection
Profile has the preliminary settings for the connection, and includes a default group policy applied to the
user before authentication.
Note The FTD 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.

1232
Licensing for Dynamic Access Policies
Licensing for Dynamic Access Policies

FTD must have one of the following AnyConnect licenses:
• AnyConnect Apex
• AnyConnect Plus
Base license must allow export-controlled functionality.
Prerequisites for Dynamic Access Policy

Table 109:
Prerequisite Type Description
Licensing • FTD must have at least one of the following

AnyConnect licenses:
• AnyConnect Apex
• AnyConnect Plus
• The FTD base license must allow

export-controlled functionality.
Configurations For more information about prerequisites for DAP,

see the Firepower Threat Defense Dynamic Access
Policies section of the Firepower Management Center
Configuration Guide.
For more information about Remote Access VPN
prerequisites and configuration, see the Firepower
Threat Defense Remote Access VPN section of the
Firepower Management Center Configuration Guide.
Guidelines and Limitations for Dynamic Access Policies

• Matching of AAA attributes in a DAP will work only if a AAA server is configured to return the correct
attributes when authenticating or authorizing a remote access VPN session.
• Minimum AnyConnect and HostScan package version supported for DAP is 4.6. But it is highly
recommended to use the latest version of AnyConnect.

1233
Configure a Dynamic Access Policy (DAP)
Configure a Dynamic Access Policy (DAP)

Create a Dynamic Access Policy
You must create a DAP policy and then add a configure the attributes for the policy.
Before you begin

Ensure that you have the HostScan package before configuring DAP endpoint attributes. You can add the
HostScan file at Objects > Object Management > VPN > AnyConnect File.
Procedure
Step 1 Choose Devices > Dynamic Access Policy > Create Dynamic Access Policy.
Step 2 Specify the Name for the DAP policy and an optional Description.
Step 3 Select the HostScan Package from the list.
Step 4 Click Save.
Create a Dynamic Access Policy Record

A dynamic access policy (DAP) can contain multiple DAP records, where you configure user and endpoint
attributes. You can prioritize the DAP records within a DAP so that the required criteria is applied when a
user attempts a VPN connection.
Procedure
Step 1 Choose Devices > Dynamic Access Policy.

Step 2 Edit an existing DAP policy or create a new one and then edit the policy.
Step 3 Specify the Name for the DAP record.
Step 4 Enter the Priority for the DAP record.
Step 5 Select an Action to be taken when DAP record matches:
• Continue—Click to apply access policy attributes to the session.
• Terminate—Select to terminate the session.
• Quarantine—Select to quarantine the connection.
Step 6 Select Display User Message on Criterion Match and add the message in the box.
The message is displayed to the user when this DAP record is selected.
Step 7 Select the Apply a Network ACL on Traffic checkbox and select the ACL from the list.

1234
Configure AAA Criteria Settings for a DAP
Step 8 Select Apply one or more AnyConnect Custom Attributes and select the custom attributes object from the
drop-down.
Step 9 Click Save.
Configure AAA Criteria Settings for a DAP

DAP complements AAA services by providing a limited set of authorization attributes that can override the
attributes that AAA provides. The FTD selects DAP records based on the AAA authorization information for
the user and posture assessment information for the session. The FTD can choose multiple DAP records
depending on this information, which it then aggregates to create DAP authorization attributes.
Procedure

Step 2 Edit an existing DAP policy or create a new one and then edit the policy.
Step 3 Select a DAP record or create a new one, and edit the DAP record.
Step 4 Click AAA Criteria.
Step 5 Select one of the Match criteria between sections
• Any—matches any of the criteria
• All—matches all of the criteria
• None—matches none of the set criteria
Step 6 Click Add to add the required Cisco VPN Criteria.

Cisco VPN Criteria includes attributes for group policy, assigned IPv4 address, assigned IPv6 address,
connection profile, username, username 2, and SCEP required.
a) Select an attribute and specify the Value.
b) Click Add another criteria to add more criteria.
c) Click Save.
SCEP Required
Step 7 Select LDAP Criteria, RADIUS Criteria, or SAML Criteria and specify the Attribute ID and Value.
Step 8 Click Save.
Configure Endpoint Attribute Selection Criteria in a DAP

Endpoint attributes contain information about the endpoint system environment, posture assessment results,
and applications. The FTD dynamically generates a collection of endpoint attributes during session establishment
and stores these attributes in a database associated with the session. Each DAP record specifies the endpoint
selection attributes that must be satisfied for the FTD to choose it for a session. The FTD selects only DAP
records that satisfy every condition configured.

1235
Add an Anti-Malware Endpoint Attribute to a DAP
Procedure
Step 1 Choose Devices > Dynamic Access Policy > Create Dynamic Access Policy.
Step 2 Edit a DAP policy and then DAP record.
Note Create a DAP policy and DAP record if not done already.
Step 3 Click Endpoint Criteria and configure the following endpoint criteria attributes:
Note You can create multiple instances of each type of endpoint attribute. There is no limit for the number
of endpoint attributes for each DAP record.
• Add an Anti-Malware Endpoint Attribute to a DAP

• Add a Device Endpoint Attribute to a DAP
• Add AnyConnect Endpoint Attributes to a DAP, on page 1237
• Add a NAC Endpoint Attribute to a DAP
• Add an Application Attribute to a DAP
• Add a Personal Firewall Endpoint Attribute to a DAP
• Add an Operating System Endpoint Attribute to a DAP
• Add a Process Endpoint Attribute to a DAP
• Add a Registry Endpoint Attribute to a DAP
• Add a File Endpoint Attribute to a DAP
• Add Certificate Authentication Attributes to DAP
Step 4 Click Save.
Add an Anti-Malware Endpoint Attribute to a DAP
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > Anti-Malware.
Step 2 Select the Match Criteria All or Any.
Step 3 Click Add to add anti-malware attributes.
Step 4 Click Installed to indicate whether the selected endpoint attribute and its accompanying qualifiers are installed
or not installed.
Step 5 Choose Enabled or Disabled to activate or de-activate real time malware scanning.
Step 6 Select the name of the anti-malware Vendor from the list.
Step 7 Select the anti-malware Product Description.
Step 8 Choose the Version of the anti-malware product.

1236
Add a Device Endpoint Attribute to a DAP
Step 9 Specify the number of days since the Last Update.

You can indicate that an anti-malware update should occur in less than (<) or more than (>) the number of
days you specify.
Step 10 Click Save.
Add a Device Endpoint Attribute to a DAP
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > Device.
Step 3 Click Add and select the = or ≠ operator to check the attribute to be equal to or not equal to the value you
enter for the following attributes:
• Host Name—Host name of the device you are testing for. Use the computer’s host name only, not the
fully qualified domain name (FQDN).
• MAC Address—MAC address of the network interface card you are testing for. The address must be
in the format xxxx.xxxx.xxxx where x is a hexadecimal character.
• BIOS Serial Number—BIOS serial number value of the device you are testing for. The number format
is manufacturer-specific.
• Port Number—Listening port number of the device.
• Secure Desktop Version—Version of the Host Scan image running on the endpoint.
• OPSWAT Version—The OPSWAT client version.
• Privacy Protection—None, Cache cleaner, Secure Desktop.
• TCP/UDP Port Number—TCP or UDP port in listening state that you are testing for.
Step 4 Click Save.
Add AnyConnect Endpoint Attributes to a DAP
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > AnyConnect.
Step 3 Click Add and select the = or ≠ operator to check the attribute to be equal to or not equal to the value you
enter.
Step 4 Select the Client Version and Platform.
Step 5 Select the Platform Version, and specify the Device Type and Device Unique ID.

1237
Add NAC Endpoint Attributes to a DAP
Step 6 Add the MAC Addresses the MAC Address Pool.

Note The MAC Address must be in the format XX-XX-XX-XX-XX-XX, where each X is a hexadecimal
character. You can click Add another MAC Address to add more addresses.
Step 7 Click Save.
Add NAC Endpoint Attributes to a DAP
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > NAC.
Step 3 Click Add to add NAC attributes.
Step 4 Set the operator to be equal to = or not equal to ≠ the posture token string. Enter the posture token string in
the Posture Status box.
Step 5 Click Save.
Add an Application Attribute to a DAP
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > Application.
Step 4 Choose equals ( = ) or does not equal (≠ ) and specify the Client Type indicate the type of remote access
connection.
Step 5 Click Save.
Add a Personal Firewall Endpoint Attribute to a DAP
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > Personal Firewall.
Step 4 Click Installed to indicate whether the selected endpoint attribute and its accompanying qualifiers (fields
below the Name/Operation/Value column) are installed or not installed.
Step 5 Choose Enabled or Disabled to activate or de-activate firewall protection.

1238
Add an Operating System Endpoint Attribute to a DAP
Step 6 Select the name of the firewall Vendor from the list.
Step 7 Select the firewall Product Description.
Step 8 Select the equals ( = ) or does not equal (≠ ) operator and choose the Version of the anti-malware product.
Step 9 Click Save.
Add an Operating System Endpoint Attribute to a DAP
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > Operating System .
Step 4 Select the equals ( = ) or does not equal (≠ ) operator and then select the Operating System.
Step 5 Select the equals ( = ) or does not equal (≠ ) operator and then specify the operating system Version.
Step 6 Click Save.
Add a Process Endpoint Attribute to a DAP
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > Process.
Step 3 Click Add to add the process attributes.
Step 4 Select Exists or Does not exist.
Step 5 Specify the Process Name.
Step 6 Click Save.
Add a Registry Endpoint Attribute to a DAP

Scanning for registry endpoint attributes applies to Windows operating systems only.
Before you begin

Before configuring a Registry endpoint attribute, define the registry key for which you want to scan in the
Host Scan window for Cisco Secure Desktop.
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > Registry.

1239
Add a File Endpoint Attribute to a DAP

Step 3 Click Add to add registry attributes.
Step 4 Select the Entry Path for the registry and specify the path.
Step 5 Choose the existence of the registry, Exists or Does not Exist.
Step 6 Select the registry Type from the list.
Step 7 Select the equals ( = ) or does not equal (≠ ) operator and enter the Value of the registry key.
Step 8 Select Case insensitive to disregard the case of the registry entry while scanning.
Step 9 Click Save.
Add a File Endpoint Attribute to a DAP
Before you begin

Before configuring a File endpoint attribute, define the file for which you want to scan in the Host Scan
window for Cisco Secure Desktop.
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > File.
Step 3 Click Add to add file attributes.
Step 4 Specify the File Path.
Step 5 Choose Exists or Does not Exist to indicate the presence of the file.
Step 6 Select less than (<) or greater than (>) and specify the Last Modified days for the file.
Step 7 Select the equals ( = ) or does not equal ≠ operator and enter the Checksum.
Step 8 Click Save.
Add Certificate Authentication Attributes to DAP

You can index each certificate so that any of the received certificates can be referenced by the configured
rules. Based on these certificate fields, you can configure DAP rules to allow or disallow connection attempts.
Procedure
Step 1 Edit a DAP record and select Endpoint Criteria > Certificate.
Step 4 Select the certificate, Cert1 or Cert2.
Step 5 Select the Subject and specify the subject value.
Step 6 Select the Issuer and specify the issuer value.
Step 7 Select the Subject Alternate Name and specify the subject value.

1240
Configure Advanced Settings for a DAP
Step 8 Specify the Serial Number.

Step 9 Select the Certificate Store: None, Machine, or User.
This information is sent by the VPN client.
Step 10 Click Save.
Configure Advanced Settings for a DAP

You can use the Advanced tab for adding selection criteria other than what is possible in the AAA and endpoint
attribute areas. For example, while you can configure the FTD to use AAA attributes that satisfy any, all, or
none of the specified criteria, endpoint attributes are cumulative, and must all be satisfied. To let the security
appliance employ one endpoint attribute or another, you need to create appropriate logical expressions in Lua
and enter them here.
Procedure

Step 2 Edit a DAP policy and then edit a DAP record.
Note Create a DAP policy and DAP record if not done already.
Step 3 Select AND or OR as the match criteria to be performed on DAP configuration.

Step 4 Add the Lua script for advanced attribute matching.
Step 5 Click Save.
Associate a DAP with a Remote Access VPN

A dynamic access policy must be associated with a remote access VPN policy for the DAP attributes to match
during VPN session authentication and authorization. You can then deploy the remote access VPN on FTD.
Procedure
Step 1 Choose Devices > Remote Access.

Step 2 Select an existing remote access VPN policy or create a new one.
Step 3 Edit a remote access VPN policy.
Step 4 Click the link in remote access VPN to select the Dynamic Access Policy.
Step 5 Select the Dynamic Access Policy from the list or click Add to configure a new DAP policy.
Step 6 Click OK.
Step 7 Click Save to save the remote access VPN policy.

1241
History for Dynamic Access Policy
Once you associate a dynamic access policy to a remote access VPN, the configured DAP records and attributes
are checked when a VPN user tries to connect to the VPN. A DAP is created based on the matching and the
appropriate action is taken on the VPN session.
History for Dynamic Access Policy

Dynamic Access Policy 7.0 The feature was introduced.

1242
CHAPTER 48
VPN Monitoring for Firepower Threat Defense
This chapter describes Firepower Threat Defense VPN monitoring tools, parameters, and statistics information.
• VPN Summary Dashboard, on page 1243
• VPN Session and User Information, on page 1244
• VPN Health Events, on page 1245
VPN Summary Dashboard

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 use the VPN dashboard to see consolidated
information about VPN users, including the current status of users, device types, client applications, user
geolocation information, and duration of connections.
Viewing the VPN Summary Dashboard

Remote access VPNs provide secure connections for remote users, such as mobile users or telecommuters.
Monitoring these connections provides important indicators of connction and user session performance at a
glance.
You must be an Admin user in a leaf domain to perform this task.
Procedure
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.

1243
VPN Session and User Information
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
403.
• For information on how to modify the VPN dashboard widgets, see Configuring Widget Preferences, on
page 418.
VPN Session and User Information

The Firepower System generates events that communicate the details of user activity on your network, including
VPN-related activity. The Firepower System monitoring capabilities enable you to determine quickly whether
remote access VPN problems exist and where they exist. You can then apply this knowledge and use your
network management tools to reduce or eliminate problems for your network and users. Optionally, you can
logout remote access VPN users as needed.
Viewing Remote Access VPN Active Sessions

Analysis > Users > Active Sessions
Lets you view the currently logged-in VPN users at any given point in time with supporting information such
as the user name, login duration, authentication type, assigned/public IP address, device details, client version,
end point information, throughput, bandwidth consumed group policy, tunnel group etc. The system also
provides the ability to filter current user information, log users out, and delete users from the summary list.
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 3008.
• To learn more about the contents of the columns in the active sessions table; see Active Sessions, Users,
and User Activity Data, on page 3001.
Viewing Remote Access VPN User Activity

Analysis > Users > User Activity
Lets you view the details of user activity on your network. The system logs historical events and includes
VPN-related information such as connection profile information, IP address, geolocation information, connection
duration, throughput, and device information.
• To learn more about user activity; see Viewing User Activity Data, on page 3013.
• To learn more about the contents of the columns in the user activity table; see Active Sessions, Users,
and User Activity Data, on page 3001.

1244
VPN Health Events
VPN Health Events

The Health Events page allows you to view VPN health events logged by the health monitor on the Firepower
Management Center. When one or more VPN tunnels between Firepower System devices are down, these
events are tracked:
• Site-to-site VPN for Firepower Threat Defense
• Remote access VPN for Firepower Threat Defense
See Health Monitoring, on page 425 for more details on how you can use the health monitor to check the status
of critical functionality across your Firepower System deployment.
Viewing VPN Health Events

When you access health events from the Health Events page on your Firepower Management Center, you
retrieve all health events for all managed appliances. You can narrow the events by specifying the module
which generated the health events you want to view.
You must be an Admin, Maintenance User, or Security Analyst to perform this task.
Procedure
Step 1 Choose System > Health > Events.

Step 2 Select VPN Status under the Module Name column.
See Health Event Views, on page 460 for more details on system health events.

1245
Viewing VPN Health Events

1246
CHAPTER 49
VPN Troubleshooting for Firepower Threat
Defense
This chapter describes Firepower Threat Defense VPN troubleshooting tools and debug information.
• System Messages, on page 1247
• VPN System Logs, on page 1247
• Debug Commands, on page 1248
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 493 for
details on using the Message Center.
VPN System Logs

You can enable system logging (syslog) for FTD devices. Logging information can help you identify and
isolate network or device configuration problems. When you enable VPN logging, these syslogs are sent from
FTD devices to the Firepower Management Center for analysis and archiving.
Any VPN syslogs that are displayed have a default severity level ‘ERROR’ or higher (unless changed). VPN
logging is managed through FTD platform settings. You can adjust the message severity level by editing the
VPN Logging Settings in the FTD platform settings policy for targeted devices (Platform Settings > Syslog >
Logging Setup). See About Configuring Syslog, on page 1450 for details on enabling VPN logging, configuring
syslog servers, and viewing the system logs.
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.

1247
Viewing VPN System Logs
Viewing VPN System Logs

The Firepower System captures event information to help you to gather additional information about the
source of your VPN problems. Any VPN syslogs that are displayed have a default severity level ‘ERROR’
or higher (unless changed). By default the rows are sorted by the Time column.
You must be an Admin user in a leaf domain to perform this task.
Before you begin

Enable VPN logging by checking the Enable Logging to FMC check box in the FTD platform settings
(Devices > Platform Settings > Syslog > Logging Setup). See About Configuring Syslog, on page 1450 for
details on enabling VPN logging, configuring syslog servers, and viewing the system logs.
Procedure
Step 1 Choose Devices > VPN > Troubleshooting.

Step 2 You have the following options:
• Search — To filter current message information, click Edit Search.
• View — To view VPN details associated with the selected message in the view, click View.
• View All — To view VPN details for all messages in the view, click View All.
• Delete — To delete selected messages from the database, click Delete or click Delete All to delete all
the messages.
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.
debug feature [subfeature] [level]

no debug feature [subfeature]

1248
Debug 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.
Command Default The default debugging level is 1.
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.
firepower# debug webvpn condition user jdoe
firepower# show webvpn debug-condition

INFO: Webvpn conditional debug is turned ON
INFO: User name filters:
INFO: jdoe
firepower# debug webvpn

INFO: debug webvpn enabled at level 1.
firepower# show debug

debug webvpn enabled at level 1
INFO: Webvpn conditional debug is turned ON
INFO: User name filters:
INFO: jdoe

1249
debug aaa
Related Commands Command Description
show debug Shows the currently active debug settings.
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”).
debug aaa [accounting | authentication | authorization | common | internal | shim |

url-redirect]
Syntax Description aaa Enables debugging for AAA. Use ? to see the available subfeatures.
accounting (Optional) Enables AAA accounting debugging.
authentication (Optional) Enables AAA authentication debugging.
authorization (Optional) Enables AAA authorization debugging.
common (Optional) Specifies the AAA common debug level. Use ? to see the available
levels.
internal (Optional) Enables AAA internal debugging.
shim (Optional) Specifies the AAA shim debug level. Use ? to see the available levels.
url-redirect (Optional) Enables AAA url-redirect debugging.
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.

1250
debug crypto ca
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.
debug crypto ca [cluster | messages | periodic-authentication | scep-proxy | transactions |

trustpool] [1-255]
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.

1251
debug crypto ikev1
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.
1-255 (Optional) Specifies the debugging level.
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.
debug crypto ikev1

See the following commands for debugging configurations or settings associated with Internet Key Exchange
version 1 (IKEv1).
debug crypto ikev1 [timers] [1-255]
Syntax Description ikev1 Enables debugging for ikev1. Use ? to see the available subfeatures.
timers (Optional) Enables debugging for IKEv1 timers.
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.
debug crypto ikev2

See the following commands for debugging configurations or settings associated with Internet Key Exchange
version 2 (IKEv2).
debug crypto ikev2 [ha | platform | protocol | timers]

1252
debug crypto ipsec
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.
timers (Optional) Enables debugging for IKEv2 timers.
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.
debug crypto ipsec

See the following commands for debugging configurations or settings associated with IPsec.
debug crypto ipsec [1-255]
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).
debug ldap [1-255]
Syntax Description ldap Enables debugging for LDAP. Use ? to see the available subfeatures.

1253
debug ssl
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.
debug ssl [cipher | device] [1-255]
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.
debug webvpn [anyconnect | chunk | cifs | citrix | compression | condition | cstp-auth |

customization | failover | html | javascript | kcd | listener | mus | nfs | request | response
| saml | session | task | transformation | url | util | xml]
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.

1254
debug webvpn
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.

1255
debug webvpn
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.

1256
PA R T XI
Firepower Threat Defense Advanced Settings
• Threat Defense Service Policies, on page 1259
• FlexConfig Policies for Firepower Threat Defense, on page 1277
• Alarms for the Cisco ISA 3000, on page 1329
CHAPTER 50
Threat Defense Service Policies
You can use Firepower Threat Defense Service Policies to apply services to specific traffic classes. For
example, you can use a service policy to create a timeout configuration that is specific to a particular TCP
application, as opposed to one that applies to all TCP applications. A service policy consists of multiple actions
or rules applied to an interface or applied globally.
• About Firepower Threat Defense Service Policies, on page 1259
• Requirements and Prerequisites for Service Policies, on page 1261
• Guidelines and Limitations for Service Policies, on page 1261
• Configure Firepower Threat Defense Service Policies, on page 1262
• Examples for Service Policy Rules, on page 1270
• Monitoring Service Policies, on page 1274
• History for Firepower Threat Defense Service Policy, on page 1275
About Firepower Threat Defense Service Policies

You can use Firepower Threat Defense Service Policies to apply services to specific traffic classes. With
service policies, you are not limited to applying the same services to all connections that enter the device or
a given interface.
A traffic class is a combination of the interface and an extended access control list (ACL). The ACL “allow”
rules determine which connections are part of the class. Any “denied” traffic in the ACL simply does not have
the service applied to it: these connections are not actually dropped. You can use IP addresses and TCP/UCP
ports to identify matching connections as precisely as you require.
There are two types of traffic class:
• Interface-based rules—If you specify a security zone or interface group in a service policy rule, the rule
applies to the ACL “allowed” traffic that goes through any interface that is part of the interface objects.
For a given feature, interface-based rules applied to the ingress interface always take precedence over
global rules: if an ingress interface-based rule applies to a connection, any matching global rule is ignored.
If no ingress interface or global rule applies, then an interface service rule on the egress interface is
applied.
• Global rules—These rules apply to all interfaces. If an interface-based rule does not apply to a connection,
the global rules are checked and applied to any connections that the ACL “allows.” If none apply, then
the connections proceed without any services applied.

1259
How Service Policies Relate to FlexConfig and Other Features
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.
How Service Policies Relate to FlexConfig and Other Features

Prior to version 6.3(0), you could configure connection-related service rules using the
TCP_Embryonic_Conn_Limit and TCP_Embryonic_Conn_Timeout pre-defined FlexConfig objects. You
should remove those objects and redo your rules using the Firepower Threat Defense Service Policy. If you
created any custom FlexConfig objects to implement any of these connection-related features (that is, set
connection commands), you should also remove those objects and implement the features through the service
policy.
Because connection-related service policy features are treated as a separate feature group from other service-rule
implemented features, you should not run into problems with overlapping traffic classes. However, please be
mindful when configuring the following:
• QoS Policy rules are implemented using the service policy CLI. These rules are applied before
connection-based service policy rules. However, both QoS and connection settings can be applied to the
same or overlapping traffic classes.
• You can use FlexConfig policies to implement customized application inspections and NetFlow. Use
the show running-config command to examine the CLI that already configures service rules, including
the policy-map, class-map, and service-policy commands. Netflow and application inspection are
compatible with QoS and connection settings, but you need to understand the existing configuration
before implementing FlexConfig. Connection settings are applied before application inspections and
Netflow.
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.
What Are Connection Settings?

Connection settings comprise a variety of features related to managing traffic connections, such as a TCP
flow through the Firepower Threat Defense device. Some features are named components that you would
configure to supply specific services.
Connection settings include the following:
• Global timeouts for various protocols—All global timeouts have default values, so you need to change
them only if you are experiencing premature connection loss. You configure global timeouts in the
Firepower Threat Defense Platform policy. Select Devices > Platform Settings.
• Connection timeouts per traffic class—You can override the global timeouts for specific types of traffic
using service policies. All traffic class timeouts have default values, so you do not have to set them.
• Connection limits and TCP Intercept—By default, there are no limits on how many connections can
go through (or to) the Firepower Threat Defense device. You can set limits on particular traffic classes

1260
Requirements and Prerequisites for Service Policies
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.
Requirements and Prerequisites for Service Policies

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
Guidelines and Limitations for Service Policies

• Service policies apply to routed or switch interfaces only, in either routed or transparent mode. They do
not apply to inline set or passive interfaces.
• You can have at most 25 traffic classes for a given interface or the global policy. Specifically, this means
that you cannot have more than 25 service policy rules for the global policy for a given security zone or
interface group. However, for interfaces, because the same interface can appear in both a security zone

1261
Configure Firepower Threat Defense Service Policies
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.
Configure Firepower Threat Defense Service Policies

You can use Firepower Threat Defense Service Policies to apply services to specific traffic classes. For
example, you can use a service policy to create a timeout configuration that is specific to a particular TCP
application, as opposed to one that applies to all TCP applications. A service policy consists of multiple actions
or rules applied to an interface or applied globally.
Procedure
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 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 Add Rule to create a new rule. See Configure a Service Policy Rule, on page 1263.
• Click Edit ( ) to edit an existing rule. See Configure a Service Policy Rule, on page 1263.
• Click Delete ( ) to delete a rule.

• Click a rule and drag it to a new location to move it. You cannot drag rules between the interface and
global lists, instead you must edit the rule to change the interface/global setting. The first rule in the list
that matches a connection is applied to the connection.
Step 5 Click OK when you are finished editing the policy.

Step 6 Click Save on Advanced window. The changes are not saved until you click save.

1262
Configure a Service Policy Rule

Configure service policy rules to apply services to specific traffic classes.
Before you begin

Go to Objects > Object Management > Access List > Extended and create an the extended access list that
defines the traffic to which the rule applies. The rule is applied to any connections that match Allow rules in
the extended access list. Define the ACL rules precisely, so that your service policy rule applies to only the
traffic that requires the service.
If you are creating an interface-based rule, you must also have configured the interfaces on the assigned
devices and added them to security zones or interface groups.
Procedure
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.
• Click Add Rule to create a new rule.
• Click Edit ( ) to edit an existing 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.
Click when the interface criteria is complete.
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 1265.
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.

1263
• 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 1269.
• 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 1273.
• 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 1270.
• 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 1270.
• 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

1264
Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass)
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.
Configure the following options:
• Detection Timeout—The time duration in hh:mm:ss format to wait after each unresponsive DCD
probe before sending another probe, between 0:0:1 and 24:0:0. The default is 0:0:15.
For systems that are operating in a cluster or high-availability configuration, we recommend that
you do not set the interval to less than one minute (0:1:0). If the connection needs to be moved
between systems, the changes required take longer than 30 seconds, and the connection might be
deleted before the change is accomplished.
• Detection Retries—The number of consecutive failed retries for DCD before declaring the connection
dead, from 1 to 255. The default is 5.
Step 6 Click Finish to save your changes.

The rule is added to the bottom of the appropriate list, either Interfaces or Global. Global rules are matched
in top-down order. Rules in the Interfaces list are matched in top down order for each interface object. Place
rules for narrowly-defined traffic classes above broader rules, to ensure the right services get applied. You
can move rules within each list by using drag and drop. You cannot move rules between lists.
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.

1265
The Asynchronous Routing Problem
The Asynchronous Routing Problem

By default, all traffic that goes through the Firepower Threat Defense device is inspected using the Adaptive
Security Algorithm and is either allowed through or dropped based on the security policy. The Firepower
Threat Defense device maximizes the firewall performance by checking the state of each packet (new connection
or established connection) and assigning it to either the session management path (a new connection SYN
packet), the fast path (an established connection), or the control plane path (advanced inspection).
TCP packets that match existing connections in the fast path can pass through the Firepower Threat Defense
device without rechecking every aspect of the security policy. This feature maximizes performance. However,
the method of establishing the session in the fast path using the SYN packet, and the checks that occur in the
fast path (such as TCP sequence number), can stand in the way of asymmetrical routing solutions: both the
outbound and inbound flow of a connection must pass through the same Firepower Threat Defense device.
For example, a new connection goes to Security Appliance 1. The SYN packet goes through the session
management path, and an entry for the connection is added to the fast path table. If subsequent packets of this
connection go through Security Appliance 1, then the packets match the entry in the fast path, and are passed
through. But if subsequent packets go to Security Appliance 2, where there was not a SYN packet that went
through the session management path, then there is no entry in the fast path for the connection, and the packets
are dropped. The following figure shows an asymmetric routing example where the outbound traffic goes
through a different Firepower Threat Defense device than the inbound traffic:
Figure 40: Asymmetric Routing
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.

1266
Guidelines and Limitations for TCP State Bypass
Guidelines and Limitations for TCP State Bypass
TCP State Bypass Unsupported Features

The following features are not supported when you use TCP state bypass:
• Application inspection—Inspection requires both inbound and outbound traffic to go through the same
Firepower Threat Defense device, so inspection is not applied to TCP state bypass traffic.
• Snort inspection—Inspection requires both inbound and outbound traffic to go through the same device.
However, Snort inspection is not automatically bypassed for TCP state bypass traffic. You must also
configure a prefilter fastpath rule for the same traffic class for which you configure TCP state bypass.
• TCP Intercept, maximum embryonic connection limit, TCP sequence number randomization—The
Firepower Threat Defense device does not keep track of the state of the connection, so these features are
not applied.
• TCP normalization—The TCP normalizer is disabled.
• Stateful failover.
TCP State Bypass NAT Guidelines

Because the translation session is established separately for each Firepower Threat Defense device, be sure
to configure static NAT on both devices for TCP state bypass traffic. If you use dynamic NAT, the address
chosen for the session on Device 1 will differ from the address chosen for the session on Device 2.
Configure TCP State Bypass

To bypass TCP state checking in asynchronous routing environments, carefully define a traffic class that
applies to the affected hosts or networks only, then enable TCP State Bypass on the traffic class using a service
policy. You must also configure a corresponding prefilter fastpath policy for the same traffic to ensure the
traffic also bypasses inspection.
Because bypass reduces the security of the network, limit its application as much as possible.
Procedure
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.

1267
Configure TCP State Bypass
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.

1268
Disable TCP Sequence Randomization
f) Click Add to add the rule to the prefilter policy.

g) Click Save to save your changes to the prefilter policy.
You can now close the prefilter edit window and return to the access control policy edit window.
h) In the access control policy edit window, the Prefilter Policy dialog box should still be open. Click OK
to save your changes to the prefilter policy assignment.
i) Click Save on the access control policy to save the changed prefilter policy assignment, if you changed
it.
You can now deploy the changes to the affected devices.
Disable TCP Sequence Randomization

Each TCP connection has two initial sequence numbers (ISN): one generated by the client and one generated
by the server. The Firepower Threat Defense device randomizes the ISN of the TCP SYN passing in both the
inbound and outbound directions.
Randomizing the ISN of the protected host prevents an attacker from predicting the next ISN for a new
connection and potentially hijacking the new session.
You can disable TCP initial sequence number randomization if necessary, for example, because data is getting
scrambled. Following are some situations where you might want to disable randomization.
• 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.
Procedure
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:
d) Enter a Name for the object, for example, preserve-sq-no.
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.

1269
Examples for Service Policy Rules
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:
b) Click Advanced, and click the Edit ( ) for the Threat Defense Service Policy.
c) Click Add Rule.
f) Deselect Randomize TCP Sequence Number.
g) (Optional.) Adjust the other connection options as needed.
policy.
Examples for Service Policy Rules

The following topics provide examples of service policy rules.
Protect Servers from a SYN Flood DoS Attack (TCP Intercept)

A SYN-flooding denial of service (DoS) attack occurs when an attacker sends a series of SYN packets to a
host. These packets usually originate from spoofed IP addresses. The constant flood of SYN packets keeps
the server SYN queue full, which prevents it from servicing connection requests from legitimate users.
You can limit the number of embryonic connections to help prevent SYN flooding attacks. An embryonic
connection is a connection request that has not finished the necessary handshake between source and destination.
When the embryonic connection threshold of a connection is crossed, the Firepower Threat Defense device
acts as a proxy for the server and generates a SYN-ACK response to the client SYN request using the SYN
cookie method (see Wikipedia for details on SYN cookies). When the Firepower Threat Defense device
receives an ACK back from the client, it can then authenticate that the client is real and allow the connection
to the server. The component that performs the proxy is called TCP Intercept.
Setting connection limits can protect a server from a SYN flood attack. You can optionally enable TCP
Intercept statistics and monitor the results of your policy. The following procedure explains the end-to-end
process.
Before you begin

• Ensure that you set the embryonic connection limit lower than the TCP SYN backlog queue on the server
that you want to protect. Otherwise, valid clients can no longer access the server during a SYN attack.

1270
To determine reasonable values for embryonic limits, carefully analyze the capacity of the server, the
network, and server usage.
• Depending on the number of CPU cores on your Firepower Threat Defense device model, the maximum
concurrent and embryonic connections can exceed the configured numbers due to the way each core
manages connections. In the worst case scenario, the device allows up to n-1 extra connections and
embryonic connections, where n is the number of cores. For example, if your model has 4 cores, if you
configure 6 concurrent connections and 4 embryonic connections, you could have an additional 3 of each
type. To determine the number of cores for your model, enter the show cpu core command in the device
CLI.
Procedure
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:
d) Enter a Name for the object, for example, protected-servers.
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:
c) Click Add Rule.
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.

1271
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.
If you want to adjust these options, do the following:

b) Choose FlexConfig > Text Object.
c) Click Edit ( ) for the threat_defense_statistics system-defined object.
d) Although you can directly change the values, the recommended approach is to open the Override section
and click Add to create a device override.
e) Select the devices to which you will assign the service policy (through the access control policy assignment)
and click Add to move them to the selected list.
f) Click Override.
g) The object must have 3 entries, so click Count as needed until you get 3.
h) Enter the values you need, in order from 1-3, as rate interval, burst rate, and average rate. Consult the
object description to verify you enter the values in the right order.
i) Click Add in the Object Override dialog box.
j) Click Save in the Edit Text Object dialog box.
Step 4 Enable TCP Intercept statistics.
You must configure a FlexConfig policy to enable TCP Intercept statistics.
a) Choose Devices > FlexConfig.
b) If you already have a policy assigned to the devices, edit it. Otherwise, create a new policy and assign it
to the affected devices.
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):
###Flex-config Appended CLI ###
threat-detection statistics tcp-intercept rate-interval 30

burst-rate 400 average-rate 200

1272
Make the Firepower Threat Defense Device Appear on Traceroutes
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.
• clear threat-detection statistics tcp-intercept—Erases TCP Intercept statistics.
Example:
hostname(config)# show threat-detection statistics top tcp-intercept

Top 10 protected servers under attack (sorted by average rate)
Monitoring window size: 30 mins Sampling interval: 30 secs
<Rank> <Server IP:Port> <Interface> <Ave Rate> <Cur Rate> <Total> <Source IP (Last Attack
Time)>
----------------------------------------------------------------------------------
1 10.1.1.5:80 inside 1249 9503 2249245 <various> Last: 10.0.0.3 (0 secs ago)
2 10.1.1.6:80 inside 10 10 6080 10.0.0.200 (0 secs ago)
Make the Firepower Threat Defense Device Appear on Traceroutes

By default, the Firepower Threat Defense device does not appear on traceroutes as a hop. To make it appear,
you need to decrement the time-to-live on packets that pass through the device, and increase the rate limit on
ICMP unreachable messages. To accomplish this, you must configure a service policy rule and adjust the
ICMP platform settings policy.
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.
Procedure
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:
d) Enter a Name for the object, for example, traceroute-enabled.
e) Click Add to add a rule to exclude OSPF.

1273
Monitoring Service Policies
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:
c) Click Add Rule.
d) Select Apply Globally and click Next.
f) Select Enable Decrement TTL.
g) (Optional.) Adjust the other connection options as needed.
policy.
Step 3 Increase the rate limit on ICMP unreachable messages.

a) Choose Devices > Platform Settings.
b) If you already have a policy assigned to the devices, edit it. Otherwise, create a new Firepower Threat
Defense platform settings policy and assign it to the affected devices.
c) Select ICMP from the table of contents.
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.
Monitoring Service Policies

You can monitor service-policy related information using the device CLI. Following are some useful commands.
• show conn [detail]
Shows connection information. Detailed information uses flags to indicate special connection
characteristics. For example, the “b” flag indicates traffic subject to TCP State Bypass.

1274
History for Firepower Threat Defense Service Policy
When you use the detail keyword, you can see information about Dead Connection Detection (DCD)
probing, which shows how often the connection was probed by the initiator and responder. For example,
the connection details for a DCD-enabled connection would look like the following:
TCP dmz: 10.5.4.11/5555 inside: 10.5.4.10/40299,

flags UO , idle 1s, uptime 32m10s, timeout 1m0s, bytes 11828,
cluster sent/rcvd bytes 0/0, owners (0,255)
Traffic received at interface dmz
Locally received: 0 (0 byte/s)
Traffic received at interface inside
Locally received: 11828 (6 byte/s)
Initiator: 10.5.4.10, Responder: 10.5.4.11
DCD probes sent: Initiator 5, Responder 5
• 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.

Feature Version Description
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.
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).

1275

1276
CHAPTER 51
FlexConfig Policies for Firepower Threat Defense
The following topics describe how to configure and deploy FlexConfig policies.
• FlexConfig Policy Overview, on page 1277
• Requirements and Prerequisites for FlexConfig Policies, on page 1297
• Guidelines and Limitations for FlexConfig, on page 1297
• Customizing Device Configuration with FlexConfig Policies, on page 1297
• Examples for FlexConfig, on page 1311
• History for FlexConfig, on page 1325
FlexConfig Policy Overview

A FlexConfig policy is a container of an ordered list of FlexConfig objects. Each object includes a series of
Apache Velocity scripting language commands, ASA software configuration commands, and variables that
you define. The contents of each FlexConfig object is essentially a program that generates a sequence of ASA
commands that will then be deployed to the assigned devices. This command sequence then configures the
related feature on the FTD device.
FTD uses ASA configuration commands to implement some features, but not all features. There is no unique
set of FTD configuration commands. Instead, the point of FlexConfig is to allow you to configure features
that are not yet directly supported through Firepower Management Center policies and settings.
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.

1277
Recommended Usage for FlexConfig Policies
Recommended Usage for FlexConfig Policies

There are two main recommended uses for FlexConfig:
• You are converting from ASA to FTD, and there are compatible features you are using (and need to
continue using) that Firepower Management Center does not directly support. In this case, use the show
running-config command on the ASA to see the configuration for the feature and create your FlexConfig
objects to implement it. Experiment with the object’s deployment settings (once/everytime and
append/prepend) to get the right setting. Verify by comparing show running-config output on the two
devices.
• You are using FTD but there is a setting or feature that you need to configure, e.g. the Cisco Technical
Assistance Center tells you that a particular setting should resolve a specific problem you are encountering.
For complicated features, use a lab device to test the FlexConfig and verify that you are getting the
expected behavior.
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.
CLI Commands in FlexConfig Objects

FTD uses ASA configuration commands to configure some features. Although not all ASA features are
compatible with FTD, there are some features that can work on FTD but that you cannot configure in Firepower
Management Center policies. You can use FlexConfig objects to specify the CLI required to configure these
features.
If you decide to use FlexConfig to manually configure a feature, you are responsible for knowing and
implementing the commands according to the proper syntax. FlexConfig policies do not validate CLI command
syntax. For more information about proper syntax and configuring CLI commands, use the ASA documentation
as a reference:
• ASA CLI configuration guides explain how to configure a feature. Find the guides at
http://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/
products-installation-and-configuration-guides-list.html
• ASA command references provide additional information sorted by command name. Find the references
at http://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/
products-command-reference-list.html
The following topics explain more about configuration commands.

1278
Determine the ASA Software Version and Current CLI Configuration
Determine the ASA Software Version and Current CLI Configuration

Because the system uses ASA software commands to configure some features, you need to determine the
current ASA version used in software running on the FTD device. This version number indicates which ASA
CLI configuration guides to use for instructions on configuring a feature. You also should examine the current
CLI-based configuration and compare it to the ASA configuration you want to implement.
Keep in mind that any ASA configuration will be very different from a FTD configuration. Many FTD policies
are configured outside of the CLI, so you cannot see the configuration by looking at the commands. Do not
try to create a one-to-one correspondence between an ASA and FTD configuration.
To view this information, make an SSH connection to the device's management interface and issue the following
commands:
• show version system and look for the Cisco Adaptive Security Appliance Software Version number.
(If you issue the command through the Firepower Management Center CLI tool, omit the system keyword.)
• show running-config to view the current CLI configuration.
• show running-config all to include all the default commands in the current CLI configuration.
You can also issue these commands from within Firepower Management Center using the following procedure.
Procedure

Step 2 Click the name of the device targeted by the FlexConfig policy.
You might need to click the open/close arrow in the Count column in the Status table to see any devices.
Step 3 Choose Advanced Troubleshooting.

Step 4 Choose Threat Defense CLI.
Step 5 Choose show as the command, and type version or one of the other commands as the parameter.
Step 6 Click Execute.
For version, search the output for the Cisco Adaptive Security Appliance Software Version number.
You can select the output and press Ctrl+C, then paste it into a text file for later analysis.
Prohibited CLI Commands

The purpose of FlexConfig is to configure features that are available on ASA devices that you cannot configure
on FTD devices using Firepower Management Center.
Thus, you are prevented from configuring ASA features that have equivalents in Firepower Management
Center. The following table lists some of these prohibited command areas.
In addition, some clear commands are prohibited because they overlap with managed policies, and can delete
part of the configuration for a managed policy.
The FlexConfig object editor prevents you from including prohibited commands in the object.

1279
Prohibited CLI Commands
Prohibited CLI Command Description
AAA Configuration blocked.
AAA-Server Configuration blocked.
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.
ARP Inspection Configuration blocked.
As-path Object Configuration blocked.
Banner Configuration blocked.
BGP Configuration blocked.
Clock Configuration blocked.
Community-list Object Configuration blocked.
Copy Configuration blocked.
Delete Configuration blocked.
DHCP Configuration blocked.
Enable Password Configuration blocked.
Erase Configuration blocked.
Fragment Setting Blocked, except for fragment reassembly.
Fsck Configuration blocked.
HTTP Configuration blocked.
ICMP Configuration blocked.
Interface Only nameif, mode, shutdown, ip address and mac-address commands

are blocked.
Multicast Routing Configuration blocked.
NAT Configuration blocked.
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.
NTP Configuration blocked.
OSPF/OSPFv3 Configuration blocked.

1280
Template Scripts
Prohibited CLI Command Description
pager Configuration blocked.
Password Encryption Configuration blocked.
Policy-list Object Configuration blocked.
Prefix-list Object Configuration blocked.
Reload You cannot schedule reloads. The system does not use the reload
command to restart the system, it uses the reboot command.
RIP Configuration blocked.
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.
SNMP Configuration blocked.
SSH Configuration blocked.
Static Route Configuration blocked.
Syslog Configuration blocked.
Time Synchronization Configuration blocked.
Timeout Configuration blocked.
VPN Configuration blocked.
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:

1281
How to Process Variables
• 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.
How to Process Variables

At runtime, a variable can resolve to a single string, a list of strings of the same type, a list of strings of different
types, or a table of named values. In addition, variables that resolve to multiple values can be of determinate
or indeterminate length. You must understand what will be returned in order to process the values correctly.
Following are the main possibilities.
Single Value Variables

If a variable always resolves to a single string, use the variable directly without modification in the FlexConfig
script.
For example, the predefined text variable tcpMssBytes always resolves to a single value (which must be
numeric). The Sysopt_basic FlexConfig then uses an if/then/else structure to set the maximum segment size
based on the value of another single-value text variable, tcpMssMinimum:
#if($tcpMssMinimum == "true")

1282
Multiple Value Variables, All Values Are the Same Type
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.
authentication key eirgp $eigrpAS @SecretEigrpAuthKey key-id @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.
Multiple Value Variables, All Values Are the Same Type

Several policy object and system variables resolve to multiple values of the same type. For example, an object
variable that points to a network object group resolves to a list of the IP addresses within the group. Similarly,
the system variable $SYS_FW_INTERFACE_NAME_LIST resolves to a list of interface names.
You can also create text objects for multiple values of the same type. For example, the predefined text object
enableInspectProtocolList can contain more than one protocol name.
Multiple value variables that resolve to a list of items of the same type are frequently of indeterminate length.
For example, you cannot know beforehand how many interfaces on a device are named, as users can configure
or unconfigure interfaces at any time.
Thus, you would typically use a loop to process multiple value variables of the same type. For example, the
predefined FlexConfig Default_Inspection_Protocol_Enable uses a #foreach loop to go through the
enableInspectProtocolList object and process each value.
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.

1283
Multiple Value Variables, Values Are Different Types
Multiple Value Variables, Values Are Different Types

You can create multiple value text objects, but have each value serve a different purpose. For example, the
predefined netflow_Destination text object should have 3 values, in order, interface name, destination IP
address, and UDP port number.
Objects defined in this way should have a determinate number of values. Otherwise, they would be hard to
process.
Use the get method to process these objects. Type .get(n) at the end of the object name, replacing n with an
index into the object. Start counting at 0, even though the text object lists its values starting at 1.
For example, the Netflow_Add_Destination object uses the following line to add the 3 values from
netflow_Destination to the ASA flow-export command.
flow-export destination $netflow_Destination.get(0) $netflow_Destination.get(1)

$netflow_Destination.get(2)
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.
Multiple Value Variables that Resolve to a Table of Values

Some system variables return a table of values. These variables include MAP in their name, for example,
$SYS_FTD_ROUTED_INTF_MAP_LIST. The routed interface map returns data that looks like the following
(line returns added for clarity):
[{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_logical_name=inside},
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_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

1284
How to See What a Variable Will Return for a Device
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.
#foreach ($intf in $SYS_FTD_ROUTED_INTF_MAP_LIST)

#if ($isIsIntfList.contains($intf.intf_logical_name))
interface $intf.intf_hardwarare_id
isis
#if ($isIsAddressFamily.contains("ipv6"))
ipv6 router isis
#end
#end
#end
How to See What a Variable Will Return for a Device

An easy way to evaluate what a variable will return is to create a simple FlexConfig object that does nothing
more than process an annotated list of variables. Then, you can assign it to a FlexConfig policy, assign the
policy to a device, save the policy, then preview the configuration for that device. The preview will show the
resolved values. You can select the preview text, press Ctrl+C, then paste the output into a text file for analysis.
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.
For example, you could construct the following FlexConfig object:
Following is a network object group variable for the

IPv4-Private-All-RFC1918 object:
$IPv4_Private_addresses
Following is the system variable SYS_FW_MANAGEMENT_IP:
$SYS_FW_MANAGEMENT_IP
Following is the system variable SYS_FW_ENABLED_INSPECT_PROTOCOL_LIST:
$SYS_FW_ENABLED_INSPECT_PROTOCOL_LIST
Following is the system variable SYS_FTD_ROUTED_INTF_MAP_LIST:
$SYS_FTD_ROUTED_INTF_MAP_LIST
Following is the system variable SYS_FW_INTERFACE_NAME_LIST:
$SYS_FW_INTERFACE_NAME_LIST
The preview of this object might look like the following (line returns added for clarity):
###Flex-config Prepended CLI ###

1285
FlexConfig Policy Object Variables
###CLI generated from managed features ###

Following is an network object group variable for the
IPv4-Private-All-RFC1918 object:
[10.0.0.0, 172.16.0.0, 192.168.0.0]
Following is the system variable SYS_FW_MANAGEMENT_IP:
192.168.0.171
Following is the system variable SYS_FW_ENABLED_INSPECT_PROTOCOL_LIST:
[dns, ftp, h323 h225, h323 ras, rsh, rtsp, sqlnet, skinny, sunrpc,
xdmcp, sip, netbios, tftp, icmp, icmp error, ip-options]
Following is the system variable SYS_FTD_ROUTED_INTF_MAP_LIST:
[{intf_hardwarare_id=GigabitEthernet0/0, intf_ipv6_eui64_addresses=[],
intf_logical_name=outside},
intf_logical_name=inside},
intf_ipv6_link_local_address=, intf_logical_name=},
{intf_hardwarare_id=Management0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_link_local_address=, intf_logical_name=diagnostic}]
Following is the system variable SYS_FW_INTERFACE_NAME_LIST:
[outside, inside, diagnostic]
FlexConfig Policy Object Variables

A policy object variable is associated with a specific policy object configured in the Object Manager. When
you insert a policy object variable in a FlexConfig object, you give the variable a name and select the object
associated with it.
Although you can give the variable the exact same name as the associated object, the variable itself is not the
same thing as the associated object. You must use the Insert > Insert Policy Object > Object Type menu in
the FlexConfig object editor to add the variable for the first time to the script in the FlexConfig to establish
the association with the object. Simply typing in the name of the object preceded by a $ sign does not create
a policy object variable.
You can create variables to point to the following types of object. Ensure that you create the right type of
object for each variable. To create objects, go to the Objects > Object Management page.
• Text Objects—For text strings, which can include IP addresses, numbers, and other free-form text such
as interface or zone names. Select FlexConfig > Text Object from the table of contents, then click Add
Text Object. You can configure these objects to contain a single value or multiple values. These objects

1286
FlexConfig System Variables
are highly flexible and built specifically for use within FlexConfig objects. For detailed information, see
Configure FlexConfig Text Objects, on page 1303.
• 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 612.
• 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 620.
• 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 685.
• 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 685.
• 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
682.
FlexConfig System Variables

System variables are replaced with information obtained from the device itself or from policies configured
for it.
You must use the Insert > Insert System Variable > Variable Name menu in the FlexConfig object editor
to add the variable for the first time to the script in the FlexConfig to establish the association with the system
variable. Simply typing in the name of the system variable preceded by a $ sign does not create a system
variable within the context of the FlexConfig object.
The following table explains the available system variables. Before using a variable, examine what is typically
returned for the variable; see How to See What a Variable Will Return for a Device, on page 1285.
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_FW_MANAGEMENT_IP The management IP address of the device
SYS_FW_HOST_NAME The device hostname
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.
SYS_FW_ENABLED_INSPECT_PROTOCOL_LIST The list of protocols for which inspection is enabled.

1287
Predefined FlexConfig Objects
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_INLINE_INTERFACE_NAME_LIST A list of logical names for interfaces configured as passive or ERSPAN

passive.
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.

The predefined FlexConfig objects provide tested configurations for select features. Use these objects if you
need to configure these features, which otherwise cannot be configured through Firepower Management
Center.
The following table lists the available objects. Make note of the associated text objects. You must edit these
text objects to customize the behavior of the predefined FlexConfig object. The text objects make it possible
for you to customize the configuration using the IP addresses and other attributes required by your network
and device.
If you need to modify a predefined FlexConfig object, copy the object, make changes to the copy, and save
it with a new name. You cannot directly edit a predefined FlexConfig object.
Although you might be able to configure other ASA-based features using FlexConfig, the configuration of
those features has not been tested. If an ASA feature overlaps with something that you can configure in
Firepower Management Center policies, do not attempt to configure it through FlexConfig.
For example, Snort inspection includes the HTTP protocol, so do not enable ASA-style HTTP inspection. (In
fact, you cannot add http to the enableInspectProtocolList object. In this case, you are prevented from
misconfiguring your device.) Instead, configure the access control policy to perform application or URL
filtering, as needed, to implement your HTTP inspection requirements.

1288
FlexConfig Object Name Description Associated Text Objects
Default_DNS_Configure Configure the Default DNS group, which defaultDNSNameServerList,

defines the DNS servers that can be used defaultDNSParameters
(Deprecated.)
when resolving fully-qualified domain
names on the data interfaces. This allows
you to use commands in the CLI, such as
ping, using host names rather than IP
addresses.
Starting with version 6.3, configure DNS
for the data interfaces in the Firepower
Threat Defense Platform Settings policy.
Default_Inspection_Protocol_Disable Disables protocols in the global_policy disableInspectProtocolList

default policy map.
Default_Inspection_Protocol_Enable Enables protocols in the global_policy enableInspectProtocolList

default policy map.
DHCPv6_Prefix_Delegation_Configure Configure one outside (Prefix Delegation pdoutside, pdinside

client) and one inside interface (recipient
Also uses the system variable
of delegated prefix) for IPv6 prefix
SYS_FTD_ROUTED_INTF_MAP_LIST
delegation. To use this template, copy it
and modify the variables.
DHCPv6_Prefix_Delegation_UnConfigure Removes the DHCPv6 prefix delegation pdoutside, pdinside

configuration.
DNS_Configure Configure DNS servers in a non-default dnsNameServerList, dnsParameters.

DNS server group. Copy the object to
change the name of the group.
DNS_UnConfigure Removes the DNS server configuration —

performed by Default_DNS_Configure and
DNS_Configure. Copy the object to change
the DNS server group names if you altered
DNS_Configure.
Eigrp_Configure Configures EIGRP routing next-hop, eigrpAS, eigrpNetworks,

auto-summary, router-id, eigrp-stub. eigrpDisableAutoSummary, eigrpRouterId,
eigrpStubReceiveOnly,
eigrpStubRedistributed,
eigrpStubConnected, eigrpStubStatic,
eigrpStubSummary
Eigrp_Interface_Configure Configures EIGRP interface authentication eigrpIntfList, eigrpAS, eigrpAuthKey,

mode, authentication key, hello interval, eigrpAuthKeyId, eigrpHelloInterval,
hold time, split horizon. eigrpHoldTime, eigrpDisableSplitHorizon

1289
Eigrp_Unconfigure Clears EIGRP configuration for an —

autonomous system from the device.
Eigrp_Unconfigure_all Clears all EIGRP configurations. —
Inspect_IPv6_Configure Configures IPv6 inspection in the IPv6RoutingHeaderDropLogList,

global_policy policy map, logging and IPv6RoutingHeaderLogList,
dropping traffic based on IPv6 header IPv6RoutingHeaderDropList.
contents.
Inspect_IPv6_UnConfigure Clears and disables IPv6 inspection. —
ISIS_Configure Configures global parameters for IS-IS isIsNet, isIsAddressFamily, isISType

routing.
ISIS_Interface_Configuration Interface level IS-IS configuration. isIsAddressFamily, IsIsIntfList

ISIS_Unconfigure Clears the IS-IS router configuration on the —

device.
ISIS_Unconfigure_All Clears the IS-IS router configuration from —

the device, including the router assignment
from the device interface.
Netflow_Add_Destination Creates and configures a Netflow export Netflow_Destinations,

destination. netflow_Event_Types
Netflow_Clear_Parameters Restores Netflow export global default —

settings.
Netflow_Delete_Destination Deletes a Netflow export destination. Netflow_Destinations,

netflow_Event_Types
Netflow_Set_Parameters Sets global parameters for Netflow export. netflow_Parameters
NGFW_TCP_NORMALIZATION Modifies the default TCP normalization —

configuration.
Policy_Based_Routing To use this example configuration, copy it, —

modify the interface name, and use the
r-map-object text object to identify a route
map object in the object manager.
Policy_Based_Routing_Clear Clears Policy Based Routing configurations —

from the device.
Sysopt_AAA_radius Ignores the authentication key in RADIUS —

accounting responses.

1290
Sysopt_AAA_radius_negate Negates the Sysopt_AAA_radius —

configuration.
Sysopt_basic Configures sysopt wait time , maximum tcpMssMinimum, tcpMssBytes

segment size for TCP packets, and detailed
traffic statistics.
Sysopt_basic_negate Clears sysopt_basic detailed traffic —

statistics, wait time, and TCP maximum
segment size.
Sysopt_clear_all Clears all sysopt configurations from the —

device.
Sysopt_noproxyarp Configures noproxy-arp CLIs. Uses system variable

SYS_FW_NON_INLINE_INTF_NAME_LIST
Sysopt_noproxyarp_negate Clears Sysopt_noproxyarp configurations. Uses system variable

SYS_FW_NON_INLINE_INTF_NAME_LIST
Sysopt_Preserve_Vpn_Flow Configures syopt preserve VPN flow. —
Sysopt_Preserve_Vpn_Flow_negate Clears the Sysopt_Preserve_Vpn_Flow —

configuration.
Sysopt_Reclassify_Vpn Configures sysopt reclassify vpn. —
Sysopt_Reclassify_Vpn_Negate Negates sysopt reclassify vpn. —
TCP_Embryonic_Conn_Limit Configures embryonic connection limits to tcp_conn_misc, tcp_conn_limit

protect against SYN Flood Denial of
(Deprecated.)
Service (DoS) attacks.
Starting with version 6.3, 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 Configures embryonic connection timeouts tcp_conn_misc, tcp_conn_timeout

to protect against SYN Flood Denial of
(Deprecated.)
Service (DoS) attacks.
Threat_Detection_Clear Clear the threat detection TCP Intercept —

configuration.

1291
Predefined Text Objects
Threat_Detection_Configure Configure threat detection statistics for threat_detection_statistics

attacks intercepted by TCP Intercept.
VxLAN_Clear_Nve Removes the NVE 1 configured when —

VxLAN_Configure_Port_And_Nve is used
from the device.
VxLAN_Clear_Nve_Only Clears the NVE configured on the interface —

when deployed.
VxLAN_Configure_Port_And_Nve Configures VLAN port and NVE 1. vxlan_Port_And_Nve
VxLAN_Make_Nve_Only Sets an interface for NVE only. vxlan_Nve_Only

Also uses system variables
SYS_FTD_ROUTED_MAP_LIST and
SYS_FTD_SWITCHED_INTF_MAP_LIST
VxLAN_Make_Vni Creates a VNI interface. After deploying vxlan_Vni

this you have to unregister and re-register
the device to properly discover the VNI
interface.
Wccp_Configure This template provides an example for isServiceIdentifier, serviceIdentifier,

configuring WCCP. wccpPassword
Wccp_Configure_Clear Clears WCCP configurations. —

There are several predefined text objects. These objects are associated with variables used in the predefined
FlexConfig objects. In most cases, you must edit these objects to add values if you use the associated FlexConfig
object, or you will see errors during deployment. Although some of these objects contain default values, others
are empty.
For information on editing text objects, see Configure FlexConfig Text Objects, on page 1303.
Name Description Associated FlexConfig Object
defaultDNSNameServerList The DNS server IP address to configure in Default_DNS_Configure

the Default DNS group.
(Deprecated.)

1292
defaultDNSParameters The parameters to control DNS behavior Default_DNS_Configure

for the default DNS server group. The
(Deprecated.)
object contains separate entries, in order,
for retries, timeout, expire-entry-timer,
poll-timer, domain-name.
disableInspectProtocolList Disables protocols in the default policy map Disable_Default_Inspection_Protocol

(global_policy).
dnsNameServerList The DNS server IP address to configure in DNS_Configure

a user-defined DNS group.
dnsParameters The parameters to control DNS behavior DNS_Configure

for a non-default DNS server group. The
object contains separate entries, in order,
for retries, timeout, domain-name,
name-server-interface.
eigrpAS Autonomous system number. Eigrp_Configure,

Eigrp_Interface_Configure,
Eigrp_Unconfigure
eigrpAuthKey EIGRP authentication key. Eigrp_Interface_Configure
eigrpAuthKeyId Shared key id that matches the Eigrp_Interface_Configure

authentication key.
eigrpDisableAutoSummary A flag that, when true, disables Eigrp_Configure

auto-summary.
eigrpDisableSplitHorizon A flag that, when true, disables split Eigrp_Interface_Configure

horizon.
eigrpHelloInterval Seconds between hello transmission. Eigrp_Interface_Configure
eigrpHoldTime Seconds before neighbor is considered Eigrp_Interface_Configure

down.
eigrpIntfList List of logical interface names where Eigrp_Interface_Configure

EIGRP is to be applied.
eigrpRouterId Router-Id, in IP address format. Eigrp_Configure
eigrpStubConnected A flag that, when true, allows you to use Eigrp_Configure

connected in the eigrp stub configuration.
eigrpStubReceiveOnly A flag that, when true, allows you to use Eigrp_Configure

receive-only in the eigrp stub
configuration.

1293
eigrpStubRedistributed A flag that, when true, allows you to use Eigrp_Configure

redistributed in the eigrp stub
configuration.
eigrpStubSummary A flag that, when true, allows you to use Eigrp_Configure

summary in the eigrp stub configuration.
enableInspectProtocolList Enables protocols in the default policy map Enable_Default_Inspection_Protocol

(global_policy). You are prevented from
adding protocols whose inspection conflicts
with Snort inspection.
IPv6RoutingHeaderDropList The list of IPv6 routing header types that Inspect_IPv6_Configure

you want to disallow. IPv6 inspection drops
packets that contain these headers without
logging the drop.
IPv6RoutingHeaderDropLogList The list of IPv6 routing header types that Inspect_IPv6_Configure

you want to disallow and log. IPv6
inspection drops packets that contain these
headers and sends a syslog message about
the drop.
IPv6RoutingHeaderLogList The list of IPv6 routing header types that Inspect_IPv6_Configure

you want to allow but log. IPv6 inspection
allows packets that contain these headers,
but sends a syslog message about the
existence of the header.
isIsAddressFamily The IPv4 or IPv6 address family. ISIS_Configure

ISIS_Interface_Configuration
IsIsIntfList List of logical interface names. ISIS_Interface_Configuration
isIsISType IS Type (level-1, level-2-only or level-1-2). ISIS_Configure
isIsNet Network entity. ISIS_Configure
isServiceIdentifier When false, uses the standard web-cache Wccp_Configure

service identifier.
netflow_Destination Defines a single Netflow export Netflow_Add_Destination

destination's interface, destination, and
UDP port number.
netflow_Event_Types Defines the types of events to be exported Netflow_Add_Destination

for a destination as any subset of: all,
flow-create, flow-defined, flow-teardown,
flow-update.

1294
netflow_Parameters Provides the Netflow export global settings: Netflow_Set_Parameters

active refresh interval (number of minutes
between flow update events), delay (flow
create delay in seconds; default 0 =
command will not appear), and template
time-out rate in minutes.
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
serviceIdentifier Dynamic WCCP service identifier number. Wccp_Configure
tcp_conn_limit Parameters used for configuring the TCP TCP_Embryonic_Conn_Limit

embryonic connection limits.
(Deprecated.)
tcp_conn_misc Parameters used for configuring the TCP TCP_Embryonic_Conn_Limit,

embryonic connection settings. TCP_Embryonic_Conn_Timeout
(Deprecated.)
tcp_conn_timeout Parameters used for configuring the TCP TCP_Embryonic_Conn_Timeout

embryonic connection timeouts.
(Deprecated.)
tcpMssBytes Maximum segment size in bytes. Sysopt_basic
tcpMssMinimum Checks whether to set maximum segment Sysopt_basic

size (MSS), which is set only if this flag is
true.

1295
threat_detection_statistics Parameters used for threat detection Threat_Detection_Configure

statistics for TCP Intercept.
vxlan_Nve_Only Parameters for configuring NVE-only on VxLAN_Make_Nve_Only

interface:
• logical name of interface
• IPv4 address (optional for routed
interface)
• IPv4 netmask (optional for routed
interface)
vxlan_Port_And_Nve Parameters used for configuring ports and VxLAN_Configure_Port_And_Nve

NVE for VXLAN:
• vxlan port
• source interface (logical name)
• type (peer or mcast)
• Peer IP Address or
default-mcast-grooup
vxlan_Vni Parameters used for creating VNI: VxLAN_Make_Vni

• Interface number (1-10000)
• segment-id (1-16777215)
• nameif (Logical Name of the
interface)
• type (routed or transparent)
• IP address (used in case of routed
mode device) or bridge-group number
(used in case of transparent mode
device)
• netmask (If device is in routed mode)
or unused
wccpPassword WCCP password. Wccp_Configure

1296
Requirements and Prerequisites for FlexConfig Policies
Requirements and Prerequisites for FlexConfig Policies

Model Support
FTD
Supported Domains
Any
User Roles
Admin
Guidelines and Limitations for FlexConfig

• If you make a mistake in the FlexConfig policy, the system will roll back all changes included in the
deployment attempt that includes the failed FlexConfig. Because rollback due to a failed deployment
includes clearing the configuration, this can be disruptive to your network. Consider timing deployments
that include FlexConfig changes to non-business hours. Also, consider isolation the deployment so it
includes just FlexConfig changes, and no other policy updates.
• When you use the VxLAN_Make_VNI object, you must deploy the same FlexConfig to all units in a
cluster or high availability pair before you form the cluster or high availability pair. The Management
Center requires the VXLAN interfaces to match on all devices before forming the cluster or high
availability pair.
• If you want to configure Equal-Cost-Multi-Path (ECMP) routing using traffic zones, the zone command
differs for FTD devices compared to the one used on ASA. Although you can still follow the instructions
in the ASA general configuration guide, use zone name ecmp instead of the ASA version of the command.
Otherwise, the operation of the traffic zone feature is identical between the ASA and FTD .
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.
Customizing Device Configuration with FlexConfig Policies

Use FlexConfig policies to customize the configuration of a FTD device.
Before using FlexConfig, try to configure all the policies and settings you need using the other features in
Firepower Management Center. FlexConfig is a method of last resort to configure ASA-based features that
are compatible with FTD but which are not otherwise configurable in Firepower Management Center.
Following is the end-to-end procedure for configuring and deploying a FlexConfig policy.

1297
Customizing Device Configuration with FlexConfig Policies
Procedure
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 1278
• CLI Commands in FlexConfig Objects, on page 1278
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 1288.
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 1281
• FlexConfig Policy Object Variables, on page 1286
• FlexConfig System Variables, on page 1287
• Configure FlexConfig Text Objects, on page 1303

1298
Configure FlexConfig Objects
Step 4 If you are using the predefined FlexConfig objects, edit the text objects used as variables.
See Configure FlexConfig Text Objects, on page 1303.
Step 5 (If necessary.) Configure FlexConfig Objects, on page 1299.

You need to create objects only if the predefined objects cannot do the job.
Step 6 Configure the FlexConfig Policy, on page 1305.

Step 7 Set Target Devices for a FlexConfig Policy, on page 1306.
You can also assign the policy to devices when you create the policy. The policy must have at least one
assigned device before you can preview it.
Step 8 Preview the FlexConfig Policy, on page 1306.

You must save changes before you can preview the policy.
Verify that the generated commands are the ones intended, and that all variables are resolving correctly.
Step 9 Choose Deploy > Deployment in the menu bar.

Step 10 Select the devices assigned to the policy, and click Deploy.
Wait for deployment to complete.
Step 11 Verify the Deployed Configuration, on page 1307.

Step 12 (If necessary.) Remove Features Configured Using FlexConfig, on page 1309.
Unlike other types of policy, simply unassigning a FlexConfig from a device might not remove the related
configuration. If you want to remove a FlexConfig-generated configuration, you follow the cited procedure.
If you are removing a Feature because it is now directly supported by the product, see also Convert from
FlexConfig to Managed Feature, on page 1310.

Use FlexConfig objects to define a configuration to be deployed to a device. Each FlexConfig policy is
composed of a list of FlexConfig objects, so the objects are essentially code modules composed of Apache
Velocity scripting commands, ASA software configuration commands, and variables.
There are several predefined FlexConfig objects that you can use directly, or you can make copies if you need
to edit them. You can also create your own objects from scratch. A FlexConfig object’s content can range
from a single simple command string to elaborate CLI command structures that use variables and scripting
commands to deploy commands whose content can differ from device to device or deployment to deployment.
You can also create FlexConfig policy objects when defining FlexConfig policies.
Before you begin

Keep the following in mind:
• FlexConfig objects translate into commands that are then deployed to the device. These commands are
already issued in global configuration mode. Therefore, do not include the enable and configure terminal
commands as part of the FlexConfig object.

1299
• Determine what types of variables you will need, and create any policy objects that you will require.
You cannot create objects for variables while editing a FlexConfig object.
• Ensure that your commands do not conflict in any way with the VPN or access control configuration on
the devices.
• 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.
Procedure

Step 2 Choose FlexConfig > FlexConfig Object from the list of object types.
• Click Add FlexConfig Object to create a new object.
• Click View ( ) to see the contents of a predefined object.
• If you want to edit a predefined object, click Copy ( ) to create a new object with the same contents.
Step 4 Enter a Name and optionally, a description for the object.

Step 5 In the object body area, enter the commands and instructions to produce the required configuration.
The object content is a sequence of scripting commands and configuration commands that generate a valid
ASA software command sequence. The FTD device uses ASA software commands to configure some features.
For more information on scripting and configuration commands, see:
• Template Scripts, on page 1281
• CLI Commands in FlexConfig Objects, on page 1278
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 1281.
• To insert system variables, choose Insert > Insert System Variable > Variable Name. For a detailed
explanation of these variables, see FlexConfig System Variables, on page 1287.
• 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 1286. For more detail on the procedure,
see Add a Policy Object Variable to a FlexConfig Object, on page 1302.
• 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 1302.

1300
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 6 Choose the deployment frequency and type.

• Deployment—Whether to deploy the commands in the object Once or Everytime. The only way to
choose the right option is to test the results of deployment.
Start by selecting Everytime. Then, after you attach the object to a FlexConfig policy, deploy the
configuration. After a successful deployment, come back to the FlexConfig policy and preview the
configuration for one of the assigned devices as described in Preview the FlexConfig Policy, on page
1306. If the section labeled ###CLI generated from managed features ### contains commands that
clear or negate the commands in the object, and the ###Flex-config Appended CLI ### section contains
the commands to reconfigure the feature, you know that Everytime is the right option.
Even if you do not see negate commands, make some minor change to the device configuration, then
run another deployment. If the deployment completes successfully, you can check the deployment
transcript (see Verify the Deployed Configuration, on page 1307). If you see that the commands were
issued again (even when they were already configured) without error, then you can keep Everytime.
Change to Once only if the system does not first negate the commands in the object before issuing them
again, or if the deployment results in errors that are specific to the command. In some cases, the system
does not allow you to issue a command that is already configured, but this is the exception.
Some additional tips:
• If the FlexConfig object points to system-managed objects such as network or ACL objects, choose
Everytime. Otherwise, updates to the objects might not get deployed.
• Use Once if the only thing you do in the object is to clear a configuration. Then, remove the object
from the FlexConfig policy after the next deployment.
• Type—Select one of the following:

• Append—(The default.) Commands in the object are put at the end of the configurations generated
from the Firepower Management Center policies. You must use Append if you use policy object
variables, which point to objects generated from managed objects. If commands generated for other
policies overlap with those specified in the object, you should select this option so your commands
are not overwritten. This is the safest option.
• Prepend—Commands in the object are put at the beginning of the configurations generated from
the Firepower Management Center policies. You would typically use prepend for commands that
clear or negate a configuration.
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.

1301
Add a Policy Object Variable to a FlexConfig Object
Step 8 Click Save.
What to do next
Add a Policy Object Variable to a FlexConfig Object

You can insert variables into a FlexConfig policy object that are associated with other types of policy object.
When the FlexConfig is deployed to a device, these variables resolve to the names or content of the associated
object.
Use the following procedure for the first use of a policy object variable in a FlexConfig object. If you need
to refer to the object again, type in the variable (including the $ sign). To understand how to use these variables,
see How to Process Variables, on page 1282.
Procedure
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.
Step 4 Click Save.

The variable appears in the Variables list at the bottom of the FlexConfig object editor.
Configure Secret Keys

A secret key is any single-string variable whose content you want to mask, such as passwords. The system
provides special treatment for these variables to help you prevent the dissemination of sensitive information.
Secret key variables do not show up in the Variables list in the FlexConfig object.
Use the following procedure to create, insert, and otherwise manage secret key variables in a FlexConfig
object. Unlike other types of variables, you can use the Insert command every time you need to insert a given
secret key variable. With respect to processing, these variables behave like single-value text object variables;
see Single Value Variables, on page 1282.

1302
Configure FlexConfig Text Objects
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.
Procedure
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.
• To delete a secret key variable, click Delete ( ) for the variable.
Step 3 Click Save.

Use text objects in FlexConfig objects as the target of policy object variables. You can use variables to supply
information that can be known only at runtime, or which can differ from device to device. During deployment,
variables that point to text objects are replaced by the content of the text object.
Text objects contain free-form strings, which can be keywords, interface names, numbers, IP addresses, and
so forth. The content depends on how you will use the information within a FlexConfig script.
Before creating or editing a text object, determine exactly what content you will need. This includes how you
intend to process the object, which will help you decide between creating a single string or multiple string
object. Read the following topics:
• FlexConfig Variables, on page 1281
• How to Process Variables, on page 1282
Procedure

Step 2 Choose FlexConfig > Text Object from the list of object types.

1303

• Click Add Text Object to create a new object.
• 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 4 Enter a Name and optionally, a description for the object.

Step 5 (New objects only.) Choose a Variable Type from the drop-down list:
• Single—If the object should contain a single text string.
• Multiple—If the object should contain a list of text strings.
You cannot change the variable type after you save the object.
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.
Step 7 Add content to the object.

You can either click in the text box next to a variable number and type in a value, or you can set up device
overrides for each device that will be assigned a FlexConfig object that uses the text object. You can also do
both, in which case the values configured in the base object act as default values in cases where an override
does not exist for a given device.
When editing predefined objects, it is a good practice to use device overrides, so that the system defaults
remain in place for other users who might need to use the object in different FlexConfig policies. The approach
you take depends on the requirements of your organization.
Tip Some predefined objects require multiple values where each value serves a specific purpose. Read
the description text carefully to determine the expected values in the object. In some cases, the
instructions specify that you must use overrides instead of changing the base values. In the case of
enableInspectProtocolList, you are prevented from entering protocols whose inspection is
incompatible with Snort inspection.
If you decide to use device overrides, do the following.

a) Select Allow Overrides.
b) Expand the Overrides area (if necessary) and click Add.
If an override already exists for the device, click edit for the override to change it.
c) On Targets in the Add Object Override dialog box, select the device for which you are defining values
and click Add to move it to the Selected Devices list.
d) Click Override, adjust the Count as needed, then click in the variable fields and type in the values for
the device.
e) Click Add.
Step 8 Click Save.
What to do next

1304
Configure the FlexConfig Policy
Configure the FlexConfig Policy

A FlexConfig policy contains two ordered lists of FlexConfig objects, one prepended list and one appended
list. For an explanation of prepend/append, see Configure FlexConfig Objects, on page 1299.
FlexConfig policies are shared policies that you can assign to multiple devices.
Procedure
Step 1 Choose Devices > FlexConfig.

• Click New Policy to create a new FlexConfig Policy. You are prompted to enter a name. Optionally,
select devices in the Available Devices list and click Add to Policy to assign devices. Click Save.
• 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.
• Click delete to remove a policy you no longer need.
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.
To remove a selected object, click Delete ( ) next to an 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 1306.
Step 5 Click Save.
What to do next
• Set target devices for the policy; see Set Target Devices for a FlexConfig Policy, on page 1306.

1305
Set Target Devices for a FlexConfig Policy
Set Target Devices for a FlexConfig Policy

When you create a FlexConfig policy, you can select the devices that use the policy. You can subsequently
change device assignments for the policy as described below.
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 1309.
Procedure
Step 1 Choose Devices > FlexConfig and edit a FlexConfig policy.

Step 2 Click Policy Assignments.
Step 3 On Targeted Devices, build your target list:
• Add—Choose one or more Available Devices, then click Add to Policy or drag and drop into the list
of Selected Devices. You can assign the policy to devices, high availability pairs, and clustered devices.
• Delete—Click Delete ( ) next to a single device, or select multiple devices, right-click, then choose
Delete Selection.
Step 4 Click OK to save your selection.

Step 5 Click Save to save the FlexConfig policy.
What to do next
Preview the FlexConfig Policy

Preview a FlexConfig policy to see how the FlexConfig objects get translated into CLI commands. The preview
shows the commands that will be generated for a selected device from the scripts and variables used in the
FlexConfig objects. The variables are resolved based on the configuration for the device, so you get a clear
idea of what will be deployed.
Use the preview to look for potential problems in the FlexConfig objects. Correct the objects until the preview
shows the expected results.
You must preview the configuration separately for each device, because the variables can resolve differently
based on the device configuration.

1306
Verify the Deployed Configuration
Procedure
Step 1 Choose Devices > FlexConfig and edit a FlexConfig policy.

Step 2 If there are any pending changes, click Save.
The preview shows results only for those FlexConfig objects that were in the most recently saved version of
the policy. You must save the policy to see a preview of newly-added objects.
Step 3 Click Preview Config.

Step 4 Choose a device from the Select Device drop-down list.
The system retrieves information from the device and configured policies, and determines what CLI commands
will be generated on the next deployment to the device. You can select the output and use Ctrl+C to copy it
to the clipboard, where you can paste it into a text file for further analysis.
The preview includes the following sections:
• Flex-config Prepended CLI—These are the commands generated by FlexConfigs that are prepended to
the configuration.
• CLI generated from managed features—These are commands generated for policies configured in
Firepower Management Center. Commands are generated for new or changed policies since the last
successful deployment to the device. These commands do not represent all commands needed to implement
the assigned policies. No commands in this section are generated from FlexConfig objects.
• Flex-config Appended CLI—These are the commands generated by FlexConfigs that are appended to
the configuration.
Step 5 Click Close to close the preview dialog.

After you deploy a FlexConfig policy to a device, verify that the deployment was successful and that the
resulting configuration is what you expected. Also, verify that the device is performing as expected.
Procedure
Step 1 To verify that deployment was successful:

a) Click System Status in the menu bar, which is unnamed between Deploy and System.
The icon looks like one of the following, and it might include a number if there are errors:
• Indicates No Warnings — Indicates no warnings or errors are present on the system.
• Indicates One or More Warnings — Indicates one or more warnings and no errors are present on
the system.
• Indicates One or More Errors — Indicates one or more errors and any number of warnings are
present on the system.
b) On Deployments, verify that the deployment was successful.

1307
c) To see more detailed information, especially for failed deployments, click Show History.
d) Select the deployment job in the list of jobs in the left column.
Jobs are listed in reverse chronological order, with the most recent job at the top of the list.
e) Click download in the Transcript column for the device in the right column.
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 that you sent through FlexConfig. 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. Messages relevant to FlexConfig
are in the CLI Apply section of the transcript.
========= CLI APPLY =========

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.
b) Click Advanced Troubleshooting.
c) Click Threat Defense CLI.
d) Select show as the command, and type running-config as the parameter.
e) Click Execute.
The running configuration appears in the text box. You can select the configuration and press Ctrl+C,
then paste it into a text file for later analysis.
Step 3 Verify that the device is performing as expected.

Use the show commands related to the feature to see detailed information and statistics. For example, if you
enabled additional protocol inspections, the show service-policy command provides this information. The
exact commands to use are feature-dependent and should be mentioned in the ASA configuration guide and
command reference you used to learn how to configure the feature.
If commands that show statistics indicate that numbers are not changing (for example, hit counts, connection
counts, and so forth), the configuration might be valid but not meaningful. If you know that traffic is going
through the device that should show up in statistics, look for what is missing in your configuration. For
example, NAT or access rules might be dropping or changing traffic before a feature can act on it.

1308
Remove Features Configured Using FlexConfig
You can use the show commands from an SSH session or through the Firepower Management Center CLI
tool.
However, if the show command that you need to use is not available directly within the FTD CLI, you will
need make an SSH connection to the device to use the commands. From the CLI, enter the following command
sequence to enter Privileged EXEC mode within the diagnostic CLI. From there, you should be able to enter
these otherwise unsupported show commands.
> system support diagnostic-cli

Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.
firepower> enable
Password: <press enter, do not enter a password>
firepower#
Remove Features Configured Using FlexConfig

If you decide you need to remove a set of configuration commands you configured using FlexConfig, you
might need to manually remove that configuration. Unassigning the FlexConfig policy from a device might
not remove all of the configuration.
To manually remove the configuration, you create new FlexConfig objects to clear or negate the configuration
commands.
Before you begin

To determine if you need to manually remove some or all of the configuration generated by an object:
1. Examine the configuration preview, as described in Preview the FlexConfig Policy, on page 1306. If the
###CLI generated from managed features ### section contains the clear or negate commands to
remove all of the commands in the FlexConfig object, then you can simply remove the object from the
FlexConfig policy, save, and redeploy.
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.
Procedure
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:
clear configure router eigrp

1309
Convert from FlexConfig to Managed Feature
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.
no sysopt traffic detailed-statistics
no sysopt connection timewait
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 3 Click Save to save the FlexConfig policy.

Step 4 Click Preview Config and verify that the clear and negation commands are generating correctly.
Step 5 Choose Deploy > Deployment in the menu bar, select the device, and click Deploy.
Wait for deployment to complete.
Step 6 Verify that the commands were removed.

View the running configuration on the device to confirm that the commands are removed. For more detailed
information, see Verify the Deployed Configuration, on page 1307.
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.
Convert from FlexConfig to Managed Feature

Each software release adds managed features to the product, that is, features that you configure directly through
policies that are controlled outside of FlexConfig. This can deprecate FlexConfig commands that you are
currently using; your configurations are not automatically converted. After the upgrade, you cannot assign or
create FlexConfig objects using the newly deprecated commands. After upgrading software, examine your
FlexConfig policies and objects.
When a feature you configured using FlexConfig starts to be supported as a managed feature, you must convert
from using FlexConfig to using the managed feature. In most cases, your existing FlexConfig configurations
continue to work post-upgrade and you can still deploy. However, in some cases, using deprecated commands
can cause deployment issues. Configuring a feature in both the GUI and FlexConfig is not supported.

1310
Examples for FlexConfig
Procedure
Step 1 Remove the FlexConfig, as explained in Remove Features Configured Using FlexConfig, on page 1309.
Step 2 Configure the settings in the newly supported managed feature.
The release notes have a list of new features for the release.
Examples for FlexConfig

Following are some examples of using FlexConfig.
How to Configure Precision Time Protocol (ISA 3000)

The Precision Time Protocol (PTP) is a time-synchronization protocol developed to synchronize the clocks
of various devices in a packet-based network. These device clocks are generally of varying precision and
stability. The protocol is designed specifically for industrial, networked measurement and control systems,
and is optimal for use in distributed systems because it requires minimal bandwidth and little processing
overhead.
A PTP system is a distributed, networked system consisting of a combination of PTP and non-PTP devices.
PTP devices include ordinary clocks, boundary clocks and transparent clocks. Non-PTP devices include
network switches, routers and other infrastructure devices.
You can configure the FTD device to be a transparent clock. The FTD device does not synchronize its clock
with the PTP clocks. The FTD device will use the PTP default profile, as defined on the PTP clocks.
When you configure the PTP devices, you define a domain number for the devices that are meant to function
together. Thus, you can configure multiple PTP domains, and then configure each non-PTP device to use the
PTP clocks for one specific domain.
Before you begin

Determine the domain number configured on the PTP clocks that the device should use. This example assumes
the PTP domain number is 10. Also, determine the interfaces through which the system can reach the PTP
clocks in the domain.
Following are guidelines for configuring PTP:
• This feature is only available on the Cisco ISA 3000 appliance.
• Cisco PTP supports multicast PTP messages only.
• PTP is available only for IPv4 networks, not for IPv6 networks.
• PTP configuration is supported on physical Ethernet data interfaces, whether stand-alone or bridge group
members. It is not supported on the management interface, subinterfaces, EtherChannels, Bridge Virtual
Interfaces (BVI), or any other virtual interfaces.
• PTP flows on VLAN subinterfaces are supported, assuming the appropriate PTP configuration is present
on the parent interface.

1311
• You must ensure that PTP packets are allowed to flow through the device. PTP traffic is identified by
UDP destination ports 319 and 320, and destination IP address 224.0.1.129, so any access control rule
that allows this traffic should work.
• In Routed firewall mode, you must enable Multicast routing for PTP multicast groups. In addition, if an
interface on which you enable PTP is not in a bridge group, you must configure the interface to join the
IGMP multicast group 224.0.1.129. If the physical interface is a bridge group member, you do not
configure it to join the IGMP multicast group.
Procedure
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.
a) Choose Devices > Device Management, and edit the device.

b) Click Routing.
c) Select Multicast Routing > IGMP.
d) Select the Enable Multicast Routing check box.
e) Click Join Group.
f) Click Add, and in the Add IGMP Join Group Parameters dialog box, configure the following options and
click OK.
• Interface—Select the PTP-clock-facing stand-alone interface.
• Join Group—Click + to add a new network object. Create a Host object with the address 224.0.1.129.
When configuring additional interfaces, simply select this object.
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).
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.

1312
• 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:
ptp mode e2etransparent

ptp domain 10
interface gigabitethernet1/1
ptp enable
The object body should look similar to the following:
Step 3 Create the FlexConfig policy and assign it to the devices.

If you created multiple FlexConfig objects for different combinations of PTP-clock-facing interfaces, you
need to create separate FlexConfig policies for each object, and assign those policies to the correct devices
based on the interfaces you need to configure. Repeat the following procedure for each group of devices.
b) Either click New Policy, or if an existing FlexConfig policy should be assigned to (or is already assigned
to) the target devices, simply edit that policy.
When creating a new policy, assign the target devices to the policy in the dialog box where you name the
policy.
c) Select the PTP FlexConfig object in the User Defined folder in the table of contents and click > to add
it to the policy.
The object should be added to the Selected Appended FlexConfigs list.
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.

1313
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:

ptp mode e2etransparent
ptp domain 10
interface gigabitethernet1/1
ptp enable
Step 4 Deploy your changes.

Because you assigned a FlexConfig policy to the devices, you will always get a deployment warning, which
is meant to caution you about the use of FlexConfig. Click Proceed to continue with the deployment.
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 1307.
Step 5 Verify the PTP configuration on each device.

From an SSH or Console session into each device, verify the PTP settings:
> show ptp clock

PTP CLOCK INFO
PTP Device Type: End to End Transparent Clock
Operation mode: One Step
Clock Identity: 34:62:88:FF:FE:1:73:81
Clock Domain: 10
Number of PTP ports: 4
> show ptp port
PTP PORT DATASET: GigabitEthernet1/1
Port identity: Clock Identity: 34:62:88:FF:FE:1:73:81
Port identity: Port Number: 1
PTP version: 2
Port state: Enabled

PTP version: 2
Port state: Disabled

PTP version: 2

PTP version: 2

1314
How to Configure Automatic Hardware Bypass for Power Failure (ISA 3000)
You can enable hardware bypass so that traffic continues to flow between an interface pair during a power
outage. Supported interface pairs are copper interfaces GigabitEthernet 1/1 and 1/2; and GigabitEthernet 1/3
and 1/4. If you have a fiber Ethernet model, only the copper Ethernet pair (GigabitEthernet 1/1 and 1/2)
supports hardware bypass.
When hardware bypass is active, traffic passes between these interface pairs at layer 1. The FTD CLI will see
the interfaces as being down. No firewall functions are in place, so make sure you understand the risks of
allowing traffic to pass through the device.
In CLI Console or an SSH session, use the show hardware-bypass command to monitor the operational
status.
Before you begin

For hardware bypass to work:
• You must place the interface pairs in the same bridge group.
• You must attach the interfaces to access ports on the switch. Do not attach them to trunk ports.
We recommend that you disable TCP sequence number randomization globally using the Threat Defense
Service Policy attached to the access control policy assigned to the device. By default, the ISA 3000 rewrites
the initial sequence number (ISN) of TCP connections passing through it to a random number. When hardware
bypass is activated, the ISA 3000 is no longer in the data path and does not translate the sequence numbers.
The receiving client receives an unexpected sequence number and drops the connection, so the TCP session
needs to be re-established. Even with TCP sequence number randomization disabled, some TCP connections
will have to be re-established because of the link that is temporarily down during the switchover.
Procedure
Step 1 Create the FlexConfig object to enable automatic bypass.

• Name—The object name. For example, Enable_HW-Bypass.
directly-supported features.
• Object body—In the object body, type the commands needed to enable automatic hardware bypass.
For example, the commands needed for both possible interface pairs:
hardware-bypass GigabitEthernet 1/1-1/2


1315

policy.
c) Select the hardware bypass FlexConfig object in the User Defined folder in the table of contents and click
> to add it to the policy.
d) Click Save.
commands generated from the hardware bypass 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 hardware bypass commands, you should see something similar to the
following:


page 1307.

1316
How to Configure Policy Based Routing
What to do next
If you want to manually invoke hardware bypass or manually turn it off, you need to create two FlexConfig
objects:
• One that manually starts bypass, which would contain one or both of the following commands, depending
on whether you want to invoke bypass for both pairs:
hardware-bypass manual GigabitEthernet 1/1-1/2

hardware-bypass manual GigabitEthernet 1/3-1/4
• One that manually turns off bypass, which would contain one or both of the following commands:
no hardware-bypass manual GigabitEthernet 1/1-1/2

no hardware-bypass manual GigabitEthernet 1/3-1/4
You would then need to add one or the other object to the FlexConfig policy, and deploy changes, to either
turn bypass on or off. You would also need to immediately remove the object from the FlexConfig policy
after deployment. If you manually invoke bypass, you would then need to repeat the process to turn it off
again. Thus, using this manual method requires frequent and careful editing of the FlexConfig policy and
additional deployments.

You can implement policy-based routing (PBR) features using FlexConfig. For example, the following graphic
shows how to load balance traffic between networks based on source IP address. In this case, we will assume
that the 10.1.0.0/16 network generates high priority traffic, which should go over the higher bandwidth link
to ISP-A, and 10.2.0.0/16 is lower priority and should go over the slower, lower bandwidth link to ISP-B.

1317
Before you begin

This procedure assumes that you have already configured the interfaces as follows:
• GigabitEthernet0/0.
• Interface name: inside
• IP address: 10.1.1.1/24
• Note that other routers in the network use this interface as the gateway for routes for the 10.1.0.0/16
and 10.2.0.0/16 address spaces.
• Interface name: outside-1
• IP address: 192.168.6.5/24
• Interface name: outside-2
• IP address: 172.16.7.6/24

1318
Procedure
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.
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.

1319
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.

1320
e) Click Add to add the rule to the route map.

f) Click Add and create a rule for low-priority traffic with the following attributes:
• Sequence No.—20.
• Redistribution—Allow.
• Match Clauses > IPv4 > Address—Select the Access List radio button, then Available Access
Lists > Extended, and move the low-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-B, 172.16.7.7 into the Specific IP edit box.
g) Click Add to add the rule to the route map.
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.
d) The body of the object has the following lines.
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.

1321
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.
h) Click Save in the Route Map Variable dialog box.

The FlexConfig object should now look like the following, where your variable is now in the variables
list at the bottom of the dialog box.

1322
i) Click Save.
Step 4 Add the FlexConfig object to the FlexConfig policy that is assigned to the device.
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.

1323
d) Click Save to save the policy.

e) Click Preview Config, then in the preview dialog box, select the FTD1 device.
The preview includes CLI generated from both the FlexConfig objects and the parts of the FMC-managed
configuration that are implemented using configuration commands. These are separated into sections.
The commands that will be configured based on what we have done in this example are the following.
You can verify you are getting the expected results using this preview.
###Flex-config Prepended CLI ###
###CLI generated from managed features ###

configure session OBJECT
object-group service ProxySG_ExtendedACL_4294969626
service-object ip
object-group service ProxySG_ExtendedACL_4294969648
service-object ip
commit noconfirm revert-save
configure session FMC_SESSION_1
access-list high-priority extended permit object-group
ProxySG_ExtendedACL_4294969626 10.1.0.0 255.255.0.0 any
access-list low-priority extended permit object-group
ProxySG_ExtendedACL_4294969648 10.2.0.0 255.255.0.0 any
commit noconfirm revert-save
route-map load-balance permit 10
match ip address high-priority
set ip next-hop 192.168.6.6
route-map load-balance permit 20
match ip address low-priority
set ip next-hop 172.16.7.7

policy-route route-map load-balance

1324
History for FlexConfig
f) Click Close to shut the preview dialog box.
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.

1325
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.

1326
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.

1327

1328
CHAPTER 52
Alarms for the Cisco ISA 3000
You can configure the alarm system on a Cisco ISA 3000 device to alert you when undesirable conditions
occur.
• About Alarms, on page 1329
• Defaults for Alarms, on page 1331
• Requirements and Prerequisites for Alarms, on page 1332
• Configure the Alarms for the ISA 3000, on page 1332
• Monitoring Alarms, on page 1340
• History for Alarms, on page 1341
About Alarms
You can configure the ISA 3000 to issue alarms for a variety of conditions. If any conditions do not match
the configured settings, the system triggers an alarm, which is reported by way of LEDs, syslog messages,
SNMP traps, and through external devices connected to the alarm output interface. By default, triggered alarms
issue syslog messages only.
You can configure the alarm system to monitor the following:
• Power supply.
• Primary and secondary temperature sensors.
• Alarm input interfaces.
The ISA 3000 has internal sensors plus two alarm input interfaces and one alarm output interface. You can
connect external sensors, such as door sensors, to the alarm inputs. You can connect external alarm devices,
such as buzzers or lights, to the alarm output interface.
The alarm output interface is a relay mechanism. Depending on the alarm conditions, the relay is either
energized or de-energized. When it is energized, any device connected to the interface is activated. A
de-energized relay results in the inactive state of any connected devices. The relay remains in an energized
state as long as alarms are triggered.
For information about connecting external sensors and the alarm relay, see Cisco ISA 3000 Industrial Security
Appliance Hardware Installation Guide.

1329
Alarm Input Interfaces
Alarm Input Interfaces

You can connect the alarm input interfaces (or contacts) to external sensors, such as one that detects if a door
is open.
Each alarm input interface has a corresponding LED. These LEDs convey the alarm status of each alarm
input. You can configure the trigger and severity for each alarm input. In addition to the LED, you can configure
the contact to trigger the output relay (to activate an external alarm), to send syslog messages, and to send
SNMP traps.
The following table explains the statuses of the LEDs in response to alarm conditions for the alarm inputs. It
also explains the behavior for the output relay, syslog messages, and SNMP traps, if you enable these responses
to the alarm input.
Alarm Status LED Output Relay Syslog SNMP Trap
Alarm not Off — — —

configured
No alarms triggered Solid green — — —
Alarm activated Minor alarm—solid Relay energized Syslog generated SNMP trap sent
red
Major
alarm—flashing red
Alarm end Solid green Relay de-energized Syslog generated —
Alarm Output Interface

You can connect an external alarm, such as a buzzer or light, to the alarm output interface.
The alarm output interface functions as a relay and also has a corresponding LED, which conveys the alarm
status of an external sensor connected to the input interface, and internal sensors such as the dual power supply
and temperature sensors. You configure which alarms should activate the output relay, if any.
The following table explains the statuses of the LEDs and output relay in response to alarm conditions. It also
explains the behavior for syslog messages, and SNMP traps, if you enable these responses to the alarm.
Alarm Status LED Output Relay Syslog SNMP Trap
Alarm not Off — — —

configured
No alarms triggered Solid green — — —
Alarm activated Solid red Relay energized Syslog generated SNMP trap sent
Alarm end Solid green Relay de-energized Syslog generated —

1330
Syslog Alarms
Syslog Alarms
By default, the system sends syslog messages when any alarm is triggered. You can disable syslog messaging
if you do not want the messages.
For syslog alarms to work, you must also enable diagnostic logging. Choose Device > Platform Settings,
add or edit an FTD platform settings policy that is assigned to the device, and configure destinations and
settings on the Syslog page. For example, you can configure a syslog server, console logging, or internal
buffer logging.
Without enabling a destination for diagnostic logging, the alarm system has nowhere to send syslog messages.
SNMP Alarms
You can optionally configure the alarms to send SNMP traps to your SNMP server. For SNMP trap alarms
to work, you must also configure SNMP settings.
Choose Device > Platform Settings, add or edit an FTD platform settings policy that is assigned to the device,
and enable SNMP and configure settings on the SNMP page.
Defaults for Alarms

The following table specifies the defaults for alarm input interfaces (contacts), redundant power supply, and
temperature.
Alarm Trigger Severity SNMP Trap Output Syslog

Relay Message
Alarm Contact 1 Enabled Closed Minor Disabled Disabled Enabled

State
Alarm Contact 2 Enabled Closed Minor Disabled Disabled Enabled

State
Redundant Power Enabled — — Disabled Disabled Enabled

Supply (when
enabled)
Temperature Enabled for the — — Enabled for Enabled for Enabled for
primary primary primary primary
temperature temperature temperature temperature
alarm (default alarm alarm alarm
values of 92°C
and -40°C for the
high and low
thresholds
respectively)
Disabled for the
secondary alarm.

1331
Requirements and Prerequisites for Alarms
Requirements and Prerequisites for Alarms

Model Support
FTD on the ISA 3000.
Supported Domains
Any
User Roles
Admin
Configure the Alarms for the ISA 3000

You use FlexConfig to configure alarms for the ISA 3000. The following topics explain how to configure the
different types of alarms.
Configure Alarm Input Contacts

If you connect the alarm input contacts (interfaces) to external sensors, you can configure the contacts to issue
alarms based on the input from the sensor. In fact, the contacts are enabled by default to send syslog messages
if the contact is closed, that is, if the electrical current stops flowing through the contact. You need to configure
the contact only if the defaults do not meet your requirements.
The alarm contacts are numbered 1 and 2, so you need to understand how you have wired the physical pins
to configure the correct settings. You configure the contacts separately.
Procedure
Step 1 Create the FlexConfig object to configure the alarm input contacts.
• Name—The object name. For example, Configure_Alarm_Contacts.
• Object body—In the object body, type the commands needed to configure the alarm contacts. The
following steps explain the commands.
d) Configure a description for the alarm contact.

1332
alarm contact {1 | 2} description string

For example, to set the description of contact 1 to "Door Open," enter the following:
alarm contact 1 description Door Open
e) Configure the severity for the alarm contact.

alarm contact {1 | 2 | any} severity {major | minor | none}
Instead of configuring one contact, you can specify any to change the severity for all contacts. The severity
controls the behavior of the LED associated with the contact.
• major—The LED blinks red.
• minor—The LED is solid red. This is the default.
• none—The LED is off.
For example, to set the severity of contact 1 to Major, enter the following:
alarm contact 1 severity major
f) Configure the trigger for the alarm contact.

alarm contact {1 | 2 | any} trigger {open | closed}
Instead of configuring one contact, you can specify any to change the trigger for all contacts. The trigger
determines the electrical condition that signals an alert.
• open—The normal condition for the contact is closed, that is, the electrical current is running through
the contact. An alert is triggered if the contact becomes open, that is, the electrical current stops
flowing.
• closed—The normal condition for the contact is open, that is, the electrical current does not run
through the contact. An alert is triggered if the contact becomes closed, that is, the electrical current
starts running through the contact. This is the default.
For example, you connect a door sensor to alarm input contact 1, and its normal state has no electrical
current flowing through the alarm contact (it is open). If the door is opened, the contact is closed and
electrical current flows through the alarm contact. You would set the alarm trigger to closed so that the
alarm goes off when the electrical current starts flowing.
alarm contact 1 trigger closed
g) Configure the actions to take when the alarm contact is triggered.

alarm facility input-alarm {1 | 2} {relay | syslog | notifies}
You can configure more than one action. For example, you can configure the device to activate the external
alarm, send syslog messages, and also send SNMP traps.
• relay—Energize the alarm output relay, which activates the external alarm that you attached to it,
such as a buzzer or a flashing light. The output LED also goes red.
• syslog—Send a syslog message. This option is enabled by default.
• notifies—Send an SNMP trap.

1333
For example, to enable all actions for the alarm input contact 1, enter the following:
alarm facility input-alarm 1 relay

alarm facility input-alarm 1 syslog
alarm facility input-alarm 1 notifies
h) Verify that the object body contains the commands you want.
For example, if your template includes all of the command examples shown in this procedure, the object
body would have the following commands:

i) Click Save.
policy.
c) Select the alarm contact FlexConfig object in the User Defined folder in the table of contents and click
> to add it to the policy.
d) Click Save.
commands generated from the FlexConfig object look correct. These will be shown at the end of the

1334
Configure Power Supply Alarms
features. For the alarm contact commands, you should see something similar to the following:


page 1307.

The ISA 3000 has two power supplies. By default, the system operates in single-power mode. However, you
can configure the system to operate in dual mode, where the second power supply automatically provides
power if the primary power supply fails. When you enable dual-mode, the power supply alarm is automatically
enabled to send syslog alerts, but you can disable the alert altogether, or also enable SNMP traps or the alarm
hardware relay.
The following procedure explains how to enable dual mode, and how to configure the power supply alarms.
Procedure
Step 1 Create the FlexConfig object to configure the power supply alarm.
• Name—The object name. For example, Power_Supply_Alarms.
• Object body—In the object body, type the commands needed to configure the power supply alarms.
The following steps explain the commands.
d) Enable dual power supply mode.

power-supply dual

1335
For example:
power-supply dual
e) Configure the actions to take when the power supply alarm is triggered.
alarm facility power-supply rps {relay | syslog | notifies | disable}
• syslog—Send a syslog message. This option is enabled by default.
• disable—Disable the power supply alarm. Any other actions configured for the power supply alarm
are inoperable.
For example, to enable all actions for the power supply alarm, enter the following:
alarm facility power-supply rps relay

alarm facility power-supply rps syslog
alarm facility power-supply rps notifies
f) Verify that the object body contains the commands you want.
power-supply dual
g) Click Save.
policy.
c) Select the power supply alarm FlexConfig object in the User Defined folder in the table of contents and
click > to add it to the policy.

1336
Configure Temperature Alarms
d) Click Save.
features. For the power supply alarm commands, you should see something similar to the following:

power-supply dual

page 1307.

You can configure alarms based on the temperature of the CPU card in the device.
You can set a primary and secondary temperature range. If the temperature drops below the low threshold,
or exceeds the high threshold, the alarm is triggered.
The primary temperature alarm is enabled by default for all alarm actions: output relay, syslog, and SNMP.
The default settings for the primary temperature range is -40°C to 92°C.
The secondary temperature alarm is disabled by default. You can set the secondary temperature within the
range -35°C to 85°C.
Because the secondary temperature range is more restrictive than the primary range, if you set either the
secondary low or high temperature, that setting disables the corresponding primary setting, even if you
configure non-default values for the primary setting. You cannot enable two separate high and two separate
low temperature alarms.
Thus, in practice, you should configure the primary only, or the secondary only, setting for high and low.

1337
Procedure
Step 1 Create the FlexConfig object to configure the temperature alarms.

• Name—The object name. For example, Configure_Temperature_Alarms.
• Object body—In the object body, type the commands needed to configure the temperature alarms.
The following steps explain the commands.
d) Configure the acceptable temperature range.

alarm facility temperature {primary | secondary} {low | high} temperature
The temperature is in Celsius. The allowed range for the primary alarm is -40 to 92, which is also the
default range. The allowed range for the secondary alarm is -35 to 85. The low value must be lower than
the high value.
For example, to set a more restrictive temperature range of -20 to 80, which falls within the allowed range
for the secondary alarm, configure the secondary alarm as follows:
alarm facility temperature secondary low -20

alarm facility temperature secondary high 80
e) Configure the actions to take when the temperature alarm is triggered.

alarm facility temperature {primary | secondary} {relay | syslog | notifies}
• syslog—Send a syslog message.
For example, to enable all actions for the secondary temperature alarm, enter the following:
alarm facility temperature secondary relay

alarm facility temperature secondary syslog
alarm facility temperature secondary notifies
f) Verify that the object body contains the commands you want.

1338

g) Click Save.
policy.
c) Select the temperature alarms FlexConfig object in the User Defined folder in the table of contents and
click > to add it to the policy.
d) Click Save.
features. For the temperature alarms commands, you should see something similar to the following:


1339
Monitoring Alarms
page 1307.
Monitoring Alarms
The following topics explain how to monitor and manage alarms.
Monitoring Alarm Status

You can use the following commands in the CLI to monitor alarms.
• show alarm settings
Shows the current configuration for each possible alarm.
• show environment alarm-contact
Shows information about the physical status of the input alarm contacts.
• show facility-alarm relay
Shows information about the alarms that have triggered the output relay.
• show facility-alarm status [info | major | minor]
Shows information on all alarms that have been triggered. You can limit the view by filtering on major
or minor status. The info keyword provides the same output as using no keyword.
Monitoring Syslog Messages for Alarms

Depending on the type of alarms you configure, you might see the following syslog messages.
Dual Power Supply Alarms
• %FTD-1-735005: Power Supply Unit Redundancy OK
• %FTD-1-735006: Power Supply Unit Redundancy Lost
Temperature Alarms
In these alarms, Celsius is replaced by the temperature detected on the device, in Celsius.
• %FTD-6-806001: Primary alarm CPU temperature is High Celsius
• %FTD-6-806002: Primary alarm for CPU high temperature is cleared
• %FTD-6-806003: Primary alarm CPU temperature is Low Celsius
• %FTD-6-806004: Primary alarm for CPU Low temperature is cleared

1340
Turning Off the External Alarm
• %FTD-6-806005: Secondary alarm CPU temperature is High Celsius

• %FTD-6-806006: Secondary alarm for CPU high temperature is cleared
• %FTD-6-806007: Secondary alarm CPU temperature is Low Celsius
• %FTD-6-806008: Secondary alarm for CPU Low temperature is cleared
Alarm Input Contact Alarms

In these alarms, description is the description for the contact that you configured.
• %FTD-6-806009: Alarm asserted for ALARM_IN_1 alarm_1_description
• %FTD-6-806010: Alarm cleared for ALARM_IN_1 alarm_1_description
• %FTD-6-806011: Alarm asserted for ALARM_IN_2 alarm_2_description
• %FTD-6-806012: Alarm cleared for ALARM_IN_2 alarm_2_description
Turning Off the External Alarm

If you are using an external alarm that is attached to the alarm output, and the alarm is triggered, you can turn
off the external alarm from the device CLI using the clear facility-alarm output command. This command
de-energizes the output pin and also turns off the output LED.
History for Alarms

Alarms for the Cisco ISA 3000 series. 6.7 Configuring alarms for the Cisco ISA 3000 series was validated using
FlexConfig. You should be able to configure the alarms in older releases
that support FlexConfig, except for the dual power supply alarms.
Supported platforms: Firepower Threat Defense on the ISA 3000.

1341
History for Alarms

1342
PA R T XII
Appliance Platform Settings
• System Configuration, on page 1345
• Platform Settings Policies, on page 1411
• Platform Settings for Classic Devices, on page 1415
• Platform Settings for Firepower Threat Defense, on page 1425
• Security Certifications Compliance, on page 1473
CHAPTER 53
System Configuration
The following topics explain how to configure system configuration settings on Firepower Management
Centers and managed devices:
• Requirements and Prerequisites for the System Configuration, on page 1346
• About System Configuration, on page 1346
• Appliance Information, on page 1348
• HTTPS Certificates, on page 1349
• External Database Access Settings, on page 1356
• Database Event Limits, on page 1358
• Management Interfaces, on page 1361
• Shut Down or Restart, on page 1369
• Remote Storage Management, on page 1370
• Change Reconciliation, on page 1373
• Policy Change Comments, on page 1375
• Dashboard Settings, on page 1384
• DNS Cache, on page 1384
• Email Notifications, on page 1385
• Language Selection, on page 1386
• Login Banners, on page 1387
• SNMP Polling, on page 1387
• Time and Time Synchronization, on page 1389
• Global User Configuration Settings, on page 1393
• Session Timeouts, on page 1397
• Vulnerability Mapping, on page 1397
• Remote Console Access Management, on page 1398
• REST API Preferences, on page 1404
• VMware Tools and Virtual Systems, on page 1405
• (Optional) Opt Out of Web Analytics Tracking, on page 1405
• History for System Configuration, on page 1406

1345
Requirements and Prerequisites for the System Configuration
Requirements and Prerequisites for the System Configuration

Model Support
FMC
Supported Domains
Global
User Roles
Admin
About System Configuration

System configuration settings apply to either a Firepower Management Center or a Classic managed device
(ASA FirePOWER, NGIPSv):
• For the Firepower Management Center these configuration settings are part of a "local" system
configuration. Note that system configuration on the Firepower Management Center is specific to a single
system, and changes to a FMC's system configuration affect only that system.
• For a Classic managed device, you apply a configuration from the Firepower Management Center as
part of a platform settings policy. You create a shared policy to configure a subset of the system
configuration settings, appropriate for managed devices, that are likely to be similar across a deployment.
Navigating the Firepower Management Center System Configuration

The system configuration identifies basic settings for a Firepower Management Center.
Procedure

Step 2 Use the navigation panel to choose configurations to change; see Table 110: System Configuration Settings
, on page 1347 for more information.
System Configuration Settings

Note that for managed devices, many of these configurations are handled by a platform settings policy applied
from the FMC; see Platform Settings Policies, on page 1411.

1346
System Configuration Settings
Table 110: System Configuration Settings
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 1375.
Access List Control which computers can access the system on specific ports; see Access List, on page 1375.
Audit Log Configure the system to send an audit log to an external host; see Audit Logs, on page 1377.
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 1379 .
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 1373.
Console Configuration Configure console access via VGA or serial port, or via Lights-Out Management (LOM); see Remote
Console Access Management, on page 1398.
Dashboard Enable Custom Analysis widgets on the dashboard; see Dashboard Settings, on page 1384.
Database Specify the maximum number of each type of event that the Firepower Management Center can store;
see Database Event Limits, on page 1358.
DNS Cache Configure the system to resolve IP addresses automatically on event view pages; see DNS Cache, on
page 1384.
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 1385.
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 1356.
HTTPS Certificate Request an HTTPS server certificate, if needed, from a trusted authority and upload certificates to the
system; see HTTPS Certificates, on page 1349.
Information View current information about the appliance and edit the display name; see Appliance Information, on
page 1348.
Intrusion Policy Configure the system to prompt users for a comment when they modify an intrusion policy; see Policy
Preferences Change Comments, on page 1375.
Language Specify a different language for the web interface; see Language Selection, on page 1386.
Login Banner Create a custom login banner that appears when users log in; see Login Banners, on page 1387.
Management Interfaces Change options such as the IP address, hostname, and proxy settings of the appliance; see Management
Interfaces, on page 1361.
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 1375.
Process Shut down, reboot, or restart Firepower processes; see Shut Down or Restart, on page 1369.
Remote Storage Device Configure remote storage for backups and reports; see Remote Storage Management, on page 1370.

1347
Appliance Information
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 1404.
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 1397.
SNMP Enable Simple Network Management Protocol (SNMP) polling; see SNMP Polling, on page 1387.
Time View and change the current time setting; see Time and Time Synchronization, on page 1389.
Time Synchronization Manage time synchronization on the system; see Time and Time Synchronization, on page 1389.
UCAPL/CC Compliance Enable compliance with specific requirements set out by the United States Department of Defense; see
Enable Security Certifications Compliance, on page 1478.
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 1393
VMware Tools Enable and use VMware Tools on a Firepower Management Center Virtual; see VMware Tools and
Virtual Systems, on page 1405.
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 1397.
Web Analytics Enable and disable collection of non-personally-identifiable information from your system. See (Optional)
Opt Out of Web Analytics Tracking, on page 1405.
Related Topics
About Platform Settings for Classic Devices, on page 1415
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.

1348
HTTPS Certificates
Field Description
Name A descriptive name you assign to the FMCappliance.

Although you can use the host name as the name of
the appliance, entering a different name in this field
does not change the host name.
This name is used in certain integrations. For example,
it appears in the Devices list for integrations with
SecureX and Cisco SecureX threat response.
If you change the name, all registered devices are
marked out of date and deployment is required to push
the new name to the devices.
Product Model The model name of the appliance.
Serial Number The serial number of the appliance.
Software Version The version of the software currently installed on the

appliance.
Operating System The operating system currently running on the

appliance.
Operating System Version The version of the operating system currently running
on the appliance.
IPv4 Address The IPv4 address of the default (eth0) management

interface. If IPv4 management is disabled, this field
indicates that.
IPv6 Address The IPv6 address of the default (eth0) management

interface. If IPv6 management is disabled, this field
indicates that.
Current Policies The system-level policies currently deployed. If a

policy has been updated since it was last deployed,
the name of the policy appears in italics.
Model Number The appliance-specific model number stored on the

internal flash drive. This number may be important
for troubleshooting.
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.

1349
Default HTTPS Server Certificates
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.
Default HTTPS Server Certificates

If you use the default server certificate provided with an appliance, do not configure the system to require a
valid HTTPS client certificate for web interface access because the default server certificate is not signed by
the CA that signs your client certificate.
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.
Custom HTTPS Server Certificates

You can use the Firepower Management Center web interface to generate a server certificate request based
on your system information and the identification information you supply. You can use that request to sign a
certificate if you have an internal certificate authority (CA) installed that is trusted by your browser. You can
also send the resulting request to a certificate authority to request a server certificate. After you have a signed
certificate from a certificate authority (CA), you can import it.
HTTPS Server Certificate Requirements

When you use HTTPS certificates to secure the connection between your web browser and the Firepower
appliance web interface, you must use certificates that comply with the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile (RFC 5280). When you import a server certificate
to the appliance, the system rejects the certificate if it does not comply with version 3 (X.509 v3) of that
standard.
Before importing an HTTPS server certificate, be certain it includes the following fields:
Certificate Field Description
Version Version of the encoded certificate. Use version 3. See

RFC 5280, section 4.1.2.1.
Serial number A positive integer assigned to the certificate by the

issuing CA. Issuer and serial number together uniquely
identify the certificate. See RFC 5280, section 4.1.2.2.
Signature Identifier for the algorithm used by the CA to sign the

certificate. Must match the signatureAlgorithm field.
See RFC 5280, section 4.1.2.3.

1350
HTTPS Server Certificate Requirements
Issuer Identifies the entity that signed and issued the

certificate. See RFC 5280, section 4.1.2.4.
Validity Interval during which the CA warrants that it will

maintain information about the status of the certificate.
See RFC 5280, section 4.1.2.5.
Subject Identifies the entitity associated with the public key

stored in the subject public key field; must be an
X.500 disinguished name (DN). See RFC 5280,
section 4.1.2.6.
Subject Alternative Name Domain names and IP addresses secured by the

certificate. Subject Alternative Name is defined in
section RFC 5280, section 4.2.1.6.
We recommend you use this field if the certificate is
used for multiple domains or IP addresses.
Subject Public Key Info Public key and an identifier for its algorithm. See RFC
5280, section 4.1.2.7.
Authority Key Identifier Provides a means of identifying the public key

corresponding to the private key used to sign a
certificate. See RFC 5280, section 4.2.1.1.
Subject Key Identifier Provides a means of identifying certificates that

contain a particular public key. See RFC 5280, section
4.2.1.2.
Key Usage Defines the purpose of the key contained in the

certificates. See RFC 5280, section 4.2.1.3.
Basic Constraints Identifies whether the certificate Subject is a CA, and

the maximum depth of validation certification paths
that include this certificate. See RFC 5280, section
4.2.1.9. This field is not strictly required for server
certificates used in Firepower appliances, but we
strongly recommend including this field and
specifying critical CA:FALSE.
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.
signatureAlgorithm Identifier for the algorithm the CA used to sign the

certificate. Must match the Signature field. See RFC
5280, section 4.1.1.2.

1351
HTTPS Client Certificates
signatureValue Digital signature. See RFC 5280, section 4.1.1.3.
HTTPS Client Certificates

You can restrict access to the Firepower System web server using client browser certificate checking. When
you enable user certificates, the web server checks that a user’s browser client has a valid user certificate
selected. That user certificate must be generated by the same trusted certificate authority that is used for the
server certificate. The browser cannot load the web interface under any of the following circumstances:
• The user selects a certificate in the browser that is not valid.
• 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.
Viewing the Current HTTPS Server Certificate

Procedure

Step 2 Click HTTPS Certificate.
Generating an HTTPS Server Certificate Signing Request

If you install a certificate that is not signed by a globally known or internally trusted CA, the user's browser
displays a security warning when they try to connect to the web interface.
A certificate signing request (CSR) is unique to the appliance or device from which you generated it. You
cannot generate a CSR for multiple devices from a single appliance. Although all fields are optional, we
recommend entering values for the following: CN, Organization, Organization Unit, City/Locality,
State/Province, Country/Region, and Subject Alternative Name.

1352
Generating an HTTPS Server Certificate Signing Request
The key generated for the certificate request is in Base-64 encoded PEM format.
Procedure

Step 3 Click Generate New CSR.
The following figure shows an example.

Step 4 Enter a country code in the Country Name (two-letter code) field.
Step 5 Enter a state or province postal abbreviation in the State or Province field.
Step 6 Enter a Locality or City.
Step 7 Enter an Organization name.
Step 8 Enter an Organizational Unit (Department) name.
Step 9 Enter the fully qualified domain name of the server for which you want to request a certificate in the Common
Name field.
Note Enter the fully qualified domain name of the server exactly as it should appear in the certificate in
the Common Name field. If the common name and the DNS hostname do not match, you receive
a warning when connecting to the appliance.
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 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.

1353
Importing HTTPS Server Certificates
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 1354.
Importing HTTPS Server Certificates

If the signing authority that generated the certificate requires you to trust an intermediate CA, you must also
supply a certificate chain (or certificate path).
If you require client certificates, accessing an appliance via the web interface will fail when the server certificate
does not meet either of the following criteria:
• The certificate is signed by the same CA that signed the client certificate.
• The certificate is signed by a CA that has signed an intermediate certificate in the certificate chain.
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.
Before you begin

• Generate a certificate signing request; see Generating an HTTPS Server Certificate Signing Request, on
page 1352.
• Upload the CSR file to the certificate authority where you want to request a certificate, or use the CSR
to create a self-signed certificate.
• Confirm that the certificate meets the requirements described in HTTPS Server Certificate Requirements,
on page 1350.
Procedure

Step 3 Click Import HTTPS Server Certificate.

1354
Requiring Valid HTTPS Client Certificates
Step 4 Open the server certificate in a text editor, copy the entire block of text, including the BEGIN CERTIFICATE
and END CERTIFICATE lines. Paste this text into the Server Certificate field.
Step 5 Whether you must supply a Private Key depends on how you generated the Certificate Signing Request:
• If you generated the Certificate Signing Request using the Firepower Management Center web interface
(as described in Generating an HTTPS Server Certificate Signing Request, on page 1352), the system
already has the private key and you need not enter one here.
• If you generated the Certificate Signing Request using some other means, you must supply the private
key here. Open the private key file and copy the entire block of text, include the BEGIN RSA PRIVATE
KEY and END RSA PRIVATE KEY lines. Paste this text into the Private Key field.
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.
Requiring Valid HTTPS Client Certificates

Use this procedure to require users connecting to the FMC web interface to supply a user certificate. The
system supports validating HTTPS client certificates using either OCSP or imported CRLs in Privacy-enhanced
Electronic Mail (PEM) format.
If you choose to use CRLs, to ensure that the list of revoked certificates stays current, you can create a scheduled
task to update the CRLs. The system displays the most recent refresh of the CRLs.
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).
Before you begin

• Import a server certificate signed by the same certificate authority that signed the client certificate to be
used for the connection; see Importing HTTPS Server Certificates, on page 1354.
• Import the server certificate chain if needed; see Importing HTTPS Server Certificates, on page 1354.
Procedure

Step 3 Choose Enable Client Certificates. If prompted, select the appropriate certificate from the drop-down list.
Step 4 You have three options:
• To verify client certificates using one or more CRLS, select Enable Fetching of CRL and continue with
Step 5.
• To verify client certificates using OCSP, select Enable OCSP and skip to Step 7.
• To accept client certificates without checking for revocation, skip to Step 8.

1355
Renewing the Default HTTPS Server Certificate
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.
Step 8 Click Save.
Related Topics
Configuring Certificate Revocation List Downloads, on page 297
Renewing the Default HTTPS Server Certificate

You can only view server certificates for the appliance you are logged in to.
Procedure

The button appears only if your system is configured to use the default HTTPS server certificate.
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.
External Database Access Settings

You can configure the Firepower Management Center to allow read-only access to its database by a third-party
client. This allows you to query the database using SQL using any of the following:
• industry-standard reporting tools such as Actuate BIRT, JasperSoft iReport, or Crystal Reports

1356
Enabling External Access to the Database
• any other reporting application (including a custom application) that supports JDBC SSL connections
• the Cisco-provided command-line Java application called RunQuery, which you can either run interactively
or use to obtain comma-separated results for a single query
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.
Enabling External Access to the Database

Procedure

Step 2 Click External Database Access.
Step 3 Select the Allow External Database Access check box.
Step 4 Enter an appropriate value in the Server Hostname field. Depending on your third-party application
requirements, this value can be either the fully qualified domain name (FQDN), IPv4 address, or IPv6 address
of the Firepower Management Center.
Note In an FMC high availability setup, enter only the active peer details. We do not recommend entering
details of the standby peer.
Step 5 Next to Client JDBC Driver, click Download and follow your browser’s prompts to download the client.zip
package.
Step 6 To add database access for one or more IP addresses, click Add Hosts. An IP Address field appears in the
Access List field.
Step 7 In the IP Address field, enter an IP address or address range, or any.
Step 8 Click Add.
Step 9 Click Save.
Tip If you want to revert to the last saved database settings, click Refresh.
Related Topics
Firepower System IP Address Conventions, on page 24

1357
Database Event Limits

To manage disk space, the FMC periodically prunes the oldest intrusion events, audit records, Security
Intelligence data, and URL filtering data from the event database. For each event type, you can specify how
many records the FMC retains after pruning; never rely on the event database containing more records of any
type than the retention limit configured for that type. To improve performance, tailor the event limits to the
number of events you regularly work with. You can optionally choose to receive email notifications when
pruning occurs. For some event types, you can disable storage.
To manually delete individual events, use the event viewer. (Note that in Versions 6.6.0+, you cannot manually
delete connection or security Intelligence events in this way.)You can also manually purge the database; see
Data Storage, on page 315.
Configuring Database Event Limits

Before you begin
• If you want to receive email notifications when events are pruned from the Firepower Management
Center's database, you must configure an email server; see Configuring a Mail Relay Host and Notification
Procedure

Step 2 Choose Database.
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 1358.
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.

The following table lists the minimum and maximum number of records for each event type that you can store
on a Firepower Management Center.

1358
Table 111: Database Event Limits
Event Type Upper Limit Lower Limit
Intrusion events 10 million (FMC Virtual) 10,000

30 million (FMC1000, FMC1600)
60 million (FMC2500, FMC2600, FMCv 300)
Discovery events 10 million (FMC Virtual) Zero (disables storage)

20 million (FMC2500, FMC2600, FMC4500,
FMC4600, FMCv 300)
Connection events 50 million (FMC Virtual) Zero (disables storage)

Security Intelligence events 100 million (FMC1000, FMC1600) If you set the
Maximum
Connection Events
1 billion (FMC4500, FMC4600) value to zero, then
connection events that
Limit is shared between connection events and
are not associated with
Security Intelligence events. The sum of the
Security Intelligence,
configured maximums cannot exceed this limit.
intrusion, file, and
malware events are not
stored on the FMC.
Caution Setting
Maximum
Connection
Events to
zero
immediately
purges
existing
connection
events other
than
Security
Intelligence
events.
See below for the

effect of this setting on
Maximum Flow Rate.
These settings do not
affect connection
summaries.

1359
Event Type Upper Limit Lower Limit
Connection summaries (aggregated 50 million (FMC Virtual) Zero (disables storage)

connection events)
1 billion (FMC4500, FMC4600)
Correlation events and compliance 1 million (FMC Virtual) One

allow list events
FMC4600, FMCv 300)
Malware events 10 million (FMC Virtual) 10,000

FMC4600, FMCv 300)
File events 10 million (FMC Virtual) Zero (disables storage)

FMC4600, FMCv 300)
Health events 1 million Zero (disables storage)
Audit records 100,000 One
Remediation status events 10 million One
Allow list violation history a 30-day history of violations One day’s history
User activity (user events) 10 million One
User logins (user history) 10 million One
Intrusion rule update import log 1 million One

records
VPN Troubleshooting database 10 million Zero (disables storage)
Maximum Flow Rate

The Maximum flow rate (flows per second) value for your FMC hardware model is specified in the Platform
Specifications section of the FMC datasheet at https://www.cisco.com/c/en/us/products/collateral/security/
firesight-management-center/datasheet-c78-736775.html?cachemode=refresh
If you set the Maximum Connection Events value in platform settings to zero, then connection events that
are not associated with Security Intelligence, intrusion, file, and malware events are not counted toward the
maximum flow rate for your FMC hardware.
Any non-zero value in this field causes ALL connection events to be counted against the maximum flow rate.
Other event types on this page do not count against the maximum flow rate.

1360
Management Interfaces
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.
About FMC Management Interfaces

By default, the FMC manages all devices on a single management interface. You can also perform initial
setup on the management interface and log into the FMC on this interface as an administrator. The management
interface is also used to communicate with the Smart Licensing server, to download updates, and to perform
other management functions.
For information about device management interfaces, see About Device Management Interfaces, on page 343.
Management Interfaces on the FMC

The FMC uses the eth0 interface for initial setup, HTTP access for administrators, management of devices,
as well as other management functions such as licensing and updates.
You can also configure additional management interfaces on the same network, or on different networks.
When the FMC manages large numbers of devices, adding more management interfaces can improve throughput
and performance. You can also use these interfaces for all other management functions. You might want to
use each management interface for particular functions; for example, you might want to use one interface for
HTTP administrator access and another for device management.
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. Managed devices will send
management traffic to the FMC management interface and event traffic to the FMCs event-only interface. If
the managed device cannot reach the event-only interface, then it will fall back to sending events to the
Note All management interfaces support HTTP administrator access as controlled by your Access List configuration
(Configure an Access List, on page 1376). 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.

1361
Management Interface Support Per FMC Model
Management Interface Support Per FMC Model

See the hardware installation guide for your model for the management interface locations.
See the following table for supported management interfaces on each FMC model.
Table 112: Management Interface Support on the FMC
Model Management Interfaces
MC1000 eth0 (Default)

eth1
MC2500, MC4500 eth0 (Default)

eth1
eth2
eth3
MC1600, MC2600, MC4600 eth0 (Default)

eth1
eth2
eth3
CIMC (Supported for Lights-Out Management only.)
Firepower Management Center Virtual eth0 (Default)
Network Routes on FMC Management Interfaces

Management interfaces (including event-only interfaces) support only static routes to reach remote networks.
When you set up your FMC, the setup process creates a default route to the gateway IP address that you
specify. You cannot delete this route; you can only modify the gateway address.
You can configure multiple management interfaces on some platforms. 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 one static route is recommended per management interface to access remote networks. We recommend
placing each interface on a separate network to avoid potential routing problems, including routing problems
from other devices to the FMC. If you do not experience problems with interfaces on the same network, then
be sure to configure static routes correctly. For example, on the FMC both eth0 and eth1 are on the same
network, but you want to manage a different group of devices on each interface. The default gateway is
192.168.45.1. If you want eth1 to manage devices on the remote 10.6.6.0/24 destination network, you can
create a static route for 10.6.6.0/24 through eth1 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 eth1 will be used as expected.
If you want to use two FMC interfaces to manage remote devices that are on the same network, then static
routing on the FMC may not scale well, because you need separate static routes per device IP address.
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

1362
NAT Environments
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.
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

1363
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
Note If you use a data interface for management on an FTD, you cannot use separate management and event
interfaces for that device.
The following example shows the Firepower Management Center and managed devices using only the default
management interfaces.
Figure 43: Single Management Interface on the Firepower Management Center
The following example shows the Firepower Management Center using separate management interfaces for
devices; and each managed device using 1 management interface.

1364
Modify FMC Management Interfaces
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.
Figure 46: Mixed Management and Event Interface Usage

Modify the management interface settings on the Firepower Management Center. You can optionally enable
additional management interfaces or configure an event-only 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.

1365
Note If you change the FMC IP address, then see Edit the FMC IP Address or Hostname on the Device, on page
390. If you change the FMC IP address or hostname, you should also change the value at the device CLI so
the configurations match. Although in most cases, the management connection will be reestablished without
resiliency.
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.
Before you begin

• For information about how device management works, see About Device Management Interfaces, on
page 343.
• If you use a proxy:
• Proxies that use NT LAN Manager (NTLM) authentication are not supported.
• If you use or will use Smart Licensing, the proxy FQDN cannot have more than 64 characters.
Procedure
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.

1366
• 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.
• IPv6 Configuration—Set the IPv6 IP address. Choose:

• Static—Manually enter the IPv6 Management IP address and IPv6 Prefix Length.
• DHCP—Set the interface to use DHCPv6 (eth0 only).
• Router Assigned—Enable stateless autoconfiguration.
• Disabled—Disable IPv6. Do not disable both IPv4 and IPv6.
• IPv6 DAD—When you enable IPv6, enable or disable duplicate address detection (DAD). You
might want to disable DAD because the use of DAD opens up the possibility of denial of service
attacks. If you disable this setting, you need check manually that this interface is not using an
already-assigned address.
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 1362.
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.
You can configure the following settings for a static route:

• Destination—Set the destination address of the network to which you want to create a route.
• Netmask or Prefix Length—Set the netmask (IPv4) or prefix length (IPv6) for the network.
• Interface—Set the egress management interface.
• Gateway—Set the gateway IP address.
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.

1367
You can configure the following shared settings:

• Hostname—Set the FMC hostname. The hostname must start and end with a letter or digit, and have
only letters, digits, or a hyphen. If you change the hostname, reboot the FMC if you want the new hostname
reflected in syslog messages. Syslog messages do not reflect a new hostname until after a reboot.
• Domains—Set the search domain(s) for the FMC, 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
• Primary DNS Server, Secondary DNS Server, Tertiary DNS Server—Set the DNS servers to be used
in order of preference.
• Remote Management Port—Set the remote management port for communication with managed devices.
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 5 In the ICMPv6 area, configure ICMPv6 settings.

• Allow Sending Echo Reply Packets—Enable or disable Echo Reply packets. 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 FMC management interfaces for testing purposes.
• Allow Sending Destination Unreachable Packets—Enable or disable Destination Unreachable packets.
You might want to disable these packets to guard against potential denial of service attacks.
Step 6 In the Proxy area, configure HTTP proxy settings.

The FMC 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.
See proxy requirements in the prerequisites to this topic.
a) Check the Enabled check box.
b) In the HTTP Proxy field, enter the IP address or fully-qualified domain name of your proxy server.
See requirements in the prerequisites to this topic.
c) In the Port field, enter a port number.
d) Supply authentication credentials by choosing Use Proxy Authentication, and then provide a User Name
and Password.
Step 7 Click Save.
Step 8 If you change the FMC IP address, then see If you change the FMC IP address, then see Edit the FMC IP
Address or Hostname on the Device, on page 390.
If you change the FMC IP address or hostname, you should also change the value at the device CLI so the
configurations match. Although in most cases, the management connection will be reestablished without

1368
Shut Down or Restart
resiliency.
Shut Down or Restart

Use the web interface to control the shut down and restart of processes on the FMC. You can:
• Shut down: Initiate a graceful shutdown of the appliance.
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.
• Reboot: Shut down and restart gracefully.

• Restart the console: Restart the communications, database, and HTTP server processes. This is typically
used during troubleshooting.
Tip For virtual devices, refer to the documentation for your virtual platform. For VMware in particular, custom
power options are part of VMware Tools.
Shut Down or Restart the FMC

Procedure

Step 2 Choose Process.
Shut down Click Run Command next to Shutdown Management Center.
Reboot Click Run Command next to Reboot Management Center.

Note Rebooting logs you out, and the system runs a database check that can
take up to an hour to complete.
Restart the console Click Run Command next to Restart Management Center Console.
Note Restarting may cause deleted hosts to reappear in the network map.

1369
Remote Storage Management
Related Topics
Remote Storage Management

On Firepower Management Centers, you can use the following for local or remote storage for backups and
reports:
• Network File System (NFS)
• Server Message Block (SMB)/Common Internet File System (CIFS)
• Secure Shell (SSH)
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.
Configuring Local Storage

Procedure

Step 2 Choose Remote Storage Device.
Step 3 Choose Local (No Remote Storage) from the Storage Type drop-down list.
Step 4 Click Save.
Configuring NFS for Remote Storage

Before you begin
• Ensure that your external remote storage system is functional and accessible from your FMC.
Procedure

Step 2 Click Remote Storage Device.
Step 3 Choose NFS from the Storage Type drop-down list.
Step 4 Add the connection information:

1370
Configuring SMB for Remote Storage
• Enter the IPv4 address or hostname of the storage system in the Host field.
• Enter the path to your storage area in the Directory field.
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 1373.
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 7 To test the settings, click Test.

Step 8 Click Save.
Configuring SMB for Remote Storage

Before you begin
Ensure that your external remote storage system is functional and accessible from your FMC:
• The system recognizes top-level SMB shares, not full file paths. You must use Windows to share the
exact directory you want to use.
• Make sure the Windows user you will use to access the SMB share from the FMC has ownership of and
read/change access to the share location.
• To ensure security, you should install SMB 2.0 or greater.
Procedure

Step 3 Choose SMB from the Storage Type drop-down list.
• Enter the IPv4 address or hostname of the storage system in the Host field.
• Enter the share of your storage area in the Share field.
• Optionally, enter the domain name for the remote storage system in the Domain field.
• Enter the user name for the storage system in the Username field and the password for that user in the
Password field.

1371
Configuring SSH for Remote Storage

Step 7 To test the settings, click Test.

Step 8 Click Save.
Configuring SSH for Remote Storage

Before you begin
• Ensure that your external remote storage system is functional and accessible from your Firepower
Management Center.
Procedure

Step 3 Choose SSH from the Storage Type drop-down list.
• Enter the IP address or host name of the storage system in the Host field.
• Enter the path to your storage area in the Directory field.
• Enter the storage system’s user name in the Username field and the password for that user in the Password
field. To specify a network domain as part of the connection user name, precede the user name with the
domain followed by a forward slash (/).
• To use SSH keys, copy the content of the SSH Public Key field and place it in your authorized_keys
file.
Step 7 If you want to test the settings, you must click Test.
Step 8 Click Save.

1372
Remote Storage Management Advanced Options
Remote Storage Management Advanced Options

If you select the Network File System (NFS) protocol, Server Message Block (SMB) protocol, or SSH to use
secure file transfer protocol (SFTP) to store your reports and backups, you can select the Use Advanced
Options check box to use one of the mount binary options as documented in an NFS, SMB, or SSH mount
man page.
If you select SMB, you can enter the security mode in the Command Line Options field using the following
format:
sec=mode
where mode is the security mode you want to use for remote storage.
Table 113: SMB Security Mode Settings
Mode Description
[none] Attempt to connect as null user (no name).
krb5 Use Kerberos version 5 authentication.
krb5i Use Kerberos authentication and packet signing.
ntlm Use NTLM password hashing. (Default)
ntlmi Use NTLM password hashing with signing (may be

Default if /proc/fs/cifs/PacketSigningEnabled
is on or if server requires signing).
ntlmv2 Use NTLMv2 password hashing.
ntlmv2i Use NTLMv2 password hashing with packet signing.
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.

1373
Configuring Change Reconciliation
Configuring Change Reconciliation

Before you begin
• Configure an email server to receive emailed reports of changes made to the system over a 24 hour period;
see Configuring a Mail Relay Host and Notification Address, on page 1386 for more information.
Procedure

Step 2 Click Change Reconciliation.
Step 3 Check the Enable check box.
Step 4 Choose the time of day you want the system to send out the change reconciliation report from the Time to
Run drop-down lists.
Step 5 Enter email addresses in the Email to field.
Tip Once you have added email addresses, click Resend Last Report to send recipients another copy
of the most recent change reconciliation report.
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 482
Change Reconciliation Options

The Include Policy Configuration option controls whether the system includes records of policy changes in
the change reconciliation report. This includes changes to access control, intrusion, system, health, and network
discovery policies. If you do not select this option, the report will not show changes to any policies. This
option is available on Firepower Management Centers only.
The Show Full Change History option controls whether the system includes records of all changes over the
past 24 hours in the change reconciliation report. If you do not select this option, the report includes only a
consolidated view of changes for each category.
Note The change reconciliation report does not include changes to Firepower Threat Defense interfaces and routing
settings.

1374
Policy Change Comments
Policy Change Comments

You can configure the Firepower System to track several policy-related changes using the comment functionality
when users modify access control, intrusion, or network analysis policies.
With policy change comments enabled, administrators can quickly assess why critical policies in a deployment
were modified. Optionally, you can have changes to intrusion and network analysis policies written to the
audit log.
Configuring Comments to Track Policy Changes

You can configure the Firepower System to prompt users for comments when they modify an access control
policy, intrusion policy, or network analysis policy. You can use comments to track users’ reasons for policy
changes. If you enable comments on policy changes, you can make the comment optional or mandatory. The
system prompts the user for a comment when each new change to a policy is saved.
Procedure

The system configuration options appear in the left navigation panel.
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.
Step 4 Optionally for intrusion or network analysis policy comments:

• Check Write changes in Intrusion Policy to audit log to write all intrusion policy changes to the audit
log.
• Check Write changes in Network Analysis Policy to audit log to write all network analysis policy
changes to the audit log.
Step 5 Click Save.
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:

1375
Configure an Access List
• 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 1388.
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.
Configure an Access List

This access list does not control external database access. See Enabling External Access to the Database, on
page 1357.
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 1417.
Before you begin

By default, the access list includes rules for HTTPS and SSH. To add SNMP rules to the access list, you must
first enable SNMP. For more information, see Configure SNMP Polling, on page 1388.
Procedure

Step 2 (Optional) Click SNMP to configure SNMP if you want to add SNMP rules to the access list. By default,
SNMP is disabled; see Configure SNMP Polling, on page 1388.
Step 3 Click Access List.
Step 4 To add access for one or more IP addresses, click Add Rules.
Step 6 Choose SSH, HTTPS, SNMP, or a combination of these options to specify which ports you want to enable
for these IP addresses.
Step 7 Click Add.
Step 8 Click Save.
Related Topics
Firepower System IP Address Conventions, on page 24

1376
Audit Logs
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 477.
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 1377..
• Stream audit log messages to an HTTP server: Stream Audit Logs to an HTTP Server, on page 1378.
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 1379.
Streaming to Multiple Syslog Servers
You can stream audit log data to a maximum of five syslog servers. However, if you have enabled TLS for
secured audit log streaming, you can stream only to a single syslog server.
Classic devices also maintain audit logs. To stream audit logs from a Classic devices, see Stream Audit Logs
from Classic Devices, on page 1417.
Stream Audit Logs to Syslog

When this feature is enabled, audit log records appear in the syslog in the following format :
Date Time Host [Tag] Sender: User_Name@User_IP, Subsystem, Action
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: admin@10.1.1.2, 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
Before you begin

Make sure the FMC can communicate with the syslog server. When you save your configuration, the system
uses port 7/UDP to verify that the syslog server is reachable. Then, the system uses port 514/UDP to stream
audit logs. If you secure the channel (optional, see Audit Log Certificate, on page 1379), the system uses
6514/TCP.

1377
Stream Audit Logs to an HTTP Server
Procedure

Step 2 Click Audit Log.
Step 3 Choose Enabled from the Send Audit Log to Syslog drop-down menu.
Step 4 The following fields are applicable only for audit logs sent to syslog:
Option Description
Host The IP address or the fully qualified name of the syslog server to which you will send
audit logs. You can add a maximum of five syslog hosts, seperated by commas.
Note You can specify multiple syslog hosts, only when TLS is disabled for the
Audit Server Certificate.
Facility The subsystem that creates the message.

Choose a facility described in Syslog Alert Facilities, on page 2635. For example, choose
AUDIT.
Severity The severity of the message.

Choose a severity described in Syslog Severity Levels, on page 2636.
Tag An optional tag to include in audit log syslog messages.

Best practice: Enter a value in this field to easily differentiate audit log messages from
other, similar syslog messages such as health alerts.
For example, if you want all audit log records sent to the syslog to be labeled with
FMC-AUDIT-LOG, enter FMC-AUDIT-LOG in the field.
Step 5 (Optional) To test whether the IP address of the syslog servers are valid, click Test Syslog Server.
The system displays the result for each server.
Step 6 Click Save.
Stream Audit Logs to an HTTP Server

When this feature is enabled, the appliance sends audit log records to an HTTP server in the following format:
Date Time Host [Tag] Sender: User_Name@User_IP, Subsystem, Action
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: admin@10.1.1.2, Operations > Monitoring,
Page View
To stream audit logs from Classic devices, use device platform settings: Stream Audit Logs from Classic

1378
Audit Log Certificate
Before you begin

Make sure the device can communicate with the HTTP server. Optionally, secure the channel; see Audit Log
Certificate, on page 1379.
Procedure

Step 2 Click Audit Log.
Step 3 Optionally, in the Tag field, enter the tag name that you want to appear with the message. For example, if
you want all audit log records to be preceded with FROMMC, enter FROMMC in the field.
Step 4 Choose Enabled from the Send Audit Log to HTTP Server drop-down list.
Step 5 In the URL to Post Audit field, designate the URL where you want to send the audit information. Enter a
URL that corresponds to a Listener program that expects the HTTP POST variables as listed:
• 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.
Step 6 Click Save.
Audit Log Certificate

You can use Transport Layer Security (TLS) certificates to secure communications between Firepower
appliances and a trusted audit log server.
Client Certificates (Required)

For each appliance (client certificates are unique), you must generate a certificate signing request (CSR),
submit it to a Certificate Authority (CA) for signing, then import the signed certificate onto the appliance.
You cannot use the FMC to import audit log certificates onto its managed devices. These certificates are
unique to each appliance, and you must log into each appliance to import them locally:

1379
Securely Stream Audit Logs
• For the FMC, use the local system configuration: Obtain a Signed Audit Log Client Certificate for the
FMC, on page 1381 and Import an Audit Log Client Certificate into the FMC, on page 1382.
• For ASA FirePOWER and NGIPSv, generate a CSR with a tool like OpenSSL, then use the CLI to import
the signed certificate: configure audit_cert import.
Server Certificates (Optional)

For additional security, we recommend you require mutual authentication between Firepower appliances and
the audit log server. To accomplish this, load one or more certificate revocation lists (CRLs). You cannot
stream audit logs to servers with revoked certificates listed in those CRLs.
Firepower supports CRLs encoded in Distinguished Encoding Rules (DER) format. Note that these are the
same CRLs that the system uses to validate HTTPS client certificates for the FMC web interface.
To require valid audit log server certificates, use the FMC web interface:
• For the FMC, use the local system configuration: Require Valid Audit Log Server Certificates, on page
1382.
• For Classic devices, use device platform settings: Require Valid Audit Log Server Certificates for Classic
Securely Stream Audit Logs

If you stream the audit log to a trusted HTTP server or syslog server, you can use Transport Layer Security
(TLS) certificates to secure the channel between the FMC and the server. You must generate a unique client
certificate for each appliance you want to audit.
To securely stream audit logs to Classic devices, see Stream Audit Logs from Classic Devices, on page 1417.
Before you begin

See ramifications of requiring client and server certificates at Audit Log Certificate, on page 1379.
Procedure
Step 1 Obtain and install a signed client certificate on the FMC:

a) Obtain a Signed Audit Log Client Certificate for the FMC, on page 1381:
Generate a Certificate Signing Request (CSR) from the FMC based on your system information and the
identification information you supply.
Submit the CSR to a recognized, trusted certificate authority (CA) to request a signed client certificate.
If you will require mutual authentication between the FMC and the audit log server, the client certificate
must be signed by the same CA that signed the server certificate to be used for the connection.
b) After you receive the signed certificate from the certificate authority, import it into the FMC. See Import
an Audit Log Client Certificate into the FMC, on page 1382.
Step 2 Configure the communication channel with the server to use Transport Layer Security (TLS) and enable
mutual authentication.
See Require Valid Audit Log Server Certificates, on page 1382.

1380
Obtain a Signed Audit Log Client Certificate for the FMC
Step 3 Configure audit log streaming if you have not yet done so.
See Stream Audit Logs to Syslog, on page 1377 or Stream Audit Logs to an HTTP Server, on page 1378.
Obtain a Signed Audit Log Client Certificate for the FMC
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.
Before you begin

Keep the following in mind:
• To ensure security, use a globally recognized and trusted Certificate Authority (CA) to sign your certificate.
• If you will require mutual authentication between the appliance and the audit log server, the same
Certificate Authority must sign both the client certificate and the server certificate.
Procedure

Step 2 Click Audit Log Certificate.
Step 3 Click Generate New CSR.
Step 4 Enter a country code in the Country Name (two-letter code) field.
Step 5 Enter a state or province postal abbreviation in the State or Province field.
Step 6 Enter a Locality or City.
Step 7 Enter an Organization name.
Step 8 Enter an Organizational Unit (Department) name.
Step 9 Enter the fully qualified domain name of the server for which you want to request a certificate in the Common
Name field.
Note If the common name and the DNS hostname do not match, audit log streaming will fail.

Step 11 Open a new blank file with a text editor.
Step 12 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 13 Save the file as clientname.csr, where clientname is the name of the appliance where you plan to use the
certificate.
Step 14 Click Close.

1381
Import an Audit Log Client Certificate into the FMC
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 1382.
Import an Audit Log Client Certificate into the FMC

In an FMC high availability setup, you must use the active peer.
For ASA FirePOWER and NGIPSv, use the CLI to import a signed certificate: configure audit_cert import.
Before you begin

• Obtain a Signed Audit Log Client Certificate for the FMC, on page 1381.
• 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.
Procedure
Step 1 On the FMC, choose System > Configuration.

Step 3 Click Import Audit Client Certificate.
Step 4 Open the client certificate in a text editor, copy the entire block of text, including the BEGIN CERTIFICATE
and END CERTIFICATE lines. Paste this text into the Client Certificate field.
Step 5 To upload a private key, open the private key file and copy the entire block of text, including the BEGIN RSA
PRIVATE KEY and END RSA PRIVATE KEY lines. Paste this text into the Private Key field.
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.
Require Valid Audit Log Server Certificates

The system supports validating audit log server certificates using imported CRLs in Distinguished Encoding
Rules (DER) format.

1382
Require Valid Audit Log Server Certificates
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.
Before you begin

• Understand the ramifications of requiring mutual authentication and of using certificate revocation lists
(CRLs) to ensure that certificates are still valid. See Audit Log Certificate, on page 1379.
• Obtain and import the client certificate following the steps in Securely Stream Audit Logs, on page 1380
and the topics referenced in that procedure.
Procedure
Step 1 On the FMC, choose System > Configuration.

Step 3 To use Transport Layer Security to securely stream the audit log to an external server, choose Enable TLS.
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 297.

1383
View the Audit Log Client Certificate on the FMC
View the Audit Log Client Certificate on the FMC

You can view the audit log client certificate only for the appliance that you are logged in to. In FMC high
availability pairs, you can view the certificate only on the active peer.
To view audit log certificates on Classic devices, use show audit_cert.
Procedure

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 403
Enabling Custom Analysis Widgets for Dashboards

Use Custom Analysis dashboard widgets to create a visual representation of events based on a flexible,
user-configurable query.
Procedure

Step 2 Click Dashboard.
Step 3 Check the Enable Custom Analysis Widgets check box to allow users to add Custom Analysis widgets to
dashboards.
Step 4 Click Save.
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

1384
Configuring DNS Cache Properties
the amount of traffic on your network and speed the display of event pages when IP address resolution is
enabled.
Configuring DNS Cache Properties

DNS resolution caching is a system-wide setting that allows the caching of previously resolved DNS lookups.
Procedure

Step 2 Choose DNS Cache.
Step 3 From the DNS Resolution Caching drop-down list, choose one of the following:
• Enabled—Enable caching.
• Disabled—Disable caching.
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).
Step 5 Click Save.
Related Topics
Configuring Event View Settings, on page 45
Email Notifications
Configure a mail host if you plan to:
• Email event-based reports
• Email status reports for scheduled tasks
• Email change reconciliation reports
• Email data-pruning notifications
• Use email for discovery event, impact flag, correlation event alerting, intrusion event alerting, and health
event alerting
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.

1385
Configuring a Mail Relay Host and Notification Address
Configuring a Mail Relay Host and Notification Address

Procedure

Step 2 Click Email Notification.
Step 3 In the Mail Relay Host field, enter the hostname or IP address of the mail server you want to use. The mail
host you enter must allow access from the appliance.
Step 4 In the Port Number field, enter the port number to use on the email server.
Typical ports include:
• 25, when using no encryption
• 465, when using SSLv3
• 587, when using TLS
Step 5 Choose an Encryption Method:

• TLS—Encrypt communications using Transport Layer Security.
• SSLv3—Encrypt communications using Secure Socket Layers.
• None—Allow unencrypted communication.
Note Certificate validation is not required for encrypted communication between the appliance and mail
server.
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.
Step 9 Click Save.
Language Selection
You can use the Language page to specify a different language for the web interface.
Set the Language for the Web Interface

The language you specify here is used for the web interface for every user. You can choose from:
• English
• Chinese (simplified)

1386
Login Banners
• Chinese (traditional)
• Japanese
• Korean
Procedure

Step 2 Click Language.
Step 3 Choose the language you want to use.
Step 4 Click Save.
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.
Customize the Login Banner

To customize login banners for Classic devices, use device platform settings. See Customize the Login Banner
for Classic Devices , on page 1420.
Procedure

Step 2 Choose Login Banner.
Step 3 In the Custom Login Banner field, enter the login banner text you want to use.
Step 4 Click Save.
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.

1387
Configure SNMP Polling
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.
Configure SNMP Polling

To configure SNMP polling on Classic managed devices, use the device platform settings. See Configure
SNMP Polling on Classic Devices, on page 1422.
Before you begin

Add SNMP access for each computer you plan to use to poll the system. See Configure an Access List, on
page 1376.
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.
Procedure

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.
Step 4 Enter a Username.

Step 5 Choose the protocol you want to use for authentication from the Authentication Protocol drop-down list.
Step 6 Enter the password required for authentication with the SNMP server in the Authentication Password field.
Step 7 Re-enter the authentication password in the Verify Password field.
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.

1388
Time and Time Synchronization
Step 12 Click Save.
Time and Time Synchronization

Synchronizing the system time on your Firepower Management Center (FMC) and its managed devices is
essential to successful operation of your Firepower System. We recommend that you specify NTP servers
during FMC initial configuration, but you can use the information in this section to establish or change time
sychronization settings after intial configuration is complete.
Use a Network Time Protocol (NTP) server to synchronize system time on the FMC and all devices. The
FMC supports secure communications with NTP servers using MD5, SHA-1, or AES-128 CMAC symmetric
key authentication; for system security, we recommend using this feature.
The FMC can also be configured to connect solely with authenticated NTP servers; using this option improves
security in a mixed-authentication environment, or when migrating your system to different NTP servers. It
is redundant to use this setting in an environment where all reachable NTP servers are authenticated.
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, SHA-1, or AES-128
CMAC keys.
Caution Unintended consequences can occur when time is not synchronized between the FMC and managed devices.
To synchronize time on FMC and managed devices, see:

• Recommended: Synchronize Time on the FMC with an NTP Server, on page 1389
This topic provides instructions for configuring your FMC to synchronize with an NTP server or servers
and includes links to instructions on configuring managed devices to synchronize with the same NTP
server or servers.
• Otherwise: Synchronize Time Without Access to a Network NTP Server, on page 1391
This topic provides instructions for setting the time on your FMC, configuring your FMC to serve as an
NTP server, and links to instructions on configuring managed devices to synchronize with the FMC NTP
server.
Synchronize Time on the FMC with an NTP Server

Time synchronization among all of the components of your system is critically important.
The best way to ensure proper time synchronization between Firepower Management Center and all managed
devices is to use an NTP server on your network.
The FMC supports NTPv4.
You must have Admin or Network Admin privileges to do this procedure.

1389
Synchronize Time on the FMC with an NTP Server
Before you begin

Note the following:
• If your FMC and managed devices cannot access a network NTP server, do not use this procedure.
Instead, see Synchronize Time Without Access to a Network NTP Server, on page 1391.
• Do not specify an untrusted NTP server.
• If you plan to establish a secure connection with an NTP server (recommended for system security),
obtain an SHA-1, MD5, or AES-128 CMAC key number and value configured on that NTP server.
• Connections to NTP servers do not use configured proxy settings.
• Firepower 4100 Series devices and Firepower 9300 devices cannot use this procedure to set the system
time. Instead, configure those devices to use the same NTP server(s) that you configure using this
procedure. For instructions, see the documentation for your hardware model.
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.
Procedure

Step 2 Click Time Synchronization.
Step 3 If Serve Time via NTP is Enabled, choose Disabled to disable the FMC as an NTP server.
Step 4 For the Set My Clock option, choose Via NTP.
Step 5 Click Add.
Step 6 In the Add NTP Server dialog box, enter the host name or IPv4 or IPv6 address of an NTP server.
Step 7 (Optional) To secure communication between your FMC and the NTP server:
a) Select MD5, SHA-1 or AES-128 CMAC from the Key Type drop-down list.
b) Enter an the corresponding MD5, SHA-1, or AES-128 CMAC Key Number and Key Value from the
specified NTP server.
Step 8 Click Add.
Step 9 To add more NTP servers, repeat Steps 5 through 8.
Step 10 (Optional) To force the FMC to use only an NTP server that successfully authenticates, check the Use the
authenticated NTP server only check box.
Step 11 Click Save.
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
1467 and Synchronize Time on Classic Devices with an NTP Server, on page 1421.

1390
Synchronize Time Without Access to a Network NTP Server
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.
Synchronize Time Without Access to a Network NTP Server

If your devices cannot directly reach the network NTP server, or your organization does not have a network
NTP server, a physical-hardware Firepower Management Center can serve as an NTP server.
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 1389.
• Do not use a virtual Firepower Management Center as an NTP server.
To change the time manually after configuring the Firepower Management Center as an NTP server, you
must disable the NTP option, change the time manually, and then re-enable the NTP option.
Procedure
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:

1391
About Changing Time Synchronization Settings
• For Firepower Threat Defense devices, see Configure NTP Time Synchronization for Threat Defense,
on page 1467.
• For all other devices, see Synchronize Time on Classic Devices with an NTP Server, on page 1421.
About Changing Time Synchronization Settings

• Your Firepower Management Center and its managed devices are heavily dependent on accurate time.
The system clock is a system facility that maintains the time of the Firepower System. The system clock
is set to Universal Coordinated Time (UTC), which is the primary time standard by which the world
regulates clocks and time.
DO NOT ATTEMPT TO CHANGE THE SYSTEM TIME. Changing the system time zone from UTC
is NOT supported, and doing so will require you to reimage the device to recover from an unsupported
state.
• If you configure the FMC to serve time using NTP, and then later disable it, the NTP service on managed
devices still attempts to synchronize time with the FMC. You must update and redeploy any applicable
platform settings policies to establish a new time source.
• To change the time manually after configuring the Firepower Management Center as an NTP server,
you must disable the NTP option, change the time manually, and then re-enable the NTP option.
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.
Procedure

Step 2 Click Time.
The current time is displayed using the time zone specified for your account in User Preferences.
If your appliance uses an NTP server: For information about the table entries, see NTP Server Status, on page
1393.

1392
NTP Server Status
NTP Server Status

If you are synchronizing time from an NTP server, you can view connection status on the Time page (choose
System > Configuration).
Table 114: NTP Status
Column Description
NTP Server The IP address or name of the configured NTP server.
Status The status of the NTP server time synchronization:

• Being Used indicates that the appliance is synchronized with the NTP server.
• Available indicates that the NTP server is available for use, but time is not yet
synchronized.
• Not Available indicates that the NTP server is in your configuration, but the NTP
daemon is unable to use it.
• Pending indicates that the NTP server is new or the NTP daemon was recently
restarted. Over time, its value should change to Being Used, Available, or Not
Available.
• Unknown indicates that the status of the NTP server is unknown.
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 (SHA-1, MD5, or AES-128 CMAC) following the status value. For example:
bad, key 2, MD5.
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.
Global User Configuration Settings

Global User Configuration settings affect all users on the Firepower Management Center. Configure these
settings on the User Configuration page (System > Configuration > User Configuration):

1393
Global User Configuration Settings
• Password Reuse Limit: The number of passwords in a user’s most recent history that cannot be reused.
This limit applies to web interface access for all users. For the admin user, this applies to CLI access as
well; the system maintains separate password lists for each form of access. Setting the limit to zero (the
default) places no restrictions on password reuse. See Set Password Reuse Limit, on page 1395.
• Track Successful Logins: The number of days that the system tracks successful logins to the Firepower
Management Center, per user, per access method (web interface or CLI). When users log in, the system
displays their successful login count for the interface being used. When Track Successful Logins is set
to zero (the default), the system does not track or report successful login activity. See Track Successful
Logins, on page 1395.
• 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.

1394
Set Password Reuse Limit
Set Password Reuse Limit

If you enable the Password Reuse Limit, the system keeps encrypted password histories for FMC users.
Users cannot reuse passwords in their histories. You can specify the number of stored passwords for each
user, per access method (web interface or CLI). A user's current password counts towards this number. If you
lower the limit, the system deletes older passwords from the history. Increasing the limit does not restore
deleted passwords.
Procedure

Step 2 Click User Configuration.
Step 3 Set the Password Reuse Limit to the number of passwords you want to maintain in the history (maximum
256).
To disable password reuse checking, enter 0.
Step 4 Click Save.
Track Successful Logins

Use this procedure to enable tracking successful logins for each user for a specified number of days. When
this tracking is enabled, the system displays the successful login count when users log into the web interface
or the CLI.
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.
Procedure

Step 3 Set Track Successful Login Days to the number of days to track successful logins (maximum 365).
To disable login tracking, enter 0.
Step 4 Click Save.

1395
Enabling Temporary Lockouts
Enabling Temporary Lockouts

Enable the temporary timed lockout feature by specifying the number of failed login attempts in a row that
the system allows before the lockout goes into effect.
Procedure

Step 3 Set the Max Number of Login Failures to the maximum number of consecutive failed login attempts before
the user is temporarily locked out.
To disable the temporary lockout, enter zero.
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.
Step 5 Click Save.
Set Maximum Number of Concurrent Sessions

You can specify the maximum 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.
Procedure

Step 3 For each type of session (Read Only and Read/Write), set the Max Concurrent Sessions Allowed to the
maximum number of sessions of that type that can be open at the same time.
To apply no limits on concurrent users by session type, enter zero.
Note 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.
Step 4 Click Save.

1396
Session Timeouts
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.
Configure Session Timeouts

To configure session timeouts for Classic devices, use device platform settings. See Configure Session Timeouts
for Classic Devices, on page 1422.
Procedure

Step 2 Click CLI Timeout.
Step 3 Configure session timeouts:
• Web interface (FMC only): Configure the Browser Session Timeout (Minutes). The default value is
60; the maximum value is 1440 (24 hours).
To exempt users from this session timeout, see Add an Internal User at the Web Interface.
• CLI: Configure the CLI Timeout (Minutes) field. The default value is 0; the maximum value is 1440
(24 hours).
Step 4 Click Save.
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.

1397
Mapping Vulnerabilities for Servers
Mapping Vulnerabilities for Servers

This procedure requires any Smart License or the Protection classic license.
Procedure

Step 2 Choose Vulnerability Mapping.
• To prevent vulnerabilities for a server from being mapped to hosts that receive application protocol traffic
without vendor or version information, clear the check box for that server.
• To cause vulnerabilities for a server to be mapped to hosts that receive application protocol traffic without
vendor or version information, check the check box for that server.
Tip You can check or clear all check boxes at once using the check box next to Enabled.
Step 4 Click Save.
Remote Console Access Management

You can use a Linux system console for remote access on supported systems via either the VGA port (which
is the default) or the serial port on the physical appliance. Use the Console Configuration page to choose the
option most suitable to the physical layout of your organization’s Firepower deployment.
On supported physical-hardware-based Firepower systems, you can use Lights-Out Management (LOM) on
a Serial Over LAN (SOL) connection to remotely monitor or manage the system without logging into the
management interface of the system. You can perform limited 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. The cable connection to support LOM varies by FMC model:
• For FMC models MC1600, MC2600, and MC4600, use a connection with the CIMC port to support
LOM. See the Cisco Firepower Managemenet Center 1600, 2600, and 4600 Getting Started Guide for
more information.
• For all other FMC hardware models, use a connection with the default (eth0) management port to support
LOM. See the Cisco Firepower Management Center Getting Started Guide for your hardware model.
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.
Configuring Remote Console Settings on the System


1398
Configuring Remote Console Settings on the System
Before you begin

• Disable Spanning Tree Protocol (STP) on any third-party switching equipment connected to the device’s
• If you plan to enable Lights-Out Management see the Getting Started Guide for your appliance for
information about installing and using an Intelligent Platform Management Interface (IPMI) utility.
Procedure

Step 2 Click Console Configuration.
Step 3 Choose a remote console access option:
• Choose VGA to use the appliance's VGA port.
• Choose Physical Serial Port to use the appliance's serial port.
• Choose Lights-Out Management to use an SOL connection on the FMC. (This may use the default
management port or the CIMC port depending on your FMC model. See the Getting Started Guide for
your model for more information.)
Step 4 To configure LOM via SOL:

• Choose the address Configuration for the system (DHCP or Manual).
• If you chose manual configuration, enter the necessary IPv4 settings:
• Enter the IP Address to be used for LOM.
Note The LOM IP address must be different from and in the same subnet as the FMC
management interface IP address.
• Enter the Netmask for the system.

• Enter the Default Gateway for the system.
Step 5 Click Save.

Step 6 The system displays the following warning: "You will have to reboot your system for these changes to take
effect." Click OK to reboot now or Cancel to reboot later.
What to do next
• If you configured serial access, be sure the rear-panel serial port is connected to a local computer, terminal
server, or other device that can support remote serial access over ethernet as described in the Getting
Started Guide for your FMC model.
• If you configured Lights-Out Management, enable a Lights-Out Management user; see Lights-Out
Management User Access Configuration, on page 1400.

1399
Lights-Out Management User Access Configuration
Lights-Out Management User Access Configuration

You must explicitly grant Lights-Out Management permissions to users who will use the feature. LOM users
also have the following restrictions:
• You must assign the Administrator role to the user.
• The username may have up to 16 alphanumeric characters. Hyphens and longer user names are not
supported for LOM users.
• A user’s LOM password is the same as that user’s system password. The password must comply with
the requirements described in User Passwords, on page 56. 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 user with LOM while a that user is logged in, or restore a user
from a backup during that user’s login session, that user may need to log back into the web interface to regain
access to impitool commands.
Enabling Lights-Out Management User Access

Use this task to grant LOM access to an existing user. To grant LOM access to a new user, see Add an Internal
User, on page 59.
Procedure
Step 1 Choose System > Users > Users.

Step 2 To grant LOM user access to an existing user, click Edit ( ) next to a user name in the list.
Step 3 Under User Configuration, enable the Administrator role.
Step 4 Check the Allow Lights-Out Management Access check box.
Step 5 Click Save.
Serial Over LAN Connection Configuration

You use a third-party IPMI utility on your computer to create a Serial Over LAN connection to the appliance.
If your computer uses a Linux-like or Mac environment, use IPMItool; for Windows environments, you can
use IPMIutil or IPMItool, depending on your Windows version.
Note Cisco recommends using IPMItool version 1.8.12 or greater.
Linux
IPMItool is standard with many distributions and is ready to use.

1400
Configuring Serial Over LAN with IPMItool
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/
http://github.com/ipmitool/ipmitool/
Windows
For Windows Versions 10 and greater with Windows Subsystem for Linux (WSL) enabled, as well as some
older versions of Windows Server, you can use IPMItool. Otherwise, you must compile IPMIutil on your
Windows system; you can use IPMIutil itself to compile. Use your favorite search engine for more information
or try this site:
http://ipmiutil.sourceforge.net/man.html#ipmiutil
Understanding IPMI Utility Commands

Commands used for IPMI utilities are composed of segments as in the following example for IPMItool on
Mac:
ipmitool -I lanplus -H IP_address -U user_name command
where:
• ipmitool invokes the utility.
• -I lanplus specifies to use an encrypted IPMI v2.0 RMCP+ LAN Interface for the session.
• -H IP_address indicates the IP address you have configured for Lights-Out Management on the appliance
you want to access.
• -U user_name is the name of an authorized remote session user.
• command is the name of the command you want to use.
The same command for IMPIutil on Windows looks like this:
ipmiutil command -V 4 -J 3 -N IP_address -Uuser_name
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.
Configuring Serial Over LAN with IPMItool

You must be an Admin user with LOM access to perform this procedure.

1401
Configuring Serial Over LAN with IPMIutil
Procedure
Using IPMItool, enter the following command, and a password if prompted:
ipmitool -I lanplus -H IP_address -U user_name sol activate
Configuring Serial Over LAN with IPMIutil

Procedure
Using IPMIutil, enter the following command, and a password if prompted:
ipmiutil -J 3 -N IP_address -U username sol -a
Lights-Out Management Overview

Lights-Out Management (LOM) provides the ability to perform a limited set of actions over an SOL connection
on the default (eth0) management interface without the need to log into the system. You use the command
to create a SOL connection followed by one of the LOM commands. After the command is completed, the
connection ends.
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.

1402
Configuring Lights-Out Management with IPMItool
Table 115: Lights-Out Management Commands
IPMItool IPMIutil Description
(not applicable) -V 4 Enables admin privileges for the

IPMI session
-I lanplus -J 3 Enables encryption for the IPMI

session
-H hostname/IP address -N nodename/IP address Indicates the LOM IP address or

hostname for the FMC
-U -U Indicates the username of an

authorized LOM account
sol activate sol -a Starts the SOL session
sol deactivate sol -d Ends the SOL session
chassis power cycle power -c Restarts the appliance
chassis power on power -u Powers up the appliance
chassis power off power -d Powers down the appliance
sdr sensor Displays appliance information,

such as fan speeds and temperatures
For example, to display a list of appliance information, the IPMItool command is:
ipmitool -I lanplus -H IP_address -U user_name sdr
The same command with the IPMIutil utility is:
ipmiutil sensor -V 4 -J 3 -N IP_address -U user_name
Configuring Lights-Out Management with IPMItool

Procedure
Enter the following command for IPMItool and a password if prompted:
ipmitool -I lanplus -H IP_address -U user_name command

1403
Configuring Lights-Out Management with IPMIutil
Configuring Lights-Out Management with IPMIutil

Procedure
Enter the following command for IPMIutil and a password if prompted:
ipmiutil -J 3 -N IP_address -U username command
REST API Preferences

The Firepower REST API provides a lightweight interface for third-party applications to view and manage
appliance configuration using a REST client and standard HTTP methods. For more information on the
Firepower REST API, see the Firepower REST API Quick Start Guide.
By default, the Firepower Management Center allows requests from applications using the REST API. You
can configure the Firepower Management Center to block this access.
Enabling REST API Access
Note In deployments using Firepower Management Center high availability, this feature is available only in the
active Firepower Management Center.
Procedure
Step 1 Choose the Cog ( ) in the upper right corner to open the system menu.
Step 2 Click REST API Preferences.
Step 3 To enable or disable REST API access to the Firepower Management Center, check or uncheck the Enable
REST API check box.
Step 4 Click Save.
Step 5 Access the REST API Explorer at:
https://<management_center_IP_or_name>:<https_port>/api/api-explorer

1404
VMware Tools and Virtual Systems
VMware Tools and Virtual Systems

VMware Tools is a suite of performance-enhancing utilities intended for virtual machines. These utilities
allow you to make full use of the convenient features of VMware products. Firepower virtual appliances
running on VMware support the following plugins:
• guestInfo
• powerOps
• timeSync
• vmbackup
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/).
Enabling VMware Tools on the Firepower Management Center for VMware

Any Any Firepower Global only Admin

Management Center
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.
Procedure

Step 2 Click VMware Tools.
Step 3 Click Enable VMware Tools.
Step 4 Click Save.
(Optional) Opt Out of Web Analytics Tracking

By default, in order to improve Firepower products, Cisco collects non-personally-identifiable usage data,
including but not limited to page interactions, browser versions, product versions, user location, and management
IP addresses or hostnames of your Firepower Management Center appliances.
Data collection begins after you accept the End User License Agreement. If you do not want Cisco to continue
to collect this data, you can opt out using the following procedure.

1405
History for System Configuration
Procedure

Step 2 Click Web Analytics.
Step 3 Make your choice and click Save.
What to do next
(Optional) Determine whether to share data via the Cisco Success Network, on page 213.

Exempt most connection 7.0 Setting the Maximum Connection Events value for the Connection Database to zero now
events from event rate exempts low priority connection events from counting towards the flow rate limit for your FMC
limits hardware. Previously, setting this value to zero applied only to event storage, and did not affect
the flow rate limit.
New/Modified pages: The System > Configuration > Database page
Supported platforms: Hardware FMCs.
Added support for 7.0 Connections between the FMC and NTP servers can be secured with AES-128 CMAC keys as
AES-128 CMAC well as previously-supported MD5 and SHA-1 keys.
authentication for NTP
New/Modified pages: The System > Configuration > Time Synchronization page.
servers.
Supported platforms: FMCs.
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.
System > Configuration > HTTPS Certificate
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 1350 for more information.
New/modified screens: None.
Supported platforms: Hardware FMCs.

1406
Secure NTP 6.5 The FMC supports secure communications with NTP servers using SHA1 or MD5 symmetric
key authentication.
System > Configuration > Time Synchronization
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 1405.
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.
System > Configuration > User Configuration
System > Users > User Roles
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
System > Configuration > Management Interfaces > Interfaces > Edit Interface dialog
box > IPv6 DAD check box

1407
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
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
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.
System > Configuration > HTTPS Certificate page > Renew HTTPS Certificate.

1408
Ability to enable and 6.3 New/Modified screens:

disable CLI access for the
New check box available to administrators in FMC web interface: Enable CLI Access on the
FMC
System > Configuration > Console Configuration page.
• Checked: Logging into the FMC using SSH accesses the CLI.
• Unchecked: Logging into FMC using SSH accesses the Linux shell. This is the default state
for fresh Version 6.3 installations as well as upgrades to Version 6.3 from a previous release.
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.

1409

1410
CHAPTER 54
Platform Settings Policies
The following topics explain platform settings policies and how to deploy them to managed devices:
• Introduction to Platform Settings, on page 1411
• Requirements and Prerequisites for Platform Settings Policies, on page 1412
• Managing Platform Settings Policies, on page 1412
• Create a Platform Settings Policy, on page 1413
• Setting Target Devices for a Platform Settings Policy, on page 1413
Introduction to Platform Settings

A platform settings policy is a shared set of features or parameters that define the aspects of a managed device
that are likely to be similar to other managed devices in your deployment, such as time settings and external
authentication.
A shared policy makes it possible to configure multiple managed devices at once, which provides consistency
in your deployment and streamlines your management efforts. Any changes to a platform settings policy
affects all the managed devices where you applied the policy. Even if you want different settings per device,
you must create a shared policy and apply it to the desired device.
For example, your organization’s security policies may require that your appliances have a “No Unauthorized
Use” message when a user logs in. With platform settings, you can set the login banner once in a platform
settings policy.
You can also benefit from having multiple platform settings policies on a Firepower Management Center.
For example, if you have different mail relay hosts that you use under different circumstances or if you want
to test different access lists, you can create several platform settings policies and switch between them, rather
than editing a single policy.
Related Topics
Configure Platform Settings for Classic Devices, on page 1416
System Configuration Settings, on page 1346

1411
Requirements and Prerequisites for Platform Settings Policies
Requirements and Prerequisites for Platform Settings Policies

Model Support
Any, but you must create the correct type of policy for the target devices:
• Firepower Settings to create a shared policy for Classic managed devices: ASA FirePOWER, NGIPSv.
• Threat Defense Settings to create a shared policy for Firepower Threat Defense managed devices.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
Managing Platform Settings Policies

Use the Platform Settings page (Devices > Platform Settings) to manage platform settings policies. This
page indicates the type of device for each policy. The Status column shows the device targets for the policy.
Procedure
Step 1 Choose Devices > Platform Settings.

Step 2 Manage your platform settings policies:
• Create — To create a new platform settings policy, click New Policy; see Create a Platform Settings
Policy, on page 1413.
• Copy — To copy a platform settings policy, click Copy ( ).
• 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.

1412
Create a Platform Settings Policy
What to do next
Create a Platform Settings Policy

Platform settings for Firepower Threat Defense devices differ from platform settings for Classic devices.
When you create a new platform settings policy you must choose a type: Firepower (for Classic managed
devices) or Threat Defense (for FTD devices).
Procedure

Step 3 Choose a device type from the drop-down list:
• Firepower Settings to create a shared policy for Classic managed devices.
• Threat Defense Settings to create a shared policy for Firepower Threat Defense managed devices.
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 1415.
• For Threat Defense Settings, see Platform Settings for Firepower Threat Defense, on page 1425.
Step 8 Click Save.
What to do next
Setting Target Devices for a Platform Settings Policy

You can add targeted devices at the same time you create a new policy, or you can change them later.
Procedure

Step 2 Click Edit ( ) next to the platform settings policy that you want to edit.

1413
Setting Target Devices for a Platform Settings Policy
Step 3 Click Policy Assignment.

list and click Add to Policy. You can also drag and drop.
Step 5 Click OK.
What to do next

1414
CHAPTER 55
Platform Settings for Classic Devices
The following topics explain Firepower platform settings and how to configure them on Classic devices:
• About Platform Settings for Classic Devices, on page 1415
• Requirements for Platform Settings for Classic Devices, on page 1416
• Configure Platform Settings for Classic Devices, on page 1416
About Platform Settings for Classic Devices

Platform settings for managed devices are policy-based so that you can apply the same configuration to
multiple devices. Use a Firepower platform settings policy with Classic devices:
• ASA FirePOWER modules
• NGIPSv
Note that for the FMC, many of these settings are handled in the system configuration; see System
Configuration, on page 1345.
Table 116: Firepower Platform Settings for Classic Devices
Platform Setting Description See
Access List Control which computers can access the system on Configure Access Lists
specific ports. for Classic Devices, on
page 1417
Audit Log Configure the system to send an audit log to an Stream Audit Logs from
external host. Classic Devices, on page
1417
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
1419
Login Banner Create a custom login banner that appears when users Customize the Login
log in. Banner for Classic
Devices , on page 1420

1415
Requirements for Platform Settings for Classic Devices
Platform Setting Description See
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 1422
SNMP Enable Simple Network Management Protocol Configure SNMP Polling

(SNMP) polling. on Classic Devices, on
page 1422
Time Synchronization Manage time synchronization on the system. Synchronize Time on

Classic Devices with an
NTP Server, on page 1421
UCAPL/CC Compliance Enable compliance with specific requirements set out Enable Security
by the United States Department of Defense. Certifications
Compliance, on page 1478
Requirements for Platform Settings for Classic Devices

License Requirements
None.
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.
Configure Platform Settings for Classic Devices

Platform settings for managed devices are policy-based so that you can apply the same configuration to
multiple devices. Use a Firepower platform settings policy with Classic devices.
Procedure
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
See About Platform Settings for Classic Devices, on page 1415 and Create a Platform Settings Policy, on page
1413.
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.

1416
Configure Access Lists for Classic Devices
Step 4 Click Save.
What to do next
Configure Access Lists for Classic Devices

By default, access to Firepower devices is not restricted. Port 22 (SSH) is open for CLI access.
To operate in a more secure environment, consider adding access for specific IP addresses. You can also add
access to poll for SNMP information over port 161.
Procedure
Step 2 Click Access List.
Step 3 To add access for one or more IP addresses, click Add Rules.
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
Stream Audit Logs from Classic Devices

Firepower appliances generate records (or audit logs) of user interactions. You can stream these audit logs to
a syslog or HTTP server. Note that sending audit information to an external URL may affect system
performance.
Optionally, you can use Transport Layer Security (TLS) certificates to secure communications between
Firepower devices and a trusted audit log server. For each device (client certificates are unique), you must
generate a certificate signing request (CSR), submit it to a Certificate Authority (CA) for signing, then import
the signed certificate onto the device. You cannot use the FMC to import audit log certificates onto its managed
devices. These certificates are unique to each device, and you must log into each device to import them.
To ensure security, use a globally recognized and trusted CA. The same CA must sign:
• Both the client certificate and the server certificate, if you plan to require mutual authentication between
the device and the audit log server.
• Any intermediate certificates in the certificate chain. If the signing CA requires you to trust an intermediate
CA, you must provide the necessary certificate chain (or certificate path).

1417
Stream Audit Logs from Classic Devices
Audit logs have the following format:

timestamp host [tag] appliance_name: username@ip_address, subsystem, action
For example:
Mar 01 14:45:24 localhost [FIREPOWER] MyFirepowerAppliance: admin@10.1.1.2, System >
Configuration, Page View
Note that the tag is optional and user-configurable. Syslog events also have an optional facility and severity..
Before you begin

Make sure your devices can communicate with the server or servers where you plan to stream audit logs. For
syslog streaming, the system uses port 7/UDP to verify that the syslog server is reachable when you save the
configuration. Then, the system uses port 514/UDP to stream audit logs. If you secure the channel, the system
uses 6514/TCP.
Procedure
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 2635) and Severity (Syslog Severity Levels, on page
2636).
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 1420.
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.

1418
Require Valid Audit Log Server Certificates for Classic Devices
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 1419.
• (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 1420.
Require Valid Audit Log Server Certificates for Classic Devices

For additional security, we recommend you require mutual authentication between Firepower appliances and
the audit log server. To accomplish this, load one or more certificate revocation lists (CRLs). You cannot
stream audit logs to servers with revoked certificates listed in those CRLs.
Firepower supports CRLs encoded in Distinguished Encoding Rules (DER) format. Note that these are the
same CRLs that the system uses to validate HTTPS client certificates for the FMC web interface.
Before you begin

Obtain and import a signed client certificate onto each device. 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.
Use a globally recognized and trusted CA. The same CA must sign the client certificates you imported and
the server certificate you will require with this procedure.
Procedure
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 297.
Step 5 Click Save.
What to do next

1419
Filter Syslogs from Audit Logs
Filter Syslogs from Audit Logs

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. This behavior is caused by the fact that the
/etc/syslog-ng.d/syslog-tls.conf is created when you deploy the Firepower platform settings policy,
which results in syslog messages being forwarded/sent to the configured host, instead of only sending the
audit logs.
If your auditing policy does not want or require these syslog records, you can prevent those syslogs from
being streamed to the configured host. To filter syslogs from audit logs, you must have access to an appliance’s
admin user account, and you must be able to either access the appliance’s console or open a secure shell.
Caution Make sure that only authorized personnel have access to the appliance and to its admin account.
Procedure
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
Customize the Login Banner for Classic Devices

You can customize the CLI login banner for Classic devices. Note that if the banner is too large or causes
errors, CLI sessions can fail when the system attempts to display the banner.
Procedure
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.
Step 4 Click Save.
What to do next

1420
Synchronize Time on Classic Devices with an NTP Server
Synchronize Time on Classic Devices with an NTP Server

Synchronizing the system time on your Firepower Management Center and all its managed devices is essential
to successful operations. If your deployment includes FTD devices, see Configure NTP Time Synchronization
for Threat Defense, on page 1467.
The device supports NTPv4.
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.
Before you begin

Make sure the device can communicate with the NTP server or servers you plan to use. You can either:
• (Recommended.) Use the same NTP servers as the FMC: Synchronize Time on the FMC with an NTP
Server, on page 1389.
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.
Procedure
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 IPv4 or IPv6 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.
Step 4 Click Save.

1421
Configure Session Timeouts for Classic Devices
What to do next
Configure Session Timeouts for Classic Devices

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. The maximum value is 24 hours, or 1440 minutes.
Procedure
Step 2 Click CLI Timeout.
Step 3 Enter a CLI Timeout (Minutes).
Step 4 Click Save.
What to do next
Configure SNMP Polling on Classic Devices

Simple Network Management Protocol (SNMP) polling allows access to the standard management information
base (MIB) on Firepower devices, which includes system details such as contact, administrative, location,
service information, IP addressing and routing information, and transmission protocol usage statistics. Note
that 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.
The system supports SNMPv1, v2, and v3. SNMPv2 only supports read-only communities and SNMPv3 only
supports read-only users. SNMPv3 also supports encryption with AES128.
Before you begin

Add SNMP access for each computer you plan to use to poll the system. See Configure Access Lists for
Classic Devices, on page 1417.
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.
Procedure
Step 2 Click SNMP.

1422
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.
Step 4 Enter a Username.

Step 5 Choose the protocol you want to use for authentication from the Authentication Protocol drop-down list.
Step 6 Enter the password required for authentication with the SNMP server in the Authentication Password field.
Step 7 Re-enter the authentication password in the Verify Password field.
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.
What to do next

1423

1424
CHAPTER 56
Platform Settings for Firepower Threat Defense
Platform settings for FTD devices configure a range of unrelated features whose values you might want to
share among several devices. Even if you want different settings per device, you must create a shared policy
and apply it to the desired device.
• Configure ARP Inspection, on page 1425
• Configure Banners, on page 1427
• Configure DNS, on page 1427
• Configure External Authentication for SSH, on page 1429
• Configure Fragment Handling, on page 1433
• Configure HTTP, on page 1434
• Configure ICMP Access Rules, on page 1436
• Configure SSL Settings , on page 1437
• Configure Secure Shell, on page 1441
• Configure SMTP, on page 1442
• Configure SNMP for Threat Defense, on page 1443
• About Configuring Syslog, on page 1450
• Configure Global Timeouts, on page 1465
• Configure NTP Time Synchronization for Threat Defense, on page 1467
• Configure Device Time Zone for Policy Application, on page 1468
• History for Firepower Threat Defense Platform Settings, on page 1469
Configure ARP Inspection

packets by enabling ARP inspection.
ARP inspection prevents malicious users from impersonating other hosts or routers (known as ARP spoofing).
ARP spoofing can enable a “man-in-the-middle” attack. For example, a host sends an ARP request to the
gateway router; the gateway router responds with the gateway router MAC address. The attacker, however,
sends another ARP response to the host with the attacker MAC address instead of the router MAC address.
The attacker can now intercept all the host traffic before forwarding it on to the router.
ARP inspection ensures that an attacker cannot send an ARP response with the attacker MAC address, so
long as the correct MAC address and the associated IP address are in the static ARP table.

1425
Configure ARP Inspection
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.
Procedure
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 863.
Step 5 Click Save.

1426
Configure Banners
Configure Banners
You can configure messages to show users when they connect to the device command line interface (CLI).
Procedure
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:
You have logged in to a secure device.

If you are not authorized to access this device,
log out immediately or risk criminal charges.
Step 4 Click Save.

Configure DNS
The Domain Name System (DNS) servers are used to resolve hostnames to IP addresses. There are two DNS
server settings that apply to different types of traffic: data and special management traffic. Data traffic includes
any services that use FQDNs for which a DNS lookup is necessary, such as Access Control Rules and Remote
Access VPN. Special management traffic includes traffic origniating on the Management interface such as
FMC management and database updates. This procedure only applies to data DNS servers. For management
DNS settings, see the CLI configure network dns servers and configure network dns searchdomains
commands.
To determine the correct interface for DNS server communications, the FTD uses a routing lookup, but which
routing table is used depends on the interfaces for which you enable DNS. See the interface settings below

1427
Configure DNS
Before you begin

• Ensure you have created a DNS server group. For instructions, see Creating DNS Server Group Objects,
on page 678.
• Ensure that the FTD has appropriate static or dynamic routes to access the DNS servers.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Click DNS.
Step 3 Check Enable DNS name resolution by device.
Step 4 Choose 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 Enable DNS lookups on all interfaces or on specific interfaces. These choices also affect which routing tables
are used.
Note that enabling DNS lookups on an interface is not the same as specifying the source interface for lookups.
The FTD always uses a route lookup to determine the source interface.
• No interfaces selected—Enables DNS lookups on all interfaces, including Management and
management-only interfaces. The FTD checks the data routing table, and if no route is found, falls back
to the management-only routing table.
• Specific interfaces selected but not the Enable DNS Lookup via diagnostic interface also
option—Enables DNS lookups on the specified interfaces. The FTD checks the data routing table only.
• Specific interfaces selected plus the Enable DNS Lookup via diagnostic interface also option—Enables
DNS lookups on the specified interfaces and the Diagnostic interface. The FTD checks the data routing
table, and if no route is found, falls back to the management-only routing table.
• Only the Enable DNS Lookup via diagnostic interface also option—Enables DNS lookups on
Diagnostic. The FTD checks only the management-only routing table. Be sure to configure an IP address
for the Diagnostic interface on the Devices > Device Management > edit device > Interfaces page.
Step 7 Click Save.

1428
Configure External Authentication for SSH
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 613.
Note You must have administrator privileges to perform this task.
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.
Attention External authentication is not supported on FTD virtual devices.

between the FMC and devices, or create separate objects. Note that the FTD supports defining users on the
RADIUS server, while the FMC requires you to predefine the user list in the external authentication object.
You can choose to use the predefined list method for the FTD, but if you want to define users on the RADIUS
server, you must create separate objects for the FTD and the FMC.
to a higher value, the FTD external authentication configuration will not work.
Assigning External Authentication Objects to Devices

For the FMC, enable the external authentication objects directly on System > Users > External Authentication;
this setting only affects FMC usage, and it does not need to be enabled for managed device usage. For FTD
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.
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.

1429
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.
Before you begin

• SSH access is enabled by default on the management interface. To enable SSH access on data interfaces,
see Configure Secure Shell, on page 1441. SSH is not supported to the Diagnostic interface.
• Inform RADIUS users of the following behavior to set their expectations appropriately:
• The first time an external user logs in, FTD creates the required structures but cannot simultaneously
create the user session. The user simply needs to authenticate again to start the session. The user
will see a message similar to the following: "New external username identified. Please log in again
to start a session."
• Similarly, if the user’s Service-Type authorization was changed since the last login, the user will
need to re-authenticate. The user will see a message similar to the following: "Your authorization
privilege has changed. Please log in again to start a session."
Procedure
Step 3 Click the Manage External Authentication Server link.
You can also open the External Authentication screen by clicking System > Users > External Authentication.
Step 4 Configure an LDAP Authentication Object.

a) Click Add External Authentication Object.
b) Set the Authentication Method to LDAP
c) Enter a Name and optional Description.
d) Choose a Server Type from the drop-down list.
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.
f) (Optional) Change the Port from the default.

g) (Optional) Enter the Backup Sever parameters.
h) Enter LDAP-Specific Parameters.
• Base DN—Enter the base distinguished name for the LDAP directory you want to access. For
example, to authenticate names in the Security organization at the Example company, enter

1430
ou=security,dc=example,dc=com. Alternatively click Fetch DNs, and choose the appropriate base
distinguished name from the drop-down list.
• (Optional) Base Filter—For example, if the user objects in a directory tree have a
• User Name—Enter a distinguished name for a user who has sufficient credentials to browse the
LDAP server. For example, if you are connecting to an OpenLDAP server where user objects have
a uid attribute, and the object for the administrator in the Security division at our example company
has a uid value of NetworkAdmin, you might enter
uid=NetworkAdmin,ou=security,dc=example,dc=com.
• Password and Confirm Password—Enter and confirm the password for the user.
• (Optional) Show Advanced Options—Configure the following advanced options.
Note If you change the encryption method after specifying a port, you reset the port to the
default value for that method. For None or TLS, the port resets to the default value
of 389. If you choose SSL encryption, the port resets to 636.
• 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 between
1 and 30. The default is 30.
Note The timeout range is different for the FTD and the FMC, so if you share an object,
be sure not to exceed the FTD's smaller timeout range (1-30 seconds). If you set the
timeout to a higher value, the FTD external authentication configuration will not work.
i) (Optional) Set the CLI 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 CLI Access Attribute
field.
j) Set the CLI Access Filter.
Choose one of the following methods:
Filter.
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).
The names on the LDAP server must be Linux-valid usernames:


1431
• All lowercase
• Cannot start with hyphen (-); cannot be all numbers; cannot include a period (.), at sign (@), or slash
(/)
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 535.
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.
The names must be Linux-valid usernames:

• All lowercase
(/)
Alternatively, you can predefine users in the external authentication object (see Step 6.j, on page 1433). 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 CLI Access Filter users (for use with the FMC), and the other object leaves the
CLI 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.
f) (Optional) Change the Port from the default.

1432
Configure Fragment Handling
g) Enter a RADIUS Secret Key.

h) (Optional) Enter the Backup Sever parameters.
i) Enter RADIUS-Specific Parameters.
• 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 CLI Access Filter, enter a comma-separated
list of usernames in the Administrator CLI Access User List field. For example, enter jchrichton,
aerynsun, rygel.
You may want to use the CLI 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 CLI Access Filter empty.
usernames:
• All lowercase
(/)
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 8 Click Refresh ( ) to view any newly-added objects.

For LDAP when you specify SSL or TLS encryption, you must upload a certificate for the connection;
otherwise, the server will not be listed on this window.
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.
Configure Fragment Handling

By default, the FTD device allows up to 24 fragments per IP packet, and up to 200 fragments awaiting
reassembly. You might need to let fragments on your network if you have an application that routinely
fragments packets, such as NFS over UDP. However, if you do not have an application that fragments traffic,
we recommend that you do not allow fragments by setting Chain to 1. Fragmented packets are often used as
Denial of Service (DoS) attacks.

1433
Configure HTTP
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..
Procedure
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.
Step 4 Click Save.

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.
Before you begin

• When you manage the FTD using the Firepower Management Center, HTTPS access to the FTD is only
for viewing packet capture files. The FTD does not have a web interface for configuration in this
management mode.
• HTTPS local users can only be configured at the CLI using the configure user add command. By default,
there is an admin user for which you configured the password during initial setup. AAA external
authentication is not supported.
• The physical management interface is shared between the Diagnostic logical interface and the Management
logical interface; this configuration applies only to the Diagnostic logical interface, if used, or to other
data interfaces. 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 has a separate IP address
and static routing.
• To use HTTPS, you do not need an access rule allowing the host IP address. You only need to configure
HTTPS access according to this section.

1434
Configure HTTP
• You can only use HTTPS to a reachable interface; if your HTTPS host is located on the outside interface,
you can only initiate a management connection directly to the outside interface.
• You cannot configure both HTTPS and AnyConnect remote access SSL VPN on the same interface for
the same TCP port. For example, if you configure remote access SSL VPN on the outside interface, you
cannot also open the outside interface for HTTPS connections on port 443. If you must configure both
features on the same interface, use different ports. For example, open HTTPS on port 4443.
• The device allows a maximum of 5 concurrent HTTPS connections.
• You need network objects that define the hosts or networks you will allow to make HTTPS connections
to the device. 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.
Procedure
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.

1435
Configure ICMP Access Rules
Configure ICMP Access Rules

By default, you can send ICMP packets to any interface using either IPv4 or IPv6, with these exceptions:
• The Firepower Threat Defense device does not respond to ICMP echo requests directed to a broadcast
address.
• The Firepower Threat Defense device only responds to ICMP traffic sent to the interface that traffic
comes in on; you cannot send ICMP traffic through an interface to a far interface.
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.
Before you begin

Ensure that the objects needed in the rules already exist. Select Objects > Object Management to configure
objects. You need network objects that define the desired hosts or networks, and port objects that define the
ICMP message types you want to control.
Procedure
Step 2 Select ICMP.
Step 3 Configure ICMP rules.
• 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 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.

1436
Configure SSL Settings
• 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.
Step 5 Click Save.

Configure SSL Settings
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 165.
Procedure
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 1438
The algorithms are listed based on the protocol version that you select. Each security protocol identifies unique
algorithm for setting up the security level.
Step 5 Click OK to save the changes.
What to do next
Select Deploy > Deployment and click Deploy to deploy the policy to the assigned devices.

1437
About SSL Settings
About SSL Settings

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. The SSL Settings window lets you configure SSL versions and encryption algorithms that will be
negotiated and used for message transmission during remote VPN access over SSL.
Configure the SSL Settings at the following location:
Devices > Platform Settings > SSL
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:
TLS V1 Accepts SSLv2 client hellos and negotiates TLSv1

(or greater).
TLSV1.1 Accepts SSLv2 client hellos and negotiates TLSv1.1

(or greater).
TLSV1.2 Accepts SSLv2 client hellos and negotiates TLSv1.2

(or greater).
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
TLSV1.2 DTLSv1, DTLSv1.2
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

1438
About SSL Settings
• 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
Note ECDSA and DHE ciphers are the highest priority.
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.

1439
About SSL Settings
• 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
Ciphers not supported by TLSv1.1 or TLSv1.2
RC4-SHA
RC4-MD5
DES-CBC-SHA
NULL-SHA

1440
Configure Secure Shell
Configure Secure Shell

If you enabled FMC access on a data interface, such as outside, you should enable SSH on that interface using
this procedure. This section describes how to enable SSH connections to one or more data interfaces on the
FTD. SSH is not supported to the Diagnostic logical interface.
Note SSH is enabled by default on the Management interface; however, this screen does not affect Management
SSH access.
The Management 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. SSH for data interfaces shares the internal and external user
list with SSH for the Management interface. Other settings are configured separately: for data interfaces,
enable SSH and access lists using this screen; SSH traffic for data interfaces uses the regular routing
configuration, and not any static routes configured at setup or at the CLI.
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.
Before you begin

• You can configure SSH internal users at the CLI using the configure user add command; see Add an
Internal User at the CLI, on page 137. By default, there is an admin user for which you configured the
password during initial setup. You can also configure external users on LDAP or RADIUS by configuring
External Authentication in platform settings. See Configure External Authentication for SSH, on page
1429.
• You need network objects that define the hosts or networks you will allow to make SSH connections to
the device. Select Objects > Object Management to configure objects.
Note You cannot use the system-provided any network object. Instead, use any-ipv4
or any-ipv6.

1441
Configure SMTP
Procedure
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.
• 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.
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.
Before you begin

Ensure that the network objects that define the host address of the primary and secondary SMTP servers exist.
Select Objects > Object Management to define the objects. Alternatively, you can create the objects while
editing the policy.
Procedure
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.

1442
Configure SNMP for Threat Defense
Configure SNMP for Threat Defense

Simple Network Management Protocol (SNMP) defines a standard way for network management stations
running on PCs or workstations to monitor the health and status of many types of devices, including switches,
routers, and security appliances. You can use the SNMP page to configure a firewall device for monitoring
by SNMP management stations.
The Simple Network Management Protocol (SNMP) enables monitoring of network devices from a central
location. Cisco security appliances support network monitoring using SNMP versions 1, 2c, and 3, as well as
traps and SNMP read access; SNMP write access is not supported.
SNMPv3 supports read-only users and encryption with DES (deprecated), 3DES, AES256, AES192, and
AES128.
Note The DES option has been deprecated. If your deployment includes SNMP v3 users using DES encryption that
were created using a version previous to 6.5, you can continue to use those users for FTDs running versions
6.6 and previous. However, you cannot edit those users and retain DES encryption, or create new users with
DES encryption. If your FMC manages any FTDs running Versions 7.0+, deploying a platform settings policy
that uses DES encryption to those FTDs will fail.
Note To create an alert to an external SNMP server, access Policies > Action > Alerts
Procedure
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.

1443
Add SNMPv3 Users
• 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.
Step 4 (SNMPv3 only.) Add SNMPv3 Users, on page 1444.

Step 5 Add SNMP Hosts, on page 1446.
Step 6 Configure SNMP Traps, on page 1448.
Step 7 Click Save.
Add SNMPv3 Users
Note You create users for SNMPv3 only. These steps are not applicable for SNMPv1 or SNMPv2c.
Note that SNMPv3 only supports read-only users.

SNMP users have a specified username, an authentication password, an encryption password, and authentication
and encryption algorithms to use.
Note When using SNMPv3 with clustering or High Availability, if you add a new cluster unit after the initial cluster
formation or you replace a High Availability unit, then SNMPv3 users are not replicated to the new unit. You
must remove the users, re-add them, and then redeploy your configuration to force the users to replicate to
the new unit.
The authentication algorithm options are MD5 (deprecated, pre-6.5 only), SHA, SHA224, SHA256, and
SHA384.
Note The MD5 option has been deprecated. If your deployment includes SNMP v3 users using the MD5
authentication algorithm that were created using a version previous to 6.5, you can continue to use those users
for FTDs running versions 6.7 and previous. However, you cannot edit those users and retain the MD5
authentication algorithm, or create new users with the MD5 authentication algorithm. If your FMC manages
any FTDs running Versions 7.0+, deploying a platform settings policy that uses the MD5 authentication
algorithm to those FTDs will fail.
The encryption algorithm options are DES (deprecated, pre-6.5 only), 3DES, AES256, AES192, and AES128.

1444
Add SNMPv3 Users
Note The DES option has been deprecated. If your deployment includes SNMP v3 users using DES encryption that
were created using a version previous to 6.5, you can continue to use those users for FTDs running versions
6.7 and previous. However, you cannot edit those users and retain DES encryption, or create new users with
DES encryption. If your FMC manages any FTDs running Versions 7.0+, deploying a platform settings policy
that uses DES encryption to those FTDs will fail.
Procedure
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 In the Auth Algorithm Type drop-down list, select the type of authentication you want to use: SHA, SHA224,
SHA256, or SHA384.
Note The MD5 option has been deprecated. If your deployment includes SNMP v3 users using the MD5
authentication algorithm that were created using a version previous to 6.5, you can continue to use
those users for FTDs running versions 6.7 and previous. However, you cannot edit those users and
retain the MD5 authentication algorithm, or create new users with the MD5 authentication algorithm.
If your FMC manages any FTDs running Versions 7.0+, deploying a platform settings policy that
uses the MD5 authentication algorithm to those FTDs will fail.
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.
Note To use AES or 3DES encryption, you must have the appropriate license installed on the device.

1445
Add SNMP Hosts
Note The DES option has been deprecated. If your deployment includes SNMP v3 users using DES
encryption that were created using a version previous to 6.5, you can continue to use those users
for FTDs running versions 6.7 and previous. However, you cannot edit those users and retain DES
encryption, or create new users with DES encryption. If your FMC manages any FTDs running
Versions 7.0+, deploying a platform settings policy that uses DES encryption to those FTDs will
fail.
Step 10 Enter the password to use for encryption in the Encryption 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
• 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.
Step 11 Click OK.

Step 12 Click Save.
Add SNMP Hosts

Use Host to add or edit entries in the SNMP Hosts table on the SNMP page. These entries represent SNMP
management stations allowed to access the FTD device.
You can add up to 4000 hosts. However, only 128 of this number can be for traps.
Before you begin

Ensure that the network objects that define the SNMP management stations exist. Select Device > Object
Management to configure network objects.
Note The supported network objects include IPv6 hosts, IPv4 hosts, IPv4 range and IPv4 subnet addresses.

1446
Add SNMP Hosts
Procedure
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.
• When you choose this interface for SNMPv3 polling, all configured SNMPv3 users are allowed to
poll and are not restricted to the user chosen in step Step 6, on page 1447. Here, SNMPv1 and SNMPv2c
are not allowed from an SNMPv3 host.
• When you choose this interface for SNMPv1 and SNMPv2c polling, the polling is not restricted at
all to the version selected in step Step 5, on page 1447.
• 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

1447
Configure SNMP Traps
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 11 Click OK.

Step 12 Click Save.

Use SNMP Traps to configure SNMP traps (event notifications) for the FTD device. Traps are different from
browsing; they are unsolicited “comments” from the FTD device to the management station for certain events,
such as linkup, linkdown, and syslog event generated. An SNMP object ID (OID) for the device appears in
SNMP event traps sent from the device.
Some traps are not applicable to certain hardware models. These traps will be ignored if you apply the policy
to one of these models. For example, not all models have field-replaceable units, so the Field Replaceable
Unit Insert/Delete trap will not be configured on those models.
SNMP traps are defined in either standard or enterprise-specific MIBs. Standard traps are created by the IETF
and documented in various RFCs. SNMP traps are compiled into the FTD software.
If needed, you can download RFCs, standard MIBs, and standard traps from the following location:
http://www.ietf.org/
Browse the complete list of Cisco MIBs, traps, and OIDs from the following location:
SNMP Object Navigator
In addition, download Cisco OIDs by FTP from the following location:
ftp://ftp.cisco.com/pub/mibs/oid/oid.tar.gz
Procedure
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 1461.

1448
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
Step 6 Select the desired event-notification traps in the Resource section:

• Connection Limit Reached – This trap indicates that a connection attempt was rejected because the
configured connections limit has been reached.
Step 7 Select the desired event-notification traps in the Other section:

• NAT Packet Discard – This notification is generated when IP packets are discarded by the NAT function.
Available Network Address Translation addresses or ports have fallen below configured threshold.
• CPU Rising Threshold – This notification is generated when rising CPU utilization exceeds a predefined
threshold for a configured period of time. Check this option to enable CPU rising threshold notifications:
• Percentage – The default value is 70 percent for the high threshold notification; the range is between
10 and 94 percent. The critical threshold is hardcoded at 95 percent.
• Period – The default monitoring period is 1 minute; the range is between 1 and 60 minutes.
• Memory Rising Threshold – This notification is generated when rising memory utilization exceeds a
predefined threshold, thus reducing available memory. Check this option to enable memory rising
threshold notifications:
• Percentage – The default value is 70 percent for the high threshold notification; the range is between
50 and 95 percent.
• Failover – This notification is generated when there is a change in the failover state as reported by the
CISCO-UNIFIED-FIREWALL-MIB.
• Cluster – This notification is generated when there is a change in the cluster health as reported by the
CISCO-UNIFIED-FIREWALL-MIB.

1449
About Configuring Syslog
• Peer Flap – This notification is generated when there is BGP route flapping, a situation in which BGP
systems send an excessive number of update messages to advertise network reachability information.
Step 8 Click Save.

About Configuring Syslog

You can enable system logging (syslog) for FTD devices. Logging information can help you identify and
isolate network or device configuration problems. You can also send some security events to a syslog server.
The following topics explain logging and how to configure it.
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.
Table 117: System Logs for Firepower Threat Defense
Logs Related To Details Configure In
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.
Security events This syslog configuration generates alerts for file and malware, Platform
connection, Security Intelligence, and intrusion events. For details, see Settings and the
About Sending Syslog Messages for Security Events, on page 2701 and Logging in an
subtopics. access control
policy

1450
Severity Levels
Logs Related To Details Configure In
(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 2632. 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 2634.
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.
Table 118: Syslog Message Severity Levels
Level Number Severity Level Description
0 emergencies System is unusable.
1 alert Immediate action is needed.
2 critical Critical conditions.
3 error Error conditions.
4 warning Warning conditions.
5 notification Normal but significant conditions.
6 informational Informational messages only.
7 debugging Debugging messages only.

Log at this level only temporarily, when debugging issues. This
log level can potentially generate so many messages that system
performance can be affected.
Note Firepower Threat Defense does not generate syslog messages with a severity level of zero (emergencies).
Syslog Message Filtering

You can filter generated syslog messages so that only certain syslog messages are sent to a particular output
destination. For example, you could configure the Firepower Threat Defense device to send all syslog messages
to one output destination and to send a subset of those syslog messages to a different output destination.
Specifically, you can direct syslog messages to an output destination according to the following criteria:
• Syslog message ID number

1451
Syslog Message Classes
(This does not apply to syslog messages for security events such as connection and intrusion events.)
• Syslog message severity level
• Syslog message class (equivalent to a functional area)
(This does not apply to syslog messages for security events such as connection and intrusion events.)
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.)
You can use syslog message classes in two ways:

• Specify an output location for an entire category of syslog messages.
• Create a message list that specifies the message class.
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.
Table 119: Syslog Message Classes and Associated Message ID Numbers
Class Definition Syslog Message ID Numbers
auth User Authentication 109, 113
— Access Lists 106
— Application Firewall 415

1452
bridge Transparent Firewall 110, 220
ca PKI Certification Authority 717
citrix Citrix Client 723
— Clustering 747
— Card Management 323
config Command Interface 111, 112, 208, 308
csd Secure Desktop 724
cts Cisco TrustSec 776
dap Dynamic Access Policies 734
eap, eapoudp EAP or EAPoUDP for Network Admission Control 333, 334
eigrp EIGRP Routing 336
email E-mail Proxy 719
— Environment Monitoring 735
ha Failover 101, 102, 103, 104, 105, 210, 311, 709
— Identity-based Firewall 746
ids Intrusion Detection System 400, 733
— IKEv2 Toolkit 750, 751, 752
ip IP Stack 209, 215, 313, 317, 408
ipaa IP Address Assignment 735
ips Intrusion Protection System 400, 401, 420
— IPv6 325
— Botnet traffic filtering. 338
— Licensing 444
mdm-proxy MDM Proxy 802
nac Network Admission Control 731, 732
nacpolicy NAC Policy 731
nacsettings NAC Settings to apply NAC Policy 732
— Network Access Point 713

1453
np Network Processor 319
— NP SSL 725
ospf OSPF Routing 318, 409, 503, 613
— Password Encryption 742
— Phone Proxy 337
rip RIP Routing 107, 312
rm Resource Manager 321
— Smart Call Home 120
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
snmp SNMP 212
— ScanSafe 775
ssl SSL Stack 725
svc SSL VPN Client 722
sys System 199, 211, 214, 216, 306, 307, 315, 414,
604, 605, 606, 610, 612, 614, 615,701,
711, 741
— Threat Detection 733
tre Transactional Rule Engine 780
— UC-IME 339
tag-switching Service Tag Switching 779
vm VLAN Mapping 730
vpdn PPTP and L2TP Sessions 213, 403, 603
vpn IKE and IPsec 316, 320, 402, 404, 501, 602, 702, 713,
714, 715
vpnc VPN Client 611
vpnfo VPN Failover 720
vpnlb VPN Load Balancing 718
— VXLAN 778

1454
Guidelines for Logging
webfo WebVPN Failover 721
webvpn WebVPN and AnyConnect Client 716
— NAT and PAT 305
Guidelines for Logging

This section includes guidelines and limitations that you should review before configuring logging.
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.
• 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.
• If you use TCP as the transport protocol, the system opens 4 connections to the syslog server to ensure
that messages are not lost. If you are using the syslog server to collect messages from a very large number
of devices, and the combined connection overhead is too much for the server, use UDP instead.
• It is not possible to have two different lists or classes being assigned to different syslog servers or same
locations.
• You can configure up to 16 syslog servers.
• The syslog server should be reachable through the Firepower Threat Defense device. You should configure
the device to deny ICMP unreachable messages on the interface through which the syslog server is
reachable and to send syslogs to the same server. Make sure that you have enabled logging for all severity
levels. To prevent the syslog server from crashing, suppress the generation of syslogs 313001, 313004,
and 313005.
• The number of UDP connections for syslog is directly related to the number of CPUs on the hardware
platform and the number of syslog servers you configure. At any point in time, there can be as many
UDP syslog connections as there are CPUs times the number of configured syslog servers. For example,
for each syslog server:
• A Firepower 4110 can have up to 22 UDP syslog connections.
• A Firepower 4120 can have up to 46 UDP syslog connections.

1455
Configure Syslog Logging for FTD Devices
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.
Configure Syslog Logging for FTD Devices
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 1457.
To configure syslog settings, perform the following steps:
Before you begin

See requirements in Guidelines for Logging, on page 1455.
Procedure
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 1457
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 1458
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
1459
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 1460
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 1461
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 1462
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 1463

1456
FTD Platform Settings That Apply to Security Event Syslog Messages
FTD Platform Settings That Apply to Security Event Syslog Messages

"Security events" include connection, Security Intelligence, intrusion, and file and malware events.
Some of the syslog settings on the Devices > Platform Settings > Threat Defense Settings > Syslog page
and its tabs apply to syslog messages for security events, but most apply only to messages for events related
to system health and networking.
The following settings apply to syslog messages for security events:
• Logging Setup tab:
• Send syslogs in EMBLEM format
• Syslog Settings tab:

• Enable Timestamp on Syslog Messages
• Timestamp Format
• Enable Syslog Device ID
• Syslog Servers tab:

• All options on the Add Syslog Server form (and the list of configured servers).
See also Best Practices for Configuring Security Event Syslog Messaging, on page 2701.
Enable Logging and Configure Basic Settings

You must enable logging for the system to generate syslog messages for data plane events.
You can also set up archiving on flash or an FTP server as a storage location when the local buffer becomes
full. You can manipulate logging data after it is saved. For example, you could specify actions to be executed
when certain types of syslog messages are logged, extract data from the log and save the records to another
file for reporting, or track statistics using a site-specific script.
The following procedure explains some of the basic syslog settings.
Procedure
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.

1457
Enable Logging Destinations
• 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 1451.
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 kilobytes.
• 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 kilobytes.
Step 7 Click Save.

Enable Logging Destinations

You must enable a logging destination to see messages at that destination. When enabling a destination, you
must also specify the message filter for the destination.

1458
Send Syslog Messages to an E-mail Address
Procedure
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 1452.
d) Click OK .
Step 5 Click Save.
Send Syslog Messages to an E-mail Address

You can set up a list of recipients for syslog messages to be sent as e-mails.

1459
Create a Custom Event List
Before you begin

• Configure an SMTP server on the SMTP Server platform settings page
• Enable Logging and Configure Basic Settings, on page 1457
• Enable Logging Destinations
Procedure
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 1451.
Step 6 Click OK.

Step 7 Click Save.
Create a Custom Event List

An event list is a custom filter you can apply to a logging destination to control which messages are sent to
the destination. Normally, you filter messages for a destination based on severity only, but you can use an
event list to fine-tune which messages are sent based on a combination of event class, severity, and message
identifier (ID).
Creating a custom event list is a two-step process. You create a custom list in the Event Lists, and then use
the event list to define the logging filter for the various types of destination, in the Logging Destinations.
Procedure
Step 2 Select Syslog > Events List.
Step 3 Configure an event list.

1460
Limit the Rate of Syslog Message Generation
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 1452.
For information on the levels, see Severity Levels, on page 1451.
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 1452.
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 1458.
Step 5 Click Save.

Limit the Rate of Syslog Message Generation

You can limit the rate at which syslog messages are generated by severity level or message ID. You can
specify individual limits for each logging level and each Syslog message ID. If the settings conflict, the Syslog
message ID limits take precedence.
Procedure
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 1451.
• 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.

1461
Configure Syslog Settings
Step 4 Click OK.

Step 5 To limit message generation by syslog message ID, click Syslog Level > Add and configure the following
options:
• Syslog ID—The syslog message ID you are rate limiting. For specific message numbers, see Cisco ASA
Series Syslog Messages.
• 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 6 Click OK.

Step 7 Click Save.
Configure Syslog Settings

You can configure general syslog settings to set the facility code to be included in syslog messages that are
sent to syslog servers, specify whether a timestamp is included in each message, specify the device ID to
include in messages, view and modify the severity levels for messages, and disable the generation of specific
messages.
If you are configuring devices to send syslog messages about security events (such as connection and intrusion
events), some settings on this page do not apply to these messages. See FTD Platform Settings That Apply
Procedure
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 2712.
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.

1462
Configure a Syslog Server
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.
b) To add a rule, click Add.

c) You select the message number whose configuration you want to change, from the Syslog ID drop down
list and then select the new severity level from the Logging Level drop down list, or select Suppressed
to disable the generation of the message. Typically, you would not change the severity level and disable
the message, but you can make changes to both fields if desired.
d) Click OK to add the rule to the table.
Step 8 Click Save.
What to do next
Related Topics
FTD Platform Settings That Apply to Security Event Syslog Messages, on page 1457

To configure a syslog server to handle messages generated from your system, perform the following steps.
If you want this syslog server to receive security events such as connection and intrusion events, see also FTD
Platform Settings That Apply to Security Event Syslog Messages, on page 1457.
Before you begin

• See requirements in Guidelines for Logging, on page 1455.

1463
• Make sure your devices can reach your syslog collector on the network.
Procedure
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: Send syslogs out of the Management interface. 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.
f) Click OK.

1464
Configure Global Timeouts
Step 6 Click Save.

What to do next

You can set the global idle timeout durations for the connection and translation slots of various protocols. If
the slot has not been used for the idle time specified, the resource is returned to the free pool.
You can also set a time out for console sessions with the device.
Procedure
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. A connection is considered
half-closed if both the FIN and FIN-ACK have been seen. If only the FIN has been seen, the regular
connection timeout applies. 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.

1465
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 system 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).
Step 4 Click Save.


1466
Configure NTP Time Synchronization for Threat Defense
Configure NTP Time Synchronization for Threat Defense

Use a Network Time Protocol (NTP) server to synchronize the clock settings on your devices. We recommend
you configure all FTDs managed by an FMC to use the same NTP server as the FMC. The FTD gets its time
directly from the configured NTP server. If the FTD's configured NTP servers are not reachable for any reason,
it synchronizes its time with the FMC.
The device supports NTPv4.
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.
Before you begin

• If your organization has one or more NTP servers that your FTD can reach, use the same NTP server or
servers for your devices that you have configured for Time Synchronization on the System >
Configuration page on your FMC.
• If you selected Use the authenticated NTP server only when configuring NTP server or servers for the
FMC, for your devices use only the NTP server or servers that are configured to authenticate with the
FMC. (The managed devices will use the same NTP servers as the FMC, but their NTP connections will
not use authentication.)
• If your device cannot reach an NTP server or your organization does not have one, you must use the Via
NTP from Defense Center option as discussed in the following procedure.
Procedure
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 IPv4 or IPv6 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.

1467
Configure Device Time Zone for Policy Application
Step 4 Click Save.
What to do next
• Make sure the policy is assigned to your devices. See Setting Target Devices for a Platform Settings
• 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 1421.
Configure Device Time Zone for Policy Application

By default, the system uses the UTC time zone. To designate a different time zone for a device, use this
procedure.
The time zone you specify will be used only for time-based policy application in policies that support this
functionality.
Procedure
You can also create time zone objects from the Objects > Object Management > Time Zone page.
Step 2 Create a new time zone object by clicking +.

Step 3 Select the time zone.
Step 4 Click Save.
What to do next
• Make sure the policy is assigned to your devices. See Setting Target Devices for a Platform Settings
• 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.

1468
History for Firepower Threat Defense Platform Settings

Platform settings using the MD5 7.0 The MD5 authentication algorithm and DES encryption for SNMPv3 users on
authentication algorithm or DES Firepower Threat Defense were deprecated in Version 6.5. If your deployment
encryption for SNMPv3 users includes SNMPv3 users using the MD5 authentication algorithm or DES encryption
can not be deployed to that were created using a version previous to 6.5, you can continue to use those
FTDdevices running Versions users for FTDs running versions previous to 7.0. However, you cannot edit those
7.0+ users and retain the MD5 or DES settings, and you cannot create new users with
the MD5 or DES settings. If your FMC manages any FTDs running Versions 7.0+,
.
deploying a platform settings policy with SNMP v3 users using the MD5
authentication algorithm or DES encryption to those FTDs will fail.
Devices > Platform Settings > SNMP > Hosts
Specify SHA224 or SHA384 for 7.0 You can now select SHA224 or SHA384 for SNMPv3 users' authorization
SNMPv3 users' authorization algorithm.
algorithm
Devices > Platform Settings > SNMP > Users
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
Specify the Management 6.6 You can now select the Management interface for communication between the
interface for SNMP device and the SNMP management station.
communication
Devices > Platform Settings > SNMP > Hosts
Specify SHA256 for SNMPv3 6.6 You can now select SHA256 for SNMPv3 users' authorization algorithm.
users' authorization algorithm

1469
DES encryption and the MD5 6.5 We recommend that you not use the MD5 authentication algorithm or DES
authentication algorithm for encryption for SNMPv3 users on Firepower Threat Defense devices, as these
SNMPv3 users on Threat options have been deprecated. If your deployment includes SNMPv3 users using
Defense have been deprecated the MD5 authentication algorithm or DES encryption that were created using a
version previous to 6.5, you can continue to use those users. However, you cannot
edit those users and retain the MD5 or DES settings, and you cannot create new
users with the MD5 or DES settings.
DES encryption and the MD5 6.4 We recommend that you not use the MD5 authentication algorithm or DES
authentication algorithm for encryption for SNMPv3 users on Firepower Threat Defense devices, as these will
SNMPv3 users on Threat be deprecated in a future Firepower version.
Defense will soon be deprecated
Limit number of SSH login 6.3 When a user accesses any device via SSH and fails three successive login attempts,
failures the device terminates the SSH session.
External Authentication added 6.2.3 You can now configure external authentication for SSH access to the Firepower
for SSH Threat Defense using LDAP or RADIUS.
Devices > Platform Settings > External Authentication
Support for UC/APPL 6.2.1 You can enable security certifications compliance in CC mode or UCAPL mode.
compliance 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.
Devices > Platform Settings > UC/APPL Compliance
Supported platforms: Any device

1470
SSL settings for remote access 6.2.1 The Firepower Threat Defense device uses the Secure Sockets Layer (SSL) protocol
VPN 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.
Devices > Platform Settings > SSL
External Authentication for SSH 6.1.0 Due to changes to support converged management access, only local users are
and HTML removed 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.
Devices > Platform Settings > External Authentication
Firepower Threat Defense 6.0.1 This feature was introduced.

support
Devices > Platform Settings

1471

1472
CHAPTER 57
Security Certifications Compliance
The following topics describe how to configure your system to comply with security certifications standards:
• Security Certifications Compliance Modes, on page 1473
• Security Certifications Compliance Characteristics, on page 1474
• Security Certifications Compliance Recommendations, on page 1475
• Enable Security Certifications Compliance, on page 1478
Security Certifications Compliance Modes

Your organization might be required to use only equipment and software complying with security standards
established by the U.S. Department of Defense and global certification organizations. Firepower supports
compliance with the following security certifications standards:
• Common Criteria (CC): a global standard established by the international Common Criteria Recognition
Arrangement, defining properties for security products
• Unified Capabilities Approved Products List (UCAPL): a list of products meeting security requirements
established by the U.S. Defense Information Systems Agency (DISA)
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.

1473
Security Certifications Compliance Characteristics
Security Certifications Compliance Characteristics

The following table describes behavior changes when you enable CC or UCAPL mode. (Restrictions on login
accounts refers to command line access, not web interface access. )
System Change Firepower Management Classic Managed Firepower Threat

Center Devices Defense
CC Mode UCAPL CC Mode UCAPL CC Mode UCAPL

Mode Mode Mode
FIPS compliance is enabled. Yes Yes Yes Yes Yes Yes
The system does not allow remote storage for Yes Yes — — — —
backups or reports.
The system starts an additional system audit daemon. No Yes No Yes No No
The system boot loader is secured. No Yes No Yes No No
The system applies additional security to login No Yes No Yes No No

accounts.
The system disables the reboot key sequence No Yes No Yes No No

Ctrl+Alt+Del.
The system enforces a maximum of ten simultaneous No Yes No Yes No No

login sessions.
Passwords must be at least 15 characters long, and No Yes No Yes No No

must consist of alphanumeric characters of mixed
case and must include at least one numeric character.
The minimum required password length for the local No No No No Yes Yes
admin user can be configured using the local device
CLI.
Passwords cannot be a word that appears in a No Yes No Yes No No

dictionary or include consecutive repeating
characters.
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 system stores password history by default. No Yes No Yes No No
The admin user can be locked out after a maximum Yes Yes Yes Yes — —
number of failed login attempts configurable through
the web interface.

1474
Security Certifications Compliance Recommendations
System Change Firepower Management Classic Managed Firepower Threat

Center Devices Defense
CC Mode UCAPL CC Mode UCAPL CC Mode UCAPL

Mode Mode Mode
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.
Security Certifications Compliance Recommendations

Cisco recommends that you observe the following best practices when using a system with security certifications
compliance enabled:
• To enable security certifications compliance in your deployment, enable it first on the Firepower
Management Center, then enable it in the same mode on all managed devices.
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.

1475
Appliance Hardening
• Do not configure the system to use any of the following features:

• Email reports, alerts, or data pruning notifications.
• Nmap Scan, Cisco IOS Null Route, Set Attribute Value, or ISE EPS remediations.
• Remote storage for backups or reports.
• Third-party client access to the system database.
• External notifications or alerts transmitted via email (SMTP), SNMP trap, or syslog.
• Audit log messages transmitted to an HTTP server or to a syslog server without using SSL certificates
to secure the channel between the appliance and the server.
• 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 SSO in deployments using CC 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 157
• User Accounts for FMC, on page 53
• Logging into the Firepower System, on page 29
• Time and Time Synchronization, on page 1389
• Configure NTP Time Synchronization for Threat Defense, on page 1467

1476
Protecting Your Network
• Creating an Email Alert Response, on page 2637

• Configuring Email Alerting for Intrusion Events, on page 2646
• Configure SMTP, on page 1442
• About SNMP for the Firepower 1000/2100 Series, on page 893
• Configure SNMP for Threat Defense, on page 1443
• Creating an SNMP Alert Response, on page 2633
• Configure Dynamic DNS, on page 886
• DNS Cache, on page 1384
• Security Certifications Compliance, on page 1473
• Configuring SSH for Remote Storage, on page 1372
• HTTPS Certificates, on page 1349
• Customize User Roles for the Web Interface, on page 126
• Add an Internal User, on page 59
• Session Timeouts, on page 1397
• About Configuring Syslog, on page 1450
• Schedule FMC Backups, on page 296
• Site-to-Site VPNs for Firepower Threat Defense, on page 1135
• Remote Access VPNs for Firepower Threat Defense, on page 1159
• FlexConfig Policies for Firepower Threat Defense, on page 1277
Protecting Your Network

See the following topics to learn about Firepower System features you can configure to protect your network:
• Access Control Policies, on page 1617
• Blocking Traffic with Security Intelligence, on page 1685
• Getting Started with Intrusion Policies, on page 1967
• Tuning Intrusion Policies Using Rules, on page 1977
• The Intrusion Rules Editor, on page 2031
• Update Intrusion Rules, on page 241
• Globally Limiting Intrusion Event Logging, on page 2025

1477
Enable Security Certifications Compliance
• Transport & Network Layer Preprocessors, on page 2265

• Detecting Specific Threats, on page 2301
• Application Layer Preprocessors, on page 2185
• IPS Device Deployments and Configuration, on page 735
• Working with Intrusion Events, on page 2849
• Searching for Events, on page 2771
• Workflows, on page 2725
• Device Management Basics, on page 341
• Login Banners, on page 1387
• System Updates, on page 231

This configuration applies to either a Firepower Management Center or managed device:
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a managed device, you apply this configuration from the FMC as part of a platform settings policy.
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.
Before you begin

• We recommend you register all devices that you plan to be part of your deployment to the FMC before
enabling security certifications compliance on any appliances.
• Firepower Threat Defense devices cannot use an evaluation license; your Cisco Smart Software Manager
account must be enabled for export-controlled features.
• Firepower Threat Defense devices must be deployed in routed mode.
• You must be an Admin user to perform this task.
Procedure
Step 1 Depending on whether you are configuring an FMC or a managed device:

1478
• FMC: Choose System > Configuration.

• Classic device: Choose Devices > Platform Settings and create or edit a Firepower policy.
• FTD device: Choose Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Click UCAPL/CC Compliance.

Note Appliances reboot when you enable UCAPL or CC compliance. The FMC reboots when you save
the system configuration; managed devices reboot when you deploy configuration changes.
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.
Step 4 Click Save.
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.

1479

1480
PA R T XIII
Network Address Translation (NAT)
• NAT Policy Management, on page 1483
• Network Address Translation (NAT) for Firepower Threat Defense, on page 1489
CHAPTER 58
NAT Policy Management
The following topics describe how to manage NAT policies for your Firepower System:
• Requirements and Prerequisites for NAT Policies, on page 1483
• Managing NAT Policies, on page 1483
• Creating NAT Policies, on page 1484
• Configuring NAT Policies, on page 1485
• Configuring NAT Policy Targets, on page 1486
• Copying NAT Policies, on page 1487
Requirements and Prerequisites for NAT Policies

Model Support
Any, but you must select the correct type of policy for the device model:
• Threat Defense NAT for FTD devices.
Supported Domains
Any
User Roles
Admin
Access Admin
Network Admin
Managing NAT Policies


1483
Creating NAT Policies
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.
Procedure
Step 1 Choose Devices > NAT .

Step 2 Manage your NAT policies:
• Copy — Click Copy ( ) next to the policy you want to copy; see Copying NAT Policies, on page 1487.
• Create — Click New Policy; see Creating NAT Policies, on page 1484.
• 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 535.
• Edit — Click Edit ( ); see Configuring NAT Policies, on page 1485.
• Report—Click Report ( ); see Generating Current Policy Reports, on page 551.
Creating NAT Policies

When you create a new NAT policy you must, at minimum, give it a unique name. Although you are not
required to identify policy targets at policy creation time, you must perform this step before you can deploy
the policy. If you apply a NAT policy with no rules to a device, the system removes all NAT rules from that
device.

1484
Configuring NAT Policies
Procedure

Step 2 From the New Policy drop-down list, choose Threat Defense NAT.
Step 3 Enter a unique Name.
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.

Step 5 Choose the devices where you want to deploy the policy:
• Choose a device in the Available Devices list, and click Add to Policy.
• Click and drag a device from the Available Devices list to the Selected Devices list.
• Remove a device from the Selected Devices list by clicking Delete ( ) next to the device.
Step 6 Click Save.
What to do next
Configuring NAT Policies

If you change the type of an interface to a type that is not valid for use with a NAT policy that targets a device
with that interface, the policy labels the interface as deleted. Click Save in the NAT policy to automatically
remove the interface from the policy.
Procedure

Step 2 Click Edit ( ) next to the NAT policy you want to modify.
Step 3 Configure your NAT policies:

1485
Configuring NAT Policy Targets
• To modify the policy name or description, click the Name or Description field, delete any characters as
needed, then enter the new name or description. 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.
• To manage policy targets, see Configuring NAT Policy Targets, on page 1486.
• To save your policy changes, click Save.
• To add a rule to a policy, click Add Rule.
• To edit an existing rule, click Edit ( ) next to the rule.
• To delete a rule, click Delete ( ) next to the rule, then click OK.
• 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
Configuring NAT Policy Targets

You can identify the managed devices you want to target with your policy while creating or editing a policy.
You can search a list of available devices and high-availability pairs, and add them to a list of selected devices.
Procedure

Step 2 Click Edit ( ) next to the NAT policy you want to modify.
Step 3 Click Policy Assignments.

list and click Add to Policy. You can also drag and drop.

1486
Copying NAT Policies
Step 5 Click OK.
What to do next

You can make a copy of a NAT policy. The copy includes all policy rules and configurations.
In a multidomain deployment, you can copy policies from current and ancestor domains.
Procedure
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.
Step 4 Click OK.

1487

1488
CHAPTER 59
Network Address Translation (NAT) for
The following topics explain Network Address Translation (NAT) and how to configure it on Firepower
Threat Defense devices.
• Why Use NAT?, on page 1489
• NAT Basics, on page 1490
• Guidelines for NAT, on page 1498
• Configure NAT for Threat Defense, on page 1503
• Translating IPv6 Networks, on page 1540
• Monitoring NAT, on page 1553
• Examples for NAT, on page 1554
• History for FTD NAT, on page 1597
Why Use NAT?

Each computer and device within an IP network is assigned a unique IP address that identifies the host. Because
of a shortage of public IPv4 addresses, most of these IP addresses are private, not routable anywhere outside
of the private company network. RFC 1918 defines the private IP addresses you can use internally that should
not be advertised:
• 10.0.0.0 through 10.255.255.255
• 172.16.0.0 through 172.31.255.255
• 192.168.0.0 through 192.168.255.255
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.

1489
NAT Basics
• 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.
• Bidirectional initiation—Static NAT allows connections to be initiated bidirectionally, meaning both to

the host and from the host.
• Source and destination NAT—For any given packet, both the source and destination IP addresses are
compared to the NAT rules, and one or both can be translated/untranslated. 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.
NAT Types
You can implement NAT using the following methods:

1490
NAT in Routed and Transparent Mode
• 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 1507.
• 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 1513.
• Static NAT—A consistent mapping between a real and mapped IP address. Allows bidirectional traffic
initiation. See Static NAT, on page 1522.
• 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 1531.
NAT in Routed and Transparent Mode

You can configure NAT in both routed and transparent firewall mode. You cannot configure NAT for interfaces
operating in inline, inline tap, or passive modes. The following sections describe typical usage for each firewall
mode.
NAT in Routed Mode

The following figure shows a typical NAT example in routed mode, with a private network on the inside.
Figure 47: NAT Example: Routed Mode
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.

1491
NAT in Transparent Mode or Within a Bridge Group
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.
NAT in Transparent Mode or Within a Bridge Group

Using NAT in transparent mode eliminates the need for the upstream or downstream routers to perform NAT
for their networks. It can perform a similar function within a bridge group in routed mode.
NAT in transparent mode, or in routed mode between members of the same bridge group, has the following
requirements and limitations:
• You cannot configure interface PAT when the mapped address is a bridge group member interface,
because there is no IP address attached to the interface.
• ARP inspection is not supported. Moreover, if for some reason a host on one side of the Firepower Threat
Defense device sends an ARP request to a host on the other side of the Firepower Threat Defense device,
and the initiating host real address is mapped to a different address on the same subnet, then the real
address remains visible in the ARP request.
• Translating between IPv4 and IPv6 networks is not supported. Translating between two IPv6 networks,
or between two IPv4 networks is supported.
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.

1492
Auto NAT and Manual NAT
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 and Manual NAT

You can implement address translation in two ways: auto NAT and manual NAT.
We recommend using auto NAT unless you need the extra features that manual NAT provides. It is easier to
configure auto NAT, and it might be more reliable for applications such as Voice over IP (VoIP). (For VoIP,
you might see a failure in the translation of indirect addresses that do not belong to either of the objects used
in the rule.)
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.

1493
Comparing Auto NAT and Manual NAT
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.
Comparing Auto NAT and Manual NAT

The main differences between these two NAT types are:
• How you define the real address.
• Auto NAT—The NAT rule becomes a parameter for a network object. The network object IP address
serves as the original (real) address.
• Manual NAT—You identify a network object or network object group for both the real and mapped
addresses. In this case, NAT is not a parameter of the network object; the network object or group
is a parameter of the NAT configuration. The ability to use a network object group for the real
address means that manual NAT is more scalable.
• How source and destination NAT is implemented.

• Auto NAT— Each rule can apply to either the source or destination of a packet. So two rules might
be used, one for the source IP address, and one for the destination IP address. These two rules cannot
be tied together to enforce a specific translation for a source/destination combination.
• Manual NAT—A single rule translates both the source and destination. A packet matches one rule
only, and further rules are not checked. Even if you do not configure the optional destination address,
a matching packet still matches one manual NAT rule only. The source and destination are tied
together, so you can enforce different translations depending on the source/destination combination.
For example, sourceA/destinationA can have a different translation than sourceA/destinationB.
• Order of NAT Rules.

• Auto NAT—Automatically ordered in the NAT table.
• Manual NAT—Manually ordered in the NAT table (before or after auto NAT rules).
NAT Rule Order

Auto NAT and manual NAT rules are stored in a single table that is divided into three sections. Section 1
rules are applied first, then section 2, and finally section 3, until a match is found. For example, if a match is
found in section 1, sections 2 and 3 are not evaluated. The following table shows the order of rules within
each section.

1494
NAT Rule Order
Table 120: NAT Rule Table
Table Section Rule Type Order of Rules within the Section
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.
If you cannot eliminate overlapping rules, where more than one

rule might apply based on the source or destination address, be
especially careful to follow these recommendations.
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.
Within each rule type, the following ordering guidelines are

used:
1. Quantity of real IP addresses—From smallest to largest. For
example, an object with one address will be assessed before
an object with 10 addresses.
2. For quantities that are the same, then the IP address number
is used, from lowest to highest. For example, 10.1.1.0 is
assessed before 11.1.1.0.
3. If the same IP address is used, then the name of the network
object is used, in alphabetical order. For example, abracadabra
is assessed before catwoman.
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)

1495
NAT Interfaces
• 192.168.1.1/32 (static)
• 172.16.1.0/24 (dynamic) (object def)
• 172.16.1.0/24 (dynamic) (object abc)
The resultant ordering would be:

• 192.168.1.1/32 (static)
• 10.1.1.0/24 (static)
• 192.168.1.0/24 (static)
• 172.16.1.0/24 (dynamic) (object abc)
• 172.16.1.0/24 (dynamic) (object def)
• 192.168.1.0/24 (dynamic)
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.

1496
Configuring Routing for NAT
Configuring Routing for NAT

The FTD device needs to be the destination for any packets sent to the translated (mapped) address.
When sending packets, the device uses the destination interface if you specify one, or a routing table lookup
if you do not, to determine the egress interface. For identity NAT, you have the option to use a route lookup
even if you specify a destination interface.
The type of routing configuration needed depends on the type of mapped address, as explained in the following
topics.
Addresses on the Same Network as the Mapped Interface

If you use addresses on the same network as the destination (mapped) interface, the Firepower Threat Defense
device 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 Firepower Threat Defense device does not
have to be the gateway for any additional networks. This solution is ideal if the outside network contains an
adequate number of free addresses, a consideration if you are using a 1:1 translation like dynamic NAT or
static NAT. Dynamic PAT greatly extends the number of translations you can use with a small number of
addresses, so even if the available addresses on the outside network is small, this method can be used. For
PAT, you can even use the IP address of the mapped 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.
Addresses on a Unique Network

If you need more addresses than are available on the destination (mapped) interface network, you can identify
addresses on a different subnet. The upstream router needs a static route for the mapped addresses that points
to the Firepower Threat Defense device.
Alternatively for routed mode, you can configure a static route on the Firepower Threat Defense device for
the mapped addresses using any IP address on the destination network as the gateway, and then redistribute
the route using your routing protocol. For example, if you use NAT for the inside network (10.1.1.0/24) and
use the mapped IP address 209.165.201.5, then you can configure a static route for 209.165.201.5
255.255.255.255 (host address) to the 10.1.1.99 gateway that can be redistributed.
For transparent mode, if the real host is directly-connected, configure the static route on the upstream router
to point to the Firepower Threat Defense device: specify the bridge group IP address. For remote hosts in
transparent mode, in the static route on the upstream router, you can alternatively specify the downstream
router IP address.
The Same Address as the Real Address (Identity NAT)

The default behavior for identity NAT has proxy ARP enabled, matching other static NAT rules. You can
disable proxy ARP if desired. You can also disable proxy ARP for regular static NAT if desired, in which
case you need to be sure to have proper routes on the upstream router.

1497
Guidelines for NAT
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.
Guidelines for NAT

The following topics provide detailed guidelines for implementing NAT.
Firewall Mode Guidelines for NAT

NAT is supported in routed and transparent firewall mode.
However, configuring NAT on bridge group member interfaces (interfaces that are part of a Bridge Group
Virtual Interface, or BVI) has the following restrictions:
• 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.
• You cannot configure interface PAT when the mapped address is a bridge group member interface,
because there is no IP address attached to the interface.
• You cannot translate between IPv4 and IPv6 networks (NAT64/46) when the source and destination
interfaces are members of the same bridge group. Static NAT/PAT 44/66, dynamic NAT44/66, and
dynamic PAT44 are the only allowed methods; dynamic PAT66 is not supported. However, you can do
NAT64/46 between members of different bridge groups, or between a bridge group member (source)
and standard routed interface (destination).
Note You cannot configure NAT for interfaces operating in inline, inline tap, or passive modes.
IPv6 NAT Guidelines

NAT supports IPv6 with the following guidelines and restrictions.
• For standard routed mode interfaces, you can also translate between IPv4 and IPv6.
• You cannot translate between IPv4 and IPv6 for interfaces that are members of the same bridge group.
You can translate between two IPv6 or two IPv4 networks only. 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.

1498
IPv6 NAT Best Practices
• 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.
IPv6 NAT Best Practices

You can use NAT to translate between IPv6 networks, and also to translate between IPv4 and IPv6 networks
(routed mode only). We recommend the following best practices:
• NAT66 (IPv6-to-IPv6)—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. If you do not want
to allow returning traffic, you can make the static NAT rule unidirectional (manual NAT only).
• NAT46 (IPv4-to-IPv6)—We recommend using static NAT. Because the IPv6 address space is so much
larger than the IPv4 address space, you can easily accommodate a static translation. If you do not want
to allow returning traffic, you can make the static NAT rule unidirectional (manual NAT only). When
translating to an IPv6 subnet (/96 or lower), the resulting mapped address is by default an IPv4-embedded
IPv6 address, where the 32-bits of the IPv4 address is embedded after the IPv6 prefix. For example, if
the IPv6 prefix is a /96 prefix, then the IPv4 address is appended in the last 32-bits of the address. For
example, if you map 192.168.1.0/24 to 201b::0/96, then 192.168.1.4 will be mapped to 201b::0.192.168.1.4
(shown with mixed notation). If the prefix is smaller, such as /64, then the IPv4 address is appended after
the prefix, and a suffix of 0s is appended after the IPv4 address. You can also optionally translate the
addresses net-to-net, where the first IPv4 address maps to the first IPv6 address, the second to the second,
and so on.
• NAT64 (IPv6-to-IPv4)—You may not have enough IPv4 addresses to accommodate the number of IPv6
addresses. We recommend using a dynamic PAT pool to provide a large number of IPv4 translations.
NAT Support for Inspected Protocols

Some application layer protocols that open secondary connections, or that embedded IP addresses in packets,
are inspected to provide the following services:
• Pinhole creation—Some application protocols open secondary TCP or UDP connections either on standard
or negotiated ports. Inspection opens pinholes for these secondary ports so that you do not need to create
access control rules to allow them.
• NAT rewrite— Protocols such as FTP embed IP addresses and ports for the secondary connections in
packet data as part of the protocol. If there is NAT translation involved for either of the endpoints, the
inspection engines rewrite the packet data to reflect the NAT translation of the embedded addresses and
ports. The secondary connections would not work without NAT rewrite.
• Protocol enforcement—Some inspections enforce some degree of conformance to the RFCs for the
inspected protocol.

1499
NAT Support for Inspected Protocols
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.
Table 121: NAT Supported Application Inspection
Application Inspected Protocol, Port NAT Limitations Pinholes Created
DCERPC TCP/135 No NAT64. Yes
DNS over UDP UDP/53 No NAT support is available for name resolution No
through WINS.
ESMTP TCP/25 No NAT64. No
FTP TCP/21 No limitations. Yes

(Clustering) No static PAT.
H.323 H.225 (Call TCP/1720 (Clustering) No static PAT. Yes

signaling)
UDP/1718 No extended PAT.
H.323 RAS
For RAS, No NAT64.
UDP/1718-1719
ICMP ICMP No limitations. No

ICMP Error (ICMP traffic directed to
a device interface is
never inspected.)
IP Options RSVP No NAT64. No
NetBIOS Name Server UDP/137, 138 (Source No extended PAT. No

over IP ports)
No NAT64.
RSH TCP/514 No PAT. Yes

No NAT64.
RTSP TCP/554 No extended PAT. Yes

(No handling for HTTP No NAT64.
cloaking.)

1500
Additional Guidelines for NAT
Application Inspected Protocol, Port NAT Limitations Pinholes Created
SIP TCP/5060 No extended PAT. Yes

UDP/5060 No NAT64 or NAT46.
Skinny (SCCP) TCP/2000 No extended PAT. Yes

No NAT64, NAT46, or NAT66.
SQL*Net TCP/1521 No extended PAT. Yes

(versions 1, 2) No NAT64.
Sun RPC TCP/111 No extended PAT. Yes

UDP/111 No NAT64.
TFTP UDP/69 No NAT64. Yes

Payload IP addresses are not translated.
XDMCP UDP/177 No extended PAT. Yes

No NAT64.

• For interfaces that are members of a bridge group, you write NAT rules for the member interfaces. You
cannot write NAT rules for the Bridge Virtual Interface (BVI) itself.
• You cannot write NAT rules for a Virtual Tunnel Interface (VTI), which are used in site-to-site VPN.
Writing rules for the VTI's source interface will not apply NAT to the VPN tunnel. To write NAT rules
that will apply to VPN traffic tunneled on a VTI, you must use "any" as the interface; you cannot explicitly
specify interface names.
• (Auto NAT only.) You can only define a single NAT rule for a given object; if you want to configure
multiple NAT rules for an object, you need to create multiple objects with different names that specify
the same IP address.
• If a VPN is defined on an interface, inbound ESP traffic on the interface is not subject to the NAT rules.
The system allows the ESP traffic for established VPN tunnels only, dropping traffic not associated with
an existing tunnel. This restriction applies to ESP and UDP ports 500 and 4500.
• If you define a site-to-site VPN on a device that is behind a device that is applying dynamic PAT, so that
UDP ports 500 and 4500 are not the ones actually used, you must initiate the connection from the device
that is behind the PAT device. The responder cannot initiate the security association (SA) because it does
not know the correct port numbers.

1501
• If you change the NAT configuration, and you do not want to wait for existing translations to time out
before the new NAT configuration is used, you can clear the translation table using the clear xlate
command in the device CLI. However, clearing the translation table disconnects all current connections
that use translations.
If you create a new NAT rule that should apply to an existing connection (such as a VPN tunnel), you
need to use clear conn to end the connection. Then, the attempt to re-establish the connection should hit
the NAT rule and the connection should be NAT'ed correctly.
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 or clear conn commands. 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.

1502
Configure NAT for Threat Defense
• 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 happens if you do not select the option to include the reserved ports (1-1023)
in the port range of a PAT pool. 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.
• Do not name a network object or group pat-pool, using any combination of upper- or lower-case letters.
• The unidirectional option is mainly useful for testing purposes and might not work with all protocols.
For example, SIP requires protocol inspection to translate SIP headers using NAT, but this will not occur
if you make the translation unidirectional.
• You cannot use NAT on the internal payload of Protocol Independent Multicast (PIM) registers.
Configure NAT for Threat Defense

Network address translation can be very complex. We recommend that you keep your rules as simple as
possible to avoid translation problems and difficult troubleshooting situations. Careful planning before you
implement NAT is critical. The following procedure provides the basic approach.
The NAT policy is a shared policy. You assign the policy to devices that should have similar NAT rules.
Whether a given rule in the policy applies to an assigned device is determined by the interface objects (security
zones or interface groups) used in the rule. If the interface objects include one or more interface for the device,
the rule is deployed to the device. Thus, you can configure rules that apply to subsets of devices within a
single shared policy by carefully designing your interface objects. Rules that apply to “any” interface object
are deployed to all devices.
You can configure multiple NAT policies if groups of your devices require significantly different rules.
Procedure
Step 1 Select Devices > NAT.

• Click New Policy > Threat Defense NAT to create a new policy. Give the policy a name, optionally
assign devices to it, and click Save.
You can change device assignments later by editing the policy and clicking Policy Assignments.
• 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.
Step 2 Decide what kinds of rules you need.

You can create dynamic NAT, dynamic PAT, static NAT, and identity NAT rules. For an overview, see NAT
Types, on page 1490.

1503
Customizing NAT Rules for Multiple Devices
Step 3 Decide which rules should be implemented as manual or auto NAT.

For a comparison of these two implementation options, see Auto NAT and Manual NAT, on page 1493.
Step 4 Decide which rules should be custom per device.

Because you can assign a NAT policy to multiple devices, you can configure a single rule on many devices.
However, you might have rules that should be interpreted differently by each device, or some rules that should
apply to a subset of devices only.
Use interface objects to control on which devices a rule is configured. Then, use object overrides on network
objects to customize the addresses used per device.
For detailed information, see Customizing NAT Rules for Multiple Devices, on page 1504.
Step 5 Create the rules as explained in the following sections.

• Dynamic NAT, on page 1507
• Dynamic PAT, on page 1513
• Static NAT, on page 1522
• Identity NAT, on page 1531
Step 6 Manage the NAT policy and rules.

You can do the following to manage the policy and its rules.
• To edit the policy name or description, click in those fields, type in your changes, and click outside the
fields.
• To view only those rules that apply to a specific device, click Filter by Device and select the desired
device. A rule applies to a device if it uses an interface object that includes an interface on the device.
• To change the devices to which the policy is assigned, click the Policy Assignments link and modify
the selected devices list as desired.
• To change whether a rule is enabled or disabled, right click the rule and select the desired option from
the State command. You can temporarily disable a rule without deleting it using these controls.
• To edit a rule, click Edit ( ) for the rule.
• To delete a rule, click Delete ( ) for the rule.
Step 7 Click Save.


Because the NAT policy is shared, you can assign a given policy to more than one device. However, you can
configure at most one auto NAT rule for a given object. Thus, if you want to configure different translations

1504
for an object based on the specific device doing the translation, you need to carefully configure the interface
objects (security zones or interface groups) and define network object overrides for the translated address.
The interface objects determine on which devices a rule gets configured. The network object overrides
determine what IP addresses are used by a given device for that object.
Consider the following scenario:
• FTD-A and FTD-B have inside networks 192.168.1.0/24 attached to the interface named “inside.”
• On FTD-A, you want to translate all 192.168.1.0/24 addresses to a NAT pool in the 10.100.10.10 -
10.100.10.200 range when going to the “outside” interface.
• On FTD-B, you want to translate all 192.168.1.0/24 addresses to a NAT pool in the 10.200.10.10 -
10.200.10.200 range when going to the “outside” interface.
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.
Procedure
Step 1 Create the security zones for the inside and outside interfaces.
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.

1505
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.
c) Select Allow Overrides.

d) Click the Overrides heading to open the list of object overrides.
e) Click Add to open the Add Object Override dialog box.
f) Select FTD-B and Add it to the Selected Devices list.
g) Click Override and change Network to 10.200.10.10-10.200.10.200
h) Click Add to add the override to the device.
By defining an override for FTD-B, whenever the system configures this object on FTD-B, it will use the
override value instead of the value defined in the original object.
i) Click Save.
Step 4 Configure the NAT rule.
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.
d) On Interface Objects, configure the following:

• Source Interface Objects = inside-zone.
• Destination Interface Objects = outside-zone.
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.
e) On Translation, configure the following:

• Original Source = inside-network object.
• Translated Source > Address= NAT-pool object.
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.

1506
Searching and Filtering the NAT Rule Table
Searching and Filtering the NAT Rule Table

You can search and filter the NAT rule table to help you find rules that you need to modify or view. When
you filter the table, only matching rules are shown. Note that although the rule numbers change to be
sequentially 1, 2, and so forth, filtering does not change the actual rule number or the rule’s location in the
table relative to hidden rules. Filtering simply changes what you can see to help you locate rules that interest
you.
When editing the NAT policy, you can use the fields above the table to do the following types of search/filter:
• Filter by Device—Click Filter by Device, then select the devices whose rules you want to see and click
OK. Whether a rule applies to a device is determined by the rule's interface constraints. If you specify
a security zone or interface group for either the source or destination interface, the rule applies to a device
if at least one interface for the device is in the zone or group. If a NAT rule applies to any source and
any destination interface, then it applies to all devices.
If you also do a text or multiple-attribute search, the results are constrained to the selected devices.
To remove this filter, click Filter by Device and deselect the devices, or select All, and click OK.
• Simple Text Search—In the Filter box, type a string and press Enter. The string is compared to all
values in the rules. For example, if you enter “network-object-1,” which is the name of a network object,
you would get rules that use the object in source, destination, and PAT pool attributes.
For network and port objects, the string is also compared to the contents of the objects used in the rule.
For example, if a PAT pool object includes the range 10.100.10.3-10.100.10.100, searching on either
10.100.10.3 or 10.100.10.100 (or a partial 10.100.10) will include rules that use that PAT pool object.
However, the match must be exact: searching on 10.100.10.5 will not match this PAT pool object, even
though the IP address is within the object’s IP address range.
To remove the filter, click the x on the right side of the Filter box.
• Multiple-Attribute Search—If a simple text search gives you too many hits, you can configure multiple
values for the search. Click in the Filter box to open the list of attributes, then select or enter strings for
the attributes you intend to search and click the Filter button. These attributes are the same as the ones
you would configure within a NAT rule. The attributes are AND’ed, so filtered results include only those
rules that match all attributes you configured.
• For binary attributes, such as the rule state (enabled/disabled), whether a PAT pool is configured
(enabled/disabled), the direction of the rule (uni/bi), or rule type (static/dynamic), simply check or
uncheck the boxes as appropriate. Select both boxes if you do not care about the attribute value. If
you deselect both boxes, no rules will match the filter.
• For string attributes, type a full or partial string relevant to that attribute. These will be object names,
either for security zones/interface groups, network objects, or port objects. It can also be the network
or port object contents, which are matched the same way they are for simple text searches.
To remove the filter, click the x on the right side of the Filter box, or click in the Filter box to open the
drop-down list, and click the Clear button.
Dynamic NAT
The following topics explain dynamic NAT and how to configure it.

1507
About Dynamic NAT
About Dynamic NAT

Dynamic NAT translates a group of real addresses to a pool of mapped addresses that are routable on the
destination network. The mapped pool typically includes fewer addresses than the real group. When a host
you want to translate accesses the destination network, NAT assigns the host an IP address from the mapped
pool. The translation is created only when the real host initiates the connection. The translation is in place
only for the duration of the connection, and a given user does not keep the same IP address after the translation
times out. Users on the destination network, therefore, cannot initiate a reliable connection to a host that uses
dynamic NAT, even if the connection is allowed by an access rule.
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.

1508
Dynamic NAT Disadvantages and Advantages
Figure 51: Remote Host Attempts to Initiate a Connection to a Mapped Address
Dynamic NAT Disadvantages and Advantages

Dynamic NAT has these disadvantages:
• If the mapped pool has fewer addresses than the real group, you could run out of addresses if the amount
of traffic is more than expected.
Use PAT or a PAT fall-back method if this event occurs often because PAT provides over 64,000
translations using ports of a single address.
• You have to use a large number of routable addresses in the mapped pool, and routable addresses may
not be available in large quantities.
The advantage of dynamic NAT is that some protocols cannot use PAT. PAT does not work with the following:
• IP protocols that do not have a port to overload, such as GRE version 0.
• Some multimedia applications that have a data stream on one port, the control path on another port, and
are not open standard.
Configure Dynamic Auto NAT

Use dynamic auto NAT rules to translate addresses to different IP addresses that are routable on the destination
network.
Before you begin

Select Objects > Object Management and create the network objects or groups needed in the rule.
Alternatively, you can create the objects while defining the NAT rule. The objects must meet the following
requirements:
• Original Source—This must be a network object (not a group), and it can be a host, range, or subnet.

1509
Configure Dynamic Auto NAT
• Translated Source—This can be a network object or group, but it cannot include a subnet. The group
cannot contain both IPv4 and IPv6 addresses; it must contain one type only. If a group contains both
ranges and host IP addresses, then the ranges are used for dynamic NAT, and then the host IP addresses
are used as a PAT fallback.
Procedure
Step 1 Select Devices > NAT and create or edit an FTD NAT policy.
• Click the Add Rule button to create a new rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Step 3 Configure the basic rule options:

• NAT Rule—Select Auto NAT Rule.
Step 4 On Interface Objects, configure the following options:

• 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.
Step 5 On Translation, configure the following options:

• Original Source—The network object that contains the addresses you are translating.
• Translated Source—The network object or group that contains the mapped addresses.
Step 6 (Optional.) On Advanced, select the desired options:

• Translate DNS replies that match this rule—Whether to translate the IP address in DNS replies. For
DNS replies traversing from a mapped interface to a real interface, the Address (the IPv4 A or IPv6
AAAA) record is rewritten 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 1583.
• 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.
Step 7 Click Save to add the rule.

Step 8 Click Save on the NAT page to save your changes.

1510
Configure Dynamic Manual NAT

Use dynamic manual NAT rules when auto NAT does not meet your needs. For example, if you want to do
different translations based on the destination. Dynamic NAT translates addresses to different IP addresses
that are routable on the destination network.
Before you begin

Select Objects > Object Management and create the network objects or groups needed in the rule. Groups
cannot contain both IPv4 and IPv6 addresses; they must contain one type only. Alternatively, you can create
the objects while defining the NAT rule. The objects must also meet the following requirements:
• Original Source—This can be a network object or group, and it can contain a host, range, or subnet. If
you want to translate all original source traffic, you can skip this step and specify Any in the rule.
• Translated Source—This can be a network object or group, but it cannot include a subnet. If a group
contains both ranges and host IP addresses, then the ranges are used for dynamic NAT, and then the host
IP addresses are used as a 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.
Procedure

• Type—Select Dynamic. This setting only applies to the source address. If you define a translation for
the destination address, the translation is always static.
• 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.


1511
interfaces.
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.

• (For source translation only.) Translate DNS replies that match this rule—Whether to translate the
IP address in DNS replies. For DNS replies traversing from a mapped interface to a real interface, the
Address (the IPv4 A or IPv6 AAAA) record is rewritten 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

1512
Dynamic PAT
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 1583.

Dynamic PAT
The following topics describe dynamic PAT.
About Dynamic PAT

Dynamic PAT translates multiple real addresses to a single mapped IP address by translating the real address
and source port to the mapped address and a unique port.
Each connection requires a separate translation session because the source port differs for each connection.
For example, 10.1.1.1:1025 requires a separate translation from 10.1.1.1:1026.
The following figure shows a typical dynamic PAT scenario. Only real hosts can create a NAT session, and
responding traffic is allowed back. The mapped address is the same for each translation, but the port is
dynamically assigned.
Figure 52: 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.

1513
Dynamic PAT Disadvantages and Advantages
Dynamic PAT Disadvantages and Advantages

Dynamic PAT lets you use a single mapped address, thus conserving routable addresses. You can even use
the Firepower Threat Defense device interface IP address as the PAT address.
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.
Dynamic PAT does not work with some multimedia applications that have a data stream that is different from
the control path. For more information, see NAT Support for Inspected Protocols, on page 1499.
Dynamic PAT might also create a large number of connections appearing to come from a single IP address,
and servers might interpret the traffic as a DoS attack. You can configure a PAT pool of addresses and use a
round-robin assignment of PAT addresses to mitigate this situation.
PAT Pool Object Guidelines

When creating network objects for a PAT pool, follow these guidelines.
For a PAT pool

• Ports are mapped to an available port in the 1024 to 65535 range. You can optionally include the reserved
ports, those below 1024, to make the entire port range available for translations.
When operating in a cluster, blocks of 512 ports per address are allocated to the members of the cluster,
and mappings are made within these port blocks. If you also enable block allocation, the ports are
distributed according to the block allocation size, whose default is also 512.
• If you enable block allocation for a PAT pool, port blocks are allocated in the 1024-65535 range only.
Thus, if an application requires a low port number (1-1023), it might not work. For example, an application
requesting port 22 (SSH) will get a mapped port within the range of 1024-65535 and within the block
allocated to the host.
• If you use the same PAT pool object in two separate rules, then be sure to specify the same options for
each rule. For example, if one rule specifies extended PAT, then the other rule must also specify extended
PAT.
For extended PAT for a PAT pool

• Many application inspections do not support extended PAT.
• 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.
• You cannot use extended PAT on units in a cluster.

1514
Configure Dynamic Auto PAT
For round robin for a PAT pool

• If a host has an existing connection, then subsequent connections from that host will use the same PAT
IP address if ports are available. However, this “stickiness” does not survive a failover. If the device fails
over, then subsequent connections from a host might not use the initial IP address.
• IP address “stickiness” is also impacted if you mix PAT pool/round robin rules with interface PAT rules
on the same interface. For any given interface, choose either a PAT pool or interface PAT; do not create
competing PAT rules.
• Round robin, especially when combined with extended PAT, can consume a large amount of memory.
Because NAT pools are created for every mapped protocol/IP address/port range, round robin results in
a large number of concurrent NAT pools, which use memory. Extended PAT results in an even larger
number of concurrent NAT pools.

Use dynamic auto PAT rules to translate addresses to unique IP address/port combinations, rather than to
multiple IP addresses only. You can translate to a single address (either the destination interface's address or
another address), or use a PAT pool of addresses to provide a larger number of possible translations.
Before you begin

requirements:
• Translated Source—You have the following options to specify the PAT address:
• Destination Interface—To use the destination interface address, you do not need a network object.
• Single PAT address—Create a network object containing a single host.
• PAT pool—Create a network object that includes a range, or create a network object group that
contains hosts, ranges, or both. You cannot include subnets. The group cannot contain both IPv4
and IPv6 addresses; it must contain one type only.
Procedure


1515

interfaces.

• 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.
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. (Pre-6.7) 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. For FTD devices running version 6.7 or higher, the flat port range is always
configured, whether you select the option or not. You can still select the Include Reserved Ports
option for these systems, and that setting is honored.

1516
Configure Dynamic Manual PAT
• 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.

bridge group. To use the IPv6 address of the interface, also check the IPv6 option. You cannot select
this option if you already configured interface PAT as the translated address or PAT pool.


Use dynamic manual PAT rules when auto PAT does not meet your needs. For example, if you want to do
different translations based on the destination. Dynamic PAT translates addresses to unique IP address/port
combinations, rather than to multiple IP addresses only. You can translate to a single address (either the
destination interface's address or another address), or use a PAT pool of addresses to provide a larger number
of possible translations.
Before you begin

• Translated Source—You have the following options to specify the PAT address:
• Single PAT address—Create a network object containing a single host.
• PAT pool—Create a network object that includes a range, or create a network object group that
contains hosts, ranges, or both. You cannot include subnets.
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.

1517
Procedure

• Type—Select Dynamic. This setting only applies to the source address. If you define a translation for
the destination address, the translation is always static.

interfaces.
for it.

1518
• (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.
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.
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. (Pre-6.7) 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

1519
Configure PAT with Port Block Allocation
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. For FTD devices running version 6.7 or higher, the flat port range is always
configured, whether you select the option or not. You can still select the Include Reserved Ports
option for these systems, and that setting is honored.
• 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 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). 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. Blocks are freed when the last xlate that
uses a port in the block is removed.
The main reason for allocating port blocks is reduced logging. The port block allocation is logged, connections
are logged, but xlates created within the port block are not logged. On the other hand, this makes log analysis
more difficult.
Port blocks are allocated in the 1024-65535 range only. Thus, if an application requires a low port number
(1-1023), it might not work. For example, an application requesting port 22 (SSH) will get a mapped port
within the range of 1024-65535 and within the block allocated to the host. You can create a separate NAT
rule that does not use block allocation for applications that use low port numbers; for twice NAT, ensure the
rule comes before the block allocation rule.
Before you begin

Usage notes for NAT rules:
• You can include the Use Round Robin Allocation option, but you cannot include the options for extending
PAT uniqueness, using a flat range, including the reserved ports, or falling through to interface PAT.
Other source/destination address and port information is also allowed.

1520
• As with all NAT changes, if you replace an existing rule, you must clear xlates related to the replaced
rule to have the new rule take effect. You can clear them explicitly or simply wait for them to time out.
When operating in a cluster, you must clear xlates globally across the cluster.
Note If you are switching between a regular PAT and block allocation PAT rule, for
object NAT, you must first delete the rule, then clear xlates. You can then create
the new object NAT rule. Otherwise, you will see pat-port-block-state-mismatch
drops in the show asp drop output.
• 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.
Procedure
Step 1 (Optional.) Configure global PAT port block allocation settings.

There are a few global settings that control port block allocation. If you want to change the defaults for these
options, you must configure a FlexConfig object and add it to your FlexConfig policy.
a) Select Objects > Object Management > FlexConfig > FlexConfig Object and create a new object.
b) Configure the block allocation size, which is the number of ports in each block.
xlate block-allocation size value
The range is 32-4096. The default is 512. Use the “no” form to return to the default.
If you do not use the default, ensure that the size you choose divides evenly into 64,512 (the number of
ports in the 1024-65535 range). Otherwise, there will be ports that cannot be used. For example, if you
specify 100, there will be 12 unused ports.
c) Configure the maximum blocks that can be allocated per host.
xlate block-allocation maximum-per-host number
The limit is per protocol, so a limit of 4 means at most 4 UDP blocks, 4 TCP blocks, and 4 ICMP blocks
per host. The range is 1-8, the default is 4. Use the “no” form to return to the default.
d) (Optional.) Enable interim syslog generation.
xlate block-allocation pba-interim-logging seconds
By default, the system generates syslog messages during port block creation and deletion. If you enable
interim logging, the system generates the following message at the interval you specify. The messages
report all active port blocks allocated at that time, including the protocol (ICMP, TCP, UDP) and source
and destination interface and IP address, and the port block. You can specify an interval from 21600-604800
seconds (6 hours to 7 days).
%ASA-6-305017: Pba-interim-logging: Active protocol block of ports for translation from
real_interface:real_host_ip to mapped_interface:mapped_ip_address/start_port_num-end_port_num
Example:

1521
Static NAT
The following example sets the block allocation size to 64, the per-host maximum to 8, and enables interim
logging every 6 hours.
xlate block-allocation size 64

xlate block-allocation maximum-per-host 8
xlate block-allocation pba-interim-logging 21600
e) Select the following options in the FlexConfig object:

• Deployment = Everytime
• Type = Append
f) Click Save to create the FlexConfig object.

g) Select Devices > FlexConfig, and create or edit the FlexConfig policy that is assigned to the devices that
need to have these settings adjusted.
h) Select your object in the available objects list and click > to move it to the selected objects list.
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.
c) Save your changes to the rule and to the NAT policy.
Static NAT
The following topics explain static NAT and how to implement it.
About Static NAT

Static NAT creates a fixed translation of a real address to a mapped address. Because the mapped address is
the same for each consecutive connection, static NAT allows bidirectional connection initiation, both to and
from the host (if an access rule exists that allows it). With dynamic NAT and PAT, on the other hand, each
host uses a different address or port for each subsequent translation, so bidirectional initiation is not supported.
The following figure shows a typical static NAT scenario. The translation is always active so both real and
remote hosts can initiate connections.

1522
Static NAT with Port Translation
Figure 53: Static NAT
Note You can disable bidirectionality if desired.
Static NAT with Port Translation

Static NAT with port translation lets you specify a real and mapped protocol and port.
When you specify the port with static NAT, you can choose to map the port and/or the IP address to the same
value or to a different value.
The following figure shows a typical static NAT with port translation scenario showing both a port that is
mapped to itself and a port that is mapped to a different value; the IP address is mapped to a different value
in both cases. The translation is always active so both translated and remote hosts can initiate connections.
Figure 54: Typical Static NAT with Port Translation Scenario
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.

1523
One-to-Many Static NAT
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.
Static Interface NAT with Port Translation
You can configure static NAT to map a real address to an interface address/port combination. For example,
if you want to redirect Telnet access for the device's outside interface to an inside host, then you can map
the inside host IP address/port 23 to the outside interface address/port 23.
One-to-Many Static NAT

Typically, you configure static NAT with a one-to-one mapping. However, in some cases, you might want to
configure a single real address to several mapped addresses (one-to-many). When you configure one-to-many
static NAT, when the real host initiates traffic, it always uses the first mapped address. However, for traffic
initiated to the host, you can initiate traffic to any of the mapped addresses, and they will be untranslated to
the single real address.
The following figure shows a typical one-to-many static NAT scenario. Because initiation by the real host
always uses the first mapped address, the translation of real host IP/first mapped IP is technically the only
bidirectional translation.
Figure 55: One-to-Many Static NAT
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.

1524
Other Mapping Scenarios (Not Recommended)
Figure 56: One-to-Many Static NAT Example
Other Mapping Scenarios (Not Recommended)

NAT has the flexibility to allow any kind of static mapping scenario: one-to-one, one-to-many, but also
few-to-many, many-to-few, and many-to-one mappings. We recommend using only one-to-one or one-to-many
mappings. These other mapping options might result in unintended consequences.
Functionally, few-to-many is the same as one-to-many; but because the configuration is more complicated
and the actual mappings may not be obvious at a glance, we recommend creating a one-to-many configuration
for each real address that requires it. For example, for a few-to-many scenario, the few real addresses are
mapped to the many mapped addresses in order (A to 1, B to 2, C to 3). When all real addresses are mapped,
the next mapped address is mapped to the first real address, and so on until all mapped addresses are mapped
(A to 4, B to 5, C to 6). This results in multiple mapped addresses for each real address. Just like a one-to-many
configuration, only the first mappings are bidirectional; subsequent mappings allow traffic to be initiated to
the real host, but all traffic from the real host uses only the first mapped address for the source.
The following figure shows a typical few-to-many static NAT scenario.

1525
Configure Static Auto NAT
Figure 57: Few-to-Many Static NAT
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).
The following figure shows a typical many-to-few static NAT scenario.

Figure 58: Many-to-Few Static NAT
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.

Use static auto NAT rules to translate addresses to different IP addresses that are routable on the destination
network. You can also do port translation with the static NAT rule.
Before you begin

requirements:

1526
• Translated Source—You have the following options to specify the translated address:
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.
Procedure


interfaces.

• 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.
• (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.

1527
Configure Static Manual NAT

DNS Queries and Responses Using NAT, on page 1583. This option is not available if you are doing port
translation.
• 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.


Use static manual NAT rules when auto NAT does not meet your needs. For example, if you want to do
different translations based on the destination. Static NAT translates addresses to different IP addresses that
are routable on the destination network. You can also do port translation with the static NAT rule.
Before you begin

• Translated Source—You have the following options to specify the translated address:
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, range, or subnets. 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.
configuring a static translation for those addresses in the rule. If you want to configure destination static

1528
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.
Procedure

• Type—Select Static. This setting only applies to the source address. If you define a translation for the
destination address, the translation is always static.

interfaces.

1529
for it.
• 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.
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.
• 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.

DNS Queries and Responses Using NAT, on page 1583. This option is not available if you are doing port
translation.
• 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.

1530
Identity NAT
• Unidirectional—Select this option to prevent the destination addresses from initiating traffic to the
source addresses. The unidirectional option is mainly useful for testing purposes and might not work
with all protocols. For example, SIP requires protocol inspection to translate SIP headers using NAT,
but this will not occur if you make the translation unidirectional.

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
The following topics explain how to configure identity NAT.
Configure Identity Auto NAT

Use static identity auto NAT rules to prevent the translation of an address. That is, to translate the address to
itself.
Before you begin

requirements:
• Translated Source—A network object or group with the exact same contents as the original source
object. You can use the same object.

1531
Configure Identity Auto NAT
Procedure


interfaces.

• Translated Source—The same object as the original source. Optionally, you can select a different object
that has the exact same contents.
Do not configure the Original Port and Translated Port options for identity NAT.

• Translate DNS replies that match this rule—Do not configure this option for identity NAT.
• IPv6—Do not configure this option for identity NAT.
• Net to Net Mapping—Do not configure this option for identity NAT.
• Perform Route Lookup for Destination Interface— 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.


1532
Configure Identity Manual NAT

Use static identity manual NAT rules when auto NAT does not meet your needs. For example, if you want
to do different translations based on the destination. Use static identity NAT rules to prevent the translation
of an address. That is, to translate the address to itself.
Before you begin

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.
Procedure

• Type—Select Static. This setting only applies to the source address. If you define a translation for the
destination address, the translation is always static.


1533
interfaces.
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.
for it.
You can select Interface Object to base the original destination on the source interface (which cannot
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.
• 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.

• Translate DNS replies that match this rule—Do not configure this option for identity NAT.

1534
NAT Rule Properties for Firepower Threat Defense
• Perform Route Lookup for Destination Interface— 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—Select this option to prevent the destination addresses from initiating traffic to the
source addresses. The unidirectional option is mainly useful for testing purposes and might not work
with all protocols. For example, SIP requires protocol inspection to translate SIP headers using NAT,
but this will not occur if you make the translation unidirectional.

NAT Rule Properties for Firepower Threat Defense

Use Network Address Translation (NAT) rules to translate IP addresses to other IP addresses. You would
typically use NAT rules to convert private addresses to publically routable addresses. The translation can be
from one address to another, or you can use Port Address Translation (PAT) to translate many addresses to
one or a few addresses, using port numbers to distinguish among the source addresses.
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 1493.
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.

1535
Interface Objects NAT Properties
Description (Optional. Manual NAT only.)

A description of the purpose of the rule.
The following topics describe the tabs for the NAT rules properties.
Interface Objects NAT Properties

Interface objects (security zones or interface groups) define the interfaces to which a NAT rule applies. In
routed mode, you can use the default "any" for both source and destination to apply to all interfaces of all
assigned devices. However, you typically want to select specific source and destination interfaces.
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.
Translation Properties for Auto NAT

Use the options on Translation to define the source addresses and the mapped translated addresses. The
following properties apply to auto NAT only.
Original Source (Always required.)
The network object that contains the addresses you are translating. This must be a network object (not
a group), and it can be a host, range, or subnet.
You cannot create auto NAT rules for the system-defined any-ipv4 or any-ipv6 objects.
Translated Source (Usually required.)
The mapped addresses, the ones to which you are translating. What you select here depends on the type
of translation rule you are defining.
• Dynamic NAT—The network object or group that contains the mapped addresses. This can be a
network object or group, but it cannot include a subnet. The group cannot contain both IPv4 and
IPv6 addresses; it must contain one type only. If a group contains both ranges and host IP addresses,
then the ranges are used for dynamic NAT, and then the host IP addresses are used as a PAT fallback.
• Dynamic PAT—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. Do not configure a PAT pool.

1536
Translation Properties for Manual NAT
• To use a single address other than the destination interface address, select the host network
object you created for this purpose. Do not configure a PAT pool.
• To use a PAT pool, leave Translated Source empty. Select the PAT pool object on PAT Pool.
• Static NAT—One of the following:

• To use a set group of addresses, select Address and the network object or group that contains
the mapped addresses. The object or group can contain hosts, ranges, or subnets. 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 the Advanced
tab. This configures static interface NAT with port translation: the source address/port is
translated to the interface's address and the same port number.
• Identity NAT—The same object as the original source. Optionally, you can select a different object
Original Port, Translated Port (Static NAT only.)

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. Do not configure
these options for identity NAT.
Translation Properties for Manual NAT

Use the options on Translation to define the source addresses and the mapped translated addresses. The
following properties apply to manual NAT only. All are optional except as indicated.
Original Source (Always required.)
The network object or group that contains the addresses you are translating. This can be a network object
or group, and it can contain a host, range, or subnet. If you want to translate all original source traffic,
you can specify Any in the rule.
Translated Source (Usually required.)
The mapped addresses, the ones to which you are translating. What you select here depends on the type
of translation rule you are defining.
• Dynamic NAT—The network object or group that contains the mapped addresses. This can be a
network object or group, but it cannot include a subnet. The group cannot contain both IPv4 and
IPv6 addresses; it must contain one type only. If a group contains both ranges and host IP addresses,
then the ranges are used for dynamic NAT, and then the host IP addresses are used as a PAT fallback.
• Dynamic PAT—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. Do not configure a PAT pool.
• To use a single address other than the destination interface address, select the host network
object you created for this purpose. Do not configure a PAT pool.

1537
PAT Pool NAT Properties
• To use a PAT pool, leave Translated Source empty. Select the PAT pool object on PAT Pool.
• Static NAT—One of the following:

• To use a set group of addresses, select Address and the network object or group that contains
the mapped addresses. The object or group can contain hosts, ranges, or subnets. 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 the Advanced
tab. This configures static interface NAT with port translation: the source address/port is
translated to the interface's address and the same port number.
• Identity NAT—The same object as the original source. Optionally, you can select a different object
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.
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.
PAT Pool NAT Properties

When you configure dynamic NAT, you can define a pool of addresses to use for Port Address Translation
using the properties on the PAT Pool tab.
Enable PAT Pool
Select this option to configure a pool of addresses for PAT.

1538
Advanced NAT Properties
PAT
The addresses to use for the PAT pool, one of the following:
• Address—The object that defines the PAT pool addresses, either a network object that includes a
range, or a network object group that contains hosts, ranges, or both. You cannot include subnets.
The group cannot contain both IPv4 and IPv6 addresses; it must contain one type only.
• Destination Interface IP—Indicates that you want to use the destination interface as the PAT
address. For this option, you must select a specific Destination Interface Object; you cannot use
Any as the destination interface. This is another way to implement interface PAT.
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.
Flat Port Range; Include Reserved Ports
To use the 1024 to 65535 port range as a single flat range when allocating TCP/UDP ports. (Pre-6.7)
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. For FTD devices running version 6.7 or higher,
the flat port range is always configured, whether you select the option or not. You can still select the
Include Reserved Ports option for these systems, and that setting is honored.
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.
Advanced NAT Properties

When you configure NAT, you can configure properties that provide specialized services in the Advanced
options. All of these properties are optional: configure them only if you need the service.

1539
Translating IPv6 Networks
Translate DNS replies that match this rule

Whether to translate the IP address in DNS replies. For DNS replies traversing from a mapped interface
to a real interface, the Address (the IPv4 A or IPv6 AAAA) record is rewritten 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
1583. This option is not available if you are doing port translation in a static NAT rule.
Fallthrough to Interface PAT (Destination Interface) (Dynamic NAT only.)
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. You cannot select this option if you already configured interface PAT as the
translated address. You also cannot select the option if you configure a PAT pool.
IPv6
Whether to use the IPv6 address of the destination interface for interface PAT.
Net to Net Mapping (Static NAT only.)
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 (Static NAT only.)
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.
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. The
unidirectional option is mainly useful for testing purposes and might not work with all protocols. For
example, SIP requires protocol inspection to translate SIP headers using NAT, but this will not occur if
you make the translation unidirectional.
Translating IPv6 Networks

In cases where you need to pass traffic between IPv6-only and IPv4-only networks, you need to use NAT to
convert between the address types. Even with two IPv6 networks, you might want to hide internal addresses
from the outside network.
You can use the following translation types with IPv6 networks:

1540
NAT64/46: Translating IPv6 Addresses to IPv4
• NAT64, NAT46—Translates IPv6 packets into IPv4 and vice versa. You need to define two policies,
one for the IPv6 to IPv4 translation, and one for the IPv4 to IPv6 translation. 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.
Note NAT46 supports static mappings only.
• 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.
NAT64/46: Translating IPv6 Addresses to IPv4

When traffic goes from an IPv6 network to an IPv4-only network, you need to convert the IPv6 address to
IPv4, and return traffic from IPv4 to IPv6. You need to define two address pools, an IPv4 address pool to
bind IPv6 addresses in the IPv4 network, and an IPv6 address pool to bind IPv4 addresses in the IPv6 network.
• The IPv4 address pool for the NAT64 rule is normally small and typically might not have enough addresses
to map one-to-one with the IPv6 client addresses. Dynamic PAT might more easily meet the possible
large number of IPv6 client addresses compared to dynamic or static NAT.
• 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.
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet

Following is a straight-forward example where you have an inside IPv6-only network, and you want to convert
to IPv4 for traffic sent to the Internet. This example assumes you do not need DNS translation, so you can
perform both the NAT64 and NAT46 translations in a single manual NAT rule.

1541
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.
Procedure
Step 1 Create the network object that defines the inside IPv6 network.
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.

1542
b) Click Add Rule.
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

• Original Source = inside_v6 network object.
• Translated Source = Destination Interface IP.
• Original Destination = inside_v6 network object.
• Translated Destination = any-ipv4 network object.
f) Click OK.

1543
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet and DNS Translation
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.
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.)

1544
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.)
The following procedure explains how to configure this example.
Before you begin

Ensure that you have interface objects (security zones or interface groups) that contain the interfaces for the
device. In this example, we will assume the interface objects are security zones named inside and outside.
To configure interface objects, select Objects > Object Management, then select Interface.
Procedure
Step 1 Create the network objects that define the inside IPv6 and outside IPv4 networks.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8::/96.

1545
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:
• Type = Static.
c) On Interface Objects, configure the following:

• Source Interface Objects = outside.
• Destination Interface Objects = inside.
d) On Translation, configure the following:

• Original Source = outside_v4_any network object.
• Translated Source > Address = inside_v6 network object.
e) On Advanced, select Translate DNS replies that match this rule.

1546
NAT66: Translating IPv6 Addresses to Different IPv6 Addresses
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.
NAT66: Translating IPv6 Addresses to Different IPv6 Addresses

When going from an IPv6 network to another IPv6 network, you can translate the addresses to different IPv6
addresses on the outside network. 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.
Because you are not translating between different address types, you need a single rule for NAT66 translations.
You can easily model these rules using auto NAT. However, if you do not want to allow returning traffic,
you can make the static NAT rule unidirectional using manual NAT only.
NAT66 Example, Static Translation between Networks

You can configure a static translation between IPv6 address pools using auto NAT. The following example
explains how to convert inside addresses on the 2001:db8:122:2091::/96 network to outside addresses on the
2001:db8:122:2999::/96 network.

1547
Before you begin

Procedure
Step 1 Create the network objects that define the inside IPv6 and outside IPv6 NAT networks.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8:122:2091::/96.

1548
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.
b) Click Add Rule.
• Type = Static.

1549
NAT66 Example, Simple IPv6 Interface PAT


• Translated Source > Address = outside_nat_v6 network object.
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.

A simple approach for implementing NAT66 is to dynamically assign internal addresses to different ports on
the outside interface IPv6 address.
When you configure an interface PAT rule for NAT66, all the global addresses that are configured on that
interface are used for PAT mapping. Link-local or site-local addresses for the interface are not used for PAT.

1550
Before you begin

Procedure
Step 1 Create the network object that defines the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8:122:2091::/96.

1551
d) Click Save.
Step 2 Configure the dynamic PAT rule for the inside IPv6 network.
b) Click Add Rule.
• Type = Dynamic.


• Translated Source = Destination Interface IP.
f) On tAdvanced, select IPv6, which indicates that the IPv6 address of the destination interface should be
used.

1552
Monitoring NAT
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.

1553
Examples for NAT
Examples for NAT

The following topics provide examples for configuring NAT on Threat Defense devices.
Providing Access to an Inside Web Server (Static Auto NAT)

The following example performs static NAT for an inside web server. The real address is on a private network,
so a public address is required. Static NAT is necessary so hosts can initiate traffic to the web server at a fixed
address.
Figure 60: Static NAT for an Inside Web Server
Before you begin

device that protects the web server. In this example, we will assume the interface objects are security zones
named inside and outside. To configure interface objects, select Objects > Object Management, then select
Interface.
Procedure
Step 1 Create the network objects that define the server’s private and public host addresses.
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.

1554
Providing Access to an Inside Web Server (Static Auto NAT)
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.
b) Click Add Rule.

1555
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server
• Type = Static.


• Original Source = WebServerPrivate network object.
• Translated Source > Address= WebServerPublic network object.
f) Click Save.
Step 3 Click Save on the NAT rule page.
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.

1556
Figure 61: Dynamic NAT for Inside, Static NAT for Outside Web Server
Before you begin

Interface.
Procedure
Step 1 Create a network object for the dynamic NAT pool to which you want to translate the inside addresses.
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.

1557
d) Click Save.
Step 2 Create a network object for the inside network.
b) Name the network object (for example, MyInsNet) and enter the network address 10.1.2.0/24.
c) Click Save.
Step 3 Create a network object for the outside web server.
b) Name the network object (for example, MyWebServer) and enter the host address 209.165.201.12.

1558
c) Click Save.
Step 4 Create a network object for the translated web server address.
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.
b) Click Add Rule.

1559
• Type = Dynamic.


• Original Source = myInsNet network object.
• Translated Source > Address= myNATpool network group.
f) Click Save.
Step 6 Configure static NAT for the web server.
a) Click Add Rule.
• Type = Static.

• Source Interface Objects = outside.
• Destination Interface Objects = inside.

1560
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT, One-to-Many)

• Original Source = myWebServer network object.
• Translated Source > Address= TransWebServer network object.
e) Click Save.
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.

1561
Figure 62: Static NAT with One-to-Many for an Inside Load Balancer
Before you begin

Interface.
Procedure
Step 1 Create a network object for the addresses to which you want to map the load balancer.
c) Define the addresses.
Name the network object (for example, myPublicIPs) and enter the network range
209.165.201.3-209.165.201.5.

1562
d) Click Save.
Step 2 Create a network object for the load balancer.
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.
b) Click Add Rule.
• Type = Static.


1563
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation)
• Original Source = myLBHost network object.

• Translated Source > Address= myPublicIPs network group.
f) Click Save.
Single Address for FTP, HTTP, and SMTP (Static Auto

NAT-with-Port-Translation)
The following static NAT-with-port-translation example provides a single address for remote users to access
FTP, HTTP, and SMTP. These servers are actually different devices on the real network, but for each server,
you can specify static NAT-with-port-translation rules that use the same mapped IP address, but different
ports.

1564
Figure 63: Static NAT-with-Port-Translation
Before you begin

device that protects the servers. In this example, we will assume the interface objects are security zones named
inside and outside. To configure interface objects, select Objects > Object Management, then select Interface.
Procedure
Step 1 Create a network object for the FTP server.

c) Name the network object (for example, FTPserver), and enter the real IP address for the FTP server,
10.1.2.27.

1565
d) Click Save.
Step 2 Create a network object for the HTTP server.
b) Name the network object (for example, HTTPserver), enter the host address 10.1.2.28.
c) Click Save.
Step 3 Create a network object for the SMTP server.
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.
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.
b) Click Add Rule.

1566
• Type = Static.


• Original Source = FTPserver network object.
• Translated Source > Address= ServerPublicIP network object.
• Original Port > TCP = 21.
• Translated Port = 21.
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.
• Type = Static.

1567


• Original Source = HTTPserver network object.
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.
• Type = Static.


1568
Different Translation Depending on the Destination (Dynamic Manual PAT)

• Original Source = SMTPserver network object.
e) Click Save.

The following figure shows a host on the 10.1.2.0/24 network accessing two different servers. When the host
accesses the server at 209.165.201.11, the real address is translated to 209.165.202.129:port. When the host
accesses the server at 209.165.200.225, the real address is translated to 209.165.202.130:port.

1569
Figure 64: Manual NAT with Different Destination Addresses
Before you begin

inside and dmz. To configure interface objects, select Objects > Object Management, then select Interface.
Procedure

c) Name the network object (for example, myInsideNetwork), and enter the real network address, 10.1.2.0/24.
d) Click Save.
Step 2 Create a network object for the DMZ network 1.

1570
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.
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.
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.

1571

c) Click Save.
Step 6 Configure dynamic manual PAT for DMZ network 1.
b) Click Add Rule.
• Type = Dynamic.

• Destination Interface Objects = dmz.

• Original Source = myInsideNetwork network object.
• Translated Source > Address= PATaddress1 network object.
• Original Destination > Address = DMZnetwork1 network object.
• Translated Destination = DMZnetwork1 network object.
Note Because you do not want to translate the destination address, you need to configure identity
NAT for it by specifying the same address for the original and translated destination
addresses. Leave all of the port fields blank.

1572
f) Click Save.
Step 7 Configure dynamic manual PAT for DMZ network 2.
a) Click Add Rule.
• Type = Dynamic.


• Original Destination > Address = DMZnetwork2 network object.
• Translated Destination = DMZnetwork2 network object.

1573
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT)
e) Click Save.
Different Translation Depending on the Destination Address and Port (Dynamic

Manual PAT)
The following figure shows the use of source and destination ports. The host on the 10.1.2.0/24 network
accesses a single host for both web services and Telnet services. When the host accesses the server for Telnet
services, the real address is translated to 209.165.202.129:port. When the host accesses the same server for
web services, the real address is translated to 209.165.202.130:port.

1574
Figure 65: Manual NAT with Different Destination Ports
Before you begin

inside and dmz. To configure interface objects, select Objects > Object Management, then select Interface.
Procedure

c) Name the network object (for example, myInsideNetwork) and enter the real network address, 10.1.2.0/24.
d) Click Save.
Step 2 Create a network object for the Telnet/Web server.

1575
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.
c) Click Save.
Step 4 Create a network object for the PAT address when using HTTP.
c) Click Save.
Step 5 Configure dynamic manual PAT for Telnet access.
b) Click Add Rule.
• Type = Dynamic.

1576


• Original Destination > Address = TelnetWebServer network object.
• Translated Destination = TelnetWebServer network object.
• Original Destination Port = TELNET port object (system-defined).
• Translated Destination Port = TELNET port object (system-defined).
Note Because you do not want to translate the destination address or port, you need to configure
identity NAT for them by specifying the same address for the original and translated
destination addresses, and the same port for the original and translated port.
f) Click Save.
Step 6 Configure dynamic manual PAT for web access.
a) Click Add Rule.

1577

• Type = Dynamic.


• Original Destination > Address = TelnetWebServer network object.
• Translated Destination = TelnetWebServer network object.
• Original Destination Port = HTTP port object (system-defined).
• Translated Destination Port = HTTP port object (system-defined).
e) Click Save.

1578
NAT and Site-to-Site VPN

The following figure shows a site-to-site tunnel connecting the Boulder and San Jose offices. For traffic that
you want to go to the Internet (for example from 10.1.1.6 in Boulder to www.example.com), you need a public
IP address provided by NAT to access the Internet. The below example uses interface PAT rules. However,
for traffic that you want to go over the VPN tunnel (for example from 10.1.1.6 in Boulder to 10.2.2.78 in San
Jose), you do not want to perform NAT; you need to exempt that traffic by creating an identity NAT rule.
Identity NAT simply translates an address to the same address.
Figure 66: Interface PAT and Identity NAT for Site-to-Site VPN
The following example explains the configuration for Firewall1 (Boulder).
Before you begin

devices in the VPN. In this example, we will assume the interface objects are security zones named
inside-boulder and outside-boulder for the Firewall1 (Boulder) interfaces. To configure interface objects,
select Objects > Object Management, then select Interfaces.
Procedure
Step 1 Create the objects to define the various networks.

c) Identify the Boulder inside network.
Name the network object (for example, boulder-network) and enter the network address, 10.1.1.0/24.

1579
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).
b) Click Add Rule.

1580
• Type = Static.

• Source Interface Objects = inside-boulder.
• Destination Interface Objects = outside-boulder.

• Original Source = boulder-network object.
• Translated Source > Address = boulder-network object.
• Original Destination > Address = sanjose-network object.
• Translated Destination = sanjose-network object.
Note Because you do not want to translate the destination address, you need to configure identity
NAT for it by specifying the same address for the original and translated destination
addresses. Leave all of the port fields blank. This rule configures identity NAT for both
source and destination.
f) On Advanced, select Do not proxy ARP on Destination interface.

1581
g) Click Save.
Step 3 Configure manual dynamic interface PAT when going to the Internet for the inside Boulder network on
Firewall1 (Boulder).
a) Click Add Rule.
• Type = Dynamic.
• Insert Rule = any position after the first rule. Because this rule will apply to any destination address,
the rule that use

FPMC Config Guide v70

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FPMC Config Guide v70

Uploaded by

Copyright:

Available Formats

Firepower Management Center Configuration Guide, Version 7.

CHAPTER 1 Getting Started With Firepower 1

Quick Start: Basic Setup 2

Firepower Management Center Configuration Guide, Version 7.0

PART I Your User Account 27

CHAPTER 2 Logging into the Firepower System 29

Firepower System User Accounts 29

CHAPTER 3 Specifying User Preferences 43

User Preferences Introduction 43

Firepower Management Center Configuration Guide, Version 7.0

CHAPTER 4 User Accounts for FMC 53

Configure an FMC Service Provider Application for Okta 82

Firepower Management Center Configuration Guide, Version 7.0

Configure the FMC for OneLogin SSO 95

CHAPTER 5 User Accounts for Devices 135

About User Accounts for Devices 135

Firepower Management Center Configuration Guide, Version 7.0

Internal and External Users 135

PART II Firepower System Management 155

CHAPTER 6 Licensing the Firepower System 157

About Firepower Licenses 157

Firepower Management Center Configuration Guide, Version 7.0

URL Filtering Licenses for Firepower Threat Defense Devices 168

Firepower Management Center Configuration Guide, Version 7.0

Troubleshoot FTD Licensing 197

Firepower Management Center Configuration Guide, Version 7.0

History for Licensing 228

CHAPTER 7 System Updates 231

About System Updates 231

CHAPTER 8 Backup and Restore 257

About Backup and Restore 257

Firepower Management Center Configuration Guide, Version 7.0

Best Practices for Backup and Restore 261

Restore FTD from Backup: Firepower 4100/9300 Chassis 276

CHAPTER 9 Configuration Import and Export 287

About Configuration Import/Export 287

CHAPTER 10 Task Scheduling 293

About Task Scheduling 293

Firepower Management Center Configuration Guide, Version 7.0

Automating Policy Deployment 298

CHAPTER 11 Data Storage 315

Data Stored on the FMC 315

CHAPTER 12 Firepower Management Center High Availability 321

About Firepower Management Center High Availability 321

Firepower Management Center Configuration Guide, Version 7.0

AMP Cloud Connections and Malware Information 322

CHAPTER 13 Device Management Basics 341

Firepower Management Center Configuration Guide, Version 7.0

About Device Management 341

Firepower Management Center Configuration Guide, Version 7.0

Change the Manager for the Device 390

PART III System Monitoring and Troubleshooting 401

CHAPTER 14 Dashboards 403

About Dashboards 403

Firepower Management Center Configuration Guide, Version 7.0

The Product Updates Widget 415

CHAPTER 15 Health Monitoring 425

Requirements and Prerequisites for Health Monitoring 425

Firepower Management Center Configuration Guide, Version 7.0

Editing Health Monitor Alerts 444

CHAPTER 16 Monitoring the System 467

CHAPTER 17 Auditing the System 477

Firepower Management Center Configuration Guide, Version 7.0